DarkBlinders: Inside an Active Espionage Campaign

Executive summary

Dream uncovered a new, active wave of cyberespionage targeting Israel and the Kurdistan Region of Iraq, conducted by DarkBlinders, the threat actor behind the Blinder Tunnel campaign previously documented by Unit 42. We observed the campaign between August and October 2026, and it remained active at the time of publication. Our investigation confirmed the compromise of a high-profile individual in Israel and identified additional compromises affecting a government cloud environment in the Kurdistan Region.

The current wave used government webmail, cloud-drive, and meeting-service lures. We also identified phishing infrastructure impersonating the Gulf Cooperation Council (GCC) Secretariat General and Kuwait's Ministry of Foreign Affairs, indicating broader targeting of Gulf governmental and diplomatic entities. GitHub repositories under the PeakyBlindersTeam account served as the malware's command-and-control infrastructure. The operator reviewed metadata from infected hosts before selectively activating a second-stage backdoor, enabling PowerShell command execution on chosen systems.

Our investigation established three key findings:

• Direct visibility into attacker operations and confirmed impact. Reverse engineering the malware enabled read-only access to the actor's command-and-control repositories, revealing operator tasking against a government cloud environment in the Kurdistan Region of Iraq and a high-profile individual in Israel associated with the security sector. Confirmed post-compromise activity included credential theft and the exfiltration of at least 1 GB of data from the government cloud environment.
• Connections across five campaign waves. Dream Security linked the current campaign to four earlier waves, each of which used a different GitHub repository for C2. These waves were documented by Elastic Security Labs, Unit 42, and Group-IB, establishing continuity across previously reported operations.
• Attribution linking the broader activity cluster. We assess with medium-to-high confidence that the examined DarkBlinders activity belongs to the same operational cluster as UNC5795 and Dust Specter. Shared infrastructure, overlapping victimology, and supporting attribution research further suggest, with medium confidence, that this cluster and UNC5187 may represent related subclusters within APT34.

Dream's agentic Campaigner system

Dream's Sphere national cyberdefense solution supported the investigation, using its Campaigner functionality as an agentic pivoting system. The Pivoter agent converted reporting into structured intelligence and expanded infrastructure relationships, while the Malware Agent supported static and dynamic analysis of the loader and backdoor. Researchers reviewed the findings and performed the repository access and malware validation described in this report.

Technical campaign overview

The campaign combined credential phishing with malware delivery. Government and cloud-service lookalikes collected credentials or presented attacker-controlled file downloads. StarkMeet, a fake video-meeting application, provided a credible reason for a recipient to install an application while a separate RuntimeBroker branch established persistence and loaded the malware.

The post-installation design separated discovery from activation. RuntimeBroker.dll collected host metadata and registered the system through myLic. The operator could then decide whether to provide host-specific activation material. RuntimeBrokerApi.dll was decrypted only for selected hosts and loaded directly into memory, after which the second-stage backdoor used myCode to retrieve tasking and return data.

Key technical findings

• RuntimeBroker.dll contained a GitHub token used to access the PeakyBlindersTeam myLic repository.
• Historical Lic.txt content supplied key material required to decrypt RuntimeBrokerApi.dll.
• RuntimeBrokerApi.dll contained a second token associated with the myCode tasking repository.
• The repositories exposed approximately ten initial check-ins but only two identified victims in the second-stage tasking channel, supporting a selective activation assessment.
• The first observed myLic host was a virtual machine with a Persian keyboard layout and may have been an operator test system.
• A separate remote file management service branded TommyFiles extended the actor's Peaky Blinders naming theme.

Research workflow and repository access

The investigation moved from loader analysis to repository history, payload recovery, and operator tasking. The workflow below shows the evidence path. Tokens are intentionally redacted in the figure.

Loader analysis and myLic

Analysis of RuntimeBroker.dll identified an embedded GitHub personal access token and repository paths under PeakyBlindersTeam. The token provided read access to myLic. The repository contained check-in records created by malware instances, including host identifiers and system metadata used by the operator to evaluate newly registered systems.

Approximately ten distinct hosts appeared in the available check-in data. The difference between these initial registrations and the smaller set visible in myCode indicates that a check-in did not automatically result in full second-stage activation.

Key recovery and second-stage decryption

Repository history was essential to payload recovery. A historical version of Lic.txt preserved key material that was no longer available in the current file state. We reproduced the loader's process by deriving the AES-256 key from the SHA-256 hash of Lic.txt and using the first 16 key bytes as the initialization vector. This recovered RuntimeBrokerApi.dll in plaintext for analysis.

