This post documents two infrastructure findings made during a recent client engagement. Neither cluster has appeared in public threat intelligence reporting at the time of writing. I am publishing now to maximise the defensive value of the indicators before the infrastructure rotates.

The two findings are analytically independent but share a common thread: both connect to tooling associated with Chinese state-sponsored espionage, and both extend clusters that have been partially documented by other researchers. I will walk through the pivot chain for each, state my confidence assessments explicitly, and flag where the chain is inferential versus technically anchored.

IOCs are available as a STIX 2.1 bundle on request. All indicators carry confidence scores and sourcing on every object.

💡 : The analysis cut-off for this investigation is May 28th 2026

Finding 1 — Unreported ShadowPad Infrastructure Cluster

Detection Anchor

ShadowPad C2 infrastructure can be fingerprinted via a characteristic HTML body hash: e760bb9ce1e83e274def380574509c7b9e9088ff. Searching on this hash returns a consistent set of hosts with overlapping provider distribution and naming conventions documented by Hunt.io¹ in their February 2024 tracking of ShadowPad via non-standard certificates.

Applying this search returned 23 hosts. Three of these—172.64.80.1, 104.21.96.85, 172.67.175.133—are Cloudflare shared infrastructure fronting the domains and are excluded from the indicator set to avoid false positives. The remaining 20 hosts had not appeared in any public reporting.

Two Unreported Domains

Two domains in the cluster stood out immediately based on naming convention:

• cashmicrosoft[.]com
• googledrivecloud[.]com

Both follow the Microsoft and Google impersonation pattern consistently observed in ShadowPad operator infrastructure. Both are proxied behind Cloudflare. The HTML body hash match gives medium-high confidence on both as ShadowPad-linked.

Confidence: medium-high

The Afghan Ministry of Interior Pivot

On 2026-05-14, cashmicrosoft[.]com was observed in Validin presenting a host certificate for moi.gov[.]af—the Afghan Ministry of Interior. Presenting a government ministry certificate is consistent with infrastructure prepared for operations involving Afghan government entities, although certificate reuse alone is insufficient to establish active targeting.

Screenshot of the certificate on Validin. Sadly, the result is not available anymore in the Community Edition

I pivoted on this certificate behaviour and identified a second host exhibiting the same pattern: 195.86.120[.]2.

Confidence on targeting inference: medium

Pivot to the Intel Certificate Cluster

195.86.120[.]2 had previously resolved a single domain for approximately two weeks: rallyracingglobal[.]com. No other domain has ever resolved to this IP. Investigating rallyracingglobal[.]com revealed a self-signed TLS certificate impersonating Intel Corporation:

C=US, ST=CA, L=Santa Clara, O=Intel Corporation, CN=Intel Corporation - Client Components Group

This certificate is observed on 9 hosts globally since February 2026. I am unaware of any legitimate Intel Corporation deployment that would expose a self-signed certificate with this subject on internet-facing infrastructure.

The tradecraft mirrors the Dell Data Vault certificate cluster documented by Hunt.io¹ as ShadowPad infrastructure: self-signed certificates impersonating US hardware vendors on Nginx-serving hosts with characteristic ShadowPad HTTP response patterns.

The nine hosts are:

• 38.60.255[.]134
• 38.60.208[.]77
• 65.20.67[.]90
• 139.180.137[.]3
• 103.140.187[.]9
• 103.140.186[.]81
• 193.56.255[.]178
• rallyracingglobal[.]com
• www.rallyracingglobal[.]com

Confidence on Intel cert cluster as ShadowPad-related: medium

Infrastructure Cohesion — 38.60.x.x

The most significant observation in this dataset is the 38.60.x.x /16 overlap across the two sub-clusters:

• 38.60.250[.]74 — present in the HTML body hash cluster
• 38.60.255[.]134 — present in the Intel cert cluster
• 38.60.208[.]77 — present in the Intel cert cluster

Three IPs in the same /16 block across two independently-derived pivot chains is a meaningful infrastructure cohesion signal. It is consistent with a single operator managing both sub-clusters from the same VPS provider block, and it upgrades the Intel cert cluster from a tradecraft-similarity inference to a plausible infrastructure overlap.

The ShadowPad assessment rests on converging infrastructure signals rather than direct malware telemetry; absent payload recovery, the relationship should be considered provisional.

Attribution Note

ShadowPad is shared across at minimum APT41, APT27, APT15, Earth Lusca, Tick, Team Tonto, and Webworm. I am not attributing this cluster to any specific group.

The moi.gov[.]af certificate behaviour is consistent with multiple actors with South and Central Asian targeting interests. Attribution would require additional TTP or sample evidence.

Finding 2 — Winnti ELF C2 Infrastructure Extension

Starting Point

Researcher @TuringAlex² published two SHA256 hashes for confirmed Winnti ELF samples in May 2026:

• c83e768f3020119dc44392a46f587366c3ef70659592fbafb6cf94f08676bf3b
• de155feb28a98a18ae7962ed321c262d80e332b646da6fe8af65d0708167faef

Both samples use linux.tklolasi[.]com as their C2 domain. This extends the Winnti ELF cloud credential harvester cluster documented by Breakglass Intelligence in April 2026³, which identified a backdoor targeting AWS, GCP, Azure, and Alibaba Cloud instance metadata endpoints, using SMTP port 25 as a covert C2 channel and Alibaba Cloud typosquat domains for infrastructure camouflage.

The linux subdomain prefix is consistent with the ELF targeting profile of this specific tool.

Confidence: high

DNS Pivot

linux.tklolasi[.]com resolved to 106.15.148[.]44 for approximately two days. Short resolution windows of this kind are consistent with active operational infrastructure being rotated to avoid blocklisting—not indicative of a parked or sinkholed domain.

Confidence on IP as operational C2: medium-high

Three Alibaba Lookalike Domains

On 106.15.148[.]44, three additional domains were co-resolving during the same window:

