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

T1505.004: IIS Components

Adversaries may install malicious components that run on Internet Information Services (IIS) web servers to establish persistence. IIS provides several mechanisms to extend the functionality of the web servers. For example, Internet Server Application Programming Interface (ISAPI) extensions and filters can be installed to examine and/or modify incoming and outgoing IIS web requests. Extensions and filters are deployed as DLL files that export three functions: Get{Extension/Filter}Version, Http{Extension/Filter}Proc, and (optionally) Terminate{Extension/Filter}. IIS modules may also be installed to extend IIS web servers.[1][2][3][4]

Adversaries may install malicious ISAPI extensions and filters to observe and/or modify traffic, execute commands on compromised machines, or proxy command and control traffic. ISAPI extensions and filters may have access to all IIS web requests and responses. For example, an adversary may abuse these mechanisms to modify HTTP responses in order to distribute malicious commands/content to previously comprised hosts.[2][1][5][6][4][7]

Adversaries may also install malicious IIS modules to observe and/or modify traffic. IIS 7.0 introduced modules that provide the same unrestricted access to HTTP requests and responses as ISAPI extensions and filters. IIS modules can be written as a DLL that exports RegisterModule, or as a .NET application that interfaces with ASP.NET APIs to access IIS HTTP requests.[8][4][9]

EnterpriseT1505.004Sub-techniqueObject v1.1 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Malicious IIS components matter because they turn a Windows web server’s normal extension points into persistence. If an attacker can install an ISAPI extension, ISAPI filter, or IIS module, that code may observe or modify HTTP requests and responses, execute commands, or proxy command-and-control traffic through a trusted server path. For leaders, the issue is not only malware on a host; it is loss of trust in a public-facing application platform that may handle credentials, customer traffic, or business-critical services.

Executive priority

Prioritize this where IIS supports externally reachable, regulated, or mission-critical applications. The key business questions are: who can change IIS components, how quickly can the team prove what modules and DLLs are legitimate, and whether audit evidence exists to reconstruct unauthorized changes. This technique supports persistence, so incident decisions should include server rebuild or component validation planning rather than only web log review.

Technical view

For Windows IIS servers, validate the inventory and change history of ISAPI extensions, ISAPI filters, and IIS modules, including native DLL modules and .NET modules. Review whether components export or implement expected IIS functions such as GetExtensionVersion, HttpExtensionProc, GetFilterVersion, HttpFilterProc, TerminateExtension/Filter, or RegisterModule when applicable. Because ATT&CK does not provide official detection text for this object, detection engineering should anchor on configuration drift, unauthorized code execution under IIS, suspicious module/filter registration, and unusual web request/response handling patterns. Relationship context shows this is a sub-technique of Server Software Component and is associated with reported software/campaign usage, so treat it as a persistence validation item during IIS compromise investigations.

Likely telemetry

  • IIS configuration data showing registered modules, ISAPI extensions, and ISAPI filters
  • File system evidence for IIS-related DLLs and .NET module artifacts, including creation and modification times
  • Windows host audit logs covering privileged changes and administrative activity on IIS servers
  • IIS web logs and application logs for unusual request patterns or server behavior
  • Process and module-loading telemetry for IIS worker processes where available

Detection direction

  • Establish a known-good baseline of IIS modules, ISAPI filters, ISAPI extensions, paths, hashes, owners, and signing status, then alert on additions or changes.
  • Tune for authorized deployment noise by integrating change-management records; IIS extension changes can be legitimate during application releases.
  • Validate visibility into both native DLL-based modules and .NET modules, since the ATT&CK description covers both.
  • Correlate suspicious component changes with privileged account activity, web traffic anomalies, and unexpected IIS worker process behavior.
  • Use the related DET0068 detection strategy as a pointer for coverage planning, but confirm local details because the supplied ATT&CK object contains no official detection procedure text.

Mitigation priorities

  • Restrict who can administer IIS and modify server components using privileged account management and least privilege.
  • Apply execution prevention so only authorized code can run on IIS servers where feasible.
  • Require and verify trusted code-signing for IIS-related binaries and deployment artifacts, recognizing that signing should be one control among several.
  • Maintain regular auditing of IIS configuration, component inventory, privileged changes, and server-side file integrity.
  • Include IIS component review in incident response playbooks for Windows web server compromise and persistence eradication.
Analyst notes and limits

The object is a Windows persistence sub-technique under Server Software Component. ATT&CK relationships list detections and mitigations, plus use by campaigns and software such as OwaAuth, RGDoor, and IceApple; these relationships show the behavior is documented in ATT&CK, not that any specific environment is affected. The most useful defensive outcome is the ability to quickly distinguish legitimate IIS extensibility from unauthorized persistence.

