CL-STA-1178 and the Blinder Tunnel Campaign: Iranian-Nexus Operators Turn a Coding Test Into a Foothold

Executive Summary

On 6 October 2026, Palo Alto Networks Unit 42 published research on a campaign it calls Blinder Tunnel and attributes to a cluster it tracks as CL-STA-1178. Unit 42 assesses “with high confidence” that the activity is Iranian-nexus. The main target it describes is an individual in Iraq working in critical infrastructure, whom Unit 42 assesses to be “likely a software engineer” based on where the coding-test samples were submitted from. The lure was a recruitment process impersonating the IT department of Dubai Airports.

In our assessment, the campaign is a useful case study because most of it relies on abusing trusted developer tooling rather than a new software vulnerability (Unit 42 does describe DLL search-order hijacking as exploited). The lure was a Visual Studio project whose own build file ran the attacker’s code when the project was opened, before anything was compiled. Unit 42 does not confirm that the Iraqi target was compromised, so what follows describes the delivery chain and tooling it analysed, not a confirmed intrusion. That chain used legitimate GitHub infrastructure for command and control, and a custom loader for the open-source Chisel tunnelling tool that would turn an infected workstation into a network pivot.

This article is based on Unit 42’s research, which is the only primary source for the campaign claims here. It is a vendor reporting its own telemetry and detections. Unit 42 links the actor to earlier Elastic Security Labs reporting, “The Shelby Strategy”; we opened that report to confirm the points in the Targeting and Peaky Blinders notes below, but did not audit it in full. Where we go beyond what Unit 42 states, we say so.

Threat Actor Profile

Name and tracking. CL-STA-1178 is a Unit 42 “cluster” designation, the label the team uses while an activity set is still being characterised and before a group name is assigned. The malware and infrastructure use a “Peaky Blinders” theme: a GitHub account named peakyblinders-tm, a loader called ShelbyLoader and a command-and-control component called ShelbyC2. Elastic’s earlier report notes that Arthur and John Shelby are characters in that TV series. Unit 42 notes that an MP3 theme song was embedded in a README in the attackers’ public repository. The naming is a link to the earlier Elastic campaign; it is not one of Unit 42’s attribution bullets.

Attribution basis. Unit 42 lists four bullets of evidence behind its attribution:

• Infrastructure. The campaign infrastructure is hosted in Iran. 87.248.129[.]239 sits on an Iranian ISP, but Unit 42 ties it to Blackwood activity in 2025 (see the infrastructure table below). The Hetzner-hosted relay at 91.107.156[.]29 links to Persian-language domains, possibly bought through an Iranian reseller.
• Metadata. The MP3 in the public README carries metadata that points to MusicDel[.]ir, an Iranian music site.
• Regional victimology. Targeting of critical entities across Iraq, Israel and the UAE.
• Convergence with Iranian playbooks. Aviation lures, AppDomainManager hijacking, GitHub dead-drops and in-memory PowerShell wrappers, which Unit 42 describes as “low confidence overlaps” with prior Iranian activity.

Confidence and caveats. Unit 42 attributes the activity “with high confidence to Iranian state-aligned attackers”. Links to specific named groups are weaker: it reports only low-confidence overlaps with the clusters it calls Screening Serpens (AppDomainManager hijacking to disable ETW; aviation-themed fake hiring lures) and Agent Serpens (GitHub fallback dead-drop resolution; memory-only PowerShell), “none of which are strong enough to attribute CL-STA-1178 to any of these groups specifically.” We would treat CL-STA-1178 as its own cluster for now, and it should not be folded into an existing profile on the strength of those overlaps. Shared technique alone is weak evidence of a shared operator. We did not independently verify the passive DNS, MP3 metadata or reseller suspicion behind the attribution.

Likely objective. Unit 42 describes the activity in espionage terms. In our assessment, the targeting of an engineer inside critical infrastructure suggests the goal was access to that person’s environment, credentials and network position rather than immediate disruption. That is our reading. Unit 42 does not state an end objective, and the report does not describe what, if anything, was taken.

Targeting and Victim Sectors

Unit 42 describes three distinct strands of activity:

1. Iraq. The primary focus is an individual, likely a software engineer, in critical infrastructure. Unit 42 says the actors target telecommunications, aviation and other critical entities across Iraq, Israel and the UAE; it does not say which sector the Iraqi target worked in beyond “critical infrastructure”.
2. United Arab Emirates. The lures impersonated Dubai Airports IT. Unit 42 says it is “not aware of any breach, compromise, or vulnerability within Dubai Airports infrastructure or systems”. The brand was used as a pretext.
3. Israel. A separate credential-harvesting campaign, observed in May and June 2026, used conflict-themed lures. Google-themed typosquatted domains offered a file named WarUnPublishedDocuments.zip and then led to a fake Google sign-in. Google told Unit 42 its own systems were not compromised.

For context, Elastic’s earlier “Shelby Strategy” report described an Iraq-based telecom victim and a probable airport third victim. That is a separate, earlier campaign and is not evidence about the victims of CL-STA-1178.

In our assessment, targeting an individual engineer is a deliberate choice: a developer’s workstation typically holds source code, build credentials, VPN profiles and often elevated access to internal systems, and a recruitment pretext gives the target a plausible reason to open an unfamiliar project from an unfamiliar sender.

TTPs and Tradecraft

Stage 0: the lure

Two lures are documented.

• A fake careers portal. An Inno Setup installer branded “Dubai Airport Careers” installed an offline decoy portal containing a ten-question HR questionnaire. Unit 42 says submitting the questionnaire “does not trigger data exfiltration, remote communication or malicious execution”, and that the portal was designed to build credibility.
• A trojanized coding test. The Iraqi target was approached in March 2026, per Unit 42, and received a ZIP file named DubaiAirport_Carrers_IT_Test.zip containing a Visual Studio project. The README asked the candidate to fix an intentional loop bug, a normal-looking interview task.

Stage 1: code execution on project open

The key trick is in the project file. A malicious .csproj included a custom GetFrameworkPaths target. When Visual Studio opened the project, that target copied files from a Resources folder into %LOCALAPPDATA%\Microsoft\RuntimeBrokers and launched the payload, before the developer had compiled anything.

Unit 42 maps this to T1127 (Trusted Developer Utilities Proxy Execution; ATT&CK). In our assessment, the practical lesson is that for a developer, opening an untrusted project is already an execution event, because a build file is code.

Stage 2: AppDomainManager hijack and sideloading

The dropped files included a renamed host binary, RuntimeBroker.exe, and a malicious .config file. The config told the .NET runtime to load attacker code through an AppDomainManager (T1574.014, AppDomainManager), and it set <etwEnable enabled="false"/> to impair Event Tracing for Windows telemetry. The renamed binary then sideloaded a malicious RuntimeBroker.dll. Unit 42 links this step from “DLL sideloading” to T1574.001, which ATT&CK titles simply “DLL”. Naming everything RuntimeBroker is masquerading as a common Windows process name. That is Unit 42’s naming; the masquerading label is our inference.

According to Unit 42, Cortex XDR flagged and blocked this chain.

Stage 3: the implant set

All .NET binaries are obfuscated with Obfuscar.

Command and control through GitHub

The primary channel is the GitHub REST API, using a repository with per-machine paths. If that fails, ShelbyLoader falls back to searching GitHub Issues and comments, with encrypted routing data hidden in HTML comments, a form of dead-drop resolver (our ATT&CK mapping: T1102.001). The loader beacons every 63 seconds against the attackers’ repository, with a 120-second interval for persistence, and sleeps for an hour after a 403 response.

In our assessment, this is the awkward part for defenders: traffic to api.github.com is normal on a developer machine, is usually allowed outbound and is TLS-encrypted. Unit 42 says GitHub has since taken down the malicious infrastructure it identified, but in our assessment nothing about the technique stops the same operators from using a fresh account.

Tunnelling with Blackwood

Blackwood’s configuration is RC4-encrypted and Base64-encoded. It sets up a reverse SOCKS5 proxy (R:0.0.0.0:10999:socks) through an external relay. The four IPs Unit 42 lists have different roles and dates:

In our assessment, a reverse SOCKS proxy lets an operator route their own traffic through the victim machine, so internal systems see connections coming from a trusted workstation. That is our interpretation of what the technique enables, not a finding Unit 42 reports from this incident.