• ayuncs[.]com — drops ali from aliyuncs.com
• aliyunbs[.]com — swaps cs for bs
• aliyuncs[.]me — mirrors the CN on a .me TLD

All three impersonate Alibaba Cloud’s primary object storage domain. This is a direct tradecraft match with the confirmed Breakglass cluster, which uses ai.aliyuncs[.]help, ns1.a1iyun[.]top, and ai.qianxing[.]co — all Alibaba Cloud impersonators. The operational logic is coherent: a cloud credential harvester targeting Alibaba Cloud workloads camouflages its C2 behind Alibaba-lookalike domains.

Co-resolution on a shared IP does not alone confirm same operator. But the specificity of the Alibaba impersonation pattern, in combination with the confirmed sample linkage to the same IP, makes coincidence unlikely.

Confidence on three lookalike domains: medium

Cross-Finding Observation

One IP appeared across both investigations: 121.201.109[.]98. This IP is present in the DragonEgg C2 indicators published by Lookout⁴ in July 2023 and in the LightSpy/DeepData indicators published by Volexity⁵ in November 2024 — both attributed to APT41. It did not directly feature in my pivot chains but its presence in both public clusters and its proximity to infrastructure I identified is worth flagging for other researchers to investigate.

IOC Summary

All IOCs can also be found here

ShadowPad cluster — HTML body hash confirmed (medium-high confidence)

cashmicrosoft[.]com, googledrivecloud[.]com, 45.77.176[.]85, 64.176.65[.]222, 207.148.97[.]65, 65.20.76[.]151, 104.238.148[.]158, 38.60.250[.]74, 64.176.50[.]187, 149.28.128[.]65, 149.28.145[.]214, 64.176.229[.]94, 149.28.159[.]61, 65.20.97[.]249, 139.180.211[.]117, 149.104.104[.]76, 80.240.16[.]246, 95.179.254[.]241, 65.20.75[.]136

ShadowPad cluster — Intel cert / pivot chain (medium confidence)

195.86.120[.]2, 38.60.255[.]134, 38.60.208[.]77, 65.20.67[.]90, 139.180.137[.]3, 103.140.187[.]9, 103.140.186[.]81, 193.56.255[.]178, rallyracingglobal[.]com

Hunting lead — Intel Corporation TLS certificate

C=US, ST=CA, L=Santa Clara, O=Intel Corporation, CN=Intel Corporation - Client Components Group on TCP/443, first observed February 2026, 9 hosts globally.

Winnti ELF extension

• Sample linkage: high confidence
• Operational C2 IP: medium-high confidence
• Additional lookalike domains: medium confidence

c83e768f3020119dc44392a46f587366c3ef70659592fbafb6cf94f08676bf3b, de155feb28a98a18ae7962ed321c262d80e332b646da6fe8af65d0708167faef, linux.tklolasi[.]com, 106.15.148[.]44, ayuncs[.]com, aliyunbs[.]com, aliyuncs[.]me

STIX Bundle

A STIX 2.1 bundle containing all indicators with confidence scores, sourcing, and analytical notes is available on request. Objects authored by Axel / Plausible Deniability are marked TLP:WHITE in the public release. Anchor objects referencing APT41, POISONPLUG.SHADOW, and the Winnti ELF malware family are included for analytical context. Inclusion of these objects should not be interpreted as attribution.

References

One question came to mind after reading it: are there other domains following the same naming pattern, registered around the same time?

The search

I searched for domains following a luckyguys naming convention, combined with similar registration timing and exposed services. One result stood out: luckyguys[.]cloud. The domain was registered January 6, 2026, one month after luckyguys[.]site (December 2, 2025) with the same registrar (Hostinger).

luckyguys[.]site WHOIS record	luckyguys[.]cloud WHOIS record

It also hosts a Gitea instance. These characteristics are consistent with those observed on luckyguys[.]site.

git.luckyguys[.]site hosting a Gitea instance (source: Validin)	luckyguys[.]cloud displaying a Gitea Welcome Page (via urlscan.io)

What made it interesting

IP 45.15.167[.]146 hosts all luckyguys[.]cloud subdomains. Its PTR record resolves to rbluckyguys[.]com. And the exposed login panel references “RB Luckyguys Management.”

Panel available on luckyguys[.]cloud/login (via urlscan.io on January 13, 2026)

The naming linkage extends beyond the primary domain, appearing in PTR records and application artifacts. It suggests a consistent ‘Luckyguys’ naming reuse across this infrastructure.

The subdomains also hint at an instant messaging interface (message.luckyguys[.]cloud and msg.luckyguys[.]cloud). This is consistent with the interface observed on luckyguys[.]site on April 8, 2026 (via urlscan.io).

Login panel found on luckyguys[.]site/login

The abandonment pattern

The domain resolves to significantly more subdomains than luckyguys[.]site (18 vs 5). Per urlscan.io snapshots, the apex domain was reachable in January and March 2026. None of the endpoints respond at the time of writing. It is consistent with infrastructure torn down following public disclosure, as documented in the original Team Cymru post.

luckyguys[.]site subdomains	luckyguys[.]cloud subdomains

Attribution

Moderate confidence. Overlap in naming, infrastructure, and artifacts is suggestive, not conclusive. No direct IP overlap with the infrastructure documented by Team Cymru was identified, suggesting this may represent a separate but potentially related infrastructure segment.

IOCs (observed subdomains and related infrastructure)

luckyguys[.]cloud
rbluckyguys[.]com
admin.luckyguys[.]cloud
api.luckyguys[.]cloud
cdn.luckyguys[.]cloud
chat.luckyguys[.]cloud
check.luckyguys[.]cloud
clients.socket.luckyguys[.]cloud
ext.luckyguys[.]cloud
file.luckyguys[.]cloud
git.luckyguys[.]cloud
main.socket.luckyguys[.]cloud
manage.luckyguys[.]cloud
message.luckyguys[.]cloud
msg.luckyguys[.]cloud
rdweb.luckyguys[.]cloud
rustdesk.luckyguys[.]cloud
socket.luckyguys[.]cloud

