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
Anonymous
Dec 3rd 2022
9 months ago
Anonymous
Dec 3rd 2022
9 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
Anonymous
Dec 26th 2022
9 months ago
Anonymous
Dec 26th 2022
9 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
9 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
9 months ago
Anonymous
Dec 26th 2022
9 months ago
https://defineprogramming.com/
Dec 26th 2022
9 months ago
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
https://defineprogramming.com/
Dec 26th 2022
9 months ago
rthrth
Jan 2nd 2023
8 months ago