Blinder Tunnel Campaign Targets Iraqi Infrastructure

We discovered that an Iranian state-aligned threat actor has been masquerading as the Dubai Airports IT department to deliver trojanized coding challenges to high-value targets. Unit 42 tracks the activity as CL-STA-1178. This activity includes a campaign we call “Blinder Tunnel,” that targeted Iraqi critical infrastructure in March 2026, following infrastructure staging that was observed as early as November 2025. We named the campaign Blinder Tunnel after infrastructure terms the attackers used, as well as the malware’s tunneling capabilities.

While other security vendors have discussed individual attacks linked to this activity, this is the first report that not only ties together these disparate attacks as related activity, but tracks the evolving 2026 activity and the Blinder Tunnel campaign as a whole. We assess with high confidence that this activity aligns with an Iranian-nexus threat.

This campaign expands on operations and incorporates a “Peaky Blinders” theme by naming infrastructure components after the British crime drama’s branding — even embedding its theme song into the malware.

During our research, we discovered that the attackers established an initial foothold using a three-step attack chain:

Exploited legitimate Windows developer .csproj files

Performed AppDomainManager hijacking

Executed binaries through DLL sideloading

These steps enabled the attackers to deploy custom malware that we refer to as ShelbyLoader V2. To blend in with legitimate cloud traffic, the campaign misused GitHub’s API infrastructure for command-and-control (C2) communication. It did so by leveraging repositories to:

Fetch decryption keys

Use GitHub issues as a resilient C2 fallback mechanism

GitHub has taken down the malicious infrastructure that we identified as being associated with this campaign.

Our investigation benefited from various operational security (OpSec) and cryptographic missteps by the attackers, including:

Exposing tools on public repositories

Combining phishing and tunneling infrastructure

Embedding metadata within the show’s theme song

These tactical errors linked Blinder Tunnel infrastructure to a separate campaign in which the same actor leveraged conflict-themed Google Drive lures for credential harvesting against an Israeli entity in May-June 2026.

Palo Alto Networks customers are better protected from the Blinder Tunnel campaign through the following products and services:

Advanced URL Filtering and Advanced DNS Security

Cortex AgentiX Agentic Assistant streamlined this investigation.

If you think you might have been compromised or have an urgent matter, the Unit 42 Incident Response team .

CL-STA-1178 represents activity from an Iranian state-aligned threat actor linked to a series of targeted cyber operations across the Middle East. Previously associated with campaigns tracked by Elastic Security Labs as The Shelby Strategy , the threat actor behind this cluster of activity frequently employs thematic branding in their malware and infrastructure, drawing inspiration from the popular television show “Peaky Blinders.”

The attackers behind this cluster target high-value infrastructure, including telecommunications, aviation and other critical entities across Iraq, Israel and the United Arab Emirates (UAE).

Since the launch of Blinder Tunnel in March 2026, Unit 42 researchers have identified an evolution in the operational capabilities associated with the activity. The attackers used tailored social engineering tactics, weaponizing recruitment lures aimed at Iraqi software developers and engineers.

We observed the threat actor staging and testing attack infrastructure as early as November 2025. This infrastructure remained dormant but operational until March 2026, when the attackers activated the campaign to target an individual in Iraq's critical infrastructure sector.

The infection chain relies on three initial execution techniques to establish covert access. The attacks introduced a new layer of evasion by weaponizing a native .csproj file, a Microsoft developer file used to build software projects. This initial stage subsequently triggered AppDomainManager hijacking , followed by DLL sideloading , leveraging their previously established execution techniques.

AppDomainManager hijacking is an emerging evasion technique that attackers are increasingly adopting, according to our recent research. Iranian threat groups like Screening Serpens and others are using this technique to force trusted Windows applications to covertly execute malicious payloads.

For C2 communication, the attackers behind Blinder Tunnel misuses legitimate GitHub API infrastructure, a strategy known as living off the cloud, to blend their malicious network activity with standard enterprise traffic. Before its removal, the GitHub repository also hosted an in-memory wrapper that executed the open-source Chisel tunneling utility. The attackers used Chisel as a bridge between their external infrastructure and compromised networks.

Figure 1 provides a high-level view of the entire campaign.

Initial Access and Delivery

Dubai Airports Careers Portal

Starting in late March 2026, the threat actor launched a social engineering campaign disguised as a professional recruitment process to compromise a specific individual, likely a software engineer. We identified this campaign through VirusTotal, following multiple file submissions from a submitter based in Iraq.

