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

T1505.002: Transport Agent

Adversaries may abuse Microsoft transport agents to establish persistent access to systems. Microsoft Exchange transport agents can operate on email messages passing through the transport pipeline to perform various tasks such as filtering spam, filtering malicious attachments, journaling, or adding a corporate signature to the end of all outgoing emails.[1][2] Transport agents can be written by application developers and then compiled to .NET assemblies that are subsequently registered with the Exchange server. Transport agents will be invoked during a specified stage of email processing and carry out developer defined tasks.

Adversaries may register a malicious transport agent to provide a persistence mechanism in Exchange Server that can be triggered by adversary-specified email events.[2] Though a malicious transport agent may be invoked for all emails passing through the Exchange transport pipeline, the agent can be configured to only carry out specific tasks in response to adversary defined criteria. For example, the transport agent may only carry out an action like copying in-transit attachments and saving them for later exfiltration if the recipient email address matches an entry on a list provided by the adversary.

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

Analyst context for executives and security teams

Analyst confidence Medium

Transport Agent abuse is a persistence risk centered on server-side email processing. Because Exchange transport agents are legitimate extensibility components, a malicious or unauthorized agent can blend into normal mail infrastructure and be triggered by email events. For leaders, the concern is not just malware on a server; it is unauthorized code living inside a business-critical communications system that may affect confidentiality, incident scope, and recovery confidence.

Executive priority

Prioritize this where Microsoft Exchange or related mail transport infrastructure is business-critical. The key governance question is whether the organization can prove who is allowed to register transport agents, what agents are installed, whether they are trusted, and whether changes are audited. This technique is most relevant to resilience, privileged access control, compliance evidence for administrative activity, and incident response readiness around email infrastructure.

Technical view

ATT&CK maps this sub-technique to persistence on Windows and Linux and relates it to Server Software Component abuse. SOC and IR teams should validate visibility into Exchange transport agent inventory, registration or configuration changes, .NET assembly placement or modification, privileged administrative actions, and mail server process/module activity. Because the official ATT&CK object provides no native detection text, detection engineering should be based on baselining approved agents and alerting on unauthorized additions, unexpected code signing status, abnormal privileged changes, and suspicious behavior tied to mail processing events. Relationship context also points to DET0166 as a relevant detection strategy and to LightNeuron as software known by ATT&CK to use this behavior.

Likely telemetry

  • Exchange transport agent inventory and configuration state
  • Administrative command and change logs related to transport agents
  • Privileged account authentication and activity on mail servers
  • File creation, modification, and integrity monitoring for transport agent assemblies and related directories
  • Code signing or trust metadata for installed assemblies

Detection direction

  • Establish an allowlist of approved transport agents and alert on new, removed, disabled, re-enabled, or modified agents.
  • Correlate transport agent changes with privileged account usage and approved change tickets to reduce false positives from legitimate administration.
  • Validate whether installed assemblies are expected, signed where required, and consistent with known-good hashes or deployment sources.
  • Monitor for unusual mail server file changes or module loads near administrative changes to transport configuration.
  • Treat mail infrastructure as high-value server software: detection should combine configuration state, endpoint telemetry, and privileged access logs rather than relying on email logs alone.

Mitigation priorities

  • Restrict who can administer Exchange transport agents using privileged account management, RBAC, least privilege, and accountable administrative workflows.
  • Require auditing of transport agent configuration, privileged actions, and relevant file changes so responders can reconstruct when persistence was introduced.
  • Use code signing or trusted software controls where applicable to reduce the chance that unauthorized assemblies can be loaded as legitimate components.
  • Maintain an approved inventory of transport agents and include it in mail server build standards, vulnerability reviews, and incident response collection plans.
  • Review mail server administrative access regularly, especially service accounts and accounts with rights to register or modify server components.
Analyst notes and limits

This object is narrowly about persistence through Microsoft Exchange transport agents, a sub-technique of Server Software Component. The supplied relationship data includes mitigations for Privileged Account Management, Code Signing, and Audit, plus a related detection strategy DET0166 and software S0395 LightNeuron. Practical defensive value depends heavily on local Exchange architecture, administrative practices, and whether configuration and endpoint telemetry are retained.

The official ATT&CK detection field is not provided, so detection guidance is inferred from the behavior description and supplied relationships rather than from explicit MITRE detection text. The supplied data does not support claims of current exploitation, customer exposure, guaranteed detection, or specific vendor tooling requirements.

Official MITRE ATT&CK definition

Transport Agent

Adversaries may abuse Microsoft transport agents to establish persistent access to systems. Microsoft Exchange transport agents can operate on email messages passing through the transport pipeline to perform various tasks such as filtering spam, filtering malicious attachments, journaling, or adding a corporate signature to the end of all outgoing emails.[1][2] Transport agents can be written by application developers and then compiled to .NET assemblies that are subsequently registered with the Exchange server. Transport agents will be invoked during a specified stage of email processing and carry out developer defined tasks.

Adversaries may register a malicious transport agent to provide a persistence mechanism in Exchange Server that can be triggered by adversary-specified email events.[2] Though a malicious transport agent may be invoked for all emails passing through the Exchange transport pipeline, the agent can be configured to only carry out specific tasks in response to adversary defined criteria. For example, the transport agent may only carry out an action like copying in-transit attachments and saving them for later exfiltration if the recipient email address matches an entry on a list provided by the adversary.

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

S0395: LightNeuron

LightNeuron is a sophisticated backdoor that has targeted Microsoft Exchange servers since at least 2014. LightNeuron has been used by Turla to target diplomatic and foreign affairs-related organizations. The presence of certain strings in the malware suggests a Linux variant of LightNeuron exists.[1]

WindowsLinux
Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1026: Privileged Account Management Enterprise subtechnique of · Technique T1505: Server Software Component Enterprise detects · Detection Strategy DET0166: Detection Strategy for T1505.002 - Transport Agent Abuse (Windows/Linux) Enterprise uses · Malware S0395: LightNeuron Enterprise mitigates · Mitigation M1047: Audit Enterprise mitigates · Mitigation M1045: Code Signing 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

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
ef161de9522c467f...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle ef161de9522c…
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 TransportAgent Jun 2016

    Microsoft. (2016, June 1). Transport agents. Retrieved June 24, 2019.

    Open source URL
  2. [2]
    ESET LightNeuron May 2019

    Faou, M. (2019, May). Turla LightNeuron: One email away from remote code execution. Retrieved June 24, 2019.

    Open source URL
  3. [3]
    mitre-attack T1505.002
    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