How to Catch a Phish Attack

This is the story of a day in the life of a Computer Security Incident Response Team (CSIRT) investigator.

It is 9:05 on a Tuesday morning. An employee has reported they received a suspicious email. The email in particular contained an Excel document. Kudos to this particular employee for catching this email because (spoilers) this Excel document leads to a pretty nasty malware family, called Trickbot. And it typically leads to ransomware.

Suspicious email with Excel attachment

So… CSIRT now has an unknown Excel file. The team has a number of systems to specifically analyze malicious documents. The first step is to drop the file onto one of these systems and start digging in! Our fearless investigator starts off by calculating the hash of the file and looking for that hash against public datasets of known malware, like VirusTotal. If it’s a known malicious file and someone’s already done the work, life for our hero is made a lot easier.

Safety Note: our investigator is only searching for the hash – not uploading the file. You don’t want to upload unknown files because it might have something that points back to your company. Instead of CSIRT uploading a file to a public location, they have set up their own private sandboxes they can use.

In this case, the file had already been uploaded by someone else to VirusTotal… but everyone was classifying the file as “safe” (0 detections out of 61 vendors… yikes).

VirusTotal hash analysis

Even though all these vendors are saying the file is safe, there are a couple of red flags. VirusTotal adds a couple of tags, one of which is “calls wmi.” Most Excel documents don’t do this. Plenty of malicious Excel documents do. Additionally, VirusTotal indicates that the Excel file is going to contact a domain, and it looks like it will download a .zip file

VirusTotal finds that the suspicious Excel file will contact a domain

A thorough look around VirusTotal reveals no more interesting information. So our cybersecurity gumshoe now goes to a public sandbox, called AnyRun. Most sandboxes will allow researchers to upload malicious files into an isolated environment where the malware can run and the researcher can interact with the malware. Again, the hash is used to see if anyone had already analyzed this file, and indeed someone had. This sandbox report shows the process tree:

The sandbox hash report process tree

Because of the process tree, our investigator can see that the Excel file was used to download a zip file, and then that zip file was unzipped. The zip file contained a JavaScript file and they can see WScript being used to run that JavaScript file. From there, that JavaScript file starts a command shell, then PowerShell, and then uses rundll32 to execute a .bin file.

The command line arguments used by cmd.exe and PowerShell are encoded with base64. They quickly decode them and see that PowerShell is being used to contact another webpage. From AnyRun, we can view the contents of that webpage.

The phishing investigation finds that PowerShell contacts support.php file

The “support.php” file contains code that will tell PowerShell to download a file as “nmj.bin” It then uses “rundll32.exe” to execute that file (which matches what we saw in the process tree). The next step: grab a hash of “nmj.bin” and look it up in yet another public sandbox tool, Hatching Triage. Triage is specifically good at extracting the configuration of malware families (in our humble investigator’s opinion). Malware authors will “configure” their malware to talk to specific domains and/or IPs. The CSIRT team wants to know this information, because they can then block those indicators of compromise (IOCs). Sure enough, Triage extracted the configuration of “nmj.bin.”

The phishing investigation uncovers the malware family

The phishing investigation finds the malware download

Additionally, Triage indicates that this malware family is Trickbot, and specifically using the rob113 botnet. Trickbot is an interesting group – it’s actually composed of several “subgroups.” Each subgroup will have different goals and uses different techniques. Specifically, the subgroup “rob” is known to use a pentesting tool called Cobalt Strike to install and execute ransomware).

So, now CSIRT has a list of domains and IPs they can block and/or look for historically, they know that the actor targeting their company is Trickbot and that, if the attack were successful, it would have likely led to data theft and ransomware. In this particular case, a huge amount of the information was in publicly available sources, which means our hero was able to gather this information in minutes. If the malware isn’t publicly known, CSIRT would have done a more manual analysis (which might include running in their own sandboxes or reverse-engineering a binary.

So in summary: the entire process our fearless investigator went through is called “pivoting.” They started with a hash, pivoted to VirusTotal, found some more information, pivoted to AnyRun for even more context, and then used information from AnyRun to pivot to Hatching Triage. The malware has been identified and the behavior has been documented for use in future investigations. At the end of the day, the company remains protected against these cyberattacks. Our CSIRT hero saved the day (with a little help from a security-aware employee)!

About the Author

Matthew Petroske

Matthew Petroske is a forensics and incident response (DFIR) engineer at OneLogin, performing incident management, intrusion detection, and investigative services. Matthew has a special interest in automating incident response processes to help his team detect, enrich and respond to security issues.

Related Articles