Impersonating the Dubai Airports IT department, the attackers approached a target with a job offer for a development role. Threat actors often abuse, take advantage of or subvert legitimate products for malicious purposes. This does not imply that the legitimate product is flawed or malicious. Unit 42 is not aware of any breach, compromise, or vulnerability within Dubai Airports infrastructure or systems.

As a mandatory first stage in the recruitment process, attackers instructed the target to download and install a file named Dubai Airport Careers .

This file was an Inno Setup installer that deployed a self-contained, offline site masquerading as a career portal. To access the assessment, the target had to log in using credentials provided by the “recruiters,” simulating a realistic portal experience.

Figure 2 shows the initial login screen.

After the target logged in, the application presented a tailored, 10-question HR questionnaire. Figure 2 shows part of this questionnaire.

Submitting the questionnaire does not trigger data exfiltration, remote communication or malicious execution. This lack of network or backend activity indicates that the application is a harmless decoy. This lack of suspicious activity is designed to build credibility and lower the victim's guard before delivering a malicious payload in the phase of the phishing operation.

Recruitment Coding Challenge

In April 2026, the same source that reported the career portal to VirusTotal made another submission, revealing the stage of the recruitment lure. Unlike the usual malicious links or documents seen in a report by ClearSky Cyber Security Iranian Dream Job campaigns, the threat actor sent the target a weaponized Microsoft Visual Studio project archive disguised as a coding assessment.

The project, named DubaiAirport_Carrers_IT_Test.zip (misspelled Carrers instead of Careers ), contained a Readme.md file with personalized instructions. The message addressed the target directly:

“Dear .”

The sender claimed to be a senior manager of a Dubai Airports IT department, instructing the recipient to open the C# Flight Management System project in their integrated development environment (IDE).

Figure 4 shows the first section of the Readme.md file, including the message tailored to the target and instructions for an at- assessment.

Under the pretense of evaluating the target's technical abilities, the project included an intentional bug in a backend C# method: a for loop that skips the last element. Attackers instructed the target to build and run the project to find and fix the bug, a task that an experienced software engineer could accomplish without difficulty.

Three-Step Infection Chain

The initial infection is triggered by a malicious .csproj file. Once executed, the attack chain progressed to AppDomainManager hijacking followed by DLL sideloading.

Stage One: Malicious .csproj File

The attackers weaponized the C# project's .csproj configuration file by misusing Visual Studio's built-in evaluation process . This method caused the payload to execute the moment the project was loaded into the IDE, even before the developer attempted to compile the code.

Figure 5 shows the project files within the DubaiAirport_Carrers_IT_Test.zip archive, including the weaponized .csproj file.

When a developer opens a project, Visual Studio performs a design-time build in the background. This process resolves dependencies and enables various features. During this initialization phase, Visual Studio runs a specific command called GetFrameworkPaths . Building on this command, the attackers defined a custom XML target with this exact name in their malicious .csproj file, overriding the safe Microsoft default behavior.

When the target opened the project, Visual Studio attempted its routine background check and executed the attacker's custom instructions without user intervention. The script created a deceptive folder in the user's local app data: %LOCALAPPDATA%\Microsoft\RuntimeBrokers . It then copied the hidden malware binaries from the project's Resources folder to this directory and launched the payload, RuntimeBroker.exe .

Figure 6 demonstrates the exact configuration of the .csproj file, highlighting the hijacked target and the sequence that copied the malicious files to their target destination.

The malware deployed, copied itself and launched in the background while the developer was still reading the deceptive Readme.md file. This technique is classified as Trusted Developer Utilities Proxy Execution . It can be effective because the malicious background execution is triggered by the legitimate, expected behavior of msbuild.exe , a trusted developer tool.

Stage Two: AppDomainManager Hijacking

The MSBuild binary launched a legitimate, signed Microsoft Visual Studio hosting process ( vshost.exe ). This file was then renamed to RuntimeBroker.exe . Upon execution, the AppDomainManager hijacking began by manipulating the application's RuntimeBroker.exe.config file. The attackers used this configuration file to replace the application's default startup manager with their own malicious version. This forced the system to pass full execution control to the malware before the host application launched, allowing their custom RAT, ShelbyLoader V2, to run in a hidden, trusted process.

Using this hijack technique allowed the attackers to manipulate the system and security configurations. By adding just a few lines of XML, the attacker instructed the system to disable one of its security-tracking mechanisms using the directive.

Because Event Tracing for Windows (ETW) is critical for monitoring execution and detecting in-memory threats, this flag could impair detection capabilities.

Figure 7 shows the RuntimeBroker.exe.config configuration file content, with the embedded malicious lines.

Figure 8 displays the malicious files from the Resources folder, which served as the actor's main tool set throughout this campaign.

Stage Three: DLL Sideloading

