Case Study: Identifying Iranian Threat Actors on U.S. Infrastructure

In July, using Intrace, an Optiv worker learned that his personal workstation appeared in dark web data associated with a malware group referred to as “Water Black.” The hostname of his desktop had been observed in underground data sources that Intrace monitors, suggesting that the machine was not only compromised, but also tagged as a high-value target. This designation was consistent with his role: he had previously led incident response work on a major ransomware case, making him an attractive target for threat actors interested in retaliation or intelligence on defensive techniques.

Dark Web Discovery and Hostname Exposure

The starting signal for the investigation was simple but serious:
Intrace’s dark web monitoring detected the hostname of the consultant’s desktop in data linked to Water Black.

• A hostname is the human-readable label for a machine on a network (for example, JOHN-DESKTOP or CORP-LAPTOP-01).
• Seeing a hostname in threat actor material usually means the attackers have achieved at least some level of access to that device or its environment.

Rather than only seeing generic IP addresses or anonymized victim references, the appearance of a specific desktop hostname is a strong indicator that the device itself was part of a campaign – not just a random internet scanner hit.

Infrastructure Link

During the early triage, Intrace correlated the Water Black reference with Internet-facing infrastructure. The team identified a single host on the internet with the hostname waterblack, hosted in a Wyoming datacenter owned by an Iranian-controlled provider. At this point:

• The hosting company was RouterHosting, LLC, which later rebranded as Cloudsy.
• This same provider had been cited in open reporting as supporting multiple government-linked hacking groups, which increased the likelihood that this was not random commodity malware infrastructure, but rather part of a more organized set of operations.

This matters because infrastructure attribution is a core part of intrusion analysis. When a provider or datacenter has prior association with state-aligned groups, and you see new suspicious domains or servers there, it raises confidence that you are dealing with an advanced, possibly government-linked threat actor rather than purely opportunistic criminals.

DNS and Traffic Pattern

On the workstation itself, Intrace examined outbound connections and DNS resolution patterns. Over several weeks, the machine had been:

• Frequently connecting to newly registered, “parked” domains.
• Many of those domains resolved to infrastructure at the same hosting provider tied to Iranian ownership.

A parked domain is a domain name that is registered but not actively used for a real website. It typically shows a generic holding page or ads. Attackers like using parked or nearly empty domains because:

1. They are cheap and easy to register in bulk.
2. They look mostly benign to casual inspection.
3. They can be repointed quickly to new servers to evade blocking.

The repeated connection pattern suggested beaconing behavior: the compromised host regularly contacting attacker-controlled infrastructure for instructions or updates. This is a common design in command-and-control (C2) malware, where the infected machine periodically checks in with a remote server to send status and receive commands.

As an immediate defensive move, the consultant blocked access to parked domains at the network level. This is interesting from an analytical perspective because cutting off the primary C2 channel often forces the malware to reveal fallback mechanisms, misconfigurations, or error behavior – which is exactly what happened next.

Crash of “MicrosoftSecurityApp.exe”

Within days of blocking parked domains, a process named MicrosoftSecurityApp.exe crashed on the workstation.

This binary name is suspicious for several reasons:

• It mimics a plausible Microsoft security component without matching a well-known, documented product.
• Malware commonly uses fake or misleading filenames to blend in with legitimate system processes (for example, adding “Microsoft”, “Security”, “Update”, or “Service” to the name).

The crash right after outbound connections were blocked suggests that this process was either:

• The malware’s core agent, trying and failing to reach its C2 domains, or
• A loader or watchdog that depended on successful outbound communication, and crashed when that communication broke.

From an analytical standpoint, this is a classic example of behavior under stress: once C2 is blocked, advanced malware may crash, restart, switch to backup channels, or try local persistence mechanisms more aggressively.

Local Persistence Clues

After dealing with the crashed MicrosoftSecurityApp.exe, the workstation attempted to launch Game Bar, a built-in Windows component typically used for gaming overlays and screen capture. The consultant had previously disabled Game Bar due to suspicious behavior, so this reactivation attempt was notable.

In the Windows Registry, Game Bar was referenced under entries that began with AppX. Other AppX entries pointed toward FTP and SSH.

A few points of explanation:

• AppX is Microsoft’s packaging format for modern Windows Store apps. Malware can sometimes abuse app container mechanisms, scheduled tasks, or AppX manifests for persistence.
• FTP (File Transfer Protocol) and SSH (Secure Shell) are standard protocols:
  • FTP is used for file transfers, often in cleartext.
  • SSH is used for encrypted remote logins and tunneling.

Seeing AppX entries pointing to FTP and SSH is strange for a personal workstation that is not supposed to act as a server. It suggests that the malware may have:

• Registered app-like entities or scheduled tasks that interact with remote FTP/SSH endpoints.
• Set up alternative channels for data exfiltration or command reception, separate from the parked domain HTTP/HTTPS C2.

The attempt to re-enable or trigger Game Bar may indicate:

• Abuse of Game Bar’s overlay and capture capabilities for screen recording or user spying.
• Use of a legitimate Windows component as part of a living-off-the-land strategy to reduce the use of obviously malicious binaries.

