OilRig (APT34): DNS Tunneling and Middle East Espionage

OilRig earned a lasting place in threat-intelligence reporting partly through its use of DNS as a covert communications channel. That history matters, but the shorthand can mislead. DNS activity alone does not identify an actor, and OilRig’s reported operations extend beyond tunneling to phishing, valid accounts, compromised infrastructure, web channels, cloud services, and other forms of persistence and collection.

The useful defensive question is therefore not “Does this domain look like OilRig?” It is “Can we connect an unusual resolver signal to the host, process, identity, access path, and activity that came before and after it?” That evidence chain helps a SOC act with confidence even when attribution remains uncertain.

Executive Answer

OilRig, commonly associated with APT34, is an Iranian government-linked espionage activity set that has targeted organizations in the Middle East and beyond since at least 2014. Historical research tied the group to malware that used DNS for command and control and data transfer, but DNS is neither an exclusive signature nor its complete modern playbook. Defenders should govern resolver paths, retain query and response logs, baseline unusual subdomains and record use, identify the generating process, and correlate DNS with endpoint, identity, email, cloud, and follow-on activity before concluding that command and control or exfiltration occurred.

Key Takeaways

• OilRig and APT34 are now combined in MITRE ATT&CK because MITRE assessed higher-confidence overlap, but provider names still reflect different datasets and periods.
• Microsoft maps Hazel Sandstorm to OilRig/APT34-related activity; Trend Micro uses Earth Simnavaz for a source-specific cluster.
• Public reporting associates the group with Iranian government-linked espionage and targets in government, energy, finance, telecommunications, chemical, and related sectors.
• DNS tunneling describes a transport technique. DNS command and control, beaconing, and exfiltration describe possible uses or objectives; DNS hijacking is a different behavior.
• A DNS anomaly is not proof of OilRig, active command and control, or confirmed data loss.
• Historical OilRig tools used DNS in multiple ways, but later reporting also describes web, email, legitimate cloud, and compromised-service channels.
• Strong detection joins resolver telemetry to the originating process, asset, identity, domain context, and subsequent access or collection.
• Encrypted DNS should be governed through approved enterprise paths and endpoint policy so privacy and visibility can coexist.

Who Is OilRig?

OilRig is a long-running cyberespionage activity set widely associated with Iran. MITRE ATT&CK tracks it as group G0049 and says it has targeted Middle Eastern and international victims since at least 2014, including organizations in financial services, government, energy, chemicals, and telecommunications. MITRE also notes evidence that the group has operated on behalf of the Iranian government.

The maintained MITRE ATT&CK OilRig profile combines years of public reporting and is the best starting point for aliases, software, and techniques. Its scope is an analytical aggregation, not a claim that every listed behavior appeared in one campaign or that every historical capability remains active.

OilRig belongs within the broader landscape of Iranian APT groups, but it should not be treated as a synonym for Iranian cyber operations as a whole. MuddyWater, Charming Kitten, APT42, and other maintained clusters can share regions, targets, techniques, or state interests while remaining analytically distinct.

Public reporting consistently presents espionage as the central mission. The likely value of access includes strategic communications, credentials, research, government and commercial information, and trusted relationships that can support follow-on access. The target list observed by researchers is a sample, not a complete census.

Is OilRig the Same as APT34?

For most defensive readers, OilRig and APT34 can be treated as strongly associated names for the same maintained ATT&CK activity set. MITRE states that it previously tracked APT34 and OilRig separately, then combined them after assessing higher-confidence overlap. That is stronger than a casual similarity, but it does not make every provider label perfectly interchangeable.

Threat-actor names are containers built from a provider’s visibility. One company may observe endpoints, another mail flow, another cloud identity activity, and another a narrow campaign. The correct approach is to preserve the source, date, behaviors, victims, and confidence attached to a name.

Microsoft’s current taxonomy maps Hazel Sandstorm to several OilRig/APT34-related labels. That mapping is useful when translating Microsoft reporting, but defenders should still cite Hazel Sandstorm when a finding depends on Microsoft’s telemetry rather than silently relabeling the campaign.