Following the execution of RuntimeBroker.exe and the subsequent AppDomainManager hijack, the attack sequence concluded with DLL sideloading as its final stage.

RuntimeBroker.exe , a renamed benign Microsoft binary, is susceptible to DLL -order hijacking. The actor exploited this flaw to perform DLL sideloading, executing the malicious payload by loading RuntimeBroker.dll into memory.

Organizations can defend against these attacks by monitoring binaries that load unknown or non-standard DLLs outside of system directories. In this particular case, Cortex XDR flagged the root .slnx file that triggered the DLL sideloading attempt as a high-severity threat, preventing execution before any user interaction could occur, as Figure 9 shows.

Security teams can detect this masquerading activity by monitoring abnormal process behavior. Cortex XDR flagged this execution chain as high risk and blocked the threat, as Figure 10 shows.

The Attackers’ Evolving Tool Set

The attacker’s tool set relied on a modular, multi-stage architecture. This architecture was designed for persistence, remote command execution and lateral movement across compromised environments. The following analysis examines the core components of the attacker’s custom tool set:

ShelbyLoader V2 : Primary loader that uses GitHub issues as a C2 fallback

PsProxy.dll : PowerShell execution engine

ShelbyC2 V2 : Primary backdoor

Blackwood : Loader running in-memory tunneling utility (Chisel)

All the .NET binaries recovered in this campaign were obscured with the open-source obfuscator Obfuscar . This tool hinders reverse engineering and automated static analysis, using runtime string decryption and non-printable Unicode characters for class and method identifiers.

ShelbyLoader V2 RuntimeBroker.dll Loader

RuntimeBroker.dll , which we named ShelbyLoader V2, is a newer version of the previously documented ShelbyLoader malware .

The malware was a C# DLL that performed the following activities:

Fingerprinted the infected host

Established communication with the C2

The malware served as the initial entry point for launching the campaign. It executed a structured routine to perform initial host anti-analysis checks and establish communication before downloading and decrypting a second-stage payload.

The malware utilized two timed mechanisms to manage its operations:

Persistence (120-second interval): The malware achieved persistence through the registry, by creating a MicrosoftRuntime value under the current user startup registry key, pointing to the binary located at %LOCALAPPDATA%\Microsoft\RuntimeBrokers\RuntimeBroker.exe . The loader logged this persistence status across four operational states and returned the results to the attackers' C2: Already persisted Newly persisted Registry key not found Executable not found

Registry key not found

Beacon (63-second interval): This timer drove the primary C2 loop. The beacon routine attempted to authenticate to the GitHub API using a hard-coded GitHub Personal Access Token (PAT): github_pat_11B2HDA2Q0KDdo…(redacted)

The beacon cycle began by communicating with the peakyblinders-tm/myLic GitHub repository and uploading a Base64-encoded machine fingerprint to /{machineId}/Lic.txt . The machineId is derived by taking the first 16 lowercase hex characters of a SHA-256 hash of the string Peaky Blinders 2.1 concatenated with the machine fingerprint.

After successful registration, the malware continuously polled for tasking by downloading the content of /{machineId}/Inf.txt . The malware parsed the response for a Base64-encoded command, which it decoded and executed. Once processed, the beacon uploaded an acknowledgment containing the SHA-256 file to update and clear the repository file. If the GitHub API returned an HTTP 403 (Forbidden) error due to rate limits, the malware enforced a one-hour sleep loop.

To hinder analysis, the malware checked for virtualization markers in the following locations:

Windows Management Instrumentation (WMI)

It also verified host hardware (CPU, RAM, disk space) and ensured it was spawned by explorer.exe before running.

GitHub Issues as a C2 Fallback Mechanism

If the hard-coded token was revoked or the primary C2 channel returned an HTTP 401 Unauthorized error, the malware activated a fallback mechanism: a dead-drop resolver that leveraged the GitHub Issues API .

The malware constructed an automated query using the current date formatted as yyyymmdd , combined with the repository identifier and an issue type filter. For every matching issue found, it fetched the URL and parsed the response body. It then extracted specific content that was hidden inside standard HTML markers: .

This extracted ciphertext was decrypted using AES-256-CBC. The decryption key was derived by running an MD5 hash of the current date string, concatenated with the unique machineId and an initialization vector (IV) derived from the MD5 of that key, iterated five times. Once decrypted, the malware applied regular expressions to update the C2 owner, repository path and authentication token:

This fallback structure was built to allow for continuous operations in the event that GitHub took down the primary C2 repository or security tools blocked it.

