How We Discovered and Prevented an IMG-Based Malware Attack

Malicious actors always seek new techniques and methods to gain a foothold in networks. One of the tried-and-true methods, phishing, continues to be utilized as a primary method. Recently, my company has seen an uptick in phishing IMG-based attacks that contain attached malware. 

However, instead of attacking a single person, the attackers have pivoted to sending emails to support shared mailboxes with targeted subjects based on the perceived use case. This has brought about some interesting new malware that left my team very intrigued by how it was able to evade initial detection by our EDR solution. Today, I’ll share how we discovered and prevented this attack.

IMG-Based Malware Attack

The method of exploiting/bypassing the IMG-based malware attacks is interesting. While using an IMG file, it could bypass some of the security mechanisms used for downloaded files like this MITRE ATT&CK technique: https://attack.mitre.org/techniques/T1553/005/. 

Within about two weeks, we encountered two different versions of the same attack, one utilizing an approach that interacted with the user and a follow-up that could deploy silently. 

Additionally, the first phishing email that was a part of each of these attacks was able to bypass the O365 machine learning and analysis. However, multiple other attacks with identical payloads were detected and quarantined before getting to the end users’ mailboxes. 

Before getting into some of the analysis, we, as a company, evaluated the need to allow users to send and receive ISO/IMG files going forward. We expect this is a temporary fix, and the malicious actors will pivot to another approach.

Malware analysis use case 

Here is the analysis and events that led to the detection and termination of the attack chain.

The first stage

The initial download of the file was not detected as malicious, and it was able to place a zone.identifier ADS on the files, similar to the following:

It was not until the user interacted with the document, a .pdf.img file, that an EDR alert was triggered based on behavioral actions taken with Powershell. The user was most likely unable to detect that this was an odd file due to a setting in their file explorer. Then they went to open what they thought was a supporting doc file to a case submitted via the shared mailbox.

If the user had configured their system to show file extensions, they might have noticed this was an iso image. However, since they missed this, users clicked to open and started the payload deployment to the system.

At this step, the user was not paying attention to this strain of malware, as it did pop up a warning for them to accept the actions.

The second stage 

A few days later, the second train of malware came through that was able to bypass this pop-up. In this attack, with the same initial config as the first, the ADS was not written to the files contained in the IMG/ISO containers, allowing them to execute without running. And because the EDR solution did not detect these files, the malware execution downloaded the IMG/ISO containing the malicious files and mounted them without being detected.

What was ultimately detected by the EDR was a Powershell command that called out to a website for additional files. In this case, the malicious command reversed the address to attempt to bypass search and detect mechanisms. Because this was not a standard action (running Powershell) for this user, the EDR managed to identify and stop the attack at this point in the chain.

Similar samples in ANY.RUN  

I found tasks with similar behavior in Public Submissions of ANY.RUN service. Going through such tasks gives additional ability to re-run tasks and take a closer look at how malware behaves in infected systems. I watched execution flow, file creation, and registry changes to determine what new rules may be created for our EDR system.

Check the sample and try to analyze it by yourself!