The loader normally decrypts RuntimeBrokerApi.dll and loads it directly into memory. This reduces the chance that the decrypted backdoor will be collected from disk. No matching plaintext sample was identified on VirusTotal at the time of analysis, which made repository history and local reproduction necessary to examine the second stage.

Backdoor analysis and myCode

RuntimeBrokerApi.dll contained a second embedded GitHub token associated with myCode. The repository held commands issued to compromised systems. These records connected the capabilities implemented in the backdoor with tasking from the live operation and provided visibility that static analysis alone could not provide.

The combined repositories show the operational sequence: myLic receives the initial beacon and host metadata; the operator selects a host and supplies activation material; RuntimeBroker.dll decrypts and loads RuntimeBrokerApi.dll; and the backdoor uses myCode for tasking and result exchange.

Read-only research safeguards

Our interaction with the GitHub infrastructure was strictly read-only and limited to retrieving existing repository contents and commit history. We did not create, modify, or delete repository content, and we did not issue commands to any malware instance.

Phishing and delivery

The actor used two delivery paths. Lookalike government, webmail, and cloud-drive pages supported credential theft and file delivery. StarkMeet used a fake meeting application to persuade recipients to install malware. The available evidence supports these delivery mechanisms, but the original message used to deliver StarkMeet.zip was not recovered.

Government webmail credential theft

The campaign recreated Outlook Web App (OWA) login pages on domains impersonating the Kuwaiti Ministry of Foreign Affairs and the GCC Secretariat General. The clearest recovered artifact was an HTML page that copied Microsoft OWA code and referenced official-looking assets from mail.mofa.gov.kw. The form collected usernames and passwords and submitted them to an attacker-controlled /owa/auth.owa endpoint.

The page did not contain an exploit or malware download. Its purpose was credential collection. A successful submission could expose email, contacts, shared files, and linked cloud services without producing an endpoint malware alert.

Cloud-drive delivery lures

The actor also reproduced the structure of Google Drive sharing links on attacker-controlled domains. Paths using /drive/file/d/<identifier>/view appeared on generic drive domains and on domains themed around the Kurdistan Regional Government and its Ministry of Electricity. The presentation gave recipients a familiar file-sharing workflow while keeping the download under attacker control.

In the captured example, the page presented Attachment.zip, reported that the archive could not be previewed, and directed the recipient to download it. This design converts an expected preview failure for a ZIP archive into a prompt for user execution.

Malware delivery through StarkMeet

StarkMeet was presented as a video-meeting application. The installer displayed a conventional setup wizard for version 3.2 and opened a functional-looking meeting interface. The Join function returned a fixed failure rather than contacting a real meeting service, allowing the visible application to serve as a decoy while the RuntimeBroker components were installed separately.

Malware execution and selective activation

The infection chain combines a meeting-client decoy, a signed .NET host, an AppDomainManager-based loader, and an encrypted second-stage backdoor. GitHub provides separate channels for host registration and operator tasking. This separation allows the operator to review infected systems before supplying the material required to activate the backdoor.

Delivery and decoy application

Campaign infrastructure referenced StarkMeet.zip, although neither the archive nor the original delivery message was recovered. Phishing email or a meeting invitation remains a plausible but unconfirmed delivery route.

The analyzed installer is an unsigned Inno Setup package presented as StarkMeet version 3.2. It installs the visible application under %LOCALAPPDATA%\StarkMeet and the malicious components under %LOCALAPPDATA%\Microsoft\RuntimeBroker. These components operate independently, allowing the RuntimeBroker.exe branch to remain persistent after the visible application is removed.

StarkMeet.exe is a .NET Framework 4.8 meeting-client decoy featuring "Stark Industries" branding and Marvel-themed participants. Camera, microphone, and screen-sharing previews function locally, but clicking Join always produces the error "Stark Meet couldn't reach a meeting server." Analysis identified no networking, persistence, or payload deployment functionality in the decoy itself.

An embedded PDB path places the application under C:\Users\Admin\Desktop\Projects\PeakyBlinders\. The same development directory appears in the PDB path of PsProxy.dll, the PowerShell execution helper embedded in the second-stage backdoor.

Loader execution, persistence, and host registration

A legitimate, signed vshost.exe, renamed RuntimeBroker.exe, loads RuntimeBroker.dll. The loader exits unless the host executable resides at the expected path: %LOCALAPPDATA%\Microsoft\RuntimeBroker\RuntimeBroker.exe

Persistence is maintained through the MicrosoftRuntime value under HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, pointing to the same executable. The first persistence check occurs 121 seconds after startup and repeats hourly.

