Stealthy .NET Malware: Hiding Malicious Payloads as Bitmap Resour...

Executive Summary

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.

Initial Discovery

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:

• Procurement - Request for quotation (RFQ) or purchase order (PO)
• The name of the compromised organization sending out the malspam emails
• The date of a specific financial transaction of interest

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 .exefile for an application named Windows Forms OCR.

Besides hiding malicious payloads as bitmap resources, other common .NET obfuscation techniques include:

• Metadata obfuscation : Renaming or removing class, method or property names to hinder static analysis
• Opcode replacement: Swapping standard intermediate language (IL) instructions with functionally equivalent but less recognizable ones (e.g., substituting the callvirtopcode with callto confuse .NET decompilers often used by analysts when examining .NET malware samples)
• Stolen bytes : Removing or relocating segments of IL code, reconstructing the code dynamically at runtime, so that decompiled code is rendered incomplete or invalid by .NET decompilers
• Control flow obfuscation: Reordering, restructuring or replacing execution paths with opaque predicates, state machines or dispatcher loops (e.g., control flow flattening)
• Virtualization-based obfuscation: Replacing IL code with custom bytecode that can only be executed by the accompanying custom interpreter (c.f. Uncovering .NET Malware Obfuscated by Encryption and Virtualization)
• String encryption : Encrypting strings at rest and decrypting them only when necessary at runtime
• Dynamic code generation: Generating and executing code at runtime via reflection

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.

Technical Analysis

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:

• ac5fc65ae9500c1107cdd72ae9c271ba9981d22c4d0c632d388b0d8a3acb68f4

Stage 1: Initial Payload

The file creation time on VirusTotal, taken from the TimeDateStampof the PE file header, had been timestomped. This means that the timestamp was overwritten with a bogus value like 2102-09-02 10:59:06UTC.

Interestingly, the MainFormclass 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:

• AbyssalScan(oceanFloor, marineLife, maxSpecimens)
• MarineExploration(oceanFloor, marineLife, maxSpecimens)
• VerifyOxygenSaturation(level)

Figure 1 depicts the original malware sample process xgDV.exeunpacking its .NET bitmap resource svinto the TL.dllassembly.

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 svas shown in Figure 2.

Stage 2: TL.dll

The bitmap resource named svis fully loaded as TL.dll. This TL.dllassembly is another loader that does not contain any resources of its own. The compilation timestamp of 2025-02-23 23:16:47UTC is not overwritten.

Figure 3 depicts the TL.dllassembly unpacking the .NET bitmap resource rbzR, found embedded in the original malware sample process xgDV.exe, into the Montero.dllassembly.

The original process then uses reflection through the LateBinding.LateCall()function call. This call invokes a method named Justy()within the TL.dllassembly. Embedded in the original sample, a second bitmap resource named rbzRis encoded as the hexadecimal string 72627A52and passed as a parameter to this Justy()method, as shown in Figure 4.

Stage 3: Montero.dll

Figure 5 depicts the Montero.dllassembly unpacking its .NET byte array resource uK5APqTdSGinto the final payload, Remington.exe.

TL.dlldeobfuscates and loads the bitmap resource named rbzRas Montero.dll. With a compilation timestamp of 2025-02-24 05:18:43UTC, Montero.dllis yet another loader. This file deobfuscates, loads and executes its own byte array resource named uK5APqTdSG.

Montero.dllaccomplishes 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).

Stage 4: Final Payload

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:

• Post-infection SMTP data exfiltration:
  • Server: hosting2[.]ro.hostsailor[.]com:587
  • Sender: packagelog@gtpv[.]online
  • Password: 7213575aceACE@@
  • Receiver: package@gtpv[.]online

Analysis Approach

One effective approach to overcome this obfuscation technique is to use the .NET Framework's ICorDebugManagedCallbackinterface to create a debugger that hooks the following API functions:

• System.Resources.ResourceManager::GetObject(string name)
  • Intercepts embedded resources (including bitmaps) being read by the .NET application
• System.AppDomain::Load(byte[] rawAssembly)and System.Reflection.Assembly::Load(byte[] rawAssembly)
  • Intercepts the loading of a .NET assembly from a raw byte array

Hooking is the act of placing breakpoints, which temporarily pauses program execution at certain points in time to extract values of interest.