Last week, I shared a small phishing campaign encountered during routine monitoring. This post focuses on what came next: how a single artifact can uncover infrastructure, tooling, and ultimately a likely operator.

Both pages in the screenshot share the same filename: invite.php. I was wondering “isn’t this invite.php suspicious? Is it used for legitimate purposes?” What you should do with your assumptions is to:

1. Make them clear
2. Test them

So let’s do it. On urlscan.io (URL scanning service), I got 3230 results for the query page.url:"/invite.php".

Disclaimer: urlscan.io has a bias toward suspicious URL. As it is crowdsourced, so you depend on user submissions, which are biased toward suspicious URLs.

urlscan.io search for /invite.php

Looking at the results, you can also see that some URLs have the path: root.tld/Windows/invite.php. Since this path appears multiple times and suggests a structured deployment (/Windows/invite.php), I’ll use it as a starting point to test whether we’re looking at a shared template or infrastructure.

What does the page tell us?

First, we should determine how we would assess that they are—or not—the same page. What I usually do is straightforward: I open the HTML file and look for anything specific. I try not to be too attached to terms related to Microsoft Teams, but more on the structure of the page.

The page has:

• a title: Microsoft Teams Voicemail Update
• a link to a google fonts: Roboto:wght@400;50
• an embedded stylesheet: zoom-blue: #0072c6, text-color: #555, bg-color: #f4f7fa, border-color: #0072c6, button-hover-bg: #0072c6
• a script block

The script starts by initializing variables related to element ID, then a preloader message transition and a redirect countdown. At the end, it calls the function startRedirect which writes “Redirecting” in the download-info element and redirects the user to the page microsoft-store.php.

invite.php DOM from teams-connect-voice[.]online

There is a lot more than you can extract. For instance, the manualDownload element has a href to microsoft-store.php and the image is located at ./img/micro.png. All those small elements will become quite handy when we will need to compare with others pages. Taken together, these elements form a reusable fingerprint that can be used for detection or retro-hunting.

Now that we have a clear idea of what to look for, we can start comparing pages. From there, I pick a random urlscan.io result.

When opening the result from lankystocks[.]com, we see a 404 page. It is common on urlscan.io to have this kind of behavior. urlscan.io performs on-demand scans, so some scans occur after the page or site has already gone offline.

404 page from lankystocks[.]com on urlscan.io.

To make sure, always check the full scanning history, and starts from the beginning. This will allow you to get an understanding of what happened on the website according to urlscan.io data. It is important to remember, what you see here is only URLs submitted to urlscan.io, not every page available.

lankystocks[.]com scanning history on urlscan.io

From there, you can see that the domain was first scanned 2 months ago (February 06), and the first URL with invite submitted the a week after, on February 13th. You can also see that the page download.phpdownloads an executable file named ZoomWorkspaceClientSetup.exe(sha256: 5701dabdba685b903a84de6977a9f946accc08acf2111e5d91bc189a83c3faea). Both the file and domains were reported by Microsoft as part of a “Signed malware impersonating workplace apps deploys RMM backdoors”. So we are onto something. But what about this page ?

We can see that the title is different (Zoom Client Update). The script block is similar, but this time it has comments and a different preloader message transitions.

lankystocks[.]com invite.php DOM, this time related to Zoom

This is clearly the same template, with minor variations. It can be because one of the page was modified by someone to make it easier to manage—which explains the comments—or that on the contrary someone removed comments altogether.

I looked at other HTML documents, and I always found the same page. If it is always the same, you can search for the hash instead of always opening and manually viewing the DOM. I found 252 results with hash:902ca83e4b0047d965ecea1059cd8d2212c386c4751f534cafc9287bc230fa64 for 88 domains. The oldest one is from 9 months ago.

At this stage, we’ve established that multiple domains reuse the same phishing template, suggesting either a shared kit or a coordinated campaign.

Clustering the infrastructure

When you have a lot of data, what is interesting is to create clusters. This allows you to see details under a new light and split the work.

Now let’s cluster based on hosting. As I stated earlier, it is not because the HTML page is the same that it is always the same person—or group of persons—behind. To further our work, we will cluster every page based on hosting behaviors. At some point, it is possible that we regroup clusters together, based on other elements. To make the clustering easier, it is best to set the option “Details: Visible” on urlscan.io. I also collapsed results by Hostname.

Clusters can be quickly identified with a simple search within the page.

A simple CTRL+F on urlscan.io is just what you need to make this clusters

We end up with three main clusters:

• The SHOCK ASN cluster: 47 domains are hosted on this ASN.
• The CloudFlare hosted Cluster, with 17 domains.
• The NameCheap cluster with 4 domains.

The rest of the domains are hosted on ASN, but there are only one or two at a time. Clustering them would take time and create a lot of small clusters. It is something you might want to do if you are concerned about this threat, but I will leave it there in this blogpost.

Clustering gave us a new insight: more than half of the domains we found are shared on the same ASN, which strongly points to a group or individual.

A small OPSEC mistake

The main interest here is the SHOCK ASN cluster, with more than half domains included in this cluster. Looking at the hosting of some domains on Validin, I found two points of interest.

DNS records for usz00mczyiee[.]store on Validin

In the DNS Start of Authority (SOA) records, you can see that the SOA_MNAME points to ns7.loominost[.]com and that the email johnseamus89@gmail[.]com is used as SOA_RNAME. Sometimes, less experienced operators have so little OPSEC that it makes them a breeze to track. In a previous role, I was able to track a similar individual with this exact technique. He had more than 5 000 domains.

Validin’s data says that the email is related to 1458 domains. By a quick look, I found that the more recent ones all look like ClickFix/Video Conferencing related domains.

All domains related to johnseamus89@gmail[.]com according to Validin