The loader derives a victim identifier from the first 16 lowercase hexadecimal characters of: SHA256("Peaky Blinders 2.1" + UserSID + MachineName + UserDomainName)

Using an embedded personal access token, it accesses the GitHub Contents API and writes a host report to PeakyBlindersTeam/myLic at {id}/{id}Inf.txt. The report contains the machine name, user and domain, logon server, time zone, interface language, installed keyboard layouts, local time, persistence status, and anti-analysis findings.

The environmental checks cover anti-analysis tests and virtual-machine artifacts, analysis-tool processes, hardware resources, timing anomalies, MAC address prefixes, usernames and hostnames, process counts, system-drive age, and the parent process. These checks produce [INFO] and [ALARM] entries in the report but do not stop execution. Their results provide the operator with information for deciding whether to activate the host.

Selective activation and payload decryption

The loader requests host-specific activation material from {id}/{id}Lic.txt in myLic. After Base64-decoding the retrieved content into a license string, it overwrites the repository file with a newline.

The license string supplies the material needed to decrypt the locally stored RuntimeBrokerApi.dll:

• Algorithm: AES-256-CBC with PKCS7 padding.
• Key: SHA-256 hash of the license string.
• Initialization vector: The first 16 bytes of the derived key.

The plaintext .NET assembly is loaded directly into a new AppDomain, without writing the decrypted DLL to disk. Clearing the license file removes the material from its current contents, although previous versions may remain accessible through Git history.

This design separates initial registration from operational access. A host can report to myLic while the second-stage backdoor remains encrypted, pending delivery of the required activation material.

Backdoor communications and command execution

On startup, RuntimeBrokerApi.dll creates a mutex named Global\ followed by the full hexadecimal SHA-256 hash of "GSC" + id. It exits if the mutex already exists, preventing multiple instances for the same victim identifier.

The backdoor communicates with PeakyBlindersTeam/myCode using a separate embedded GitHub token. Its primary endpoint is api.github.com, with a Cloudflare Worker available as a fallback relay. Before accepting the relay, the malware checks that its /rate_limit response contains GitHub-shaped JSON and an X-GitHub-Request-Id header.

Tasking is retrieved from {id}/{id}.txt approximately every 63 seconds. If the command file is missing but the repository is accessible, the implant creates an empty file. After reading a command, it clears the file by replacing its contents with a newline.

Results are written beneath the same victim directory using filenames that combine inverted .NET ticks and a readable timestamp. The inverted value causes newer results to sort before older ones. Command and result text is Base64-encoded, without additional application-layer encryption.

PowerShell execution is provided by PsProxy.dll, embedded as Base64 within the backdoor and loaded through Assembly.Load(). Its PsProxy.PSExecutor.RunCommand method creates a System.Management.Automation runspace. Commands therefore execute within the existing process without spawning powershell.exe, limiting visibility from detections that rely on that child process.

Alongside PowerShell execution, the backdoor implements the following commands:

Credential rotation through public GitHub comments

Both malware stages implement a mechanism for replacing their GitHub account, repository, and token settings. This routine runs hourly and can also be triggered by an HTTP 403 access failure, with failure-triggered attempts limited to once every 30 minutes.

The main channel depends on a GitHub token hardcoded in the binary. If GitHub revokes that token or takes down the repository, the implant is orphaned. A "magic comment" lets the operator hand every implant a new owner, repository, and token without touching the victim, by posting to one of the busiest public repositories on GitHub. The malware searches issues in the public Microsoft/vscode repository:

• GET /search/issues?q=<yyyyMMdd>+repo:Microsoft/vscode+type:issue searches for issues matching today's date string.
• For each result, it fetches the issue's comments_url and takes the text inside the first <!-- … --> block in each comment.
• It removes the date string, CR/LF characters, and the comment markers from that text. The code expects the date to sit inside the hidden block.
• It Base64-decodes and AES-CBC-decrypts the result five times in a row (PKCS7 padding), with key = MD5(yyyyMMdd + victimID) and IV = MD5(key).
• It applies the result in memory only if all three of Owner=…, LicRepo=…, and LicToken=… are present. Otherwise, it keeps the current settings, logging "Magic comment not found — keeping existing credentials".

Obfuscation and binary metadata

Both RuntimeBroker.dll and RuntimeBrokerApi.dll are obfuscated with Obfuscar and carry Microsoft-themed version information, including version 10.0.26100.7019 and the description "Microsoft® Windows® Operating System."

Operator infrastructure and victim visibility

Peaky Blinders naming theme

