Malware Analysis - handling base64
I love work with information security. That’s a fact.:) I also really like to play with malware analysis, and from some time now, thats what I do for living :). And guess what I do in my free time??:) Yes, play with malware analysis too :).
I would like to share with you a situation that may occur when you are doing malware analysis.
I use pine to read some of my personal email, and last week I saved one spam that had something attached to it.
While analyzing the saved email, I saw that there was a file attached on it, that was base64 encoded.
The first sign it on the body:
------=_Part_75367_15338122.1181350292468
Content-Type: application/octet-stream; name="badfile.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="badfile.exe"
X-Attachment-Id: f_f2pdfmt5
...
Can you notice the:
Content-Transfer-Encoding: base64
Yes, that means that it is base64 encoded!:)
Now, how to handle it?
That’s what I want to share with you malware analysts enthusiastics today :)
As we can see with the GNU File utility, the saved-email.txt is a text file:
[lab3:~/mail# file saved-email.txt
saved-email.txt: ASCII text
I like perl, and it offers a really simple way to decode that file:
[lab3:~/mail# perl -MMIME::Base64 -e 'print decode_base64(join("", <>))' <saved-email.txt >badfile.exe.file
Done!
Now,did it work??
Easy, lets use the File utility again:
[lab3:~/mail# file badfile.exe.file
badfile.exe.file: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit
Done!:) Now it is just to go ahaed an analyze the file, but thats another history...;)
-------------------------------------------------------------------------------------------
Handlers on Duty: Pedro Bueno ( pbueno //&&// isc. sans. org)
I would like to share with you a situation that may occur when you are doing malware analysis.
I use pine to read some of my personal email, and last week I saved one spam that had something attached to it.
While analyzing the saved email, I saw that there was a file attached on it, that was base64 encoded.
The first sign it on the body:
------=_Part_75367_15338122.1181350292468
Content-Type: application/octet-stream; name="badfile.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="badfile.exe"
X-Attachment-Id: f_f2pdfmt5
...
Can you notice the:
Content-Transfer-Encoding: base64
Yes, that means that it is base64 encoded!:)
Now, how to handle it?
That’s what I want to share with you malware analysts enthusiastics today :)
As we can see with the GNU File utility, the saved-email.txt is a text file:
[lab3:~/mail# file saved-email.txt
saved-email.txt: ASCII text
I like perl, and it offers a really simple way to decode that file:
[lab3:~/mail# perl -MMIME::Base64 -e 'print decode_base64(join("", <>))' <saved-email.txt >badfile.exe.file
Done!
Now,did it work??
Easy, lets use the File utility again:
[lab3:~/mail# file badfile.exe.file
badfile.exe.file: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit
Done!:) Now it is just to go ahaed an analyze the file, but thats another history...;)
-------------------------------------------------------------------------------------------
Handlers on Duty: Pedro Bueno ( pbueno //&&// isc. sans. org)
Keywords:
0 comment(s)
Yahoo! Messenger exploits seen in the wild
Just three days after the PoCs for 2 Yahoo! Messenger vulnerabilities have been posted (http://isc.sans.org/diary.html?storyid=2943), we’ve been informed by Roger C. from the Malware-Test Lab about a site hosting exploits for the mentioned vulnerabilities.
The exploit is referenced the standard way – an iframe points to the web site hosting the exploit (n.88tw.net). The exploit has been pretty simply obfuscated. One thing that makes it easier to identify is the object creation – for some reason attackers left it outside of the obfuscated string so it is very easy to spot:
<object classid="clsid:DCE2F8B1-A520-11D4-8FD0-00D0B7730277" id='viewme'></object>
Practically the only difference from the published PoC is the objects name – in this case it is, as you can see above, “viewme”, while the object name in the originally published PoC was “target”.
The rest is very much the same, apart from the attached shellcode. The shellcode in the sample we analyzed downloaded another dropper (of course), and this second component wasn’t detected by any AV vendor on the VirusTotal site when we tested it (!!). This dropper downloaded further components, of which one was called 5in1.exe – we haven’t analyzed this yet but judging just by the file name, it doesn’t sound good.
Mitigation
As you are probably aware, Yahoo! provided a fix practically only couple of hours after the PoCs have been posted online (kudos to Yahoo! for this). If you are using Yahoo! Messenger you should upgrade as soon as possible. Alternatively, you can set the kill bits for the affected ActiveX controls, as we’ve posted in our original diary.
One thing that might help as well is the AV detection. Although the second stage dropper wasn’t detected by any AV vendor, the JavaScript that triggers the exploit was detected by couple of programs. As the names were generic (HEUR/Exploit.HTML, JS:Feebs-D, Heuristic.Exploit.HTML), my guess is that those that detected this properly got lucky (the Javascript used standard eval(unescape("”) method). In any case, every defense layer helps.
The exploit is referenced the standard way – an iframe points to the web site hosting the exploit (n.88tw.net). The exploit has been pretty simply obfuscated. One thing that makes it easier to identify is the object creation – for some reason attackers left it outside of the obfuscated string so it is very easy to spot:
<object classid="clsid:DCE2F8B1-A520-11D4-8FD0-00D0B7730277" id='viewme'></object>
Practically the only difference from the published PoC is the objects name – in this case it is, as you can see above, “viewme”, while the object name in the originally published PoC was “target”.
The rest is very much the same, apart from the attached shellcode. The shellcode in the sample we analyzed downloaded another dropper (of course), and this second component wasn’t detected by any AV vendor on the VirusTotal site when we tested it (!!). This dropper downloaded further components, of which one was called 5in1.exe – we haven’t analyzed this yet but judging just by the file name, it doesn’t sound good.
Mitigation
As you are probably aware, Yahoo! provided a fix practically only couple of hours after the PoCs have been posted online (kudos to Yahoo! for this). If you are using Yahoo! Messenger you should upgrade as soon as possible. Alternatively, you can set the kill bits for the affected ActiveX controls, as we’ve posted in our original diary.
One thing that might help as well is the AV detection. Although the second stage dropper wasn’t detected by any AV vendor, the JavaScript that triggers the exploit was detected by couple of programs. As the names were generic (HEUR/Exploit.HTML, JS:Feebs-D, Heuristic.Exploit.HTML), my guess is that those that detected this properly got lucky (the Javascript used standard eval(unescape("”) method). In any case, every defense layer helps.
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
Comments