The official ATT&CK detection field for this object is not provided. Telemetry and control guidance therefore must be validated against the organization’s IIS versions, deployment model, logging configuration, and change-management process. No claim is made here about active exploitation, attribution, or guaranteed detection coverage.

Official MITRE ATT&CK definition

IIS Components

Adversaries may install malicious components that run on Internet Information Services (IIS) web servers to establish persistence. IIS provides several mechanisms to extend the functionality of the web servers. For example, Internet Server Application Programming Interface (ISAPI) extensions and filters can be installed to examine and/or modify incoming and outgoing IIS web requests. Extensions and filters are deployed as DLL files that export three functions: Get{Extension/Filter}Version, Http{Extension/Filter}Proc, and (optionally) Terminate{Extension/Filter}. IIS modules may also be installed to extend IIS web servers.[1][2][3][4]

Adversaries may install malicious ISAPI extensions and filters to observe and/or modify traffic, execute commands on compromised machines, or proxy command and control traffic. ISAPI extensions and filters may have access to all IIS web requests and responses. For example, an adversary may abuse these mechanisms to modify HTTP responses in order to distribute malicious commands/content to previously comprised hosts.[2][1][5][6][4][7]

Adversaries may also install malicious IIS modules to observe and/or modify traffic. IIS 7.0 introduced modules that provide the same unrestricted access to HTTP requests and responses as ISAPI extensions and filters. IIS modules can be written as a DLL that exports RegisterModule, or as a .NET application that interfaces with ASP.NET APIs to access IIS HTTP requests.[8][4][9]

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

Related techniques

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1505 Server Software Component This object subtechnique of Server Software Component.
Associated objects

Groups, software, and campaigns

Malware Enterprise

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]

Windows
Malware Enterprise

S1022: IceApple

IceApple is a modular Internet Information Services (IIS) post-exploitation framework, that has been used since at least 2021 against the technology, academic, and government sectors.[1]

Windows
Campaign Enterprise

C0022: Operation Dream Job

Operation Dream Job was a cyber espionage operation likely conducted by Lazarus Group that targeted the defense, aerospace, government, and other sectors in the United States, Israel, Australia, Russia, and India. In at least one case, the cyber actors tried to monetize their network access to conduct a business email compromise (BEC) operation. In 2020, security researchers noted overlapping TTPs, to include fake job lures and code similarities, between Operation Dream Job, Operation North Star, and Operation Interception; by 2022 security researchers described Operation Dream Job as an umbrella term covering both Operation Interception and Operation North Star.[1][2][3][4]

Campaign Enterprise

C0058: SharePoint ToolShell Exploitation

The SharePoint ToolShell Exploitation campaign was conducted in July 2025 and encompassed the first waves of exploitation against incompletely patched spoofing (CVE-2025-49706) and remote code execution (CVE-2025-49704) vulnerabilities affecting on-premises Microsoft SharePoint servers. Later patched and updated as CVE-2025-53770 and CVE-2025-53771, the ToolShell vulnerabilities were widely exploited including by China-based ransomware actor Storm-2603 and espionage actors Threat Group-3390 and ZIRCONIUM. SharePoint ToolShell Exploitation targeted multiple regions and industries including finance, education, energy, and healthcare across Asia, Europe, and the United States.[1][2][3][4][5]

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1026: Privileged Account Management Enterprise uses · Malware S0258: RGDoor Enterprise detects · Detection Strategy DET0068: Detection Strategy for T1505.004 - Malicious IIS Components Enterprise subtechnique of · Technique T1505: Server Software Component Enterprise uses · Malware S1022: IceApple Enterprise mitigates · Mitigation M1038: Execution Prevention Enterprise mitigates · Mitigation M1047: Audit Enterprise uses · Campaign C0022: Operation Dream Job Enterprise uses · Campaign C0058: SharePoint ToolShell Exploitation Enterprise mitigates · Mitigation M1045: Code Signing Enterprise uses · Malware S0072: OwaAuth Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Mitigation Enterprise

M1038: Execution Prevention

Prevent the execution of unauthorized or malicious code on systems by implementing application control, script blocking, and other execution prevention mechanisms. This ensures that only trusted and authorized code is executed, reducing the risk of malware and unauthorized actions. This mitigation can be implemented through the following measures:

Application Control:

- Use Case: Use tools like AppLocker or Windows Defender Application Control (WDAC) to create whitelists of authorized applications and block unauthorized ones. On Linux, use tools like SELinux or AppArmor to define mandatory access control policies for application execution. - Implementation: Allow only digitally signed or pre-approved applications to execute on servers and endpoints. (e.g., `New-AppLockerPolicy -PolicyType Enforced -FilePath "C:\Policies\AppLocker.xml"`)

Script Blocking:

