Unmasking UNC1860: How Shared Shellcode Structures Reveal Iranian Espionage

TLDR: Threat actor UNC1860 uses a modular, multi-stage malware ecosystem to facilitate both espionage and disruptive operations across the Middle East. By analyzing shared shellcode structures and custom obfuscation schemes, researchers can link seemingly disparate tools like TOFULoad and TOFUPIPE to a single, highly capable threat group. This research demonstrates that effective attribution requires moving beyond simple file hashes to a semantic analysis of how attackers build and deploy their toolsets.

Security researchers often fall into the trap of treating every new malware sample as a unique entity. We hunt for hashes, we build YARA rules, and we move on. But when you look at the broader campaign, you realize that the "noise" of individual tools often masks a singular, cohesive strategy. The recent research into the Iranian-affiliated group UNC1860 is a masterclass in why we need to stop looking at tools in isolation and start looking at the underlying architecture of the attack.

The Architecture of a Modular Threat

UNC1860 does not rely on a single, monolithic backdoor. Instead, they have built a sprawling, modular ecosystem of custom malware. The group’s toolkit includes droppers, backdoors, and GUI-based controllers, all designed to be swapped in and out depending on the target and the mission.

What makes this group dangerous is not the complexity of any single tool, but the consistency of their development. They rely heavily on one-day vulnerabilities to gain an initial foothold. Once inside, they deploy small, home-brewed webshells that serve as loaders for more advanced payloads. These loaders are intentionally kept small and simple to avoid triggering OWASP A03:2021-Injection detections or other heuristic-based security controls.

The real "Aha!" moment in this research comes from comparing the shellcode structures used by these different tools. Despite being written in different languages—ranging from C++ to C#—the underlying logic for loading and executing payloads is identical. Whether the actor is using a driver like WinTapix or a passive listener like TOFUPIPE, the shellcode structure remains constant. This is not a coincidence. It is a deliberate design choice that ensures their tools are always compatible, regardless of the environment they are targeting.

Moving Beyond Hash-Based Detection

For a pentester or a red teamer, this research is a reminder that your own toolchain might be leaving a signature that is far more revealing than you think. If you are building custom implants, are you reusing the same shellcode stubs across different projects? If so, you are creating a "fingerprint" that a skilled threat hunter can use to link your activities together, even if you change your C2 infrastructure or your obfuscation techniques.

The obfuscation schemes used by UNC1860 are another point of interest. They use custom routines, which they call CryptoSlay and ObfuSlay, to hide their strings and API calls. These are not complex cryptographic implementations. They are simple, effective, and—most importantly—reused across their entire arsenal.

// Example of the shellcode structure used by UNC1860
struct st_received_shellcode {
    int64 shellcode_size;
    BYTE shellcode[];
    int64 shellcode_output;
    int64 shellcode_output_len;
    int64 magic_0x18;
    BYTE shellcode_arg[];
};

When you encounter these structures during an engagement, you are likely looking at a deliberate attempt to maintain a consistent operational capability. The group’s reliance on undocumented IOCTLs within http.sys to facilitate passive communication is particularly clever. It allows them to blend in with legitimate network traffic, making detection significantly harder for traditional EDR solutions.

The Reality of Modern Attribution

Attribution is often treated as a political game, but for those of us in the trenches, it is a technical necessity. If you know that a specific set of TTPs belongs to a group that favors disruptive operations over quiet data exfiltration, you can prioritize your defensive efforts accordingly.

The UNC1860 case proves that we need to shift our focus from technical code analysis to a semantic analysis of actions. It is not enough to know that a piece of malware uses a specific API call. You need to understand why that call is being made and how it fits into the broader lifecycle of the attack.

If you are conducting a penetration test, try to think about your own operations in these terms. Are your tools modular? Do they share a common core? If you were to be "caught" by a blue team, would they be able to link your different stages of the attack back to a single, unified campaign?

The next time you are analyzing a suspicious binary, don't just dump the strings and look for C2 domains. Look for the structural similarities in how the code is organized. Look for the "funny" naming conventions or the repetitive, minor errors that might indicate a specific developer or a specific team. These are the details that matter. They are the breadcrumbs that lead you to the real story behind the attack.

Stop chasing the noise. Start looking for the architecture. That is how you stay ahead of groups like UNC1860.