---
{
  "title": "Server Software Component",
  "summary": "Server component abuse places unauthorized behavior inside an extensible server feature.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1505"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1505: Server Software Component",
      "url": "https://attack.mitre.org/techniques/T1505"
    }
  ],
  "editorialVersion": 2
}
---

## Server extensibility creates another trust boundary

Server software components extend the behavior of a larger application or platform. Legitimate features may support modules, scripts, stored procedures, agents, or other extensions. Unauthorized components can introduce persistent access or alter server behavior while appearing inside a familiar service.

The relevant component type and execution model depend on the server product. An unfamiliar file in a server directory is not enough to establish the technique. Investigators need registration or installation evidence, provenance, configuration, authority, and runtime behavior.

## An unexpected module handles requests

In a fictional portal environment, a new server component appears shortly before unexplained request handling and process activity. The analyst reviews application configuration, deployment history, file integrity, installation records, service identity, and relevant runtime events.

An approved feature release may explain the addition. Compare the actual component with the reviewed package and change request. A trusted main server executable does not automatically establish the legitimacy of every extension loaded into its operation.

The team determines whether the component was merely present, registered, loaded, or invoked. Those stages support different conclusions. An unused file and an actively executed module should not receive the same impact statement without evidence.

## Review administrative reach

Determine who could install or modify the component and what authority it receives when used. A component running under a service identity may reach data, configuration, or connected systems available to that identity. Describe observed access separately from potential capability.

[[least-privilege]] helps review installation and service permissions. [[shared-modules]] describes reusable code loading, while [[compromise-host-software-binary]] concerns changes to existing software itself. The exact evidence determines whether either additional concept applies.

Preserve relevant configuration, artifacts, and request or process records before cleanup where practical. Short-lived deployment changes can otherwise make the original execution path difficult to reconstruct.

## Restore a reviewed server state

Remove unauthorized components through an approved process, address the access that installed them, and review related changes. Restarting the service or deleting one file may not remove registration, additional artifacts, or exposed credentials.

Coordinate with the application owner because extension changes can interrupt important functions. Recovery checks should establish the approved component set, required business behavior, and relevant monitoring after restoration.

For practice, compare a documented server plugin deployment with a fictional module installed by an unexplained administrator session. Identify provenance, registration, identity, invocation, and effect evidence. [[incident-response]] coordinates the operational work, while [[incident-reporting]] distinguishes an installed component from confirmed unauthorized execution and downstream impact.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]