A report from BreakingGlass intelligence mentions the email and its related activities. The report identifies ClickFix domains linked to johnseamus89@gmail[.]com. They also found that loominost[.]com and phishing pages share the same Google Analytics ID: G-XDVX0QEYVC. Finally, it states that the team could not link the email—johnseamus89@gmail[.]com—and the loominost operator with enough confidence. This aligns with their conclusion: at this stage, the link between the email address and the Loominost operator remains unconfirmed.

However, by pivoting further—specifically by correlating the email address with external forum activity—we can introduce an additional layer of context that was not explored in their analysis.

Kevin

At this stage, the infrastructure pivot (SOA email + nameserver) provides a strong lead—but not yet an attribution. To go further, I looked for external references to the email address.

Searching for johnseamus89@gmail[.]com returns a thread on BlackHatWorld[.]com, an internet marketing forum.

BlackHatWorld user toufic complains about not being able to reach Kevin with email johnseamus89@gmail[.]com]

In a thread titled “Kevin’s PBN”, a user references this email address as a contact point for an individual operating under the handle eatingMemory. While forum content should always be treated cautiously, this establishes a potential link between the email observed in DNS records and an online persona. The original post also shares two ways of contacting eatingMemory:

• the skype address kevinleeck
• the email adsynced@outlook.com

End of eatingMemory first post on the Kevin’s PBN thread on BlackHatWorld

Separately, the same eatingMemory account advertises, on July 11th, 2023, a hosting service named Loominost.

eatingMemory post about Loominost on BlackHatWorld

This is particularly interesting given that:

• the SOA records observed earlier reference ns7.loominost[.]com
• the same infrastructure is tied to phishing domains using the identified template
• the email address appears both in DNS data and in forum discussions referencing eatingMemory

Taken together, these elements suggest that:

• the Loominost service,
• the email address johnseamus89@gmail[.]com,
• and the eatingMemory persona

are likely connected and may be operated by the same individual (referred to as “Kevin” in the forum thread).

While BreakingGlass did not establish a confident link between the email and the Loominost operator, combining infrastructure pivots with forum intelligence provides a stronger—though still circumstantial—case for overlap.

What can be stated with more confidence is the behavioral pattern:

• large-scale domain registration (≈1500 domains linked to the email)
• recurring use of shared phishing templates
• overlap with ClickFix / fake conferencing lures
• continued activity within SEO and marketing forums

This suggests an operator with a background in SEO-driven infrastructure, repurposed for phishing and malware delivery at scale.

I will not attempt to go further in identifying the individual behind these activities.

At this point, we’ve moved from a single suspicious filename to a reused phishing template, clustered infrastructure, and a likely operator—entirely by pivoting on small technical details.

What’s next

From a defensive perspective, simple artifacts like file paths (/invite.php) or shared assets can serve as reliable pivot points for detection and retro-hunting. You can find all related IoCs here.

There’s more to explore around the ‘Invite Only’ ClickFix sub-technique, which I’ll cover in a follow-up post, but that’s a thread worth pulling separately.

Together, these shifts suggest a paradox: Iran’s cyber operations may be becoming less coordinated—but more unpredictable.

The fragmentation of the IRGC

The airstrikes delivered by the U.S. and Israel forced the Iranian military to divide into smaller operating cells to reduce the impact of strikes. This decentralization makes units smaller, but also more autonomous². Historically, forced decentralization has produced more autonomous but less coordinated units—as seen with the IRA’s shift to cell-based structure in the 1980s, or Al-Qaeda’s fragmentation after 2001. In both cases, the result was less central coherence but greater operational unpredictability.

Losing senior commanders in such a short time might disrupt the chain of command, and units might lose their central coordination. For cyber units—especially those linked to IRGC, known publicly as APT33, APT35, APT42, Cyber Av3ngers and Cotton Sandstorm—it could mean less coordination, but also more freedom to act, perhaps independently.

Fragmentation may not just decentralize operations—it may also reshape incentives. Units operating with greater autonomy may seek to demonstrate their value through more visible or more aggressive activity, particularly in a context where central oversight is weakened. At the time of writing, there are no public reports of a noticeable change, but the conflict is not over. CISA published an advisory about Iranian-affiliated cyber actors targeting the critical infrastructure in the U.S.³. Despite not providing a clear attribution, the advisory seems to be related to Cyber Av3ngers, a group related to IRGC-CEC.

Iran has long relied on plausible deniability for its cyber operations—sponsoring groups that could be disowned when needed. In an overt conflict, this matters less. When missiles are already flying, denying a cyberattack does not change much for escalation management. But deniability does not go away, it changes audience. Third-party states and post-conflict diplomacy still create incentives to keep some operations technically unattributed. Fragmentation cuts both ways here. Units operating without central oversight may conduct operations Tehran never sanctioned—making deliberate deniability harder to manage. But decentralized cells also look exactly like non-state actors. Attribution becomes harder, and deniability emerges by accident rather than design.

Fragmentation may also push some units toward external dependencies they would not have relied on previously. Russia is reported to provide Iran with satellite imagery and collaborate on cyber operations⁴. There is already a report about MuddyWater—a group likely related to the Ministry Of Intelligence and Security (MOIS)—usage of a Russian Malware-As-A-Service toolkit. While the report states that the tools were bought “off the shelves”, they also might have been handed out willingly by Russia given the historically permissive relationship between Russian authorities and cybercriminal ecosystems. In the past, members of the Federal Security Service (FSB) were directly connected to cybercrime groups, like in the Evil Corp case⁵.

Internet Blackout

Since January 2026, Iran has shut down its Internet access. While some privileged individuals were handed “white SIM cards”—granting them unlimited, unfiltered Internet access—the vast majority of citizens can only access a downgraded domestic network⁶.

The regime’s stated reasoning is that cutting Internet access helps prevent incoming cyber attacks, yet it remains unclear how much it does. This is not the first time that Iran uses this tactic; it did the same in the 2025 conflict⁷. Knowing this, it is plausible that military strategists planned ahead and did enough pre-positioning without relying too much on Internet connectivity after the start of the conflict. In reality, it is more likely that the Internet shutdown is a convenient disguise for digital censorship. The shutdown happens just after a massive crackdown where thousands of Iranians were reportedly killed⁸. Restricting access to the Internet might also be a way to avoid the spread of information about the killings, both within Iran and abroad and to make it harder for citizens to organize.