Earth Simnavaz is similarly source-scoped. Trend Micro used the name in 2024 reporting on activity affecting organizations in the Middle East. A source-specific cluster can overlap a broader actor model without proving that every historical OilRig operator, tool, or target belongs to that one campaign.

Attribution: What Is Known and What Remains Analytical?

The defensible public baseline is that OilRig is a suspected Iranian threat group engaged primarily in espionage, with evidence assessed by MITRE and multiple researchers as consistent with Iranian government interests. Exact organizational hierarchy, sponsor, operator roster, and tasking are less visible in public data and should not be stated more precisely than the source allows.

Shared infrastructure, tool code, working hours, language, victimology, and operational patterns can strengthen attribution. None is decisive alone. Reused commodity tools, compromised servers, false flags, and shared victims can create misleading similarities.

For incident response, attribution should be proportional to the evidence and secondary to containment. A team can confidently isolate a hostile process, revoke a compromised account, or block an unauthorized resolver path without proving which government-linked cluster operated it. The actor assessment becomes more useful after the activity chain is preserved.

Who Does OilRig Target?

MITRE’s maintained profile includes financial, government, energy, chemical, and telecommunications organizations in the Middle East and internationally. Campaign reporting has also covered technology, defense-adjacent, and other strategically valuable entities. These patterns support risk prioritization, but sector membership alone is not evidence that an organization is being targeted.

The Middle East emphasis is strategically important. Regional governments, critical services, supply chains, energy operations, telecommunications providers, and organizations connected to geopolitical decision-making can provide intelligence value or trusted access to another target.

OilRig has also been associated with attempts to exploit trust relationships. That makes supply-chain attacks relevant even when the immediate incident does not involve a software build system. A compromised service provider, partner, web server, mailbox, or shared administrative relationship can become an access path to a more valuable organization.

Defenders should translate sector reporting into an asset-and-relationship model: which identities, systems, vendors, resolvers, mailboxes, APIs, and data stores would offer strategic value, and which trusted paths connect them? This produces more useful controls than a static industry label.

A Condensed OilRig Timeline

Why DNS Tunneling Became Associated With OilRig

DNS is essential infrastructure. Most networks permit clients to resolve names, security tools may inspect it less deeply than web traffic, and the protocol can carry variable query names and several response types. An operator can abuse those properties to exchange small pieces of non-DNS information while making the traffic resemble ordinary name resolution at a distance.

Historical Unit 42 research identified multiple OilRig-associated tools that used DNS communications from at least 2016. The OilRig DNS-tunneling analysis described recurring ideas such as client identification, sequencing, changing subdomains, and use of different DNS record types. Those details establish historical capability; they are not a template for assuming every unusual query is the same malware.

For a conceptual explanation of the transport itself, DeepStrike’s guide to DNS tunneling covers why attackers can place non-DNS data inside queries or responses and why ordinary allow-or-block logic struggles to distinguish that activity from legitimate resolution.

The defender’s advantage is that covert use changes patterns. It can generate unusually long or varied labels, high numbers of unique subdomains, unexpected record mixes, periodic requests, concentrated volume to a rare domain, or DNS activity from a process that should not resolve names directly. None is conclusive alone. Correlation creates confidence.

DNS Tunneling, C2, Exfiltration, Beaconing, and Hijacking

These terms are related but not interchangeable.

DeepStrike’s guide to DNS data exfiltration explores the data-loss question in more depth. The critical incident-response distinction is between suspicious transport, attempted transfer, observed transfer, and confirmed exposure of sensitive information.

An alert about high entropy or unique subdomains may justify isolation and evidence preservation. It does not by itself prove what data moved, whether the transfer succeeded, or whether an adversary received it. Those conclusions require endpoint, file-access, staging, network, and destination evidence.

How OilRig Used DNS at a High Level

Historical reporting shows a family resemblance rather than one fixed protocol. OilRig-associated tools used DNS as a way to check in, identify an infected system, exchange instructions, and return results in small units. Researchers observed changing subdomains and several record types across different tools and campaigns.

For defenders, three implications are more valuable than reproducing the mechanics:

1. A single parent domain can receive many distinct subdomains from one or more clients.
2. The resolver may see a pattern that a perimeter flow sensor cannot fully explain.
3. The endpoint can identify the process, parent process, user, and local activity that give the DNS pattern meaning.

