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 a software engineer or developer working in critical infrastructure in Iraq. The lure was a recruitment process impersonating the IT department of Dubai Airports.

The campaign is a useful case study because very little of it relies on a software vulnerability. The victim opened a Visual Studio project, and the project’s own build file ran the attacker’s code before anything was compiled. From there the operators used legitimate GitHub infrastructure for command and control, and a custom loader for the open-source Chisel tunnelling tool to turn the victim’s workstation into a network pivot.

Adversary Wire has not previously profiled this cluster. This article is based on Unit 42’s research, which is currently the only primary technical source we have found. We could not locate the Elastic Security Labs report that Unit 42 is described as linking the activity to, so we make no claims about it. 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 operators themselves use a “Peaky Blinders” theme for their infrastructure and malware: a GitHub account named peakyblinders-tm, a loader called ShelbyLoader and a command-and-control component called ShelbyC2. Unit 42 notes that an MP3 theme song was embedded in a README in the attackers’ public repository.

Attribution basis. Unit 42 gives three strands of evidence for the Iranian nexus:

• Infrastructure. One Blackwood command-and-control IP belongs to an Iranian ISP. A separate Hetzner-hosted relay uses Persian-language domains, possibly bought through an Iranian reseller.
• Metadata. The MP3 in the public README carries a comment tag that points to an Iranian music site.
• Victimology and tradecraft. The targeting and techniques overlap with known Iranian espionage activity.

Confidence and caveats. The attribution to Iran is high confidence. Links to specific named groups are weaker: Unit 42 reports only low-confidence overlaps with the clusters it calls Screening Serpens and Agent Serpens. We would treat CL-STA-1178 as its own cluster for now. It should not be folded into any existing profile on the strength of those overlaps. Our own Screening Serpens coverage describes the same broad AppDomainManager technique, but shared technique alone is weak evidence of a shared operator.

Likely objective. Unit 42 describes the activity in espionage terms. The targeting of a developer 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 a developer in critical infrastructure. Unit 42 names telecommunications and aviation, along with “other critical entities”, as the wider targeting.
2. United Arab Emirates. The lures impersonated Dubai Airports IT. Unit 42 states that it has no evidence that Dubai Airports itself was breached. The brand was used as a pretext only.
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.

Targeting an individual engineer is a deliberate choice. A developer’s workstation typically has source code, build credentials, VPN profiles and often elevated access to internal systems. A recruitment pretext also gives the operator a plausible reason for the target 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. It made no network calls. Unit 42 describes this as a credibility-building step, which fits: a victim who sees no suspicious traffic or warnings has little reason to doubt it.
• A trojanized coding test. From April 2026, the target 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’s own phrasing is that the malware “copied itself and launched in the background while the developer was still reading.”

Unit 42 maps this to T1127 (Trusted Developer Utilities Proxy Execution). The practical lesson is that for a developer, opening an untrusted project is already an execution event. 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), and it set <etwEnable enabled="false"/> to impair Event Tracing for Windows telemetry. The renamed binary then sideloaded a malicious RuntimeBroker.dll (T1574.001). 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 (T1102.001). The loader beacons every 63 seconds and checks in every 120 seconds.

For the defender, this is the awkward part. 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 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. Unit 42 lists four relay and staging IPs: 91.107.156[.]29, 87.248.129[.]239, 65.109.214[.]145 and 38.180.136[.]127. In practice 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. This 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 2026. First delivery of the trojanized coding test.
• 1 May 2026. Blackwood delivered from a public GitHub repository.
• Early May 2026. A staging server used for the Israeli credential-harvesting campaign.
• May to June 2026. The Israeli conflict-themed credential harvesting.
• 6 October 2026. Unit 42 publishes.

We are not aware of any public confirmation of data theft, downstream compromise or the identity of the Iraqi victim organisation. Unit 42 does not say whether the operators succeeded in moving beyond the developer’s machine. The absence of that detail should not be read as reassurance. A tunnel that exists for weeks and is then taken down by the hosting platform is a typical staging step for the access that follows.

Defensive Implications

Unit 42’s recommendations, paraphrased, are to monitor for binaries loading non-standard DLLs from outside system directories, treat untrusted project files as hostile on open rather than only on build, watch for anomalous traffic to GitHub from non-developer hosts, block the published indicators, use phishing-resistant MFA and be alert to industry-specific recruitment lures. Building on those, we would prioritise:

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. Visual Studio and MSBuild do not offer a safe preview mode.
2. Hunt for the host artefacts. The %LOCALAPPDATA%\Microsoft\RuntimeBrokers folder (note the plural, which 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. SOC Analyst Hub covers AppDomainManager hijack detection in general terms.
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, and the GitHub accounts peakyblinders-tm and GreenBeret0.

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.
• Whether the Elastic Security Labs reporting that Unit 42 links to adds technical detail. We could not find it.

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