Network Artifact: TCP 22 and a Link to “GhostContainer”

During this window, the consultant observed a TCP connection on port 22 to the address 52.98.240.82.

• TCP port 22 is almost universally associated with SSH.
• The IP in question is linked to legitimate infrastructure (for example, cloud or SaaS providers), but online discussions had associated it with something called “GhostContainer.”

GhostContainer is a backdoor targeting Microsoft Exchange servers, documented by security researchers. It provides attackers with persistent, remote access into Exchange environments, including the ability to execute commands and move laterally.

While the consultant’s machine was not an Exchange server, the fact that:

1. There was SSH-like behavior on TCP 22 to an address linked to GhostContainer reporting, and
2. The host had been previously beaconing to suspicious domains tied to state-linked infrastructure,

suggests that the workstation may have been:

• Part of a broader toolset used by the same actors that deploy GhostContainer elsewhere, or
• Used as a staging point or observation node to monitor or manage Exchange-side operations from a trusted endpoint.

This aligns with the pattern of a high-value target compromise: rather than just stealing files, the attackers potentially wanted a trusted machine in the environment they could use to pivot, observe incident response actions, or maintain access even as corporate systems were being hardened.

Attempted Rogue Root Certificate Installation

The consultant also recalled an attempt to install a rogue Root Certificate Authority (CA).

This is a crucial detail. A Root CA certificate is one of the anchors that operating systems and browsers use to decide whether an encrypted connection (for example, HTTPS) is trustworthy. If an attacker manages to install their own malicious root certificate on a system, they can:

• Intercept and decrypt otherwise secure TLS traffic (for example, webmail, dashboards, admin portals).
• Present fake certificates for arbitrary domains (for example, outlook.com, vpn.company.com) and have them appear valid to the compromised system.

In practice, this would allow the attackers to:

• Conduct man-in-the-middle (MITM) attacks on the victim’s connections without triggering certificate warnings.
• Read or alter sensitive communications, including incident response email chains, ticketing systems, and other confidential exchanges.

The attempted root CA installation is a strong indicator of intent to persist and surveil, not just quick smash-and-grab activity.

Why This Person Was Targeted

The victim was not chosen at random. Intrace’s review of the dark web references and context revealed that:

• He was explicitly labeled as a high-value target.
• This status likely stemmed from his previous incident response work on a major ransomware case.

From an attacker’s point of view, compromising someone with deep visibility into defenses and response processes provides:

• Intelligence on how defenders detect and respond to certain intrusions.
• Potential leverage or retaliation against someone who had previously disrupted their operations.
• Access to valuable contact networks and documentation, even if they sit primarily on corporate systems, because the personal workstation is often used as a side channel.

This combination of personal targeting, Iranian-linked infrastructure, parked domain beaconing, rogue root CA attempts, and backdoor-style behavior is consistent with a deliberate, multi-stage intrusion rather than random drive-by malware.

How Intrace Structured the Investigation

From Intrace’s perspective, the investigation followed a clear structure:

1. Signal intake from dark web
   • Detect the hostname and high-value designation in Water Black-related data.
   • Confirm that the referenced host belongs to an Optiv consultant.
2. Infrastructure correlation
   • Find the waterblack host at the Iranian-owned datacenter in Wyoming.
   • Map related parked domains resolving to the same provider.
   • Cross-reference with prior reporting on the hosting company’s involvement with government-linked groups.
3. Host telemetry and behavior
   • Examine outbound connections over several weeks to parked domains.
   • Identify MicrosoftSecurityApp.exe as a suspicious process and analyze its behavior around the time network blocking was implemented.
   • Review registry entries, including AppX references to Game Bar, FTP, and SSH.
4. Network artifacts and external tool links
   • Note TCP 22 traffic to 52.98.240.82 and its mention in discussions of GhostContainer.
   • Assess whether observed behavior fits within a backdoor or lateral-movement pattern.
5. Trust and cryptography integrity
   • Investigate the attempted installation of a rogue Root CA.
   • Evaluate the risk of ongoing encrypted traffic interception.
6. Containment and hardening recommendations
   • Isolate the workstation from sensitive environments.
   • Remove suspicious binaries and registry entries.
   • Reset credentials and strengthen multi-factor authentication.
   • Enforce strict DNS and egress controls, with monitoring for new parked domains and suspicious SSH traffic.
   • Audit trusted certificates on the machine and revoke any unauthorized CAs.

Outcome

By combining dark web intelligence, infrastructure analysis, host forensics, and careful interpretation of network artifacts, Intrace was able to reconstruct the compromise path and clarify how an Optiv consultant became a targeted victim of Iranian-linked threat activity. The case highlighted how:

• Personal devices used by security professionals can become strategic targets.
• Parked domains and obscure hosting providers can serve as quiet C2 infrastructure.
• Attempts to install rogue root certificates and exploit built-in Windows components like Game Bar are consistent with long-term, stealthy access goals rather than noise.

Optiv used these findings to contain the incident, harden the consultant’s environment, and adjust detection logic to look for similar patterns across other endpoints and clients.

‍