Caching and recursive resolution also matter. A central resolver may aggregate many clients, while a passive sensor may see the resolver rather than the original endpoint. Reliable investigation therefore depends on client attribution through resolver logs, DHCP history, asset inventory, endpoint telemetry, or workload metadata.

OilRig Tradecraft Extends Beyond DNS

A “DNS actor” label creates tunnel vision. MITRE’s OilRig profile includes spearphishing, PowerShell, scheduled tasks, valid accounts, credential access, web shells, remote-management tools, supply-chain compromise, public-facing application exploitation, and several command-and-control methods. These are historical observed behaviors across multiple reports, not a prediction that every operation follows one script.

ESET’s reporting on OilRig-related Outer Space and Juicy Mix campaigns described compromised legitimate websites, C#/.NET backdoors, and an email-service-based channel. A 2025 update also refined the provider’s internal subgroup scope, illustrating why readers should preserve the tracking source and date.

Later campaign research has described legitimate cloud or email services as delivery or communication infrastructure. The security lesson is not to block major platforms indiscriminately. It is to ask whether the process, account, destination, application consent, data access, and timing make sense for that user and asset.

Trend Micro’s Earth Simnavaz research adds a more recent Middle East-focused view and highlights exposed infrastructure and post-exploitation activity. It supports a broader model in which server hardening, privilege monitoring, credential protection, and lateral-movement visibility sit alongside DNS analytics.

ATT&CK Behaviors That Matter Most

The table below is a defensive prioritization of behavior families associated with OilRig in maintained public reporting. It is not a claim that every technique is current in every campaign.

MITRE mappings should help teams organize hypotheses and controls. They should not become a compliance checklist detached from local architecture. One well-correlated resolver-to-process detection can be more useful than dozens of brittle technique rules.

The DeepStrike Resolver-to-Host Investigation Chain

DNS analytics often stop at a domain score. The Resolver-to-Host Investigation Chain turns the alert into seven connected decisions.

1. Establish Resolver Ownership

First determine whether the client used an approved enterprise resolver, a local forwarder, a cloud-native service, a directly reached external resolver, or an encrypted DNS path. Without resolver ownership, the team may lack client attribution or query-response history.

The initial control is architectural: document approved paths, restrict unauthorized direct resolution, and retain enough metadata to map a query to a device or workload. Exceptions should have owners and review dates.

2. Characterize the Query Pattern

Measure what is unusual: query volume, unique subdomains, label length, character distribution, record types, response codes, timing, periodicity, domain age, first-seen time, and whether many clients share the pattern. Compare like with like servers to servers, developer systems to developer systems, and agents to the same agent version.

No single threshold fits every environment. A rare domain with modestly unusual labels may be more interesting than a high-entropy domain used by thousands of managed devices.

3. Identify the Process or Workload

Map the client IP and timestamp to the endpoint, container, virtual workload, or network device, then identify the process responsible for the request. Examine the parent process, user, executable provenance, signer, installation path, start time, and adjacent network connections.

This step separates many benign services from suspicious execution. It also reveals a visibility gap when an organization can see the query but cannot attribute it to a workload.

4. Add Identity and Access Context

Identify the signed-in user, service account, token, privilege level, recent authentication events, newly registered devices, password or MFA changes, and access from other locations. DNS may be the first alert even when the broader incident is identity-led.

A process running under a privileged or recently compromised identity changes urgency. So does a host that accessed sensitive mail, files, secrets, or administrative interfaces shortly before the DNS pattern began.

5. Evaluate Domain and Infrastructure Context

Assess registration history, first-seen data, hosting relationships, passive DNS, certificate context, reputation, and whether the domain is expected for the application. Treat reputation as one input. New or low-prevalence domains are not automatically malicious, and known services can be abused.

Analysts should record what the organization observed, what an external source asserts, and what remains inference. This preserves an auditable evidence chain.

6. Hunt Preceding and Follow-On Behavior

Look backward for phishing, exploitation, new processes, script execution, credential access, scheduled tasks, web-shell activity, RMM use, and unusual sign-ins. Look forward for discovery, file access, staging, lateral movement, mailbox collection, cloud access, and persistence.

