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.
2015-09-28


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
2015-11-28
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 :
5.8.35.241
202023 | 5.8.35.0/24 | LLHOST | EU | llhost-inc.com | LLHost Inc

Spam Module C&C 2015-11-28 :

5.8.32.10 
5.8.32.8
5.8.32.52
5.8.34.20
5.8.32.53
5.8.32.56
202023 | 5.8.32.0/24 | LLHOST | EU | zanufact.com | 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

Security Weekly #442 – Interview with Ferruh Mavituna

Interview with Ferruh Mavituna

Security Weekly brings back Ferruh Mavituna to discuss SLDC and writing vulnerable command injection in PHP. For a full list of topics discussed, visit our wiki: http://wiki.securityweekly.com/wiki/index.php/Episode442#Guest_Interview:_Ferruh_Mavituna_-_6:05PM-6:45PM

 

Failed Windows 3.1 and Hacking BackSecurity news this week we talk about the latest iThing, this one brews your coffee. Find out why its a bad idea to run Windows 3.1 in your environment, or Windows NT. Paul goes back in time, talking about OpenVMS.

http://wiki.securityweekly.com/wiki/index.php/Episode442#Stories_of_the_Week_-_7:00PM-8:00PM

 

Security Weekly Web Site: http://securityweekly.com

Hack Naked Gear: http://shop.securityweekly.com

Follow us on Twitter: @securityweekly

Hack Naked TV – November 20, 2015

Welcome to another episode of Hack Naked TV recorded November 20th 2015. Today Beau talks Bitlocker bypass, Gmail address spoofing and more. For a full list of stories covered, visit the wiki here: http://wiki.securityweekly.com/wiki/index.php/Hack_Naked_TV_November_20_2015#Beau.27s_Stories

Security Weekly Web Site: http://securityweekly.com

Hack Naked Gear: http://shop.securityweekly.com

Follow us on Twitter: @securityweekly

Hack Naked TV – November 19, 2015

Welcome to another episode of Hack Naked TV recorded November 19th 2015. Today Aaron talks about encrypted communications in the Paris terrorist attacks, Google security news, Comcast password resets, and the Well Fargo Cybersecurity Survey.

For a full list of stories, visit our wiki here: http://wiki.securityweekly.com/wiki/index.php/Hack_Naked_TV_November_19_2015#Aaron.27s_Stories

Security Weekly Web Site: http://securityweekly.com

Hack Naked Gear: http://shop.securityweekly.com

Follow us on Twitter: @securityweekly

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
Session 1 security: ENCRYPTED BUT *NOT* VALIDATED
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.

Authentication

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!

Challenges

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

Security Weekly #441 – Interview with Marton Linvy & Barton Miller from SWAMP

Interview with Miron Livny and Barton Miller

This week, we interview Miron Livny and Barton Miller of SWAMP. SWAMP simultaneously alleviates the costs, maintenance and licensing burdens of tools, while also eliminating the need to learn numerous tool interfaces. You can read more about SWAMP here: https://continuousassurance.org/

 

IoT Security In Alarm Clocks

Security news this week features the unmasking of TOR users, an alarm clock that slaps you around and more. For a full list of stories, visit our wiki: http://wiki.securityweekly.com/wiki/index.php/Episode441#Stories_of_the_Week_-_7:00PM-8:00PM

Security Weekly Web Site: http://securityweekly.com

Hack Naked Gear: http://shop.securityweekly.com

Follow us on Twitter: @securityweekly

Security Weekly #440 – Interview with Michael Bazzell, Stories of the Week

Interview with Michael Bazzell

This week we interview Michael Bazzell author of "Open Source Intelligence Techniques", "Hiding from the Internet" and the technical advisor for TV hacker drama "Mr. Robot" on the USA network.

For a list of relevant links, visit our wiki: http://wiki.securityweekly.com/wiki/index.php/Episode440#Interview:_Michael_Bazzell

 

Security News - Canadian Encryption

This week, Paul and the crew discusses the million dollar bug bounty for iPhones and why it may be legal to hack your car. For a full list of stories talked about during the show, visit our wiki: http://wiki.securityweekly.com/wiki/index.php/Episode440#Stories_of_the_Week_-_7:00PM-8:00PM

Security Weekly Web Site: http://securityweekly.com

Hack Naked Gear: http://shop.securityweekly.com

Follow us on Twitter: @securityweekly

Hack Naked TV – November 9, 2015

Today Beau talks about vBulletin RCE, PageFair serving malware, and a million dollar bug bounty for iOS 9. For a full list of stories visit http://wiki.securityweekly.com/wiki/index.php/Hack_Naked_TV_November_9_2015#Beau.27s_Stories.

For a directory of all Hack Naked TV shows visit http://wiki.securityweekly.com/wiki/index.php/Hack_Naked_Show_Notes.

Security Weekly Web Site: http://securityweekly.com

Hack Naked Gear: http://shop.securityweekly.com

Follow Security Weekly on Twitter: @securityweekly

Follow Beau on Twitter: @dafthack