The operators also planted encrypted fallback C2 data within the of benign GitHub issues. The underlying text cannot be decrypted without a target's unique machineId . However, the campaign's overall timeline suggests that an issue posted on April 16, 2026, served as a potential additional C2 of this implant, as Figure 11 shows.

PsProxy.dll: The PowerShell Proxy Module

To execute local commands, the attackers used a dedicated in-memory module, PsProxy.dll , which served as a stateless execution engine with no standalone network or persistence capabilities.

The malware leveraged a technique described by MITRE as executing PowerShell commands without invoking the PowerShell.exe binary. Security tools generally hunt for malicious activity by monitoring the PowerShell.exe process. To evade this detection, PsProxy.dll bypassed the standard console and hooked into the core PowerShell engine ( System.Management.Automation.dll ).

The malware then initialized a customized runspace — an invisible, self-contained execution context — within the hijacked host process. This allowed the attacker's script to execute without spawning PowerShell.exe .

The malware authors designed this architecture for both stealth and stability. The PowerShell module ran without dropping malicious scripts to the disk or spawning suspicious processes. It also operated in a separate memory compartment, preventing a crashed script from disrupting the primary C2 connection. When a command arrived from the server, the main payload passed the raw script over to this proxy for execution.

Figure 12 illustrates the role of PsProxy.dll within the attack chain as a secondary execution module for the ShelbyC2 V2 RAT.

ShelbyC2 V2 RuntimeBrokerApi.dll: Loading the Final Payload

Once the malware established stable communication with the GitHub-hosted C2, the RuntimeBroker.dll loader read an AES-CBC-encrypted file named RuntimeBrokerApi.dll from its base directory. We named this main RAT ShelbyC2 V2, based on the name of its last reported iteration, ShelbyC2 .

The decryption key was generated using the full SHA-256 hash of a license content string fetched at runtime from the GitHub C2:

hxxps[:]//api.github[.]com/repos/peakyblinders-tm/myLic/contents/{machineId}/Lic.txt

The IV was set to the first 16 bytes of that same hash. The decrypted bytes were then loaded into memory as a raw .NET assembly.

ShelbyC2 V2 ( RuntimeBrokerApi.dll ) operated as the primary RAT. It managed command execution via the previously analyzed PsProxy.dll PowerShell module and served as the staging mechanism for deploying the Blackwood tunneling tool into the network, which we analyze in detail in the following section.

Blackwood: A Custom, Zero-Disk Chisel Tunneling Tool

On May 1, 2026, the attackers expanded their GitHub-centric infrastructure by creating a new public repository named pubs under the peakyblinders-tm account. This repository hosted a single archive file: Client.zip . Our analysis of this payload revealed a malicious executable internally named Blackwood , which was previously covered by CPX and submitted to VirusTotal in May 2025.

Figure 13 shows the GitHub repository pubs , containing the Client.zip file.

Figure 14 shows the extracted archive content, where the malicious file is named Blackwood.dll .

To deploy Blackwood , the attackers relied on the same execution playbook observed with the primary loader, ShelbyLoader V2: AppDomainManager hijacking and DLL sideloading. Inside the extracted archive, the attackers stored:

The malicious payload

A legitimate Microsoft-signed binary, vshost32.exe

A configuration file named vshost32.exe.config

When the trusted vshost32.exe executable was launched, the .NET runtime parsed the configuration file and sideloaded Blackwood.dll into the application's memory.

Blackwood.dll acted as a loader for the open-source Chisel tunneling tool. Once deployed, it enabled the attackers to establish encrypted TCP tunnels over HTTP with SOCKS5 proxy support to bypass perimeter defenses and enable lateral pivoting across compromised networks. To hide the tunneling payload from analysis, the core binary was embedded within the .NET loader as an 8.4 MB manifest resource named Blackwood.Cheese.xml . This payload was also encrypted with AES-256-CBC.