The GitHub account name PeakyBlindersTeam made the theme explicit. The actor retained the operational repository names myLic and myCode while moving them under this account. We also identified remote file infrastructure branded TommyFiles. The name appears to reference Tommy Shelby, the central character in Peaky Blinders, and extends the same theme beyond GitHub.

Naming is not sufficient for attribution on its own. In this case, the shared theme accompanies the same malware workflow, repository naming, and operational role, making it useful for clustering infrastructure and guiding pivots.

TommyFiles remote file infrastructure

The recovered interface presented a username and password prompt for a remote file management console. Its role is consistent with operator-controlled staging or file management, although the screenshot alone does not establish which payloads or stolen data were stored behind the service.

Observed hosts and likely testing

The myLic repository contained check-in records for approximately ten distinct hosts. The first observed system was a virtual machine configured with a Persian keyboard layout. We assess that it may have been an operator test environment used to validate infrastructure or malware behavior before victim activation. This remains an analytical judgment because the available record does not identify the system owner.

Confirmed victim visibility

The myCode repository provided visibility into two victims that progressed beyond initial check-in. One was a government entity in the Kurdistan Region of Iraq whose affected environment was associated with cloud infrastructure. The second was a high-profile individual in Israel associated with the security sector.

The difference between approximately ten myLic registrations and two myCode victims is consistent with deliberate operator selection. Systems could beacon to myLic without receiving the key material required for RuntimeBrokerApi.dll, allowing the operator to reserve the full backdoor for hosts considered operationally relevant.

Historical campaigns

During our investigation, we identified earlier DarkBlinders campaigns and GitHub infrastructure used during 2025, including the accounts johnshelllby, arturshellby, and GreenBeret0. We subsequently observed the actor's infrastructure evolve through peakyblinders-team and peakyblinders-tm, followed by the newest campaign using PeakyBlindersTeam. Our review of the ClickHouse public GitHub-event archive also identified a previously unreported account, PeakyBlindersTM, created on 26 August 2025. Minutes after its creation, this account created main branches for repositories named PeakyBlindersTeam.github.io and PeakyBlindersTM. Although its naming and timing make it a relevant investigative lead, no published reporting or additional technical evidence currently confirms its association with DarkBlinders.

Attribution and relationships between activity clusters

Dream Security assesses with medium-to-high confidence that the DarkBlinders activity examined in this report belongs to the same operational cluster as activity tracked as UNC5795 and Dust Specter. This assessment draws on extensive infrastructure associations and matching malware samples across the documented campaigns.

A further infrastructure connection links this combined cluster to UNC5187. Historical server fingerprints, overlapping victimology, and supporting attribution research lead us to assess with medium confidence that UNC5795 and UNC5187 may represent related subclusters within the broader APT34 group.

Indicators of an Iranian nexus

Infrastructure testing

During our analysis, passive DNS history showed that starkmeet[.]com used ParsVDS nameservers and resolved to 51.79.96[.]115, an address within OVH Hosting infrastructure in Canada. The use of ParsVDS provides limited contextual support for an Iranian nexus, although this infrastructure association alone does not establish the operator's location or identity.

Operator environment

The earliest check-in visible in myLic came from a VM with a Persian keyboard layout. Its position as the earliest recorded check-in, together with the environment metadata, suggests that it may have been an operator test system. The Persian keyboard layout is consistent with an Iranian nexus, but does not independently establish attribution.

Together, these observations provide contextual support for the Iranian nexus assessed through the infrastructure and malware relationships detailed below.

Linking DarkBlinders to UNC5795

Correlating infrastructure and malware from successive DarkBlinders campaigns with Google Threat Intelligence (GTI) identified extensive associations with UNC5795. These span domains, related subdomains, hosting addresses, and delivery URLs across multiple waves. The infrastructure included domains themed around telecommunications providers, airports, meeting services, and network speed tests.

Malware sample mappings reinforce this relationship. The HTTPService.dll and HTTPApi.dll samples documented by Elastic Security Labs as SHELBYLOADER and SHELBYC2 (the earlier-wave counterparts of RuntimeBroker.dll and RuntimeBrokerApi.dll, respectively) are classified as HOTAIR and AEROSTAT and associated with UNC5795.

The infrastructure associations across successive campaigns, supported by these malware mappings, underpin our medium-to-high-confidence assessment that the examined DarkBlinders activity falls within UNC5795. Google's public reporting on UNC5795's use of HOTAIR and AEROSTAT against Middle Eastern targets provides additional corroboration.

Connecting Dust Specter to the same cluster