Conclusion

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 Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

• The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the IoCs shared in this research.
• Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
• Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.

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:

• North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
• UK: +44.20.3743.3660
• Europe and Middle East: +31.20.299.3130
• Asia: +65.6983.8730
• Japan: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 00080005045107

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.

Indicators of Compromise

Note that some of the listed samples use a Captive.dllwith the SHA-256 hash 5adff9ae840c6c245c0a194088a785d78d91fe734ee46a7d51605c1f64f6daddas the Stage 2 loader, instead of the aforementioned TL.dll.

Agent Tesla Variant Activity

SHA-256 hashes for three samples

1. 30b7c09af884dfb7e34aa7401431cdabe6ff34983a59bec4c14915438d68d5b0
2. 5487845b06180dfb329757254400cb8663bf92f1eca36c5474e9ce3370cadbde
3. ac5fc65ae9500c1107cdd72ae9c271ba9981d22c4d0c632d388b0d8a3acb68f4

Post-infection SMTP data exfiltration

For SHA-256 hash: 30b7c09af884dfb7e34aa7401431cdabe6ff34983a59bec4c14915438d68d5b0

• Server: mail.gtpv[.]online:587
• Sender: kings@gtpv[.]online
• Password: 7213575aceACE@@
• Receiver: king@gtpv[.]online

For SHA-256 hash: 5487845b06180dfb329757254400cb8663bf92f1eca36c5474e9ce3370cadbde

• Server: nffplp[.]com:587
• Sender: airlet@nffplp[.]com
• Password: $Nke%8XIIDtm
• Receiver: smt.treat@yandex[.]com

For SHA-256 hash: ac5fc65ae9500c1107cdd72ae9c271ba9981d22c4d0c632d388b0d8a3acb68f4

• Server: hosting2.ro.hostsailor[.]com:587
• Sender: packagelog@gtpv[.]online
• Password:7213575aceACE@@
• Receiver: package@gtpv[.]online

XLoader Activity

SHA-256 hashes for four samples

1. 511af3c08bd8c093029bf2926b0a1e6c8263ceba3885e3fec9b59b28cd79075d
2. 604cbcfa7ac46104a801a8efb7e8d50fa674964811ec7652f8d9dec123f8be1f
3. 98195a4d27e46066b4bc5b9baea42e1e5ef04d05734c556d07e27f45cb324e80
4. a4a6364d2a8ade431974b85de44906fe8abfed77ab74cc72e05e788b15c7a0cf

C2 for data exfiltration

For SHA-256 hash: 511af3c08bd8c093029bf2926b0a1e6c8263ceba3885e3fec9b59b28cd79075d

• hxxp[://]www.sixfiguredigital[.]group/aoc3/

For SHA-256 hash: 604cbcfa7ac46104a801a8efb7e8d50fa674964811ec7652f8d9dec123f8be1f

• hxxp[://]www.sixfiguredigital[.]group/aoc3/

For SHA-256 hash: 98195a4d27e46066b4bc5b9baea42e1e5ef04d05734c556d07e27f45cb324e80

• hxxp[://]www.sixfiguredigital[.]group/aoc3/

For SHA-256 hash: a4a6364d2a8ade431974b85de44906fe8abfed77ab74cc72e05e788b15c7a0cf

• hxxp[://]www.yperlize[.]net/aa02/

Remcos RAT Activity

SHA-256 hashes for three samples

1. 3b83739da46e20faebecf01337ee9ff4d8f81d61ecbb7e8c9d9e792bb3922b76
2. 8146be4a98f762dce23f83619f1951e374708d17573f024f895c8bf8c68c0a75
3. 9ed929b60187ca4b514eb6ee8e60b4a0ac11c6d24c0b2945f70da7077b2e8c4b

C2 for data exfiltration

For SHA-256 hash: 3b83739da46e20faebecf01337ee9ff4d8f81d61ecbb7e8c9d9e792bb3922b76

• myhost001.myddns[.]me:9373
• 103.198.26[.]222:9373

For SHA-256 hash: 8146be4a98f762dce23f83619f1951e374708d17573f024f895c8bf8c68c0a75

For SHA-256 hash: 9ed929b60187ca4b514eb6ee8e60b4a0ac11c6d24c0b2945f70da7077b2e8c4b

Additional Resources