During execution, the malware derived the decryption key by computing the SHA-256 hash of a hard-coded ASCII passphrase ( y0Da+QH#pwSg38E?=8R;71-jQu8Tqq ). After Blackwood.dll decrypted the embedded XML resource, it revealed the actual Chisel payload — a Go-compiled DLL. The Blackwood.dll loader then reflectively loaded this Chisel DLL into memory and executed it.

The Chisel tool read its operational settings from the external configuration file Blackwood.dll.conf , which was dropped alongside the executable. The loader employed a conditional evasion scheme:

If the loader binary had a DLL extension, the loader treated the configuration file as Base64-encoded text and decrypted the file via the RC4 algorithm using the hard-coded key “ My name is Blackwood ! ”

If the extension had been changed, the loader would have read the file in plaintext, resulting in a decryption failure.

Figure 15 displays the successful decryption using the hard-coded key, yielding a Chisel configuration.

The discovered IP address, 91.107.156[.]29 , functioned as a dedicated tunneling endpoint. The configuration instructed the infected machine to connect to this server and establish a reverse SOCKS proxy ( R:0.0.0.0:10999:socks ), creating a bridge that could allow attackers to route traffic to the target's internal network.

Initial Tool Set Testing

Throughout the campaign, the attackers performed operational testing to validate and improve their infrastructure and malware functions. The attackers confirmed dead-drop C2 resolution through GitHub in November 2025 and simulated Iraqi connections on a mock GitHub issue dashboard in April 2026. We also observed that the attackers tested additional infrastructure on a staging server for a phishing campaign targeting an Israeli entity in May 2026.

A comprehensive analysis of these operational testing phases is provided in Appendix A.

Additional Credential Harvesting Campaign

Analysis of Blackwood tunneling configurations submitted to VirusTotal revealed additional attacker infrastructure active between May and June 2026. One of the servers showed that the attackers reused the same infrastructure for both internal network access and credential harvesting. Our research linked this server to a phishing campaign in May–June 2026 targeting an Israeli entity, using conflict-themed lures.

A detailed breakdown of this additional campaign is available in Appendix B.

Attribution to the Iranian Nexus

Despite utilizing cloud infrastructure and code obfuscation to hide their operations, the actors behind the Blinder Tunnel campaign left behind several forensic artifacts. Based on infrastructure ownership, embedded metadata, targeted victimology and overlaps in tradecraft, we assess that an Iranian state-aligned threat actor conducted this campaign.

The key findings that led us to this attribution include:

Iranian-hosted infrastructure : The initial Blackwood C2 IP address belongs to an Iranian ISP: TOSE'EH ERTEBATAT NOVIN ARIA. A secondary Hetzner tunneling server resolves to Persian-language domains that the attackers likely acquired via an Iranian reseller.

MP3 file metadata : An .mp3 file hosted in the attackers' public GitHub repository retained metadata pointing to MusicDel[.]ir , a popular Iranian music platform.

Regional geopolitical victimology : The campaign's targeting profile aligns with previously documented regional espionage activity and historical targeting patterns associated with this activity cluster.

Convergence with Iranian espionage playbooks : The campaign employed established Iranian tactics, techniques and procedures (TTPs), which shows low confidence overlaps between CL-STA-1178 and established Iranian groups. Among the TTPs are: Using aviation-targeted lures AppDomainManager hijacking to disable ETW (resembling Screening Serpens) Using GitHub dead-drop resolvers Using in-memory .NET PowerShell wrappers (resembling Agent Serpens )

Using aviation-targeted lures

AppDomainManager hijacking to disable ETW (resembling Screening Serpens)

Using GitHub dead-drop resolvers

Using in-memory .NET PowerShell wrappers (resembling Agent Serpens )

A detailed technical breakdown of the attribution artifacts is available in Appendix C.

The activity tracked as CL-STA-1178 represents targeted operations against Middle Eastern enterprise networks in the newly uncovered campaign Blinder Tunnel.

The attackers behind the activity used tailored social engineering techniques to masquerade as Dubai Airports recruiters, using a trojanized Visual Studio coding challenge to target a high-value job seeker based in Iraq.

The campaign is characterized by misuse of built-in developer tools and DLL sideloading. Attackers also used AppDomainManager hijacking to bypass security monitors like ETW. These evasion techniques enabled the attackers to deploy:

The primary loader, ShelbyLoader V2

The custom RAT payload, ShelbyC2 V2

The custom Blackwood tunneling tool

The Blinder Tunnel campaign relied on living-off-the-cloud techniques. By misusing GitHub APIs and reading encrypted within GitHub issues to rotate C2 servers, the attackers disguised the malware’s command traffic as legitimate enterprise platform activity.

We assess with high confidence that this activity cluster aligns with the work of an Iranian-nexus threat actor. The attacker using infrastructure themed around the TV show “Peaky Blinders” links this activity to the campaign previously documented in Elastic Security’s “The Shelby Strategy” report. Furthermore, OpSec failures and flawed cryptography uncovered a parallel campaign targeting an Israeli entity, revealing a broader operational footprint. The campaign's tool set and geographical targeting align with established regional threat activity and historical tradecraft.

This operation underscores the need for organizations to secure developer environments, monitor anomalous cloud platform traffic and maintain vigilance against industry-specific social engineering lures.

Palo Alto Networks Protection and Mitigation

Cortex AgentiX Agentic Assistant streamlined this investigation by allowing the team to query the data using natural language, providing deeper context and insights, and suggesting clear recommendations on what researchers should do . Figures 16 and 17 show examples of this.

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 to identify and automatically block the recruitment lures, malicious build steps, and payloads associated with this campaign.

Advanced URL Filtering and Advanced DNS Security identify and block known malicious domains and URLs associated with this activity, specifically stopping the GitHub C2 traffic, Chisel tunneling attempts, and credential-harvesting phishing infrastructure associated with this threat cluster.

Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware and 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)