Iranian cyber actors should still retain Internet access broadly comparable to pre-conflict levels. But it is likely that they had to relocate some services and tooling outside of local servers, and possibly out of Iran, to be more agile. It is unclear which organization is responsible for the Internet shutdown in Iran, but if IRGC is the leader, it might abuse its position to pressure or undermine competing agencies such as MOIS.

Taken together, these dynamics—fragmented command structures and disrupted infrastructure—create compounded uncertainty. Iranian cyber units may be operating with less oversight, less coordination, and less stable tooling simultaneously. This is not necessarily a sign of weakness: it may produce more erratic, harder-to-predict behavior. But it also creates friction that even well-resourced threat actors cannot fully absorb.

Conclusion

If some of what I am writing is true, it means that in the upcoming days we may witness Iranian threat actors adapting to the situation in their own ways and diverging from their known TTPs. It could also mean some operations become more opportunistic or that some units seize the opportunity to shine above their rival units.

These are not predictions but hypotheses—meant to be tested against the behavior of Iranian cyber actors in the coming weeks. This analysis was produced under the banner of Plausible Deniability—a fitting name, perhaps, for a piece about a regime that has always preferred to keep it that way.

References

On January 2025, Trellix published an article named “Blurring the Lines”. It discuss the fact that it is increasingly difficult to tell cyber-crime and APT groups from each other with TTPs. Even if the title of the article promised to explain “how”, I did not really get it. So I wrote what I think is how threat actors all use the same TTPs: they just do what is most likely to work.

Information systems are still vulnerable. threat actors want to be the most efficient possible when exploiting them. In competitive video games, this is what is called the Most Effective Tactics Available (META). In the context of cyber threats, it is all the Tactics, Techniques and Procedures (TTPs) that are the most likely to achieve the threat actor objective without detection and at the lowest possible cost. The META is dynamic. The threat actors learn and adapt to the cyber ecosystem, just as defenders do. If a tactic or technique is too well countered by the defenders, threat actors will change accordingly. For instance, macro-embedded documents were the go-to for initial access. Microsoft finally decided that it was time to consider this seriously, so it is a technique that belongs almost to the past. I still encounter some macro-related documents once in a while. These documents exploit old vulnerabilities like CVE-2017-11882. Some people did not install the patch, even today.

We tend to forget, but threat actors are like penetration teams¹. They have at their disposal the sharing of knowledge from the offensive cyber community, especially their tooling. These tools are as efficient as custom-made tools—sometimes even better—and they are free. Because anyone can use them, attributing the usage to a particular group is not possible. Some of these tools are well established in the META.

The META also targets the insecurity by default of information systems and the difficulty to monitor them. Defense evasion techniques exploit legitimate tools and functionalities of the operating system. Living of the Land binaries are first used by the operating system, applications, and administrators. Windows is designed to allow process injection and loading DLLs. Command and control infrastructures are similar. Some legitimate services offer the same functionalities, like uploading files and sending data. Detecting the nefarious intent behind those behaviors on a large information system is a big challenge.

For threat actors, what has been spared in R&D costs is paid by reduced chances of success against defenders aware of the META. This is a risk cybercriminals—especially the least advanced—are more willing to take. They can always find a new target. For groups affiliated with governments and the military, they might prefer to have every chance on their side, that is if the target is worth the effort. They will more likely use their own tools and infrastructure to avoid detection.

Not every corporation can—let alone be willing to—watch over each PowerShell script execution, or block access to Dropbox. The amount of doors that can be opened by attackers is massive, and they only need one to be successful. As every group is using it, implementing defenses against the META can mutualize the effort² and keep your organization safer against a lot of threats. The META is not a failure of attribution—it is a reminder that efficiency is universal. Nation-state actors and cybercriminals converge not because they collaborate, but because they operate in the same ecosystem and respond to the same incentives. Defenders who understand this stop chasing group labels and start focusing on behaviors. That is where they can deal with threat actors the best.

A quick note: In the following article, I refer directly to Iran, rather than specific entities such as MOIS or IRGC. I believe that it makes the reading easier, without altering the statements. For a deeper dive into the ecosystem, I recommend to read Sekoia’s overview, from which I also used for reference.²

Stuxnet: The Wake-Up Call

First, the development of Iranian cyber capabilities and their usage should be understood as a direct result of lessons learned from Stuxnet. Right from the start, Iran has been the target of two of the biggest cyber powers in the world. And Iran considers them both their arch enemies. Stuxnet tried to disrupt Iran’s nuclear program, a strategic asset, potentially military in nature. Stuxnet also sent a message to every country in the world: cyber can be used to achieve kinetic objectives and it is considered fair game. The impact on Iran’s thinking about cyber is unknown for sure, but what is clear is that they understood what can be done with it, and worked on it³. The same can be said about other major players, mainly China.

Cyber attack as retaliation

Iran was not trying to use cyber attacks only as a plausible deniable tool, but also as both a weapon and a message. The first reported usage of Shamoon in August 2012 against Saudi Aramco—Saudi Arabia’s state owned oil company—happens right after a cyberattack on Iran’s oil terminals on April 2012⁴. There is no official statement linking the two events, but it is hard not to see a possible retaliation. The attack on Iran’s oil terminals was thought to be carried out by the U.S., and a retaliation against one of their biggest allies, Saudi Arabia, on the same sector can be interpreted as a response in kind. If Iran needs more stealth, it could use it too.

Iran was—or at least tried to be—stealthy. The original article omits all espionage activities attributed to Iran, whether they are domestic or abroad. The first documented campaign is from 2007, so 5 years before the Shamoon attack. It was somehow stealthy because it did not get publicly reported until 2016⁵. APT35, APT42, Infy, MuddyWater or Oilrig deserves mention when discussing Iran’s cyber capabilities because they were developed alongside wipers and information warfare, not in isolation.

