Working as a SOC Analyst, I come across dozens of phishing attempts a day. Most of these are just that – attempts. However, late last year, one malicious actor got further than most, giving us the dreaded call from a client: “A user has clicked an email, we need you to check it out”. Luckily in this case, the user never got further than a suspicious DNS request, but nevertheless there was a lot of work to do to ensure that was really the case. Knowing the amount of time it would otherwise take to investigate all the loose ends of this mess, I decided to speed things up and load up what I found into SpiderFoot, because who doesn’t like letting the work get done for you?
Finding the IOCs
At this stage, all I had was a zipped up email sent by the customer with the malicious email, and the header info. The email was pretty standard, including a smart little .html file that used URL escape characters to encode the payload. I won’t spend too much time on the boring details, but decoding these characters gave me this URL:
This ended up a dead end. The URL redirects to that last part (highlighted), and serves the phishing page. Threat actors often use established infrastructure to host these pages, so that it doesn’t set off the most basic alarms by web browsers or DNS filters. Where I needed SpiderFoot’s help came from the email header.
As expected, the threat actor spoofed a popular domain, waze[.]com, and routed the real email through an SMTP server:
The real domain was a dummy (blurred as it may be a hijacked domain, contains a human name), providing another dead end. But this person made a mistake here, and used what appeared to be local infrastructure to route the email:
Starting a Scan
Normally, the optimal way to run SpiderFoot is with as many useful data points as possible – unfortunately in this case I only had one to go off. Nonetheless, running the scan gave me plenty to work with:
One of the best things about SpiderFoot is the visualizations, the first place I went after the scan finished. It’s easy to work out which modules have done the lion’s share of work, and ultimately what kind of data we’ve found. In this case, there was quite a bit from SHODAN, which is often a good sign because it means we’ll have information on what the host uses, not just where it is and if it’s malicious (because we know the latter already).
The last image, the Node Graph, shows us that a large amount of information came from RIR data that SHODAN and some other modules have found. The graph shows us location information, software used, and some indications of malicious artifacts that should show us more about the adversary.
Hunting the Adversary
Digging down into the data types, there’s a few things standing out:
The malicious IP address is of course, our IOC. A popular AV Webroot detects it as malicious, which at the very least means I’m not the first to come across it. The next data type that has ‘Risky’ flags is Software Used, showing what the host appears to be running to serve the phishing emails:
As we noticed earlier, the email header containing this IP address noted the sending server was running Ubuntu. Together with this information, the OS and Internet Name info from SpiderFoot, we know that the adversary is renting a Deltahost server to run this software on a Linux server. SpiderFoot has already provided through its many modules the location of this server in Kyiv, Ukraine, and a little background searching on this provider reveals that not only are they a Ukrainian company providing servers in the US, Netherlands, and Ukraine exclusively, they only have Ukrainian customers. Now we know that our adversary is likely based in Ukraine.
Some other interesting data that SpiderFoot has collected shows the ports the server is using (80, 22), serving their Apache httpd web page on port 80, and the OpenSSH software on port 22 – pretty standard stuff in this case, but it’s nice not to have to run a port scan myself to check for any anomalies.
Closing the Case
So what do we know? We now know that we have a Ukrainian citizen, possibly resident, who has deployed a Linux server locally to route their phishing emails, and exposed a web page likely to serve a landing page for those unlucky victims. The adversary made this attack successful by using as much legitimate infrastructure, and as we saw before, URL shorteners and redirects, to obfuscate and legitimize the behavior so that it wouldn’t set off any alarms.
Using SpiderFoot, I’ve been able to run dozens of checks I’d otherwise do manually, and have to haphazardly collate them together to show the client what hit them, and how. In Business Email Compromise (BEC) incidents like this, there’s often little you can do to identify and report on the adversary, but nonetheless having this information enables you to give your client peace of mind knowing that you have the capabilities to identify where it came from and how they did it. Leveraging this information also allows you to understand the organization’s weak points, enrich threat intelligence feeds, and help other security teams out there identify similar attacks, all using SpiderFoot as your base point and making the process drastically more efficient.
Leave a Reply