Live Active security incident? Get immediate response
MITRE ATT&CK® Malware

S0258: RGDoor

RGDoor is a malicious Internet Information Services (IIS) backdoor developed in the C++ language. RGDoor has been seen deployed on webservers belonging to the Middle East government organizations. RGDoor provides backdoor access to compromised IIS servers. [1]

EnterpriseS0258MalwareObject v1.2 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

RGDoor matters because it is an IIS backdoor for Windows web servers: a compromised public-facing web server can become a persistent access point, command channel, and staging location for additional tools. For leaders, the key issue is not just malware removal; it is whether web server hardening, IIS change control, logging, and incident response playbooks can prove what changed, what commands ran, and whether additional files or data were staged.

Executive priority

Prioritize RGDoor as a resilience and assurance concern for organizations that operate IIS on Windows, especially where web servers support public services or sensitive business workflows. ATT&CK links RGDoor to OilRig and notes prior deployment on Middle East government web servers, but local risk should be based on exposure, IIS administration practices, and telemetry readiness. Executives should ask whether IIS component changes are governed, whether SOC teams can distinguish legitimate web traffic from command-and-control over web protocols, and whether incident responders can rapidly collect web, host, and file evidence from affected servers.

Technical view

RGDoor is described by ATT&CK as a C++ malicious IIS backdoor that provides backdoor access to compromised IIS servers. Relationship context ties it to IIS Components for persistence, Windows Command Shell for execution, Web Protocols and Ingress Tool Transfer for command-and-control activity, System Owner/User Discovery, Deobfuscate/Decode Files or Information, and Archive via Custom Method. SOC and IR teams should validate visibility on Windows IIS hosts for unexpected IIS modules/components, suspicious command shell execution in the web server context, unusual inbound or outbound HTTP/S patterns, new or modified files transferred to the server, user discovery commands or artifacts, decoding behavior, and custom archive-like files. Official ATT&CK detection guidance is not provided, so detection engineering should be built from these relationships and local IIS baselines.

Likely telemetry

  • IIS configuration, module/component inventory, and change records
  • IIS web access logs and HTTP/S request metadata
  • Windows process creation telemetry, especially command shell execution associated with IIS worker processes or service accounts
  • Windows file creation, modification, and transfer evidence on IIS web directories and server staging paths
  • Network telemetry for web protocol communications to and from IIS servers

Detection direction

  • Establish a known-good baseline of IIS components and alert on unexpected IIS module/component additions or modifications.
  • Correlate IIS web requests with host process execution, especially Windows command shell activity launched in proximity to web traffic or under IIS-related identities.
  • Review web protocol traffic for anomalous request patterns, unusual endpoints, unexpected external destinations, or command/result-like exchanges while accounting for normal application behavior.
  • Monitor for tool or file transfer into IIS servers and for suspicious files placed in web-accessible or staging directories.
  • Look for user discovery behavior on IIS hosts and correlate it with web server process ancestry and administrative activity.

Mitigation priorities

  • Reduce exposed IIS attack surface and enforce change control for IIS components, modules, and web application deployments.
  • Harden Windows IIS servers using least-privilege service accounts and administrative access controls appropriate to the environment.
  • Ensure security monitoring covers IIS configuration changes, web logs, Windows process creation, file activity, and network web protocol traffic.
  • Create an IR playbook for suspected IIS backdoors that preserves IIS logs, component inventories, process evidence, transferred files, and relevant network records.
  • Segment and monitor web servers so a compromised IIS host cannot easily become a staging point for broader tool transfer or discovery.
Analyst notes and limits

The ATT&CK object identifies RGDoor as malware for Windows IIS servers and provides relationship-driven behavior context, including persistence through IIS components and command-and-control over web protocols. The OilRig relationship is useful for threat intelligence context, but it should not be treated as proof of current activity or local targeting without independent evidence.

Official ATT&CK detection guidance is not provided, tactics are not specified on the malware object itself, and the supplied source detail is limited to the ATT&CK fields, one Unit 42 reference, and ATT&CK relationships. Environment-specific conclusions require local IIS exposure data, server baselines, logs, and incident evidence.

Official MITRE ATT&CK definition

RGDoor

RGDoor is a malicious Internet Information Services (IIS) backdoor developed in the C++ language. RGDoor has been seen deployed on webservers belonging to the Middle East government organizations. RGDoor provides backdoor access to compromised IIS servers. [1]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

7 rows
Domain ID Name Relationship / procedure
Enterprise T1505.004 IIS Components Sub-technique

RGDoor establishes persistence on webservers as an IIS module.CitationUnit 42 RGDoor Jan 2018CitationESET IIS Malware 2021

Enterprise T1059.003 Windows Command Shell Sub-technique

RGDoor uses cmd.exe to execute commands on the victim’s machine.CitationUnit 42 RGDoor Jan 2018

Enterprise T1560.003 Archive via Custom Method Sub-technique

RGDoor encrypts files with XOR before sending them back to the C2 server.CitationUnit 42 RGDoor Jan 2018

Enterprise T1071.001 Web Protocols Sub-technique

RGDoor uses HTTP for C2 communications.CitationUnit 42 RGDoor Jan 2018

Enterprise T1033 System Owner/User Discovery

RGDoor executes the whoami on the victim’s machine.CitationUnit 42 RGDoor Jan 2018

Enterprise T1140 Deobfuscate/Decode Files or Information

RGDoor decodes Base64 strings and decrypts strings using a custom XOR algorithm.CitationUnit 42 RGDoor Jan 2018

Enterprise T1105 Ingress Tool Transfer

RGDoor uploads and downloads files to and from the victim’s machine.CitationUnit 42 RGDoor Jan 2018

Associated objects

Groups, software, and campaigns

Group Enterprise

G0049: OilRig

OilRig is a suspected Iranian threat group that has targeted Middle Eastern and international victims since at least 2014. The group has targeted a variety of sectors, including financial, government, energy, chemical, and telecommunications. It appears the group carries out supply chain attacks, leveraging the trust relationship between organizations to attack their primary targets. The group works on behalf of the Iranian government based on infrastructure details that contain references to Iran, use of Iranian infrastructure, and targeting that aligns with nation-state interests.[1][2][3][4][5][6][7]

Relationship explorer

All related ATT&CK context

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.2
Created
Modified
Raw hash
f52c7eecaeff5cff...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.2 Current bundle f52c7eecaeff…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Unit 42 RGDoor Jan 2018

    Falcone, R. (2018, January 25). OilRig uses RGDoor IIS Backdoor on Targets in the Middle East. Retrieved July 6, 2018.

    Open source URL
  2. [2]
    RGDoor

    (Citation: Unit 42 RGDoor Jan 2018)

  3. [3]
    mitre-attack S0258
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.