The Watch Commander’s Log is a series that provides a direct view into the threats Agio’s Managed Detection and Response (MDR) team handles for our clients. If you have questions about anything you read here, please feel free to reach out to us at email@example.com. If you are a current Agio MDR client, you can also reach out to your assigned MDR analyst.
Agio Managed Detection & Response (MDR) had two clients receive phishing emails the first week of June that appeared to be from the Cayman Islands Monetary Fund. These emails were more advanced than what our team normally encounters during an investigation because the attacker employed sophisticated obfuscation in the payload of the email.
I employed defensive actions that blocked the domains and the sender in Inky, Microsoft O365, and Umbrella.
The first step in the investigation was to download the .EML formatted email to the analyst machine. The format .EML means that the email contains ASCII text files that contain the email messages with nontransparent headers. The headers contain chunks of content that will either be obfuscated (i.e., Base64) or quoted-printable words (i.e., human-readable and not obfuscated.)
After downloading the .EML file it is important not to open it in an email client, such as Outlook, unless you’re performing dynamic analysis in a sandboxed machine. Instead, I parsed the email and extracted all attachments from the command line with a tool called ripMIME.
rip# ripmime -i message.eml
Outlook-EmailingSc.png message.eml textfile0 textfile1 textfile2 textfile3 textfile4 textfile5
I then investigated each of the text files. As you can see in the image below, they’ve been automatically deobfuscated by the tool.
I expanded the shortened URL in the text file and found the website was a compromised cloud computing platform, Appspot.com. Further investigation into the compromised site showed encryption and Microsoft login strings, which appeared to support the hypothesis that the site was being used as a credential harvester.
A quick Google search concerning the reputation of the compromised website shows that the SSL certificates of the site are, in fact, being abused by malicious actors to spoof Microsoft login web pages.
I changed the .EML extension of the original message to .TXT to open the ASCII file in Notepad and preview the SMTP headers.
In most, if not all, phishing campaigns, the Sender Policy Framework (SPF) is very helpful in identifying and verifying true positive (TP) phish. In our sample, the team had the following:
received-spf: Fail (protection.outlook.com: domain of cimamoney.com does not designate 18.104.22.168 as permitted sender)
authentication-results: spf=fail (sender IP is 22.214.171.124)
The SPF record indicates which server IP addresses are authorized to send email on a domain’s behalf. When a recipient email server receives an email, it checks the SPF record for the sending domain. Passing or failing this process is a clue that the email may or may not be legitimate. In this instance, the sender’s IP address was not authorized to send email on behalf of the sending domain.
The ripMIME tool also parsed and extracted a .PNG file which contained two strings that could be indicative of malware and/or steganography.
I attempted to extract metadata from the file, but this involved cracking the password of the .PNG, which required a heavier processor.
I analyzed the .PNG file thoroughly, but the results were inconclusive since a malicious .PNG file would certainly contain malicious code that would either be above or below the starting and ending markers for a non-malicious .PNG file. In other words, a normal .PNG file begins at a specific offset and is always a Start of Image (SOI) FF D8 in hexadecimal and is always an End of Image (EOI) FF D9 in hexadecimal.
In the screenshots below, you can see that the sample appears to begin and end as a normal, non-malicious .PNG file.
In the screenshot below, you can see that no antivirus engines have detected this file by the MD5 hash.
(Image source: VirusTotal)
However, this doesn’t mean anything, as this file was found to be in association with a phishing campaign.
I attempted to verify the integrity of the file, but this process could not be completed as the integrity check showed file corruption.
Although the password was not cracked, and this case has been closed, there was an intriguing clue that the attacker left behind in the name of the Author (Mr. Cisco) and the UUID (Universally Unique Identifier).
Investigating the existence of the UUID found in the sample shows that it has previously been used in an XMP metadata packet, specifically as Stealth RT.
I can’t help but wonder if the two pieces are related, and I’m looking forward to one day cracking the passphrase and investigating the metadata of this sample. I’ll see you soon, Mr. Cisco…
If you have questions about anything you read here, please feel free to reach out to us at firstname.lastname@example.org. If you are a current Agio MDR client, you can also reach out to your assigned MDR analyst.