This is where an isolated DNS anomaly becomes an incident hypothesis. It is also where investigators determine whether there is evidence of data access or transfer rather than assuming both.

7. Search for Alternate Channels

If containment blocks DNS, do not assume the operation is finished. Hunt the same process, host, identity, and destinations across web traffic, mail APIs, cloud services, remote-management tools, and other protocols. Historical OilRig reporting makes this especially important, but the principle applies to any capable adversary.

The completed chain should end with a decision: benign, expected but poorly governed, suspicious and contained, or confirmed malicious with a scoped incident. “Unknown actor” is an acceptable attribution outcome when the behavior decision is well supported.

A DNS Signal Confidence Matrix

The matrix is deliberately false-positive aware. DNS infrastructure supports CDNs, software updates, security products, service discovery, domain validation, DKIM and DMARC, certificate automation, and many cloud platforms. Detection quality depends on context, not on making normal complexity look malicious.

Detection Priorities

1. Centralize Resolver Visibility

Route enterprise DNS through approved recursive resolvers or protective DNS services. Retain query and response data, timestamps, client identifiers, record type, response code, and the mapping needed to identify the originating asset. For cloud and container environments, preserve workload and tenant context.

The goal is not unlimited retention. Set a documented period based on investigation needs, privacy obligations, cost, and regulatory requirements. Ensure responders can access the data quickly and know its limitations.

2. Baseline Behavior by Asset and Application

Profile domains, unique subdomains, label lengths, record types, response patterns, and timing by comparable asset group. A domain that is rare across the enterprise may be normal for one managed application; a common service may be suspicious when contacted by an unusual interpreter or server.

Use prevalence and change detection to prioritize, then verify on the endpoint. Avoid a universal entropy threshold that produces alerts without decisions.

3. Join DNS to Endpoint and Identity

Resolver detections become substantially stronger when a team can identify the process, parent, user, binary reputation, privilege, and adjacent activity. Integrate resolver events with EDR, DHCP or asset inventory, identity protection, authentication, and privileged-access telemetry.

This join also exposes blind spots. Network appliances, unmanaged devices, containers, and transient cloud workloads may require different attribution methods.

4. Govern Encrypted DNS

Encrypted DNS can improve privacy and integrity, but unmanaged endpoints that select arbitrary resolvers can bypass enterprise policy and fragment evidence. Support approved encrypted resolution through controlled services while restricting unauthorized paths and retaining endpoint or resolver telemetry.

The final 2026 NIST Secure Domain Name System Deployment Guide recommends detecting and blocking unauthorized DNS tunneling, using real-time and historical query-response data, integrating DNS with SIEM workflows, and accounting for encrypted DNS in the monitoring architecture.

5. Cover Phishing, Exposure, and Valid Accounts

DNS analytics cannot compensate for an unpatched internet-facing service, weak mailbox controls, or an unmonitored privileged account. Correlate suspicious domains with email delivery, URL access, application exploitation, new sign-ins, token use, MFA changes, account recovery, and server persistence.

DeepStrike’s phishing statistics and trends provide broader context for why identity and user-targeted entry paths remain relevant. Local detections should focus on the organization’s actual mail, browser, identity, and cloud controls rather than copying industry percentages into alert logic.

6. Monitor Alternative Communications

Look for unexpected web, email API, cloud storage, and remote-management activity from the same process, identity, or asset. Blocking one protocol can push a capable operator to another channel or reveal an existing fallback.

Document which legitimate remote and cloud tools are approved, who owns them, and where their audit logs live. Unknown use of an allowed service is an investigation lead, not automatic proof of abuse.

Mitigation Roadmap

First 30 Days: Establish Control and Evidence

• Inventory approved recursive resolvers, cloud DNS services, forwarders, and encrypted DNS paths.
• Restrict endpoint DNS to approved services where architecture permits.
• Confirm resolver logs include client attribution, query and response data, record types, response codes, and synchronized timestamps.
• Integrate DNS alerts with EDR and asset inventory.
• Review high-risk internet-facing systems and urgent remediation ownership.
• Inventory privileged identities, service accounts, RMM tools, mail APIs, and cloud applications.
• Create a playbook that distinguishes suspicious DNS, attempted transfer, observed transfer, and confirmed data exposure.