Iran can also use its wide network of proxies to at least avoid direct attribution. For instance, the BiBi wiper is reported to be used by a “Pro-Hamas” group, but Check Point Research has assessed Void Manticore, an Iran-linked group, as the actor behind BiBi⁶. The same can be said about Handala and other persona: they first appear as legitimate Palestinian group, but turned out to be operated by Iran’s Ministry of Intelligence and Security (MOIS) according to Check Point Research⁷. Iran might even—if it is not already the case— give them tools and methodologies to carry out cyber attacks like they give them weapons and cash, making attribution even more challenging.

While visibility has played a role in some Iranian cyber operations, Unit42’s framing this as a priority over stealth overlooks Iran’s parallel investments in espionage and proxy networks. The truth is more nuanced: Iran’s cyber strategy is context-dependent, balancing overt retaliation with covert influence and intelligence gathering.

Adaptation Over Innovation: Iran’s Cyber Pragmatism

Iran has already introduced plausible deniability in their cyber operation since at least 2007 with their first espionage campaign. So ransomware was not that much of a smokescreen. This is not to say that it was not used in that way in some occurrences. But again, it needs a bit of context.

The 2020-2022 period was a big boom for ransomware activities: infrastructures needed to adapt to COVID restrictions and the state of crypto meant that it was easier to get paid with it than it was a decade ago. Groups started to emerge, cause mayhem and gain a lot of money: more than $1 billion in payments reported in the U.S. only in the period 2020-2021⁸. Not only cybercriminals were interested.

It was a golden opportunity for some states: you can attack the western economy, and make some money at the same time. This is not lost on countries that were under heavy sanctions from the West, mainly Iran and North Korea. Iran-aligned actors did engage in ransomware operations, and not only as a plausible deniability cover^{8 9}. Other states, like Russia and China, adopt a more hands-off approach, allowing domestic hackers to operate with minimal oversight—sometimes benefiting from their actions while avoiding direct responsibility. Just as Iran adapted to the ransomware boom, it also capitalized on the growing reliance on administrative tools.

Administrative tools and EDR solutions did not exist, or not widely used in the previous decade. Now, they are powerful solutions for any IT department handling an infrastructure. It is also a great gift for threat actors, as MDM/RMM tools literally holds the key to the kingdom. Back in the day, you had to find a way to access the network, map it, make lateral movement and privilege escalation, until you are satisfied and launch your attack with your signature wiper. That’s a lot of things to do, and a lot of detection opportunities, and a good EDR might catch it.

Now, threat actors just have to find a way to get the RMM administrator account and type a small set of commands. No need for custom development, and less room for attribution. It makes detection significantly harder, as activity can blend with legitimate administrative operations. Iran evolved its cyber capabilities and interest accordingly, which shows that they are well aware of their environment. It also highlights that Iran’s cyber strategy is less about innovation than about pragmatic adaptation to constraints and opportunities. Economic constraints likely reinforced Iran’s preference for cost-effective, high-impact cyber operations.

Conclusion

The conclusion of Unit42’s article is hard to dispute, defenders should take a very close look at their identity management and the rights they give to administrative tools. If they fall in the wrong hands, it could be a catastrophe. Unit42’s warning about identity weaponization is valid and urgent. However, by focusing solely on this tactical shift, we risk losing sight of the broader strategic picture: Iran’s cyber operations are not just about tools but about adapting to achieve long-term geopolitical goals. Iran-aligned actors didn’t just adopt ransomware as a smokescreen—they leveraged it as a dual-purpose tool, blending financial gain with strategic disruption. This adaptability reflects a broader pattern: Iran’s cyber operations evolve in response to environmental opportunities, such as the rise of cryptocurrency or the proliferation of administrative tools. Understanding Iran’s cyber operations requires looking beyond tools and tactics to the strategic logic that drives their use.

References

First of all, what is .NET ?

• C# programs run on .NET, a virtual execution system called the common language runtime (CLR) and a set of class libraries. The CLR is the implementation by Microsoft of the common language infrastructure (CLI), an international standard. The CLI is the basis for creating execution and development environments in which languages and libraries work together seamlessly.
• Source code written in C# is compiled into an intermediate language (IL) that conforms to the CLI specification.
• When the C# program is executed, the assembly is loaded into the CLR. The CLR performs Just-In-Time (JIT) compilation to convert the IL code to native machine instructions. The CLR provides other services related to automatic garbage collection, exception handling, and resource management. Code that’s executed by the CLR is sometimes referred to as “managed code.” “Unmanaged code,” is compiled into native machine language that targets a specific platform.

More on C#

C# is an object-oriented, component-oriented programming language. C# provides language constructs to directly support these concepts, making C# a natural language in which to create and use software components. Since its origin, C# has added features to support new workloads and emerging software design practices. At its core, C# is an object-oriented language. You define types and their behavior.

• Some of the cool features that C# has a program language includes :
  • Garbage Collection : automatically reclaims memory occupied by unreachable unused objects
  • Nullable Types : guard against variables that don’t refer to allocated objects
  • Exception Handling : provides a structured and extensible approach to error detection and recovery.
  • Lambda Expressions : support functional programming techniques
  • Language Integrated Query : syntax creates a common pattern for working with data from any source
  • Support Asynchronous Operations : provides syntax for building distributed systems.
  • C# allows dynamic allocation of objects and in-line storage of lightweight structures.
    • C# supports generic methods and types, which provide increased type safety and performance. C# provides iterators, which enable implementers of collection classes to define custom behaviors for client code.

That’s for the managed code part. C# also allows the code to be unmanaged. You see all the features I listed above ? You can still say, screw this, I’m going to do it my own way. Unmanaged code doesn’t run inside the CLR and thus are considered unsafe.

