Back
A Blocked Security Alert Doesn’t Always Mean “Case Closed”
Digging Deeper to Uncover a Fenix Botnet Targeting HR & Payroll Tax Employees in Mexico
When a client’s EDR platform alerted that it had blocked a file being accessed through a non-domain address, that could have been “case closed” – the file was blocked and the activity was halted.
Or so it seemed.
Our SOC, however, decided to dig a little deeper because the nature of the alert was highly suspect, and we needed to be thorough in our analysis
Limited Tools But Copious Resources
We provide MDR services for this client and manage their SIEM, but we don’t manage their CrowdStrike instance. In other words, we receive alert logs originating from CrowdStrike, but we aren’t able to pivot to CrowdStrike to triage the event with this EDR tool.
With limited resources, here’s what we did know from what the alert told us:
A user within the client’s network had reached out to a non-domain IP address to download a .jse file. This behavior is suspicious because the action originated from an employee in the HR department, a position that would not require manipulating JavaScript or visiting a non-domain IP address to download JavaScript from a command prompt.
Right away, we knew the employee wasn’t the one performing these actions. So we decided to use the tools we had to dig deeper and understand what was going on.
We then took some critical steps in identifying the threat.
- We quarantined the workstation within 10 minutes following the alert because we were confident that this was malicious and wanted to prevent malware from spreading to other endpoints at the company.
- Using publicly-available, Open Source Intelligence (OSINT) sources that aggregate threat bulletins, we researched whether the IP address in question had been used in any threat campaigns and checked its reputation.
- We then created a sandbox environment in which to more closely examine the file that was accessed via that non-domain IP. We could tell right away that it was an obfuscated JS file that if left alone would generate persistence, downloading more malware, and further the attack.
- Once we’d determined the IP address was suspect and the file was likely malicious, we went back to OSINT to search for any references to a SAT.jse file in active use by threat campaigns.
Identifying the Fenix Botnet
Through our research, we found that the malicious file was a dropper to a botnet called Fenix, which specifically targets users in HR and payroll tax positions at companies in Mexico.
At this point, we were able to correlate a few data points:
- This client was headquartered in Mexico and the initial alert came from an HR employee’s workstation.
- The .jse file was being used to deliver the Fenix botnet.
- We also determined that the IP address was hosted within the Blnwx network that has been known to host malware related to the Fenix botnet.
Now the pieces had come together.
At this point, we let the client know so they could alert the HR and payroll tax teams to act with increased vigilance. Knowing the threat campaign was specifically targeting their business meant another attempt was likely not far off.
As predicted, the same alert came from a different HR user a day later, but since we’d done our research, we recognized it right away as part of the same threat campaign.
Cleaning Up After the Botnet
We determined the first workstation never actually hit the IP address in question so it was an unsuccessful download of the file, but we still issued a quarantine because the workstation might be actively going to other IPs and pulling other files that may not be picked up by security tools.
Most of the time, bad actors gain entry through phishing attempts where an employee clicks a bad link or downloads a bad file, which was the case here.
Why We Dig Deeper Into Alerts
Although the alert was blocked by our client’s CrowdStrike instance, what we observed made us suspicious enough to take a deeper look. Often, a blocked alert doesn’t account for other attempts being made at other workstations, or persistence that may have been established at the initial point of entry.
It’s also important to know what type of threat you’re dealing with. In this case, we identified a threat campaign that was more than just a one-off – it was a targeted campaign aimed at specific workers in Mexico. That extra step allows us to empower companies to understand what to look out for and prevent future attacks.
Finally, leveraging aggregator tools like OSINT, which can identify patterns in reporting from other threat tools, makes it far easier to understand your adversary and implement proper remediations.
Despite acting on limited tools with this specific client, we were able to determine threat activity with high confidence and take swift and effective action.
Working with an MSSP affords companies that extra layer of security to be sure that a blocked threat doesn’t continue to rear its ugly head.
Get the deeper picture surrounding your alerts. Contact us.
10.15.24