So you found yourself responding to an alert about one of your employees downloading a malicious version of Advanced IP Scanner? This has become fairly common, as system admins and IT technicians want to download the tool to use legitimately within their environment. But threat actors have been hosting very convincing malicious versions that are being discovered through malvertising (e.g., “malicious advertising” like Google Ads). Now, suppose you want to take a deeper dive and grab the file for yourself, yet you find yourself dealing with some issues, namely:
- The employee deleted the downloaded file
- The URL they clicked redirects to the real Advanced IP Scanner website
- Trying to get the ad to pop up in Google searches just isn’t working
I was recently dealing with this exact scenario, and the method I chose to use was to trick the site into thinking I was coming from a Google ad click. I chose this method mainly because it seemed like my only way to grab the initial file at the time. The original file was no longer in place on the user’s machine, but I still wanted to analyze it. When I navigated to the malicious URL, however, I discovered the website was redirecting me to the real Advanced IP Scanner website, so I decided to trick it! (I’ll illustrate later how this wasn’t even necessary, and I thought way too hard about it.)
The site we’re dealing with in this scenario is hxxps://advanced[.]ip-scanner[.]co (Please don’t visit this particular link).
As mentioned, I want to grab the original file so I can analyze it. My goal in analyzing this file is to simply see what it does. Does it connect back to a C2 (command and control server)? Does it drop persistence on the host so threat actors can connect to the system? Or for more malicious code to run after the file has been removed? Does it attempt to steal user credentials from the host? These are some basic questions I want answered in my analysis, but in order to do this, I need the file.
So let’s grab it. Let me show you what happens if we go to the site. In my case, I get redirected to the legitimate Advanced IP Scanner website instead of the malicious one:
Okay, well, what if I try to Google it? Maybe I can get the ad to show up?
Nope, in this case I get the legitimate site. (Please note, previous malvertising campaigns were able to spoof the URL that was shown on the ad, but I confirmed this one by visiting the site.)
I still want to trick this website into thinking I’m coming from a Google ad click so it’ll serve up the malicious website instead of the legitimate one. I need to grab the malicious download, but how can I do that? Well, my first thought was to see what happens when I click an ad to another legitimate site. What kind of cookies or header data is applied to tell the website I’m coming from a Google ad click?
In this case, I opened up the browser’s developer pane with F12, clicked on the network tab, and went back to the legitimate advanced-ip-scanner.com via the ad click.
After some poking and prodding, I discovered the top result is the one we want to explore some more. So let’s click on this result and take a look at what we get.
If we scroll down to Request Headers we can see this line:
Okay let’s head over to Postman and give it a shot. In case you’re unfamiliar with it, Postman lets developers execute HTTP requests and test API responses. This way I can freely edit any headers or provide cookie data and see what kind of response I get from the website. In Postman I want to create a new GET request, and I want to append a Referer header with the value https://www.google.com/
Let’s see if this works. Let’s hit Send.
That’s a thing! You’ll see some references in the screenshot to advanced-ip-scanner.com but that’s because the threat actors straight-up cloned the site. If we connect with and without the referrer, there are slight differences in the resulting pages.
So at this point I want to find the download. I’m going to Ctrl+F the word download.
Lo and behold! Let’s try to visit that directory at advanced-ip-scanner[.]com/download/.
That’s a thing too. Now, before we investigate a bit, remember earlier when I said, “I’ll illustrate later how this wasn’t even necessary, and I thought way too hard about it”?
Well, it turns out only the main page advanced[.]ip-scanner[.]co redirects if you have the incorrect referer. All I had to do was append /download and it would let me see the open directory with or without the referrer header. But, hey, hindsight is 20/20.
Let’s poke around a bit. I find that ipscanner.txt to be interesting mainly due to the naming convention. dl.php and dwnl.php are likely related to downloading logic, and I’m unsure about apps2co.php at the moment, so I’ll look at the ipscanner.txt first. So let’s check that out.
It might not be immediately obvious, but this is incredibly interesting because that looks like Base64 encoding. Let’s decode that. Off to CyberChef! For anyone who’s unfamiliar, CyberChef is a fantastic web-based tool for data analysis. It can help us uncompress, decode, and decrypt data, and it’s a wonderful “Swiss army knife” for cybersecurity professionals.
Now that’s interesting. In the above image we see the original output of ipscanner.txt on the top right with my decoding method shown on the left, highlighted in green. I’m simply applying “From Base64” to decode the text. On the bottom right, we can see the output. That’s an executable.
A quick and dirty way to tell this is an executable is that we can see “This program cannot be run in DOS mode.” near the top of the output. That’s a tell-tale sign of an .exe. We could download this a few different ways. We could click the “save output” button (the little floppy disk icon above the output) in CyberChef and save that as an .exe and we would have our malicious executable. But I want to illustrate another way.
I’m going to download the raw Base64 on to my VM (virtual machine) as a .txt file and use certutil to decode it using the command certutil -decode source dest.
In the above screenshot, I’m simply running certutil -decode raw.txt decoded.exe against the raw.txt which contains the original Base64 and outputting it as decoded.exe. Certutil is often used exactly like this by threat actors to create an .exe from encoded data on a target system, so this will generally trigger most EDR products to create an alert.
We got the file! I also used Get-FileHash to get the SHA256 hash to compare this against the hash originally referenced in the alert that triggered all of this, and it’s the same, which confirms I have the malicious file.
Okay, but what about the other links shown in the /download directory? Well, as it turns out, we’re working too hard yet again.
If we click the apps2co.php link on this page, it serves up the decoded .exe. And if I check that hash against the original hash from the alert and the hash of my decoded .exe we get the same hash.
(At this point, we won’t be going any further because then this would turn into a blog on static and dynamic malware analysis. But I hope you found reading this as enjoyable as it was for me to dig into.)
Investigation theory tells us to form contextual and answerable questions while investigating an alert. The question I asked myself that caused me to go down this rabbit hole was, “What does this file do?” To answer this question, my initial intention was to download the original malicious file so I could analyze its behavior. This would help me not only understand what the file is doing, but also help me dig deeper and ensure the host is clean.
I hope this blog was enjoyable and informative in showing how a security analyst might step through obtaining an original file when the malicious website is set to redirect as a method of hiding from security workers.
I’d like to thank my colleague Jai Minton for digging into this with me. For his insights, you can check out his blog here.
A version of this article originally appeared in Medium.