💡 : There is a functionnality called Ahead Of Time that compiles the code directly to native code and doesn’t need the JIT compiler to run while still being managed code. It’s brand new in .NET7 ! - It only supports a limited number of libraries in .NET 7.

C# in the context of malware

C# is very popular in malware. First because it’s an easy language with powerful features, as we have seen above. You can also have access to Windows functionality rather easily. With just these arguments, it’s easy to imagine why Threat Actors might be interested in this language. Even more when you take into account the amount of open-source code available to do what you want (even bad things, like a RAT).

The advantage of using C# is that you can easily implement functionality and modules and focus on evasion. To do so, Threat Actors use packing and/or obfuscation. For example, AgentTesla (of course it’s a RAT) can look like this :

You can read a cool AgentTesla Analysis here if you are interested to see packing/obfuscation in action

Moreover, Threat Actors can even leverage specific .NET functionalities. If you did the FlareOn 9, for your greatest pleasure, you had to deal with two .NET challenges. They are both inspired by real world malwares and abuses Mixed Mode Assemblies and Dynamic Methods.

.NET Reverse Engineering

As we saw, .NET malware can be hard to work with, because of the various mechanisms Threat Actors uses. But they do so because .NET by design is rather easy to analyze. Remember the schema I did just before? We can actually decompile the generated executable with awesome tools like DnSpy.

💡 :Just to be exact, when using .NET decompilers we see decompiled code based on the IL, so be aware that Threat Actors might modify the IL directly.

By default, .NET executable also contains a lot of metadata. My favorite one is the GUIDs. It’s an awesome pivot to try, you might find APT related code well hidden on GitHub (just imagine…). You can read more about them here. VirusTotal also implement them, and you can pivot directly from there !

Going further

If you are interested in .NET analysis, I can’t recommend enough this paper from Alexandre Borges There is also interesting people on Twitter :

• @dr4k0nia
• @washi_dev
• @vinopaljiri

Conclusion

I was really surprised with the engagement of my dumb question, and I thought that it could be interesting to compile (pun intended) everything that was said and add some more information. Doing a blog post is easier than replying to all conversations. Let me know if you found this interesting. I know I haven’t been that deep into .NET shenanigans, but others already explained everything

I went to the CTF with a new laptop, and so I didn’t have everything setup. It means that I didn’t have a Windows VM available, so no dynamic analysis for me ! It’s fine, I tend to prefer analysing stastically because it forces you to understand deeply what’s going on, instead of just watching the stack/registers for a string !

I also take this opportunity to showcase how I use Ghidra to give a more detailed analysis.

So, let’s analyse this little malware, shall we ?

Analysis

Satan helped me to create a new malware :), finding what it does will lead you to the flag !

As it’s a CTF challenge, I didn’t do the usual MD5/SHA reconnaissance, I opened it straight into Ghidra.

The beginning of the functions looks like this :

A lot of things is happening, but we don’t really care : most of it is the CRT making various checks.

What we want to look further is FUN_140001c00

We got two things going on :

• A function that uses the GS register and the unicode for “ntdll.dll”
• Another function that uses the return value from the first function

💡 : FS and GS are two segments registers. You can use the FS register on Windows 32-bit to access the TEB, and the GS register for Windows 64-bit. You can read more about segment registers and why they aren’t used anymore here : https://stackoverflow.com/questions/10810203/what-is-the-fs-gs-register-intended-for

So now that we know that the in_GS_OFFSET relates to the TEB, we just need to know what the 0x60 offset relates to. We have the answer here : 0x60 offset points to the PEB

So the two parameters for the function FUN_140001000 are actually :

• unicode “ntdll.dll”
• PEB

With that information, it makes it easier to understand what’s going on here : This functions searches for the ntdll base address by enumerating the InMemoryOrderModuleList.

Going back to the calling function, we understand it deeper :

With that in mind, we can move forward to the second function. In it, we can see what looks like stack-strings, and a function called several times with some arguments not changing :

Looking into this function, it’s what we got :

It’s a simple xor decryption routine. A little clean-up :

💡 : Little tip when dealing with stackstring in Ghidra, once you know the size of the data, assign it as an array. For example, local_60 seems to have a size of 24, as we can see in the xor_decode function. Retyping the variable to a byte[24] give an easier way to visualize :

Now we can decode the variables with the xor key 0x7861786f which gives us :

• NtAllocateVirtualMemory
• NtWriteVirtualMemory
• NtCreateThreadEx
• NtWaitForSingleObject

You might have see it, but one decryption uses a different key than the rest. Decoding it, it isn’t a string… What can this be ? We will check it later.

I forgot to ask : with the API names we just decrypted and the description of the challenge, did you found what’s next ? No ? Let’s continue and see what happens.

The API names are used as parameters for two functions after their decryption: FUN_14000010f0 and FUN_140001200

FUN_14000010f0

We can see here that FUN_14000010f0 looks in NTDLL Export Directory for the address of the function passed as the third parameter.

FUN_140001200 then looks at the retrieved address and validates that it’s a syscall stub.

Wait, syscall I said ? With those APIs, what we just saw and the description, we have enough clues to understand what’s going on : It’s an implentation of Hell’s Gate !

If you don’t know about Hell’s Gate, it’s a technique used to bypass EDR hooks. If you want to dig deeper into Hell’s Gate and/or EDR bypass, be sure to check this article by AliceCliment as everything is beautifuly explained !

Here is little drawing of the inner working of the program :

Now we just need to decrypt the payload and understand what it does in order to find the flag !

I have done it using this cyberchef recipe. The output is the shellcode we want.

Opening it in Ghidra, and manually disassemble gives this :

Be careful, you can’t XOR decode this one in Cyberchef. To do so I used this python one liner :

>>>bytes.fromhex(hex(0x7fb9e16be26c4d79 ^ 0x298a623990e3f1b)[2:]).decode('utf-8')[::-1]

'brb{HG!}'

And here we go ! We got our flag !

Wrapping up