- Use Case: Use script control mechanisms to block unauthorized execution of scripts, such as PowerShell or JavaScript. Web Browsers: Use browser extensions or settings to block JavaScript execution from untrusted sources. - Implementation: Configure PowerShell to enforce Constrained Language Mode for non-administrator users. (e.g., `Set-ExecutionPolicy AllSigned`)

Executable Blocking:

- Use Case: Prevent execution of binaries from suspicious locations, such as `%TEMP%` or `%APPDATA%` directories. - Implementation: Block execution of `.exe`, `.bat`, or `.ps1` files from user-writable directories.

Dynamic Analysis Prevention: - Use Case: Use behavior-based execution prevention tools to identify and block malicious activity in real time. - Implemenation: Employ EDR solutions that analyze runtime behavior and block suspicious code execution.

Mitigation Enterprise

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

Mitigation Enterprise

M1045: Code Signing

Code Signing is a security process that ensures the authenticity and integrity of software by digitally signing executables, scripts, and other code artifacts. It prevents untrusted or malicious code from executing by verifying the digital signatures against trusted sources. Code signing protects against tampering, impersonation, and distribution of unauthorized or malicious software, forming a critical defense against supply chain and software exploitation attacks. This mitigation can be implemented through the following measures:

Enforce Signed Code Execution:

- Implementation: Configure operating systems (e.g., Windows with AppLocker or Linux with Secure Boot) to allow only signed code to execute. - Use Case: Prevent the execution of malicious PowerShell scripts by requiring all scripts to be signed with a trusted certificate.

Vendor-Signed Driver Enforcement:

- Implementation: Enable kernel-mode code signing to ensure that only drivers signed by trusted vendors can be loaded. - Use Case: A malicious driver attempting to modify system memory fails to load because it lacks a valid signature.

Certificate Revocation Management:

- Implementation: Use Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs) to block certificates associated with compromised or deprecated code. - Use Case: A compromised certificate used to sign a malicious update is revoked, preventing further execution of the software.

Third-Party Software Verification:

- Implementation: Require software from external vendors to be signed with valid certificates before deployment. - Use Case: An organization only deploys signed and verified third-party software to prevent supply chain attacks.

Script Integrity in CI/CD Pipelines:

- Implementation: Integrate code signing into CI/CD pipelines to sign and verify code artifacts before production release. - Use Case: A software company ensures that all production builds are signed, preventing tampered builds from reaching customers.

**Key Components of Code Signing**

- Digital Signature Verification: Verifies the authenticity of code by ensuring it was signed by a trusted entity. - Certificate Management: Uses Public Key Infrastructure (PKI) to manage signing certificates and revocation lists. - Enforced Policy for Unsigned Code: Prevents the execution of unsigned or untrusted binaries and scripts. - Hash Integrity Check: Confirms that code has not been altered since signing by comparing cryptographic hashes.

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.1
Created
Modified
Raw hash
0d59af3172cd8fd7...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle 0d59af3172cd…
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.

Open mirrored raw JSON Open MITRE-hosted copy
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]
    Microsoft ISAPI Extension Overview 2017

    Microsoft. (2017, June 16). ISAPI Extension Overview. Retrieved June 3, 2021.

    Open source URL
  2. [2]
    Microsoft ISAPI Filter Overview 2017

    Microsoft. (2017, June 16). ISAPI Filter Overview. Retrieved June 3, 2021.

    Open source URL
  3. [3]
    IIS Backdoor 2011

    Julien. (2011, February 2). IIS Backdoor. Retrieved June 3, 2021.

    Open source URL
  4. [4]
    Trustwave IIS Module 2013

    Grunzweig, J. (2013, December 9). The Curious Case of the Malicious IIS Module. Retrieved June 3, 2021.

    Open source URL
  5. [5]
    Microsoft ISAPI Extension All Incoming 2017

    Microsoft. (2017, June 16). Intercepting All Incoming IIS Requests. Retrieved June 3, 2021.

    Open source URL
  6. [6]
    Dell TG-3390

    Dell SecureWorks Counter Threat Unit Threat Intelligence. (2015, August 5). Threat Group-3390 Targets Organizations for Cyberespionage. Retrieved August 18, 2018.

    Open source URL
  7. [7]
    MMPC ISAPI Filter 2012

    MMPC. (2012, October 3). Malware signed with the Adobe code signing certificate. Retrieved June 3, 2021.

    Open source URL
  8. [8]
    Microsoft IIS Modules Overview 2007

    Microsoft. (2007, November 24). IIS Modules Overview. Retrieved June 17, 2021.

    Open source URL
  9. [9]
    ESET IIS Malware 2021

    Hromcová, Z., Cherepanov, A. (2021). Anatomy of Native IIS Malware. Retrieved September 9, 2021.

    Open source URL
  10. [10]
    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
  11. [11]
    mitre-attack T1505.004
    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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use