Monthly Archives: November 2015

Inside Jahoo (Otlard.A ?) – A spam Botnet

Trash and Mailbox by Bethesda Softworks

Otlard.A (or let's say at least the malware triggering 2806902 || ETPRO TROJAN Win32.Otlard.A C&C Checkin response )  is a Spam Botnet

I saw it loaded as a plugin in an instance of Andromeda

That Andromeda is being spread via :

  • Bedep build id 6005 and here 6007 from an Angler EK fed by Malvertising :

VirtualDonna group redirecting traffic to an Angler instance loading Bedep buildid 6007 in memory
Bedep 6007 loading Andromeda 55ead0e4010c7c1a601511286f879e33 before update task.

Note : Bedep 6007 was sometimes loading it with other payload
-2015-09-16 for : ec5d314fc392765d065ff16f21722008 with Trapwot (FakeAV) e600985d6797dec2f7388e86ae3e82ba and Pony a4f08c845cc8e2beae0d157a3624b686
-2015-09-29 for : 37898c10a350651add962831daa4fffa with Kovter ( 24143f110e7492c3d040b2ec0cdfa3d0 )

That Andromeda beaconing to dnswow .com enslaved >10k bots in a week :
Andromeda dnswow 2015-11-22

Andromeda dnswow 2015-11-27
Here the Otlard.A task in that Andromeda instance :
Task installing Otlard.A as a plugin to Andromeda

  • a Task in a Smokebot dropped by Nuclear Pack fed by Malvertising :
Malvertising > Nuclear Pack > Smokebot > Stealer, Ramnit, Htbot and Andromeda > Otlard.A
Smokebot : cde587187622d5f23e50b1f5b6c86969
Andromeda : b75f4834770fe64da63e42b8c90c6fcd
(out of topic Ramnit : 28ceafaef592986e4914bfa3f4c7f5c0 - It's being massively spread those days in many infection path. (Edit 2015-12-29 :  Htbot.B :  d0a14abe51a61c727420765f72de843a named ProxyBack by PaloAlto)

Now here is what the control panel of that plugin looks like :

Otlard.A panel :

Otlard.A - JahooManager - Main - 2015-09-27
Otlard.A - JahooManager - Servers - 2015-09-27
Otlard.A - JahooManager - Settings - 2015-09-27
Otlard.A - JahooManager - Campaigns - 2015-09-27
Otlard.A - JahooManager - Bot - 2015-09-27
that exe is : 2387fb927e6d9d6c027b4ba23d8c3073 and appears to be Andromeda

Otlard.A - JahooSender - Tasks - 2015-09-27

Otlard.A - JahooSender - Tasks - 2015-11-28

Otlard.A - JahooSender - Tasks - Done Task - 2015-09-27
Otlard.A - JahooSender - Domains - 2015-09-27
Otlard.A - JahooSender - Domains - 2015-11-28

Otlard.A - JahooSender - Messages - 2015-09-27
Otlard.A - JahooSender - Messages - 2015-11-28
Otlard.A - JahooSender - Messages - Edit a Message - 2015-11-28
Otlard.A - JahooSender - Messages - Edit a Message - 2015-11-28
Otlard.A - JahooSender - Messages - Edit a Message - 2015-11-28
Otlard.A - JahooSender - Headers - 2015-11-28
Otlard.A - JahooSender - Headers - Editing Header - 2015-11-28
Otlard.A - JahooSender - Headers - Editing Header - 2015-11-28
Otlard.A - JahooSender - Macross - 2015-11-28

Otlard.A - JahooSender - Macross - 2015-11-28

Otlard.A - JahooSender - Macross - Editing macross - 2015-11-28
Otlard.A - JahooSender  - Macross - Editing macross - 2015-11-28
Otlard.A - JahooSender - Macross - Editing macross - 2015-11-28
Otlard.A - JahooSender - Attach - 2015-11-28
Otlard.A - JahooSender - Attach - Attached image - 2015-11-28
Otlard.A - JahooSender - Rules - 2015-11-28
Otlard.A - JahooSender - Rules > Spam - 2015-11-28
Olard.A - JahooSender - Rules > User - 2015-11-28
Olard.A - Bases - Emails - 2015-11-28
Olard.A - Bases - Blacklist - 2015-11-28
Olard.A - Bases - Blacklist - Edit - 2015-11-28
Olard.A - Botnet - Main - 2015-09-27
Olard.A - Botnet - Main - 2015-11-28
Otlard.A - Botnet - Modules - 2015-11-28
Otlard.A - Botnet - Modules - Edit - 2015-11-28
Otlard.A - Incubator - Accounts - 2015-11-28
Otlard.A - Incubator - Settings - 2015-11-28
Note : registrator menu has disappeared in last version. 

Andromeda C&C 2015-11-28 :
202023 | | LLHOST | EU | | LLHost Inc

Spam Module C&C 2015-11-28 :
202023 | | LLHOST | EU | | LLHost Inc

Thanks : Brett StoneGross for helping me with decoding/understanding the network communications

Files :
All samples which hashes have been discussed here are in that zip.
Jahoo - socker.dll : 7d14c9edfd71d2b76dd18e3681fec798
( If you want to look into this, i can provide associated network traffic)

Read More :

Inside Andromeda Bot v2.06 Webpanel / AKA Gamarue - Botnet Control Panel 2012-07-02
Inside Pony 1.7 / Fareit C&C - Botnet Control Panel - 2012-06-27
Inside Smoke Bot - Botnet Control Panel - 2012-04-28

Post publication Reading :
ProxyBack Malware Turns User Systems Into Proxies Without Consent - 2015-12-23 - JeffWhite - PaloAlto

Why Cameron hates WhatsApp so much

It’s a well-known fact that UK’s Prime Minister David Cameron doesn’t care much about peoples’ privacy. Recently he has been driving the so called Snooper’s Charter that would give authorities expanded surveillance powers, which got additional fuel from the Paris attacks.

It is said that terrorists want to tear down the Western society and lifestyle. And Cameron definitively puts himself in the same camp with statements like this:

“In our country, do we want to allow a means of communication between people which we cannot read? No, we must not.”
David Cameron

Note that he didn’t say terrorists, he said people. Kudos for the honesty. It’s a fact that terrorist blend in with the rest of the population and any attempt to weaken their security affects all of us. And it should be a no-brainer that a nation where the government can listen in on everybody is bad, at least if you have read Orwell’s Nineteen Eighty-Four.

But why does WhatsApp occur over and over as an example of something that gives the snoops grey hair? It’s a mainstream instant messenger app that wasn’t built for security. There are also similar apps that focus on security and privacy, like Telegram, Signal and Wickr. Why isn’t Cameron raging about them?

The answer is both simple and very significant. But it may not be obvious at fist. Internet was by default insecure and you had to use tools to fix that. The pre-Snowden era was the golden age for agencies tapping into the Internet backbone. Everything was open and unencrypted, except the really interesting stuff. Encryption itself became a signal that someone was of interest, and the authorities could use other means to find out what that person was up to.

More and more encryption is being built in by default now when we, thanks to Snowden, know the real state of things. A secured connection between client and server is becoming the norm for communication services. And many services are deploying end-to-end encryption. That means that messages are secured and opened by the communicating devices, not by the servers. Stuff stored on the servers are thus also safe from snoops. So yes, people with Cameron’s mindset have a real problem here. Correctly implemented end-to-end encryption can be next to impossible to break.

But there’s still one important thing that tapping the wire can reveal. That’s what communication tool you are using, and this is the important point. WhatsApp is a mainstream messenger with security. Telegram, Signal and Wickr are security messengers used by only a small group people with special needs. Traffic from both WhatsApp and Signal, for example, are encrypted. But the fact that you are using Signal is the important point. You stick out, just like encryption-users before.

WhatsApp is the prime target of Cameron’s wrath mainly because it is showing us how security will be implemented in the future. We are quickly moving towards a net where security is built in. Everyone will get decent security by default and minding your security will not make you a suspect anymore. And that’s great! We all need protection in a world with escalating cyber criminality.

WhatsApp is by no means a perfect security solution. The implementation of end-to-end encryption started in late 2014 and is still far from complete. The handling of metadata about users and communication is not very secure. And there are tricks the wire-snoops can use to map peoples’ network of contacts. So check it out thoroughly before you start using it for really hot stuff. But they seem to be on the path to become something unique. Among the first communication solutions that are easy to use, popular and secure by default.

Apple’s iMessage is another example. So easy that many are using it without knowing it, when they think they are sending SMS-messages. But iMessage’s security is unfortunately not flawless either.


Safe surfing,


PS. Yes, weakening security IS a bad idea. An excellent example is the TSA luggage locks, that have a master key that *used to be* secret.


Image by Sam Azgor

POLL – Is it OK for security products to collect data from your device?

We have a dilemma, and maybe you want to help us. I have written a lot about privacy and the trust relationship between users and software vendors. Users must trust the vendor to not misuse data that the software handles, but they have very poor abilities to base that trust on any facts. The vendor’s reputation is usually the most tangible thing available.

Vendors can be split into two camps based on their business model. The providers of “free” services, like Facebook and Google, must collect comprehensive data about the users to be able to run targeted marketing. The other camp, where we at F-Secure are, sells products that you pay money for. This camp does not have the need to profile users, so the privacy-threats should be smaller. But is that the whole picture?

No, not really. Vendors of paid products do not have the need to profile users for marketing. But there is still a lot of data on customers’ devices that may be relevant. The devices’ technical configuration is of course relevant when prioritizing maintenance. And knowing what features actually are used helps plan future releases. And we in the security field have additional interests. The prevalence of both clean and malicious files is important, as well as patterns related to malicious attacks. Just to name a few things.

One of our primary goals is to guard your privacy. But we could on the other hand benefit from data on your device. Or to be precise, you could benefit from letting us use that data as it contributes to better protection overall. So that’s our dilemma. How to utilize this data in a way that won’t put your privacy in jeopardy? And how to maintain trust? How to convince you that data we collect really is used to improve your protection?

Our policy for this is outlined here, and the anti-malware product’s data transfer is documented in detail in this document. In short, we only upload data necessary to produce the service, we focus on technical data and won’t take personal data, we use hashing of the data when feasible and we anonymize data so we can’t tell whom it came from.

The trend is clearly towards lighter devices that rely more on cloud services. Our answer to that is Security Cloud. It enables devices to off-load tasks to the cloud and benefit from data collected from the whole community. But to keep up with the threats we must develop Security Cloud constantly. And that also means that we will need more info about what happens on your device.

That’s why I would like to check what your opinion about data upload is. How do you feel about Security Cloud using data from your device to improve the overall security for all users? Do you trust us when we say that we apply strict rules to the data upload to guard your privacy?



Safe surfing,


Image by


dnscat2: now with crypto!

Hey everybody,

Live from the SANS Pentest Summit, I'm excited to announce the latest beta release of dnscat2: 0.04! Besides some minor cleanups and UI improvements, there is one serious improvement: all dnscat2 sessions are now encrypted by default!

Read on for some user information, then some implementation details for those who are interested! For all the REALLY gory information, check out the protocol doc!

Tell me what's new!

By default, when you start a dnscat2 client, it now performs a key exchange with the server, and uses a derived session key to encrypt all traffic. This has the huge advantage that passive surveillance and IDS and such will no longer be able to see your traffic. But the disadvantage is that it's vulnerable to a man-in-the-middle attack - assuming somebody takes the time and effort to perform a man-in-the-middle attack against dnscat2, which would be awesome but seems unlikely. :)

By default, all connections are encrypted, and the server will refuse to allow cleartext connections. If you start the server with --security=open (or run set security=open), then the client decides the security level - including cleartext.

If you pass the server a --secret string (see below), then the server will require clients to authenticate using the same --secret value. That can be turned off by using --security=open or --security=encrypted (or the equivalent set commands).

Let's look at the man-in-the-middle protection...

Short authentication strings

First, by default, a short authentication string is displayed on both the client and the server. Short authentication strings, inspired by ZRTP and Silent Circle, are a visual way to tell if you're the victim of a man-in-the-middle attack.

Essentially, when a new connection is created, the user has to manually match the short authentication strings on the client and the server. If they're the same, then it's a legit connection. Here's what it looks like on the client:

Encrypted session established! For added security, please verify the server also displays this string:

Tort Hither Harold Motive Nuns Unwrap

And the server:

New window created: 1
For added security, please ensure the client displays the same string:

>> Tort Hither Harold Motive Nuns Unwrap

There are 256 different possible words, so six words gives 48 bits of protection. While a 48-bit key can eventually be bruteforced, in this case it has to be done in real time, which is exceedingly unlikely.


Alternatively, a pre-shared secret can be used instead of a short authentication string. When you start the server, you pass in a --secret value, such as --secret=pineapple. Clients with the same secret will create an authenticator string based on the password and the cryptographic keys, and send it to the server, encrypted, after the key exchange. Clients that use the wrong key will be summarily rejected.

Details on how this is implemented are below.

How stealthy is it?

To be perfectly honest: not completely.

The key exchange is pretty obvious. A 512-bit value has to be sent via DNS, and a 512-bit response has to come back. That's pretty big, and stands out.

After that, every packet has an unencrypted 40-bit (5-byte) header and an unencrypted 16-bit (2-byte) nonce. The header contains three bytes that don't really change, and the nonce is incremental. Any system that knows to look for dnscat2 will be able to find that.

It's conceivable that I could make this more stealthy, but anybody who's already trying to detect dnscat2 traffic will be able to update the signatures that they would have had to write anyway, so it becomes a cat-and-mouse game.

Of course, that doesn't stop people from patching things. :)

The plus side, however, is that none of your data leaks! And somebody would have to be specifically looking for dnscat2 traffic to recognize it.

What are the hidden costs?

Encrypted packets have 64 bits (8 bytes) of extra overhead: a 16-bit (two-byte) nonce and a 48-bit (six-byte) signature on each packet. Since DNS packets have between 200 and 250 bytes of payload space, that means we lose ~4% of our potential bandwidth.

Additionally, there's a key exchange packet and potentially an authentication packet. That's two extra roundtrips over a fairly slow protocol.

Other than that, not much changes, really. The encryption/decryption/signing/validation are super fast, and it uses a stream cipher so the length of the messages don't change.

How do I turn it off?

The server always supports crypto; if you don't WANT crypto, you'll have to manually hack the server or use a version of dnscat2 server <=0.03. But you'll have to manually turn off encryption in the client; otherwise, the connection fail.

Speaking of turning off encryption in the client: you can compile without encryption by using make nocrypto. You can also disable encryption at runtime with dnscat2 --no-encryption. On Visual Studio, you'll have to define "NO_ENCRYPTION". Note that the server, by default, won't allow either of those to connect unless you start it with --security=open.

Give me some technical details!

Your best bet if you're REALLY curious is to check out the protocol doc, where I document the protocol in full.

But I'll summarize it here. :)

The client starts a session by initiating a key exchange with the server. Both sides generate a random, 256-bit private key, then derive a public key using Elliptic Curve Diffie Hellman (ECDH). The client sends the public key to the server, the server sends a public key to the client, and they both agree on a shared secret.

That shared secret is hashed with a number of different values to derive purpose-specific keys - the client encryption key, the server encryption key, the client signing key, the server signing key, etc.

Once the keys are agreed upon, all packets are encrypted and signed. The encryption is salsa20 and uses one of the derived keys as well as an incremental nonce. After being encrypted, the encrypted data, the nonce, and the packet header are signed using SHA3, but truncated to 48 bits (6 bytes). 48 bits isn't very long for a signature, but space is at an extreme premium and for most attacks it would have to be broken in real time.

As an aside: I really wanted to encrypt the header instead of just signing it, but because of protocol limitations, that's simply not possible (because I have no way of knowing which packets belong to which session, the session_id has to be plaintext).

Immediately after the key exchange, the client optionally sends an authenticator over the encrypted session. The authenticator is based on a pre-shared secret (passed on the commandline) that the client and server pre-arrange in some way. That secret is hashed with both public keys and the secret (derived) key, as well as a different static string on the client and server. The client sends their authenticator to the server, and the server sends their authenticator to the client. In that way, both sides verify each other without revealing anything.

If the client doesn't send the authenticator, then a short authentication string is generated. It's based on a very similar hash to the authenticator, except without the pre-shared secret. The first 6 bytes are converted into words using a list of 256 English words, and are displayed on the screen. It's up to the user to verify them.

Because the nonce is only 16 bits, only 65536 roundtrips can be performed before running out. As such, the client may, at its own discretion (but before running out), initiate a new key exchange. It's identical to the original key exchange, except that it happens in a signed and encrypted packet. After the renegotiation is finished, both the client and server switch their nonce values back to 0 and stop accepting packets with the old keys.

And... that's about it! Keys are exchanged, an authenticator is sent or a short authentication string is displayed, all messages are signed and encrypted, and that's that!


A few of the challenges I had to work through...

  • Because DNS has no concept of connections/sessions, I had to expose more information that I wanted in the packets (and because it's extremely length-limited, I had to truncate signatures)
  • I had originally planned to use Curve25519 for the key exchange, but there's no Ruby implementation
  • Finding a C implementation of ECC that doesn't require libcrypto or libssl was really hard
  • Finding a working SHA3 implementation in Ruby was impossible! I filed bugs against the three more popular implementations and one of them actually took the time to fix it!
  • Dealing with DNS's gratuitous retransmissions and accidental drops was super painful and required some hackier code than I like to see in crypto (for example, an old key can still be used, even after a key exchange, until the new one is used successfully; the more secure alternative can't handle a dropped response packet, otherwise both peers would have different keys)

Shouts out

I just wanted to do a quick shout out to a few friends who really made this happen by giving me advice, encouragement, or just listening to me complaining.

So, in alphabetical order so nobody can claim I play favourites, I want to give mad propz to:

  • Alex Weber, who notably convinced me to use a proper key exchange protocol instead of just a static key (and who also wrote the Salsa20 implementation I used
  • Brandon Enright, who give me a ton of handy crypto advice
  • Eric Gershman, who convinced me to work on encryption in the first place, and who listened to my constant complaining about how much I hate implementing crypto

Yes, your PC is getting slower. But why?

I’m sure you know the feeling. You used to have a nice brand-new computer and everything loaded so quickly. It was a pleasure to use it. But now it is slowing down and you see more and more of the dreaded spinning hourglass, or some other animated mouse pointer. Yes, a computer is really like a marriage. Everything is so nice in the beginning, but friction is often building up over time. Both need some maintenance to avoid problems. 😉

You have to fix your marriage yourself, I’m not an expert in that field. But let’s take a closer look at the computer because it’s a lot easier to understand. First the three most common reasons for slowness.

  1. Your system is getting clogged up by junk. You have unnecessary programs installed and there is virtual garbage everywhere.
  2. Your system is just getting too old. You are running out of hardware capacity as you want to do more with the latest program versions.
  3. You are infected. Malware on the system is stealing your capacity.

I will in this article focus on the first point as it is by far the most common reason. But first a couple of words about the other reasons. Number 2 is pretty obvious. If your system is too old then you need to get a new computer. My only advice here is to consider if you really need a traditional PC or if a tablet could do the work. The mobile devices have a much more modern architecture, which improves security. Number 3 is also quite straightforward. If you suspect this, you just need to check out F-Secure Internet Security  or SAFE.

Ok, but now to the real beef. Your problem is most likely an messy system, but what to do? This problem is technically complex and there is probably a large number of smaller factors that all contribute to a significant slowdown. Now you have two options, do it yourself or get a cleaning tool. A lot can actually be done manually. Just Google for “speed up PC”, or something similar, and you have tons of instructions of varying relevance, quality and level of technical competence. Works well for nerds, but many don’t want to go there.

That’s why we made F-Secure Booster. I have been running this tool for a while on my computer, and it’s really a convenient way to keep the system in shape. You can clean a lot automatically just by a clicking a button. But Booster also has a fairly comprehensive set of optimizations that you can review and select one by one. So it’s easy to use, but can also keep the more technically savvy users occupied for a while. Quite a nice combination in my opinion.

So why not give F-Secure Booster a try right away? It may push the end-of-life of your PC forward by several years. And makes sure you get less gray hair.


Safe surfing,


PS. I wish there was a simple tool for revitalizing marriages too. And I leave it to you to come up with funny analogies between marriages and the problems #2 and #3. 😉


Image by

F-Secure Launches New Bug Bounty Program

Bruce Schneier talks about security as a process, because the work of securing systems is never complete. And in the spirit of this, F-Secure has launched a new Vulnerability Rewards program – or “bug bounty” as they’re sometimes called – to give everyone the opportunity to help F-Secure improve its products. Bug Bounties are one way companies can test the security of its products, and have been used by companies like Google, Facebook and Microsoft because it gives more people the opportunity to test products and contribute to their development.

“Our products all have a service component, because we work hard to maintain them,” says Jose Perez, a Senior Researcher at F-Secure Labs. ““We have to make sure they’re protecting users from the latest threats, but we also need to make sure that the applications themselves are airtight. So this program lets people explore the software built into the applications, and make a bit of money if they can point something out to us that needs to be improved to better protect our customers.”

The program will give people that find security vulnerabilities in selected F-Secure applications a reward ranging from €100 to €15 000. A security vulnerability, for the purposes of the program, is defined as:

“…an issue that causes a breach of confidentiality, integrity, or availability of the service or data, or applies to personal data (privately identifiable information) being stored or processed in a way that is not compliant with the current Finnish data protection legislation.”

So how can someone get started looking for security vulnerabilities in F-Secure’s products?

“Well, it’s kind of difficult for me to just make bug hunting sound easy,” laughs Perez. “But I would tell people to start by getting ahold of a guide to help them walk through the whole process. I hear that A Bug Hunter’s Diary: A Guided Tour Through the Wilds of Software Security is a pretty good one, and it’s as good a place to start as any.”

Anyone interested in taking part in the bug bounty should check the program’s rules and disclosure policies listed on the program’s web page.

[ Image by Lauren Hammond | Flickr ]