Applying the same correlation to Dust Specter revealed extensive infrastructure and malware associations with UNC5795. These included meeting-service and commercial-themed domains used for command and control, together with related URLs and hosting addresses.

The tooling provides a further connection. The RiroDiog.exe sample documented by Zscaler as GHOSTFORM is classified as TREEWORLD and associated with UNC5795. This exact sample match reinforces the infrastructure associations. TREEWORLD also appears alongside HOTAIR and AEROSTAT in Google's public description of UNC5795 operations, connecting the tooling observed across the DarkBlinders and Dust Specter campaigns.

DarkBlinders and Dust Specter therefore converge on UNC5795 through their respective infrastructure and malware associations. We assess with medium-to-high confidence that the examined campaigns belong to a common operational cluster. For the remainder of this section, UNC5795 refers to this combined body of activity.

Infrastructure linking UNC5795 and UNC5187

A pivot from the Dust Specter–associated domain meetingapp[.]site revealed an infrastructure connection to UNC5187. Passive DNS records showed that the domain resolved to 89.46.233[.]239 between 26 May and 2 June 2026.

The same address had previously served as command-and-control infrastructure for windowsObject.exe, an ENDDOT-family sample associated with UNC5187. The malware communicated with the address on TCP port 10443, linking the UNC5187-associated infection chain to the server later used by UNC5795-associated infrastructure.

Historical service observations strengthen this connection. A distinctive HTTP banner hash associated with UNC5187 was observed on the address between February 2025 and February 2026. Across the broader period, from February 2025 through our investigation, SSH was repeatedly observed on the uncommon TCP port 4781, with banner changes corresponding to version upgrades. Despite these changes, the server retained the same SSH host key across available observations, including during the period when meetingapp[.]site resolved to the address. This stable cryptographic fingerprint provides additional evidence of continuity of the SSH endpoint across the two clusters' use of the infrastructure.

The recurring HTTP fingerprint, persistent SSH configuration, and unchanged SSH host key support an assessment of continued operator control across the relevant periods. Together, they strengthen the connection between the earlier UNC5187 activity and the server's subsequent use by UNC5795-associated infrastructure. Although these observations do not establish uninterrupted control by a particular operator, they support infrastructure reuse under related administration.

Possible placement within APT34

The infrastructure connection to UNC5187 provides one line of support for placing the combined DarkBlinders/UNC5795/Dust Specter cluster within the broader APT34 group. Its focus on Iraqi government targets and use of government-themed social engineering are also consistent with previously documented APT34-associated operations, although these characteristics are not exclusive to that group.

Existing attribution research provides further corroboration. Recorded Future identifies overlap between Dust Specter and TAG-135, which it tracks as an APT34 subcluster, while Google/Mandiant describes UNC5187 as having moderate-confidence ties to APT34. These assessments support connections to APT34 from both sides of the infrastructure relationship identified in our investigation.

Considering the technical findings, victimology, and supporting research together, we assess with medium confidence that UNC5795 may represent a subcluster within APT34 and that UNC5187 may constitute another related subcluster. Their precise organizational placement remains unresolved.

Assessing the relationship between UNC5795 and UNC5187

The infrastructure sharing suggests an operational relationship between UNC5795 and UNC5187. A server used by UNC5187-associated malware later supported UNC5795 infrastructure, while its historical fingerprints and unusual SSH configuration indicate likely continuity of administration across the relevant periods.

Their overlapping focus on Iraqi government entities adds context to this technical connection and suggests a shared intelligence collection interest. Combined with their respective APT34 associations, these findings support a medium-confidence assessment that the two clusters are operationally related and may belong to the same broader group.

UNC5795 and UNC5187 could represent different portions of one team's activity, or distinct but closely connected APT34 subclusters sharing infrastructure or supporting resources. We retain the separate designations because the available evidence establishes a relationship more clearly than it establishes the organizational structure behind it.

Indicators of compromise

This section consolidates the indicators from this investigation for detection and hunting. Certificates are excluded. Domains are reduced to the main registered domain, with subdomains retained only when they identify a distinct shared-service resource. URL entries are limited to credential pages, file-delivery paths, payload downloads, and operational backend endpoints. Domains, URLs, and IP addresses are defanged.

GitHub and Cloudflare are shared platforms. Match the exact account, repository, Worker hostname, and path shown below rather than blocking github.com, api.github.com, workers.dev, or Cloudflare services globally.

Domain indicators

URL indicators

Hosting IP indicators

File and content hashes

Scope note: Hosting geography describes infrastructure location and should not be treated as victim geography. Indicator descriptions summarize the observed campaign role.