I really liked this challenge. First because it wasn’t a crackme like often in the Reverse category, and more interesting it’s a technique I haven’t reversed yet so it’s pretty cool !

Turla (also known as Snake and more) is one of the oldest espionnage group known so far. Activities from the Turla group are known since 2006. They are believed to be a Russian State Sponsored group, with interests in Governments, Military and Press.

What is pellicular about Turla is their capabilities and also their behavior regarding attribution. Throughout this article, we are gonna explore it in more details.

Technical geniuses… But also morons

Turla is known for having a strong technical side. Even if they also uses open source tools (like everyone else), they also develops their own exploits and their malwares are hard to analyze, with heavy use of obfuscation and unknown windows functions.

Throughout the years, Turla campaigns revealed themselves as sophisticated. They were able to leverage a Microsoft Exchange Transport Agent to enable persistence on a mail server with LightNeuron, used at least two zero days on the Epic Turla campaign, bypassed driver enforcement and lastly being able to do (supposedly) MITM attack at the ISP level. Moreover, they are creative with their TTPs, for instance with the Satellite Turla campaigns (also called MAKERSMARK), where they hijacked satellite internet links (http://blog.passivetotal.org/snakes-in-the-satellites-on-going-turla-infrastructure/).

An interesting thing about the satellite Turla campaign is a leaked Canadian Intelligence document, which explains that despite having a highly sophisticated technical side, the OPSEC used by operators seems to be lacking: They used compromised infrastructure for personnal browsing. They even describe the campagne as “Designed by genius, implemented by morons”. This is not surprising, considering that APT ties with Intelligence Agencies is not that advanced, they don’t have access to all OPSEC knowledge and processes when doing operations.

You try to false flags

APT groups would rather avoid being detected than misdirect attribution. That’s not really the case with Turla. They are stealthy, but won’t hesistate to cover their tracks by impersonnate another group. We will see two campaigns attributed to Turla that showcase this.

Made in China… Or not

In 2012, during an intrusion Turla became aware that they were detected and an IR team was looking for them. They decided to plant a false flag by downloading, installing and desinstalling a malware attributed to a Chinese APT, known as Quarian. It was even more clever than this, because the C2 that they used during this operation was also based in China, to further throw the responders on the wrong road. However, the planted sample wasn’t even configured and wasn’t used in the operation. The analysts figured out that it was most likely to disturb them and that Turla had just copied this sample from elsewhere.

Iranian Take over

The Middle East is a area of interest for both Iran and Russia. There is no surprise to see them actively operates there. However, what is unusual is the fact that Turla used two Iranian malwares for their operations. They got access to the source code of two malwares (Nautilus and Neuron) and used them as their own. What they didn’t know it that neither of them was previously identified nor attributed to Iran. They were only seen with Turla operation.

But it goes deeper than this. In fact it seems that Turla was able to completly overtake the Iranian infrastructure and used it for their own operations It’s the only occurence of an APT completly taking over another one

Conclusion

Turla is a really interesting threat actor by their use of capabilities and the way they play around attribution. As always with attributing incidents and campaigns to a specific threat actor, it’s a tricky exercice done by security companies. It’s never a declaration, but an assessment based on attributes that can (and must) be reexamined in the future.

Let’s get technical

I tried a couple of things, without much success. The packer uses A LOOOOOOT of forand while loop, making it almost impossible for an emulator like Qiling to run it. It also makes it harder to understand what is going on. I let that sink, until one day, @c3rb3ru5d3d53c showcased her new project :

I found it very cool, and she gave me a lead on how to proceed with my problem :

I never did this kind of thing, but it was about time ! First I needed to understand exactly how the packer proceed.

💡 : Because of how the code is made, I can’t really show interesting screenshots as execution is scattered in all places

It first loads two chunks of data from its PE sections. At the time of writing, there is three possibility :

• .rdata and
• .ndata and .data
• .data (both chunks are inside)

One chunk is actually the obfuscated/encrypted/encoded packed executable, the other one is only use during the decryption process.

Then the payload gets decoded, and decrypted using a hard-coded value (it’s the first 4 bytes of .data divided by 512, I also refer to it as “marker” when in the 3rd variant) Afterward, there is an obfuscation that takes place, however the code changes between samples… How to overcome this ? Despite not being the same, the code looks the same, meaning I can catch the pattern with a Yara rule… Which I did.

comparison of three code variants \n

I get the code, and run it using Unicorn or Qiling.

💡 : As a principle, I always prefer when computers handle the hard work

And here we are, at the final stage ! The second chunk of data is finally used to decrypt the packed executable.

Only IcedID ?

When doing this research, I was focused on IcedID. To test my code on multiple samples I made a Yara Rule and a retro hunt using Risk Mitigation.

💡 : I couldn’t sell my whole family just to pay for VirusTotal… Sorry about this

Guess what I found ? Not only IcedID, but also Bazar, like one from this campaign.

So either the packer is available for sale on some forums, or the two groups shares tools sometimes.

I couldn’t really find much more info on this, or maybe there is none available. Maybe you, who are reading this, have more info on the subject ! If so, do not hesitate to hit me up on Twitter !

Cleaning our hands, for real this time

That’s it, now we can really be clean, as I made three scripts in order to automate and make your life easier :

The first one is a python script, as simple as that. It uses Unicorn for code emulation, and decrypt the IcedID config… If the unpacked executable is an IcedID sample, of course.

The second is a Karton Unpacker module, so you can use it in your Karton pipeline.

The last one is a mwcfg module, you can decrypt an IcedID sample config with it.

Conclusion

And here we are. From what I know, it’s the only public work on Iceloader, so it’s like when you find a dinosaur species : you can name it whatever you want. It’s not really my idea, it came from @c3rb3ru5d3d53c, but I like it. Otherwise I would have given it a Pokémon name (most likely Regice).

Hope you liked what you just read, and also my work ! This was really fun to do, despite not making great advance every day, as I’m doing everything during my free time, so it’s like 1-2hours a day :(. But overall a really cool challenge !