Table of Contents
- Module 1: Middle East Cyber Threat Landscape Briefing
- Overview: The Kinetic-Cyber Pattern
- Iran’s Cyber Posture After the Strikes
- Verifying Claims: Handling Unconfirmed Attribution
- Key Iranian-Linked Threat Actors
- The Operational Asymmetry: Noise vs. Silent Positioning
- Physical Infrastructure Risk: The Cloud Data Center Incident
- Indirect Spillover Risk: The UK Advisory
- The US Picture: Domestic Warnings
- Defensive Response Framework
- Summary
Module 1: Middle East Cyber Threat Landscape Briefing
Overview: The Kinetic-Cyber Pattern
In late February of this year, the United States and its allies launched military strikes against Iran. That kinetic action is the backdrop for this briefing, but the more operationally relevant detail for defenders is how quickly cyber activity appeared alongside the military action — not as a delayed follow-on, but present from the very start of the conflict.
This mirrors a pattern already observed during the Russia-Ukraine conflict beginning in 2022, where cyber operations were part of the picture from day one. The practical lesson for security teams is that the effects of a regional conflict do not stay neatly contained inside the conflict zone. If an organization depends on providers, suppliers, or operations located in or connected to the region, it can feel the impact even while being geographically far removed from the fighting.
timeline
title Kinetic-Cyber Pattern Precedent
2022 : Russia invades Ukraine
: Cyber operations active from day one of the conflict
Late Feb (this year) : US and allied strikes against Iran
: Cyber activity emerges alongside the strikes, not after them
This briefing focuses on three questions security teams should be asking right now:
- Who are the threat actors involved?
- What are they actually doing (versus what is being claimed publicly)?
- What should security teams be doing about it, regardless of whether their organization sits “in” the conflict zone?
Iran’s Cyber Posture After the Strikes
There is an apparent contradiction in Iran’s post-strike cyber posture that is worth unpacking carefully.
Unit 42 assessed that Iran’s internal internet connectivity dropped to somewhere between roughly 1% and 4% of normal levels following the strikes. The instinctive read is that this would hamstring Iran’s ability to coordinate cyber operations. In practice, that instinct is misleading.
Iran’s cyber ecosystem — whether by original design or simply as a byproduct of how it evolved — has proven fairly resilient to domestic network disruption. It is structured in layers:
- State agency groups at the core (the formal, state-directed operational units)
- Proxy actors operating around that core, many of them physically located outside Iran
- Hacktivist collectives, also largely operating outside Iranian territory
None of these outer layers depend on Iran’s domestic internet to function, and critically, they were already active before the kinetic phase of the conflict even began. A domestic connectivity collapse inside Iran does very little to slow down actors who were never dependent on that connectivity in the first place.
mindmap
root((Iranian Cyber Ecosystem))
State Agency Groups
Core, state-directed
Formal operational units
Proxy Actors
Largely based outside Iran
Independent of domestic connectivity
Hacktivist Collectives
Also largely outside Iran
Already active pre-conflict
Key takeaway: a ~1-4% domestic connectivity figure should not be read as “Iran’s cyber capability is degraded.” The actors that matter operationally were largely unaffected by the domestic outage.
Verifying Claims: Handling Unconfirmed Attribution
During any high-visibility conflict, public claims of compromise spike, and not all of them hold up to scrutiny. Two examples from this conflict illustrate why claims need to be handled carefully rather than treated as settled fact.
Recycled credentials presented as new. Group-IB found that credentials presented as freshly stolen by at least one group had actually been pulled from older, previously circulated combo lists. The lesson: “suspicious” is not the same thing as “verified,” and threat actors have an incentive to inflate the appearance of fresh compromise for propaganda value.
The Handala / medical device manufacturer incident. The pro-Iranian-aligned hacktivist collective known as Handala claimed a wide-reaching attack against a major medical device manufacturer with significant ties to the US military and veterans’ healthcare systems. That company did confirm a severe global network disruption occurred. However, the full extent of Handala’s claims about the scope of the breach remained unverified at the time of this recording.
The plausible reasons the target may have been seen as relevant to this conflict include its presence in Israel and its ties into US military and veteran healthcare supply chains. But for defenders, the exact motive matters less than what the choice of target signals more broadly: a company does not need to sit on the front line of a geopolitical conflict to be considered a relevant target.
flowchart TD
A[Public breach claim surfaces] --> B{Is the claim independently confirmed?}
B -->|Yes, e.g. confirmed network disruption| C[Treat as real operational impact]
B -->|No, claim details unverified| D[Treat as unconfirmed - do not assume full scope]
C --> E[Assess targeting rationale, not just headline]
D --> E
E --> F[Ask: which normally-visible actors have gone quiet?]
The more useful operational question for defenders is not “who is making the most noise right now?” It is “which threat actors would we normally expect to see active, but haven’t heard from?” That question points directly at the next section.
Key Iranian-Linked Threat Actors
Three Iranian-linked groups matter most operationally right now, and they fall into two very different behavioral categories: one is conspicuously quiet, and two are actively running confirmed campaigns.
APT34 / OilRig — the quiet one
APT34, also tracked as OilRig, is Iran’s most prolific espionage group. It has been largely absent from public reporting since February 28th of this year. That silence is not reassuring — with a group like OilRig, quiet historically means positioning: gaining initial access, establishing persistence, harvesting credentials, and moving carefully before anything becomes visible to defenders.
This pattern is comparable to the behavior seen from Volt Typhoon: get in, establish persistence (often through living-off-the-land binaries, or LOLBins), and then loiter — sometimes for months, sometimes for years — without triggering obvious alerts.
OilRig’s historical targeting has focused on:
- Energy
- Finance
- Government
- Telecommunications
Its operational signature involves long dwell times, credential harvesting, and lateral movement — it is fundamentally an access-and-persistence group, not a smash-and-grab group. The current silence is consistent with, not contrary to, how it typically operates.
Indicators consistent with OilRig’s early-access tradecraft that defenders should be watching for include:
- Low-frequency / quiet DNS query activity that doesn’t match established baselines
- Web shells deployed on Microsoft Exchange servers
- General low-visibility behavior that is easy to miss if defenders are only watching for obvious disruption
MuddyWater — active and coordinated
MuddyWater is giving defenders something far more immediate to track. Its ongoing campaign (referred to in reporting as “Operation Olalampo” — note: this campaign name was transcribed from spoken audio and the exact published name may differ slightly) is targeting the wider Middle East and Africa (META) region. SANS and Unit 42 both found infrastructure overlap between this campaign and a separately tracked campaign referred to as “RedKitten,” suggesting coordination — or at minimum shared infrastructure — across Iranian-linked actors.
MuddyWater relies heavily on:
- Legitimate, dual-use tools (rather than custom malware)
- Compromised legitimate credentials
- Blending into normal operational activity within the target environment
Perimeter controls alone will not catch this style of operation — detection requires visibility inside the environment itself, not just at the network edge.
APT35 / Charming Kitten — patient social engineering
APT35, also known as Charming Kitten, is another Iran-based group continuing to harvest credentials against military, government, academic, and telecommunications targets. Its tradecraft is defined by patience:
- Extended, carefully constructed fake personas on social platforms
- Outreach via WhatsApp and Telegram sustained over multiple weeks
- Phishing pages that clone Google login and Google Meet interfaces, hosted on legitimate Google infrastructure to inherit trust and evade domain-reputation filtering
The targeting profile here is telling: this activity is aimed at understanding decision-making and intent, not simply gaining infrastructure access. It is classic long-horizon espionage tradecraft.
flowchart LR
subgraph Quiet_Positioning["Quiet - Positioning Phase"]
A[APT34 / OilRig]
A --> A1[Absent from public reporting since Feb 28]
A1 --> A2[Consistent with: gain access, persist, harvest creds, stay hidden]
end
subgraph Active_Operations["Active - Confirmed Campaigns"]
B[MuddyWater]
B --> B1["Operation Olalampo" targeting META region]
B1 --> B2[Overlap with RedKitten infrastructure]
C[APT35 / Charming Kitten]
C --> C1[Fake personas + WhatsApp/Telegram outreach]
C1 --> C2[Google-hosted credential phishing pages]
end
| Threat Actor | Also Known As | Current Posture | Primary Targeting | Key Tradecraft |
|---|---|---|---|---|
| APT34 | OilRig | Quiet since Feb 28 — likely positioning | Energy, finance, government, telecoms | Long dwell time, credential harvesting, lateral movement, ASPX web shells on Exchange, low-frequency DNS |
| MuddyWater | — | Active, confirmed campaign (“Operation Olalampo”) | Middle East & Africa (META) region broadly | Legitimate/dual-use tools, compromised credentials, infrastructure overlap with “RedKitten” |
| APT35 | Charming Kitten | Active, confirmed campaign | Military, government, academic, telecoms | Long-term fake personas, WhatsApp/Telegram social engineering, Google-hosted credential phishing clones |
The Operational Asymmetry: Noise vs. Silent Positioning
Stepping back, the overall picture is one of asymmetry: two actively confirmed operations (MuddyWater and Charming Kitten) generating visible signal, set against Iran’s most prolific espionage group (OilRig) sitting quietly in the background. That asymmetry — not the volume of headlines — is what should be driving defensive prioritization.
Hacktivist activity claiming “targets” will naturally draw the most public attention because it is loud and easy to report on. But APT34’s silence since late February is arguably the more important signal for security teams to be watching, precisely because it doesn’t generate headlines.
Physical Infrastructure Risk: The Cloud Data Center Incident
One event in this conflict deserves attention as a genuine risk marker rather than a footnote: a major cloud provider confirmed a fire at a UAE data center after objects struck the facility during the kinetic phase of the conflict. This was physical, military action directly affecting commercial cloud infrastructure.
A great many organizations still operate under the assumption that “if it’s in the cloud, it’s somehow abstracted away from geography.” This incident is a clear, concrete reminder that it isn’t. Cloud infrastructure is still physical infrastructure, sitting in a physical location, subject to physical risk.
The incident itself was not a catastrophic outage, but it demonstrated the underlying mechanism of concentration risk: if a significant share of an organization’s services depend on infrastructure concentrated in one geographic location, disruption there can propagate further than expected — surfacing in banking systems, airline booking platforms, customer-facing platforms, or any number of services that look completely unrelated to the region until something breaks underneath them. In a high-pressure geopolitical environment, assumptions about resilience and abstraction get tested very quickly.
flowchart TD
A["Physical/kinetic event near cloud data center (UAE)"] --> B[Facility fire confirmed by provider]
B --> C{Is service concentrated in that region/facility?}
C -->|Yes| D[Concentration risk realized]
C -->|No, distributed| E[Limited direct exposure]
D --> F["Downstream impact surfaces in unrelated-looking services:<br/>banking, airline bookings, customer platforms"]
F --> G["Reveals dependency/concentration risk<br/>that was previously invisible to the business"]
This isn’t just an incident report — it’s what the incident reveals about dependency and concentration risk. If an organization relies on providers, suppliers, or services tied to that region, physical distance from the conflict does not remove exposure. The map matters.
Indirect Spillover Risk: The UK Advisory
In early March, the UK’s National Cyber Security Centre (NCSC) published an advisory drawing a deliberate and important distinction between two categories of risk:
- Direct attack risk — for UK domestic organizations, this is not assessed as significantly elevated at this time.
- Indirect spillover risk — through shared cloud services, supply relationships, and connected systems — which is a materially different conversation.
The organizations most exposed to that indirect risk are typically the ones that have never asked where their supply chain actually goes, or what physical infrastructure their cloud services sit on. The NCSC’s Director for National Resilience was explicit on this point: the absence of a direct attack is not evidence of safety if an organization’s supply chains run through the affected region.
flowchart TD
Start["Is my organization directly targeted?"] --> Direct{Direct attack evidence?}
Direct -->|No direct evidence| Assume["Common assumption:<br/>'We are not exposed'"]
Assume --> Trace["Trace actual dependencies:<br/>Tier-2 vendors, cloud data center locations,<br/>critical SaaS suppliers with Gulf-region operations"]
Trace --> Reveal{Dependency traced to the region?}
Reveal -->|Yes| Indirect["Indirect spillover risk exists<br/>regardless of geographic distance"]
Reveal -->|No| Lower["Lower indirect exposure - but re-verify periodically"]
Security teams consistently report the same experience: “We don’t have operations in the Middle East” or “we’re not exposed” is the starting assumption, right up until dependencies are actually traced — two-tier vendors, cloud data center physical locations, and critical software suppliers with Gulf operations — at which point the picture changes quickly.
The US Picture: Domestic Warnings
The pattern in the United States is similar to the UK’s. The Department of Homeland Security (DHS) warned that low-level activity from pro-Iranian activists is likely, including distributed denial-of-service (DDoS) attacks, phishing, and reconnaissance. Separately, the Cybersecurity and Infrastructure Security Agency (CISA), together with its partners, warned that Iranian state-sponsored or affiliated actors may target vulnerable US networks and other entities of interest.
For defenders, the balance to strike is not overreacting to every low-level event that surfaces, but also not dismissing the broader pattern those events sit within.
Once an organization has actually worked through its exposure, the response itself is a familiar one. Much of this maps directly onto the same resilience discipline already associated with ransomware preparedness:
- Patching
- Network segmentation
- Backups
- Multi-factor authentication (MFA)
- Active hunting for persistence mechanisms
This is not a separate discipline requiring a new program — it is the same operational muscle, applied in a different geopolitical context.
Defensive Response Framework
This isn’t a ticketing exercise. It requires leadership attention and actual resourcing, not just a task assigned to an individual analyst. Three concrete actions should anchor the response:
1. Map your indirect exposure. Many organizations state they have no Middle East operations and stop the analysis there. The more useful questions are:
- Where is our cloud infrastructure physically located?
- Which suppliers further down our chain have significant operations in the region?
- Which critical SaaS platforms that we depend on sit on infrastructure concentrated in an active conflict zone?
This mapping exercise is unglamorous and frequently deferred, but it is impossible to make a sensible risk decision without it. Organizations that actually complete this exercise almost always uncover something they had not properly weighed — a deprioritized vendor relationship, or a cloud dependency that traces back to the region in ways that were never tracked.
2. Treat APT34/OilRig’s silence as an active threat indicator, not an absence of one. Begin hunting now for the indicator patterns that vendors and researchers are already flagging, including:
- Low-frequency DNS anomalies
- ASPX web shells deployed on Exchange servers
Establishing a baseline of normal DNS query patterns in your environment is a prerequisite — without a baseline, OilRig-style anomalies will not stand out from routine noise. OilRig does not tend to announce itself; when it moves, the access is typically already established.
3. Test your resilience before you need it. The cloud data center incident is a reminder that the services organizations depend on still sit on physical infrastructure. Concretely test failover mechanisms and measure how long recovery actually takes — not how long you assume it takes, because there is usually a meaningful gap between the two. A written recovery plan is only useful once it has actually been exercised.
flowchart TD
A[Defensive Response Framework] --> B["1. Map indirect exposure<br/>(cloud location, tier-2 vendors, SaaS dependencies)"]
A --> C["2. Treat OilRig silence as active threat<br/>(baseline DNS, hunt for web shells)"]
A --> D["3. Test resilience before you need it<br/>(measure real failover/recovery time)"]
B --> E[Leadership attention + real resourcing required]
C --> E
D --> E
Finally, don’t let hacktivist activity — the loud, headline-generating claims of groups actively declaring targets — pull attention away from the state-actor picture underneath it. That loud activity does not sound reassuring, but APT34’s silence since late February is probably the more important signal to be watching right now. The overall pattern of Iranian cyber operations is patient and deliberate, designed to establish access well ahead of when that access is actually used. The question every defender should be asking is whether their defenses are ready for that — or whether they will only realize the access was there after the fact.
Summary
This conflict reinforced a pattern already seen in Russia-Ukraine: cyber activity runs in parallel with kinetic conflict from day one, and its effects are not contained by geography. Key takeaways:
- Domestic disruption inside Iran does not equate to reduced Iranian cyber capability. State agency groups, proxy actors, and hacktivist collectives operating outside Iran are largely independent of Iran’s domestic internet connectivity.
- Public breach claims require verification before action. Recycled credentials get presented as fresh compromise, and confirmed disruption does not automatically validate the full scope of an attacker’s claims.
- The quiet actor may be the more dangerous one. APT34/OilRig’s absence from public reporting since late February is consistent with active positioning (persistence, credential harvesting), not reduced activity.
- MuddyWater and Charming Kitten are running confirmed, active campaigns with distinct tradecraft: legitimate-tool abuse and infrastructure sharing for MuddyWater; patient, persona-driven social engineering for Charming Kitten.
- Cloud infrastructure is still physical infrastructure. A data center fire caused by kinetic action is a direct demonstration of geographic concentration risk that can surface in seemingly unrelated downstream services.
- Indirect spillover risk often exceeds direct attack risk for organizations physically distant from the conflict, driven by shared cloud services, supply chains, and connected systems.
- The organizational response is not new — it is the same resilience discipline (patching, segmentation, backups, MFA, persistence hunting) already applied to ransomware readiness, applied here in a geopolitical context.
Defender Checklist
| # | Action | Why It Matters |
|---|---|---|
| 1 | Map physical location of all cloud infrastructure and critical SaaS dependencies | Concentration risk is invisible until an incident forces the question |
| 2 | Trace tier-2 and tier-3 supplier operations for Gulf/Middle East presence | Indirect exposure is usually larger than assumed |
| 3 | Establish a DNS query baseline for your environment | Required to spot low-frequency anomalies associated with OilRig-style tradecraft |
| 4 | Actively hunt for ASPX web shells on Exchange servers | Known OilRig persistence indicator |
| 5 | Treat “no reported activity” from historically prolific groups as a signal, not reassurance | Silence from an access-oriented group is consistent with positioning, not absence |
| 6 | Verify breach claims independently before acting on scope | Claimed impact and confirmed impact are frequently different things |
| 7 | Reinforce patching, segmentation, backups, and MFA | Same resilience baseline already used for ransomware readiness |
| 8 | Test failover and measure actual recovery time, not assumed recovery time | Written recovery plans are unproven until exercised |
| 9 | Brief leadership and secure real resourcing, not just ticket assignment | Geopolitical cyber risk requires organizational prioritization, not just analyst attention |
| 10 | Monitor both hacktivist noise and state-actor silence in parallel | Loud claims and quiet positioning represent different risk categories that both need tracking |
Search Terms
security · hot · takes · middle · east · briefing · threat · intel · networking · systems · cyber · risk