Europe and Middle East: +31.20.299.3130

Japan: +81.50.1790.0200

Australia: +61.2.4062.7950

India: 000 800 050 45107

South Korea: +82.080.467.8774

Indicators of Compromise

Blinder Tunnel malware payloads and hashes

DubaiAirport_Carrers_IT_Test.zip – Initial malicious archive 6e7d9b33f1e72ea1ede71373a604ecdb060dab7d42055179c1eede9ecd1fd239

6e7d9b33f1e72ea1ede71373a604ecdb060dab7d42055179c1eede9ecd1fd239

FlightManager.csproj – Weaponized Visual Studio project file f5b12772db6817f7a765a6fe7565fd3d4f87edc28e42fe3ec0244a372a410fc9

f5b12772db6817f7a765a6fe7565fd3d4f87edc28e42fe3ec0244a372a410fc9

RuntimeBroker.dll – Primary RAT loader 53f35e49eb9b271fd8cbcd3daacb525328dbf159a03dbd1c7adebe0363daa402

53f35e49eb9b271fd8cbcd3daacb525328dbf159a03dbd1c7adebe0363daa402

PsProxy.dll – In-memory PowerShell execution engine 3fd810a3aa0039993393741b32287c367a9a5037a41e826906440887cdd3ed13

3fd810a3aa0039993393741b32287c367a9a5037a41e826906440887cdd3ed13

Blackwood.dll – Custom Chisel tunneling wrapper 76273382e4252c1f60a2251141e108942494409c759358320735891762c0682e

76273382e4252c1f60a2251141e108942494409c759358320735891762c0682e

Blackwood.dll.conf – Contacting 91.107.156[.]29 d3561bd4aad003dc3e08157b0891860bb496b80cd6e44901692e08ab1d4e8260

d3561bd4aad003dc3e08157b0891860bb496b80cd6e44901692e08ab1d4e8260

Blackwood archive – Contacting 65.109.214[.]145 f5ba1645694c62f527ed6ceda8c68a5c3dd92b4032439167e8e937e72803b4bd

f5ba1645694c62f527ed6ceda8c68a5c3dd92b4032439167e8e937e72803b4bd

Blackwood archive – Contacting 87.248.129[.]239 7cc571aca6d8715d9aaad3d83e1bcd30467565d583db1dfe73697c5d00a1f875

7cc571aca6d8715d9aaad3d83e1bcd30467565d583db1dfe73697c5d00a1f875

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\MicrosoftRuntime

GitHub C2 infrastructure:

hxxps[:]//github[.]com/peakyblinders-tm

hxxps[:]//github[.]com/GreenBeret0

Iranian “Dream Job” Campaign – ClearSky Cyber Security

Blackwood .NET Malware Analysis: Chinese APT Payload [Best on mobile] – CPX

PowerLess Trojan: Iranian APT Phosphorus Adds New PowerShell Backdoor for Espionage – Cybereason Nocturnus

The Shelby Strategy – Elastic Security Labs

DarkBlinders – Group IB

Drokbk Malware Uses GitHub as Dead Drop Resolver – Sophos

Tracking Iranian APT Screening Serpens’ 2026 Espionage Campaigns – Unit 42

Appendix A: The Attackers’ Initial Testing of Their Tool Set

According to our observations, the attackers conducted multiple operational tests throughout the campaign to validate and refine their own tools.

First Observed GitHub

On Nov. 18, 2025, it appears that the threat actor performed operational tests to validate their C2 mechanisms, using a public GitHub repository to test their dead-drop resolution capabilities. By embedding an encrypted payload block inside a , the malware developers could verify that their malware located and retrieved fallback C2 instructions.

This early activity suggests a prolonged preparation period, indicating that this campaign could have started in November 2025. Figure 17 shows the left by the threat actor.

Analysis of the “asasas” GitHub Thread

On April 24, 2026, the operators used a GitHub issue in their peakyblinders-tm repository as an operational logging dashboard. The issue's asasas title and an initial hisasas suggest that the attackers created this thread as a preliminary trial run. These strings indicate adjacent QWERTY key smashing, typical of a quick confidence check to verify permissions before logging real telemetry.