A disciplined patch-management program supports the same objective by reducing exposed infrastructure paths that could bypass a phishing- or DNS-centered detection plan.

Days 31–60: Build Context and Triage

• Baseline unique subdomains, label lengths, record use, NXDOMAIN rates, and query timing by asset cohort.
• Add process-level DNS telemetry for high-value endpoints and servers.
• Correlate DNS with authentication, mailbox, cloud, proxy, WAF, and vulnerability data.
• Define approved cloud, email API, and remote-management use.
• Tune alerts with benign application owners rather than suppressing unexplained patterns.
• Test client attribution across DHCP changes, VPN, NAT, containers, and transient workloads.
• Establish privacy, retention, and access controls for DNS telemetry.

An attack-surface management workflow can keep the exposed-asset inventory and ownership current, especially when cloud services and vendor-managed systems change faster than periodic scans.

Days 61–90: Exercise and Measure

• Run a consented exercise that starts with one entry path and shifts among DNS, web, and cloud channels at a conceptual level.
• Measure time to map resolver event to asset, process, user, and data access.
• Test isolation, resolver blocking, identity revocation, mail and cloud scoping, and evidence preservation.
• Validate that responders can distinguish blocked attempts from confirmed data loss.
• Test communications among SOC, network, endpoint, identity, cloud, legal, privacy, and business owners.
• Convert gaps into named remediation items with owners and deadlines.

The objective is not a perfect “OilRig detector.” It is a resilient control system that can investigate comparable behaviors regardless of the eventual actor name.

Incident Response for Suspected OilRig Activity

Preserve Before You Simplify

Save resolver query and response logs, EDR process and network telemetry, DHCP and asset mappings, proxy and firewall records, authentication events, mailbox and cloud audit logs, vulnerability findings, and relevant server artifacts. Record time zones and clock drift.

Avoid deleting a suspicious file or blocking a domain before capturing enough evidence to scope other affected systems, unless immediate harm requires emergency action.

Contain the Host and Resolver Path

Isolate the affected endpoint or workload using approved procedures. Block or sinkhole the relevant domain safely where appropriate, and close unauthorized direct or encrypted resolver paths without disrupting approved enterprise resolution.

Containment should preserve the ability to observe whether related hosts or identities are active. Coordinate network, endpoint, and application owners before broad blocks.

Identify the Generating Process

Determine which process or workload made the requests, its parent chain, execution origin, user or service identity, file provenance, persistence, and adjacent connections. Search for the same process, binary, service, task, account, and destination across the environment.

If the source is a server or appliance without EDR, use operating-system, application, hypervisor, flow, and administrative-access evidence to reconstruct the activity.

Scope Identity, Email, and Cloud Access

Review recent sign-ins, token use, MFA and recovery changes, privileged actions, mailbox rules, API access, new applications, consent grants, cloud storage access, and service-account behavior. Revoke affected sessions and credentials based on evidence and risk.

Do not assume a password reset invalidates every token, mailbox rule, app consent, SSH key, API credential, or service secret.

Determine Data Access Before Declaring Loss

Establish what files, mailboxes, databases, shares, secrets, or cloud objects the affected identity and host accessed. Look for collection and staging, then determine whether network or service evidence supports attempted, observed, or completed transfer.

Use precise language in executive, legal, customer, and regulatory communications. “Suspicious DNS consistent with tunneling” and “confirmed exfiltration of identified records” are very different findings.

Recover and Retest

Remove persistence, rebuild or restore affected systems as appropriate, rotate exposed secrets, close the initial access path, review third-party trust, and validate the control changes. Continue monitoring for alternate channels and related identities after the immediate alert disappears.

A practiced incident response plan reduces decision delay by assigning evidence, containment, communications, legal, privacy, and recovery responsibilities before a real intrusion.

OilRig vs. Other Iranian Activity Sets

The comparison is a navigation aid, not a universal attribution key. Provider scopes can change, and campaign evidence may sit at a narrower or broader level than the familiar actor label.

Common Defensive Mistakes

Treating Entropy as a Verdict

Long random-looking labels can be generated by legitimate cloud, security, update, certificate, and email systems. Entropy is useful for ranking events, not for proving malicious intent.

