Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2015-04-21 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Dridex Redirecting to Malicious Dropbox Hosted File Via Google

Published: 2015-04-21
Last Updated: 2015-04-23 02:50:25 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

Thanks to Wayne for sending us in the latest Dridex sample. He observed them arriving this morning around 8am ET. According to Wayne, this malware may use Google Analytics to count how many people opened the file, but I haven't confirmed that. Google redirects are however used to obscure the destination.

Checking my own inbox, I found a couple of the messages in my spam folder. Here is an example I received:

The link is kind of interesting. It leads to Google, but Google will redirect you to the malicious file which is hosted on dropbox. At least the file above was still available.

 

The link:

hxxps://www.google.com/url? q=https://www.dropbox.com/s/ 0c5we7id7mgwk89/ACH transaction0336.doc?dl=1 &sa=D&sntz=1&usg=AFQjCNFvX9uqV7uVjP8NWYKa4xkImgXPBA

Google will show a note that the user was redirected, but the file will download right away. It will not open, and the user will have to open it an enable the Macro to execute.

Hashes of the Word document:

MD5: f12cfa3f42784769c1542155a4f9cde8
SHA1: 5a939df2692091c89b5a75db3bba990aae3b6d10

And a quick review with fellow handler Didier's oledump tool shows indeed a number of suspect macros.

$ ./oledump.py -p ./plugin_dridex.py ../ACH\ transaction0336.doc  -e
  1:       114 '\x01CompObj'
  2:      4096 '\x05DocumentSummaryInformation'
  3:      4096 '\x05SummaryInformation'
  4:     10927 '1Table'
  5:    136110 'Data'
  6:       666 'Macros/PROJECT'
  7:       161 'Macros/PROJECTwm'
  8: m     683 'Macros/VBA/Module1'
               Plugin: Dridex decoder
  9: m     683 'Macros/VBA/Module2'
               Plugin: Dridex decoder
 10: M    3592 'Macros/VBA/Module3'
               Plugin: Dridex decoder
 11: m     683 'Macros/VBA/Module4'
               Plugin: Dridex decoder
 12: M    2526 'Macros/VBA/Module5'
               Plugin: Dridex decoder
 13: M   10321 'Macros/VBA/ThisDocument'
               Plugin: Dridex decoder
 14:      5094 'Macros/VBA/_VBA_PROJECT'
 15:       649 'Macros/VBA/dir'
 16:      7220 'WordDocument'

Virustotal only shows 4 "hits" out of 57 AV tools tested for this binary

https://www.virustotal.com/en/file/efd9e8d6fe04bf8b7abcdd208c7f1b2b2fabf2ae09bce9775631047455cd533b/analysis/1429631351/

 

 

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
4 comment(s)

Logging Complete Requests in Apache 2.2 and 2.4

Published: 2015-04-21
Last Updated: 2015-04-21 15:15:57 UTC
by Johannes Ullrich (Version: 1)
1 comment(s)

Apache has an interesting option to log complete requests, including the body of POST requests. The method has come in handy for honeypots. For a normal server, the logging is likely excessive (other then for debug purposes), and I do not think sensitive data can be masked like it mod_security.

The complete request logging uses the "mod_dumpio" module, which was introduced in Apache 2.2. In Apache 2.2, all you need to do is to enable the module, and set the log level:

DumpIOInput On
DumpIOLogLevel debug

In Apache 2.4, the logging system got revamped, and you now specify the log level per module using the LogLevel directive:

DumpIOInput On
LogLevel dumpio:trace7

​The logs will end up in your error log, and look like:

[Tue Apr 21 15:08:40.894950 2015] [dumpio:trace7] [pid 15247] mod_dumpio.c(63): [client 188.138.17.205:48510] mod_dumpio:  dumpio_in (data-HEAP): 26 bytes
[Tue Apr 21 15:08:40.894980 2015] [dumpio:trace7] [pid 15247] mod_dumpio.c(103): [client 188.138.17.205:48510] mod_dumpio:  dumpio_in (data-HEAP): GET /robots.txt HTTP/1.1\r\n

You can filter a particular request by greping for the client IP and port:

grep '188.138.17.205:48510' error.log

To make things more readable, I use this shell script (for the above log from 188.138.17.205 and port 48510)

grep '188.138.17.205:48510' error.log | cut -f8- -d':' | egrep -v ' [0-9]+ bytes$' | grep -v '^$' | cut -c2- | sed 's/\\r\\n//'

The output:

GET /robots.txt HTTP/1.1
Host: [redacted]:8080
Accept-Encoding: identity

The same module can also be used to log all output, which may come in handy to debug errors on SSL servers, but I haven't had a need to use that function yet.

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
1 comment(s)
Diary Archives