The thread contained a series of additional that appeared to be automated alerts posted by the repository owner. These alerts flagged events such as New device Found and Login detected . The thread also contained system attributes such as #microsoft to denote the host operating system.

One of the log entries records a connection from the IP address 138 . 256 . 21[.]23 alongside the country code for Iraq, IQ . Since .256 exceeds the maximum IPv4 octet value of 255, we assess that attackers used a fabricated, non-routable IP address during an operational test to avoid triggering real network traffic. Despite the invalid IP address, the explicit inclusion of the IQ country code suggests a connection to the campaign's geographic targeting focus in the Middle East.

Figure 18 shows the GitHub issue thread, displaying a sequence of from the repository owner that combine what appear to be test strings, mock connection data and automated alerts.

Appendix B: Additional Credential Harvesting Campaign

The server 65.109.214[.]145 was identified through a Blackwood malware sample submitted to VirusTotal on May 24, 2026. Analysis indicates that this IP address was central to a credential-harvesting campaign between May and June 2026, hosting phishing domains as well as the backend Blackwood.dll component, configured on port 8080.

The server hosted a targeted infrastructure consisting of several Google-themed typosquatted domains. These included:

googeldrive[.]cam, drivegoogel[.]cam

On May 16, 2026, a VirusTotal submitter from Israel submitted a phishing URL hosted on this IP address: hxxps[:]//cloud.g-drive[.]cam/drive/file/d/[generated id]/view

The underlying landing page was designed to look like a Google Drive error page displaying a prompt to download an archive file named WarUnPublishedDocuments.zip .

Clicking the download button shown in Figure 19 directed the target to a site impersonating a Google login portal to collect user credentials at hxxps[:]//cloud.g-drive[.]cam/signin/v2/identifier?from=landing .

We reported this information to Google, who investigated the activity outlined in this report. They confirmed that Google Drive systems and infrastructure were not compromised or involved in any way in the attacks.

The threat actors utilized external lookalike domains designed to impersonate Google Drive and Google Workspace interfaces for credential harvesting. Google Safe Browsing and Chrome protections actively block access to these identified malicious domains.

Google noted that they encourage organizations to enforce phishing-resistant multi-factor authentication (such as passkeys) and advise users to verify destination URLs before entering account credentials.

Further infrastructure tracking revealed the threat actor’s earlier staging environment. By pivoting on domains hosted on the primary 65.109.214[.]145 server, we discovered the domain asdfafadafg[.]online . This domain resolved to a secondary IP address, 38.180.136[.]127 .

Timeline analysis indicates that the operators used this server to test their phishing infrastructure during early May 2026, before migrating their operations to the primary 65.109.214[.]145 server.

Appendix C: Attribution to the Iranian Nexus

Despite the attackers’ use of code obfuscation to hide their tracks, we discovered infrastructure overlaps and operational mistakes that revealed key attribution artifacts. An Iranian IP address, embedded music metadata and the targeted activity against critical infrastructure in the Middle East point to an Iranian state- espionage operation. We summarize each forensic artifact and how it aligns with our attribution process.

Our investigation into the Blackwood malware samples revealed four IP addresses used in the activity cluster. Two of the identified IP addresses provided clues to the operator’s country of origin.

87.248.129[.]239 This server was identified through an initial Blackwood malware sample submitted to VirusTotal on May 25, 2025, prior to the current campaign. This is an Iranian IP address, hosted by the internet service provider TOSE'EH ERTEBATAT NOVIN ARIA CO PJS. Active between April and June 2025, this server was the first to be linked to the Blackwood malware.

91.107.156[.]29 Extracted from the embedded configuration file inside the Blackwood malware sample, the IP address 91.107.156[.]29 functions as a tunneling relay. Although this server is hosted on Hetzner's infrastructure in Germany, passive DNS telemetry links it to an external domain layout. Historical DNS records reveal subdomains pointing to ns1.soroshpasargad[.]com and to the 3ff7dfc547e8697c registrar. In Persian, Sorosh means messenger or angel. Pasargad refers to the ancient capital of the first Persian Empire. Based on the aforementioned Persian domain and other Persian domains under the same registrar, we suspect that the current server listed under Hetzner could have been acquired from an Iranian reseller.

An OpSec oversight on the attackers' public GitHub profile provided an indicator of the operators' regional origin. The threat actor maintained a public repository under the organization profile peakyblinders-tm . The repository's README file included an embedded audio file titled Peaky Blinders Team.mp3 , featuring the television show's theme song, “Red Right Hand.”

Figure 20 shows the Readme.md file from the attacker's public GitHub repository.

