This article highlights a new obfuscation technique threat actors are using to hide malware through steganography within bitmap resources embedded in otherwise benign 32-bit .NET applications. Upon execution, these files kick off a multi-stage chain of extracting, deobfuscating, loading and executing secondary payloads (dynamic-link libraries), eventually detonating the final payload (executable).
We illustrate how to recover the final payload from the initial bitmap resource embedded in the original file using malware drawn from recent malicious spam (malspam) campaigns observed in our internal telemetry. Security practitioners can better defend against this technique by understanding the inner workings of it.
Palo Alto Networks customers are better protected from the threats discussed in this article through the following products and services:
If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.
Related Unit 42 Topics | Agent Tesla, Remcos RAT, XLoader |
We observed multiple waves of malspam from a campaign using email attachments between the end of 2024 and early 2025. The most prominent of these waves targeted organizations in the financial industry in the Republic of Türkiye. Another wave of malspam targeted the logistics sector in Asia. In this campaign, attackers disseminated more than 250 emails, each with the same malware attached, throughout the targeted regions.
The attackers composed the email subject in the targeted region's native language. The original malware sample was a Windows executable (.exe) file, with a filename either related to:
One commonality among the waves of malspam in this campaign is using bitmap resources embedded in otherwise benign 32-bit .NET applications to spearhead these attacks into targeted industries, sectors and regions. For example, the malware sample we analyzed for this article uses a copy of a legitimate .exe file for an application named Windows Forms OCR.
Besides hiding malicious payloads as bitmap resources, other common .NET obfuscation techniques include:
Attackers can use each of these techniques either independently or in some combination to strengthen the resilience of a malicious .NET application against reverse engineering efforts.
The following sections present a detailed analysis of how we recovered the final payload from an initial bitmap resource.
This analysis is for a malware sample with the following SHA-256 hash:
The file creation time on VirusTotal, taken from the TimeDateStamp of the PE file header, had been timestomped. This means that the timestamp was overwritten with a bogus value like 2102-09-02 10:59:06 UTC.
Interestingly, the MainForm class used in the .NET code of this sample adopts a naming convention for its methods and parameters consistent with a particular topic.
For example, it would pair marine research and oceanography with names like the following:
Figure 1 depicts the original malware sample process xgDV.exe unpacking its .NET bitmap resource sv into the TL.dll assembly.
The InitializeComponent() method of the MainForm .NET class is responsible for deobfuscating and loading the first 71,168 bytes of the malicious bitmap resource named sv as shown in Figure 2.
The bitmap resource named sv is fully loaded as TL.dll. This TL.dll assembly is another loader that does not contain any resources of its own. The compilation timestamp of 2025-02-23 23:16:47 UTC is not overwritten.
Figure 3 depicts the TL.dll assembly unpacking the .NET bitmap resource rbzR, found embedded in the original malware sample process xgDV.exe, into the Montero.dll assembly.
The original process then uses reflection through the LateBinding.LateCall() function call. This call invokes a method named Justy() within the TL.dll assembly. Embedded in the original sample, a second bitmap resource named rbzR is encoded as the hexadecimal string 72627A52 and passed as a parameter to this Justy() method, as shown in Figure 4.
Figure 5 depicts the Montero.dll assembly unpacking its .NET byte array resource uK5APqTdSG into the final payload, Remington.exe.
TL.dll deobfuscates and loads the bitmap resource named rbzR as Montero.dll. With a compilation timestamp of 2025-02-24 05:18:43 UTC, Montero.dll is yet another loader. This file deobfuscates, loads and executes its own byte array resource named uK5APqTdSG.
Montero.dll accomplishes the deobfuscation by applying XOR encryption with subtraction, as shown in Figure 6. Using the XOR key opIaZhYa, this process produces the final payload named Remington.exe.
Additionally, a number of flags dictate the nature of this final payload's execution (e.g., whether the final payload is forked as a child process or not).
The objective of this obfuscation is to evade detection and successfully detonate popular malware families (e.g., Agent Tesla variants, XLoader and Remcos RAT) to gain an initial foothold into victim systems.
In this case, the final payload belongs to the Agent Tesla family. Its configuration is extracted as follows:
One effective approach to overcome this obfuscation technique is to use the .NET Framework's ICorDebugManagedCallback interface to create a debugger that hooks the following API functions:
Hooking is the act of placing breakpoints, which temporarily pauses program execution at certain points in time to extract values of interest.
The use of bitmap resources to conceal malicious payloads is a steganography technique that is prevalent in malspam campaigns. By hiding malicious payloads as bitmap resources, threat actors can potentially bypass traditional security mechanisms and evade detection.
The analysis covered in this article underscores how threat actors are able to leverage this method of delivery to execute malicious code in a stealthy manner. It is important for security practitioners to understand this obfuscation technique to stay ahead of such threats.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Note that some of the listed samples use a Captive.dll with the SHA-256 hash 5adff9ae840c6c245c0a194088a785d78d91fe734ee46a7d51605c1f64f6dadd as the Stage 2 loader, instead of the aforementioned TL.dll.
SHA-256 hashes for three samples
Post-infection SMTP data exfiltration
For SHA-256 hash: 30b7c09af884dfb7e34aa7401431cdabe6ff34983a59bec4c14915438d68d5b0
For SHA-256 hash: 5487845b06180dfb329757254400cb8663bf92f1eca36c5474e9ce3370cadbde
For SHA-256 hash: ac5fc65ae9500c1107cdd72ae9c271ba9981d22c4d0c632d388b0d8a3acb68f4
SHA-256 hashes for four samples
C2 for data exfiltration
For SHA-256 hash: 511af3c08bd8c093029bf2926b0a1e6c8263ceba3885e3fec9b59b28cd79075d
For SHA-256 hash: 604cbcfa7ac46104a801a8efb7e8d50fa674964811ec7652f8d9dec123f8be1f
For SHA-256 hash: 98195a4d27e46066b4bc5b9baea42e1e5ef04d05734c556d07e27f45cb324e80
For SHA-256 hash: a4a6364d2a8ade431974b85de44906fe8abfed77ab74cc72e05e788b15c7a0cf
SHA-256 hashes for three samples
C2 for data exfiltration
For SHA-256 hash: 3b83739da46e20faebecf01337ee9ff4d8f81d61ecbb7e8c9d9e792bb3922b76
For SHA-256 hash: 8146be4a98f762dce23f83619f1951e374708d17573f024f895c8bf8c68c0a75
For SHA-256 hash: 9ed929b60187ca4b514eb6ee8e60b4a0ac11c6d24c0b2945f70da7077b2e8c4b