Dridex Redirecting to Malicious Dropbox Hosted File Via Google
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/
Logging Complete Requests in Apache 2.2 and 2.4
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.
Comments