An analysis of the audio file's embedded metadata revealed that the operators did not strip the file's original attributes before uploading it to their public project page. As shown in the metadata breakdown in Figure 21, the field explicitly retains the value MusicDel[.]ir .

MusicDel[.]ir is an active, public Iranian music distribution website used primarily for downloading tracks in Iran. The presence of this specific metadata string indicates that the operators downloaded the audio file from a domestic Iranian platform before uploading it to their GitHub infrastructure.

The targeting profile corresponds with victimology previously observed across other Iranian APT campaigns. The targets were all in the Middle East, specifically within the telecommunications and aviation sectors:

Iraq: In their research on “ The Shelby Strategy ,” Elastic Security Labs documented that the threat actor executed spear phishing campaigns from within a compromised Iraqi telecommunications infrastructure. According to their findings, this activity targeted two separate Iraqi communications companies. The activity’s geographic focus was the same in the campaign we investigated. This is corroborated by recent technical artifacts, as multiple campaign-related payloads — including the job assignment archive — were submitted to VirusTotal from Iraq. Additionally, the operators used the country code IQ (Iraq) in their mock connection logs during their GitHub operational testing. Based on the established operational profile and technical evidence linking this activity to the region, we assess that the individual targeted in Blinder Tunnel matches the profile of a software engineer based in Iraq.

United Arab Emirates (UAE): The initial lure mimicked the Dubai Airports IT Department. In another aviation-themed operation, Elastic Security Labs identified related infrastructure targeting the UAE aviation sector, including the malicious subdomain portal.sharjahairport[.]cloud .

Israel: The activity also targeted an Israeli entity using conflict-themed social engineering lures. A suspicious URL was submitted to VirusTotal via the web interface from an IP address in Israel. The URL redirected to a phishing page that served an archive named WarUnPublishedDocuments.zip , which in turn led to a site impersonating a Google login portal.

The “Peaky Blinders” Theme

Throughout past and present campaigns (2025-2026), the threat actor behind this activity consistently used a “Peaky Blinders” theme in naming their malware architecture and GitHub-based C2 repositories. This is evident in the following:

GitHub accounts named after the show’s name and main characters: peakyblinders-tm ArthurShelby JohnShelllby

A repository referencing the gang's clothing: GreenBeret0

The presence of the show’s theme song in the repo's README file

These indicators served as a unique fingerprint that aided in attribution.

Similarities to Other Known APTs

Public threat intelligence tracks the Blinder Tunnel campaign as disparate activities independent of any known group. Unit 42 tracks this activity as a cluster, specifically using the CL-STA-1178 moniker. The tradecraft used in the Blinder Tunnel campaign shows low-confidence overlaps with established Iranian groups, none of which are strong enough to attribute CL-STA-1178 to any of these groups specifically. However, we do attribute the activity with high confidence to Iranian state-aligned attackers.

As detailed in a recent Unit 42 report , the Screening Serpens (aka UNC1549, Smoke Sandstorm, Iranian Dream Job) group targets technology, aerospace and defense professionals in the Middle East using highly tailored social engineering lures. The group has used personalized recruitment offers designed to trick targets into initiating the infection chain.

Another evolution highlighted in our research is the use of .NET AppDomainManager hijacking, manipulating legitimate configuration files to disable endpoint security mechanisms before the malware executes.

The Blinder Tunnel campaign employs both tactics. The Dubai Airport Coding Challenge deployment aligns with Screening Serpens' pattern of fraudulent hiring lures targeting the aviation sector.

Manipulation of the RuntimeBroker.exe.config file to execute AppDomainManager hijacking, to disable ETW ( ), was used by Screening Serpens throughout 2026.

When analyzing the Iranian state- activity tracked as Agent Serpens (aka APT35, Charming Kitten, Phosphorus), we noticed additional similarities in its operational playbook.

An overlap between this Blinder Tunnel campaign and Agent Serpens activity is the misuse of trusted developer platforms to maintain resilient C2 infrastructure. If communication channels fail, both campaigns rely on GitHub as a fallback dead-drop resolver.

As described in this research, the ShelbyLoader V2 backdoor queries the GitHub Issues API to extract AES-encrypted routing data hidden within HTML . Similarly, Drokbk malware uses the GitHub API to parse a specific repository file to locate and re-establish its C2 connection.

Furthermore, Cybereason's analysis of the Iranian threat group highlights a similar PowerShell execution technique. Just as Blinder Tunnel operations rely on memory-only wrappers, Agent Serpens deploys the PowerLess Trojan to execute PowerShell commands within a native .NET context. In both cases, the techniques used prevented the creation of a suspicious PowerShell.exe process that could trigger event detection alerts.