Assuming Every DNS Alert Is Exfiltration

The channel may support check-ins, tasking, results, discovery, or failed communications. Confirm data access, staging, direction, and transfer before declaring a breach of specific information.

Looking Only at the Resolver

A resolver can reveal the pattern but not always the originating process or identity. Without endpoint, workload, DHCP, and asset context, analysts may block a domain while missing the actual persistence.

Blocking DNS and Closing the Case

A capable operator may use web, mail, cloud, or remote services as an alternative. Continue hunting the host, identity, process, and destination relationships after the DNS path is contained.

Treating Encrypted DNS as Inherently Malicious

Encryption can be a legitimate security and privacy control. The management problem is unauthorized resolver selection and lost attribution. Provide approved encrypted paths and enforce policy consistently.

Overfitting to OilRig

DNS tunneling is not exclusive to one actor. Build behavior-led detections, then use source-scoped attribution as context. A correct containment decision does not require a famous name.

Ignoring Team Boundaries

Network, endpoint, identity, cloud, email, and server evidence often belong to different owners. An alert can stall even when every team has one useful piece. Define the investigation handoffs in advance.

Validate the Defenses

A purple-team or adversary-emulation exercise should test decisions, not reproduce malware. Begin with a safe DNS anomaly, require the SOC to identify the client and process, introduce identity or cloud context, then test whether responders find a controlled alternate channel and distinguish attempted transfer from confirmed loss.

The relationship between red teams and blue teams is most useful when each missed observation becomes a telemetry, ownership, playbook, or control improvement rather than a score against the defenders.

DeepStrike’s Red Teaming as a Service can help organizations evaluate these cross-domain controls through scoped, authorized simulations designed around business risk and agreed safety boundaries.

Frequently Asked Questions

What is OilRig?

OilRig is a long-running cyberespionage activity set widely associated with Iran. MITRE tracks it as G0049 and links it to targeting in the Middle East and internationally across government, energy, finance, telecommunications, chemical, and other strategically valuable sectors.

Is OilRig the same as APT34?

MITRE now combines OilRig and APT34 after assessing higher-confidence overlap. They can usually be treated as strongly associated names, but analysts should preserve each source’s label, dates, campaign scope, and confidence rather than assuming every provider tracks an identical set.

Is Hazel Sandstorm another name for OilRig?

Hazel Sandstorm is Microsoft’s current name mapped to OilRig, APT34, EUROPIUM, Helix Kitten, and related labels in Microsoft’s taxonomy. It is best used when discussing Microsoft-tracked activity, not as a universal replacement for every historical OilRig report.

How did OilRig use DNS tunneling?

Historical research described several OilRig-associated tools using DNS to check in, exchange instructions, identify systems, or return results. The implementations varied. Defenders should focus on unusual query patterns and the responsible process rather than recreating or depending on one protocol signature.

Does a DNS-tunneling alert prove data exfiltration?

No. It may indicate a suspicious transport or command-and-control hypothesis, but confirmed exfiltration requires evidence about data access, staging, direction, transfer, and destination. Teams should distinguish attempted, observed, and confirmed data movement.

How can defenders detect OilRig-related DNS activity?

Use approved resolvers, retain query and response logs, baseline subdomain and record behavior, map events to the originating process and identity, and correlate with phishing, exploitation, persistence, credential, cloud, and data-access evidence. These controls detect behavior; they do not prove actor identity by themselves.

What should responders do after suspected OilRig activity?

Preserve resolver, endpoint, network, identity, email, cloud, and server evidence; contain the host and unauthorized channel; revoke exposed sessions and credentials; hunt persistence and alternative communications; determine what data was accessed; recover affected systems; and retest the failed controls.

Conclusion

OilRig’s history explains why DNS deserves a place in threat hunting, but it also warns against a one-protocol view of an adversary. A resolver signal becomes actionable when defenders can trace it to a process, identity, access path, and sequence of behavior and when they continue looking after the DNS channel is blocked.

The durable objective is not to recognize one malware family or actor label. It is to govern resolver paths, retain usable evidence, correlate security domains, make careful data-loss conclusions, and exercise the people who must act together. That capability protects the organization whether the final attribution is OilRig, another threat actor, or remains unknown.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.