Historical Incidents and Impact

The documented timeline is short, and the visible impact is limited to what Unit 42 reports:

• April to June 2025. Blackwood activity tied to 87.248.129[.]239; a sample was submitted to VirusTotal on 25 May 2025. Unit 42 notes the malware was previously covered by CPX as “Blackwood .NET Malware Analysis: Chinese APT Payload”.
• 18 November 2025. A staging test, per Unit 42.
• March 2026. Unit 42 places the approach to the Iraqi individual here.
• April 2026. The coding challenge was submitted to VirusTotal; Unit 42 also gives a 24 April 2026 “asasas” thread and flags a GitHub comment dated 16 April 2026 as a possible additional C2.
• 1 May 2026. The pubs repository was created with Client.zip, the Blackwood delivery point.
• Early May 2026. A staging server was used for the Israeli credential-harvesting campaign.
• May to June 2026. The Israeli conflict-themed credential harvesting.
• 6 October 2026. Unit 42 publishes.

No evidence found as of 26 October 2026 of data theft, downstream compromise or the identity of the Iraqi victim organisation, in the sources we checked: the Unit 42 Blinder Tunnel post, the Unit 42 Screening Serpens post and Elastic’s “The Shelby Strategy”. We did not run a wider search of other vendors or news. Unit 42 does not say whether the operators moved beyond the developer’s machine, and the absence of that detail should not be read as reassurance. Unit 42 reports that GitHub took down the infrastructure it identified but gives no takedown date, so we cannot say how long the tunnelling capability was available. In our assessment, a tunnelling tool is typically a staging step for follow-on access.

Defensive Implications

Unit 42’s conclusion is to “secure developer environments, monitor anomalous cloud platform traffic and maintain vigilance against industry-specific social engineering lures”. (Advice to verify URLs before entering credentials and use phishing-resistant MFA is Google’s, quoted in the Unit 42 appendix on the Israeli campaign.) The specific measures below are our own assessment, not Unit 42’s:

1. Treat project files as executables. Open third-party code in a disposable VM or a locked-down dev container, never on a workstation holding production credentials.
2. Hunt for the host artefacts. The %LOCALAPPDATA%\Microsoft\RuntimeBrokers folder (note the plural; in our assessment that is not a standard Windows path), the HKCU\...\Run\MicrosoftRuntime value and a RuntimeBroker.exe that is not the Windows one are all cheap to search for.
3. Baseline GitHub use. API calls to GitHub from servers, kiosks or machines whose users are not developers are worth an alert. On developer machines, look for regular beaconing intervals such as the 63-second cadence reported here.
4. Watch for ETW tampering. A .config file that disables etwEnable next to a .NET host binary is unusual enough to be a detection on its own.
5. Brief recruiting and HR staff and engineers. Unsolicited “technical assessments” from an employer you did not apply to are the pretext here. Verify through an independent channel.
6. Segment developer networks. Because the likely use of the Chisel tunnel is lateral reach, a developer workstation should not have flat access to operational or administrative networks.

Indicators

Unit 42 publishes hashes, IPs, domains and host artefacts in its report, and we recommend using its list directly rather than a copy. Defanged examples from that list include the relay IPs above, the typosquatted domains googeldrive[.]cam and drivegoogel[.]cam, the GitHub account peakyblinders-tm and the GitHub repository GreenBeret0, which Unit 42 lists among its GitHub C2 infrastructure IOCs. Note that Unit 42 dates 87.248.129[.]239 to 2025 Blackwood activity; we infer it is separate from the 2026 campaign infrastructure.

What We Do Not Know

• Whether CL-STA-1178 is a new operator or a sub-team of an existing Iranian group. Unit 42’s own overlaps are low confidence.
• How many developers were targeted, and whether any lure besides the Iraqi case succeeded.
• What the operators did after the tunnel was established.
• How the 2025 Blackwood activity relates to this cluster, given earlier public coverage that titled the malware a Chinese APT payload.
• Whether Elastic’s “The Shelby Strategy” report adds technical detail beyond the points we cite; we did not audit it in full.

Adversary Wire will update this profile if further reporting resolves these points.