How T1505 Server software component hides persistence inside servers you already run
Server software that is trusted, patched and monitored can still carry an attacker's foothold. T1505 Server software component is the MITRE ATT&CK technique where an adversary plants a component inside a server application so that it survives restarts and keeps access without needing a new malicious binary on the host. It sits under the Persistence tactic, TA0003, whose ATT&CK definition is that the adversary is trying to maintain its foothold. This page targets Enterprise ATT&CK version 20.0, and because ATT&CK can rename or deprecate techniques between releases, your detection mappings should record the version they were written against.
ATT&CK describes six sub-techniques, and each lives in a different place in your estate: web shells placed in web-accessible directories, transport agents that hook mail flow on mail servers, server software extensions for SQL-style database servers and for web or application servers, IIS components that load into Microsoft Internet Information Services, and network device or appliance components that run on the network equipment itself. The common thread is that the component runs with the server's own privileges and is often loaded by a process that defenders already expect to be busy. Confirm the exact sub-technique names and descriptions against the ATT&CK 20.0 page for T1505 before you write rules, because wording can change between versions.
Intrusions that use this technique tend to surface late, because the server's normal behavior hides the change. Your first decision is inventory: list which server roles in your environment can load extensions, modules, transport agents or appliance add-ons, and who is authorized to change them. Your second is baseline: record the approved set of web root files, loaded modules and extension configurations so that later drift is visible. Ask your platform and security teams to confirm, for each server platform you run, which of these change paths produce log or file telemetry you can actually collect.
Which telemetry reveals a server software component foothold
This table maps each ATT&CK data component relevant to T1505 to the signal a defender should look for and the open-source collector that gathers it. Read each row as a starting point: confirm per server product which logs the software actually writes before relying on a signal. The main takeaway is that no single data component covers every platform, so coverage gaps should be checked before the detection is trusted.
| Data component | Signal to look for | Open-source collector | Platform notes |
|---|---|---|---|
| Process Creation (DC0032) | Unexpected child processes spawned by a web, database or application server process | Wazuh agent, Velociraptor, Sysmon on Windows | Windows and Linux agents report process events; confirm auditd or Sysmon configuration per host |
| Command Execution (DC0064) | Shell or interpreter commands run under a server service account | Wazuh agent, Velociraptor, Security Onion host logs | Command capture depends on audit rules on Linux and macOS and logging policy on Windows |
| File Creation (DC0039) | New web shells, modules or plugins written into server web or extension directories | Wazuh file integrity monitoring, Velociraptor artifacts | Confirm monitored paths for each server product, since install locations vary |
| File Modification (DC0061) | Changes to existing server configuration, handler or module files | Wazuh file integrity monitoring, Velociraptor | Compare against a known-good baseline captured after a clean install and patch |
| Application Log Content (DC0038) | Authentication anomalies, unexpected requests to unusual paths, or errors from modified server components | Wazuh log collection, Security Onion, Zeek HTTP logs, Suricata alerts | Network devices and appliances often expose logs only through vendor syslog; confirm the log level and format per product |
| Network Traffic Content (DC0078) | Requests carrying unexpected parameters or encoded payloads to server endpoints | Suricata rules, Zeek, Security Onion | Visibility depends on TLS inspection and sensor placement; confirm with the network team before relying on it |
Detection logic for T1505 that SOC teams can tune
The five ideas below are starting points for a SOC, not finished rules. Each one pairs a behavior on the server with the baseline you need to build in your own environment before alerts are trusted. Express each idea as a Sigma rule so it can be converted to your SIEM, and tune it in a cyber range before it reaches production.
New or modified files in web directories
Watch for new or changed files under web-accessible paths such as document roots, application plugin folders and upload directories. A web shell placed under T1505.003 usually shows up as a script file that appears outside a deployment window. Build an allowlist of expected file types per path, and set the alert to fire on any new script extension written by a process other than the deployment tool. Expect false positives from CMS plugin updates, asset builds and backup restores, so label those jobs in your baseline before tuning.
Server processes spawning shells
A web server, application pool or database service that starts a command shell or scripting interpreter is a strong T1505 signal, because these processes rarely need to run commands. Alert when the parent is a server worker and the child is a shell or interpreter, then review the command context in the same log. Tune by excluding known health checks and scheduled maintenance tasks that the platform team owns. Confirm in the lab that your EDR records parent-child relationships for these services.
Unexpected child processes of web workers
Worker processes that serve requests should have a stable set of children, and a new child that does not match that set deserves review. This idea differs from the shell rule because it covers any unfamiliar binary, including compiled tools dropped next to the application. Record the normal child process list for each server role during a quiet period, then alert on additions. Expect noise after patching or after a runtime upgrade, so add a change window to the detection logic.
New extension or module registration
T1505 includes adversaries registering modules, extensions or plugins with a server to gain code execution inside its request handling. Monitor configuration files and the module registry for entries that were not created through your change process. Compare each registration against an approved inventory and alert on any mismatch. Changes come from legitimate administrators and package managers, so tie each alert to a ticket reference or change record to reduce noise.
Anomalous parameters in application logs
Application and web access logs can show requests with unusually long parameters, encoded payloads or repeated calls to a single new path that serves no business purpose. Build a baseline of request paths and parameter lengths per endpoint, then alert on new paths that receive POST traffic from few clients. Set thresholds in the lab using replayed traffic, since legitimate APIs and search features also produce long parameters. Retain these logs long enough to investigate a path that was first used weeks earlier.
How to baseline legitimate server components before alerting
Detection for T1505 Server Software Component depends on knowing what should already be on each server. Before any alert on new web shells, server extensions, modules or transport agents is trusted, build a per-server inventory of approved components: the extensions and modules loaded by web and application servers, the transport or mail agents and their plug-ins, and the web-accessible files that the application is meant to serve. Without that list, a rule that flags an unfamiliar file or module will fire on every legitimate deployment and teams will learn to ignore it. Decide who owns each server's inventory, which change record authorizes each entry, and what happens when a component appears that has no matching record.
Build the baseline from three sources that agree with each other. Configuration management is the primary source, because it describes the intended state of each server, including the module lists and web root contents the platform should have. Change tickets provide the authorization trail for each addition and removal. File integrity data, collected through a tool such as Wazuh syscheck or a comparable agent, shows what is actually on disk and when it changed. Reconcile the three: any component present on disk but absent from configuration management or from an approved change is a finding to investigate, not a baseline entry to accept. Ask your team to confirm which file integrity capability and paths their chosen agent covers before relying on it for web roots.
Refresh the baseline after every approved release, and treat the refresh as part of the release itself. Each refresh should record the new component list, the change ticket that authorized it, and the ATT&CK version the detection mappings target, so that a later review can tell whether an alert reflects a technique change or a server change. MITRE revises ATT&CK on a regular cycle and can rename, deprecate or revoke techniques, so store baseline versions alongside the mapping version they were tested against (see the MITRE ATT&CK updates page). Keep the previous baseline so that rollbacks and disputed changes can be compared against a known state.
How to validate that the T1505 detection fires
This sequence proves that the T1505 detection fires for a chosen sub-technique, on a non-production server, with a benign artifact that is removed afterward. It produces a dated record of the alert path, time to alert, analyst action and cleanup, which becomes the baseline for re-testing after rule or platform changes.
Agree the sub-technique under test
The detection owner, the server owner and the SOC lead agree which T1505 sub-technique the run covers and which ATT&CK version the detection maps to, because releases can rename, deprecate or revoke techniques. Record the sub-technique ID, the detection strategy or analytic name, the target platform and the owner of the expected alert. The step closes when all three roles sign the written test plan.
Select a non-production test server
The platform team picks a non-production server that matches the production build for the platform under test, such as a web or application server hosting the same server software family. Confirm with the server owner that the host is isolated from production traffic, that backups exist, and that the change window is recorded. The step closes when the host, its owner and its rollback path are written into the plan.
Plan a benign test artifact
Define a harmless marker that stands in for the server software component behavior the detection watches for, such as a clearly named, non-executing test file or configuration entry with no network reach and no credential use. Illustrative example: a file named with the test run ID placed in a documented directory. Write down exactly what the artifact is, where it lives and how it will be removed. The step closes when the artifact definition is peer reviewed and approved by the server owner.
Confirm the expected log and alert path
Before placing the artifact, trace the path from the source telemetry, such as Process Creation, File Creation or Application Log Content, through the collector and SIEM to the alert queue. Check that the agent on the test server is reporting, that the rule is enabled, and that the alert routes to the on-call queue. Document each hop with the field or log source it depends on. The step closes when a dry event from the agent is visible in the SIEM search.
Place the artifact and start the timer
The red or purple team member places the approved artifact at the planned time and logs the exact timestamp in the run record, while a second observer watches the alert queue without touching the artifact. The observer records when the event is ingested, when the rule fires and when the alert appears. The step closes when the alert, or a documented miss, is captured with timestamps from the source system.
Record analyst action and time to alert
The on-call analyst works the alert as they would a real one, following the runbook, and records each triage decision, the enrichment queries used and the escalation outcome. Compare the alert timestamp with the artifact timestamp to calculate time to alert, and note any delay between alert creation and analyst acknowledgement. The step closes when the analyst's notes and both timestamps are attached to the run record.
Remove the artifact and confirm the alert closes
The red team member removes the test artifact using the removal steps in the plan, then the analyst confirms the host returns to its baseline state and closes the alert with a test disposition label. Verify that the closure is recorded and that no residual change remains on the host. The step closes when the baseline check passes and the alert shows as closed with the test label.
Version and retain the results
Store each run record with the ATT&CK version, detection rule version, sub-technique, platform, host, artifact definition, log source, timestamps, analyst notes and outcome in version control, and tag the run with its rule and data source versions. Re-run the sequence after rule changes, agent upgrades or ATT&CK updates, and compare results over time. The step closes when the run record is committed and linked to the detection owner's backlog for any gaps found.
Preventive controls that reduce T1505 exposure
T1505 abuses server software components that an adversary can add or alter after gaining access, so most preventive value comes from shrinking what is installed and proving what remains. The cards below cover the two mitigations that map most directly to this technique, then the supporting controls that limit who can change server components and whether those changes can be trusted.
Disable or remove unused modules
Remove every server module, extension or plugin that the service does not need. Each unused component is an extra place where a malicious addition can hide and run with the service's privileges. Build an inventory per server role, compare it with what the business actually uses, and disable or uninstall the rest through the change process. Confirm with each vendor which modules can be disabled without breaking the service, since removing a shared dependency can cause outages.
Audit server configuration and components
Compare the live configuration of each server against an approved baseline on a schedule. Audit records should show which modules are loaded, which extensions are registered and which configuration keys changed, and who made each change. Route these events to your SIEM, such as Wazuh, so an unexpected module or a new handler triggers review. Confirm which logging options each server product offers, because default audit levels are often too low to show component loading.
Limit privileged accounts that manage servers
Restrict who can install, load or change server components to a small set of named administrators. Adding a module usually requires elevated rights, so limiting those rights raises the bar for an adversary who has only a standard service account. Review group memberships on each server quarterly, separate administrator accounts from daily-use accounts, and log every elevation. Ask your identity team to confirm how privileged access is granted and removed in your environment.
Restrict write access to component directories
Set file permissions so that only the service's administrative identity can write to module, plugin and extension directories. When a service account can write to its own binary or plugin folder, a single compromise can turn into a persistent component. Use the platform's access control model, check permissions after each upgrade because installers often reset them, and alert on any file creation inside these paths.
Require code signing for loadable components
Accept only components whose publisher signature verifies before the server loads them. Signing gives you a way to tell a vendor's module from one an adversary dropped into the same folder. Confirm whether your server platform supports signature checks on plugins natively, and where it does not, document the alternative, such as an approved hash list maintained under change control. Treat any failed verification as an incident until it is explained.
Manage server components through change control
Route every module addition, update and removal through a documented change record. Most T1505 activity looks like an unscheduled change, so a change calendar gives analysts a clear baseline to compare against. Tie each approved change to a ticket, record the component's name and version, and keep the configuration backup from before the change. Ask your operations team to confirm how emergency changes are recorded so they are not skipped during incidents.
What to do in the first hour after a T1505 alert
The first decision after a T1505 Server Software Component alert is whether the component is approved, and that answer has to come from records, not memory. Check the change management system, the deployment pipeline and the vendor or internal build inventory for the component name, version, hash and install path that triggered the alert. If the component matches an approved extension, plugin, module or web shell handler that the owning team can vouch for, close it with a documented reason and still review how it got onto the host. If no approved record exists, treat the alert as an active intrusion until proven otherwise. Confirm the owner of the server application and the on-call contact before anyone changes the host, because the application team usually knows which modules, filters or extensions should exist.
Preserve evidence before remediation. Take a forensic snapshot or memory capture where the platform allows it, copy the suspect file or module with its hash and timestamps, and export the web server or application configuration, the relevant Application Log Content and the Process Creation records covering the hours before the alert. Record the server's current listening services and open connections. Removing the component first, or restarting the service to clear it, destroys the state an investigator needs to see how the component was loaded and what it ran. Use a read-only collection method and log who collected what and when, so the chain of custody holds if the incident later involves regulators or counsel. Scope other servers before you clean anything. Query the same product, version and build across the fleet for the same file hash, file name and configuration key. A single compromised instance often means others were built from the same image or deployed through the same pipeline. Within the first hour, also check for credential use or lateral movement from the host: review authentication logs for service accounts the application runs under, look for new outbound connections from that server, and check for administrative tooling launched from it. Decide on containment based on what those checks show. Isolating the host at the network layer is usually the lowest-regret step when evidence of lateral movement or an unapproved component is confirmed, while leaving it running may be justified only when the owning team and incident lead agree that monitoring under a documented plan will preserve evidence without exposing other systems.
How to rehearse T1505 detection in a private cyber range
Build the range as an isolated copy of the environment you want to test, with no route to production data or corporate identity systems. The goal is to generate realistic telemetry on the hosts where T1505 Server Software Component would appear, so your Wazuh or Security Onion stack and SIEM ingest the same sources you rely on in production.
- Web and application servers: Include at least one web server and one application server with the same role, service accounts and log formats as production, so Application Log Content from these hosts is comparable.
- Database server: Add a database host with its own audit logging enabled, since many server software abuse scenarios touch data-tier components.
- Network device simulator: Use a simulator or lab device that emits syslog in the vendor format you run, so network-device telemetry is tested end to end.
- Wazuh or Security Onion stack: Deploy the collection and analysis tier in the range with the same agents, rule sets and Zeek or Suricata sensors you plan to use in production.
- SIEM: Forward all sources to the SIEM with the same parsing and time synchronization as production. Confirm timestamp accuracy before the first exercise.
Before running any exercise, check that every host forwards logs and that the range cannot reach production networks.
Injects are controlled events that the exercise control team triggers so that defenders can practice detection and response. For T1505, plan injects by sub-technique family rather than by specific tooling, so the exercise stays focused on what the defenders should see. Keep the written inject plan at the level of expected telemetry and business effect, and store operational details with the exercise control team only.
- Web server component family: Inject a scenario where a server-side component change is recorded in application logs and file change telemetry, and check whether the SOC receives an alert.
- Database component family: Inject an unexpected change to a database-side extension or plugin, and verify that audit logs and file modification data reach the SIEM.
- Network device family: Inject a configuration change on the simulated device that appears in syslog, and confirm the alert routes to the network team.
- Management and monitoring family: Inject a change to a component that receives privileged access, and confirm that privileged account and command execution telemetry is reviewed.
- Cross-version check: Record which ATT&CK version each inject maps to, because detection strategy IDs and data component IDs can change between releases.
For each inject, the exercise lead should log the start time, the expected telemetry and the planned end time, so the review can compare what happened with what was planned.
A good result is not simply an alert. Define acceptance criteria before the exercise: which data sources must show the activity, how quickly an analyst must triage it, what the analyst records, and what changes afterward. Use these criteria consistently across exercises so results can be compared over time.
- Alert timing: Agree on a target window between the injected event and the first alert, and record the actual interval for every inject. Use the window as a baseline, not a service level, and adjust it with the SOC lead.
- Analyst notes: Require the analyst to record the data sources consulted, the reasoning for the severity assigned, and whether the host was contained or escalated.
- Response quality: Check that the response follows the playbook, including evidence preservation and communication with the application owner before any change is reverted.
- Post-exercise tuning: Review false positives and missed detections, then update Sigma rules or Wazuh rules and retest them against the same inject.
- Documentation: Store the results with the ATT&CK version, the rule versions and the date, so auditors and the security team can trace each improvement.
Confirm with your own SOC leads which timing and severity thresholds apply to your environment before the first exercise.
Questions SOC leads and detection engineers ask about T1505
How do I separate T1505 activity from normal plugin or extension deployment?
Start by baselining who is allowed to install or change server-side components, through which change process, and on which hosts. Normal deployments usually come through a change ticket, a configuration management run or a known service account, while suspicious activity tends to arrive outside those paths. Alert on new or modified web server modules, extensions and application plugins that do not match the approved inventory, and correlate them with Process Creation and File Creation events from the web server's process tree. Treat any component added outside the change window as a lead to triage, not an automatic incident, and record the baseline so analysts can tell the difference quickly.
Which logs should I retain for web servers to detect server software component abuse?
Retain web server access and error logs, application logs, and host telemetry for the web server process, including Process Creation, File Creation and File Modification events on module and extension directories. Keep these logs centrally, with enough retention to cover your incident response and compliance obligations, which your legal and compliance leads should confirm. Application Log Content is often the most useful source for reading module loading and administrative actions, so confirm that the application writes those events at a level that captures them. Time synchronization across these sources matters, because correlation fails when timestamps drift.
How do I monitor network devices that cannot run an endpoint agent?
Network devices usually cannot host a Wazuh or Velociraptor agent, so detection relies on what they emit. Forward syslog and management plane audit logs to a central collector, and watch for firmware, plugin or configuration changes that the vendor logs. Where the device supports it, compare running configuration and component inventories against a known good baseline on a schedule, and use Zeek or Suricata on mirrored or tapped traffic to spot unexpected management sessions or file transfers to the device. Confirm with each vendor which events and integrity checks their platform actually provides before writing rules against them.
How often should I retest T1505 detections when ATT&CK releases change mappings?
Retest whenever the ATT&CK version you target changes, because releases can rename, deprecate or revoke techniques and sub-techniques, and detection mappings should name the version they target. Recent releases include v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Review the MITRE ATT&CK updates pages at each release, diff the STIX bundle for the T1505 sub-techniques, and rerun your range scenarios against any affected rule. Set a recurring review cadence that your team can sustain, and record which version each rule was validated against.
How do I measure detection quality for T1505 in a cyber range?
Measure detection quality by running scripted scenarios in the range, then recording whether each expected alert fired, how long it took to reach an analyst, and whether the analyst could explain the activity from the alert alone. Track false positives against the approved baseline, and track misses separately so you can see which sub-techniques lack coverage. Use the same scenario set after each rule change so results are comparable over time. Define your success thresholds in advance with your SOC leads, since no universal target applies to every environment.
Can my own team run T1505 detection and range exercises without outside help?
Often yes, if your team has the skills in web server administration, log pipelines and detection engineering, and if it can dedicate time to the work. Outside support is most useful for scoping the range, building repeatable scenarios, reviewing rules and checking that evidence is kept in a form auditors can follow. DeployOpen implements and integrates open-source platforms in your own infrastructure, runs security testing and private cyber ranges, and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Scope any engagement in writing before work starts so responsibilities are clear.
What should I check first when a T1505 alert fires on a production web server?
Check whether the component is on the approved inventory, whether a change ticket covers it, and whether the timestamp matches a maintenance window. Then review the web server's process tree, recent File Creation and File Modification events in the module directories, and any administrative actions in application logs. Preserve the affected files and logs before making changes, and escalate to incident response if the component is unapproved or its origin cannot be explained. Document each step so the outcome can feed back into your baseline and your range scenarios.
Official ATT&CK sources for T1505 and Persistence
Start with the primary sources before you write a single detection for T1505 Server software component. The Persistence tactic (TA0003) describes an adversary trying to maintain its foothold, and the technique page for T1505 is the authoritative place to confirm its description, its six sub-techniques, the data components it references and the mitigations it maps to. Treat your internal detection library as a derived artifact of that page, not as a source of truth. Record the ATT&CK version you targeted in every rule and every coverage map, because releases can rename, deprecate or revoke techniques and sub-techniques.
The MITRE ATT&CK updates page lists each release and links to its release notes. Read the notes for every version between the one you last mapped and the one you are targeting. The notes for the October 2025 release describe the move from detections embedded in technique pages to detection strategies and analytics, along with changes to data components and the deprecation of data sources. If your T1505 rules still cite data sources, plan a mapping update before you rely on them for audit evidence.
For machine-readable mappings, download the STIX 2.1 bundle for the Enterprise domain from the attack-stix-data repository, using the enterprise-attack 20.0 bundle or the version you target. Query the bundle to extract the relationships between T1505, its sub-techniques, the data components and the mitigations, then diff it against your last export. Confirm the current technique page before relying on any mapping in a report, because the bundle and the web pages should agree but a reviewer will check the live page. Ask your team to name the owner of this check and the cadence at which it runs.
How DeployOpen builds T1505 detections and range exercises
DeployOpen works on T1505 Server software component as a fixed-scope engagement inside the client's own infrastructure, starting from the platforms that host server-side components and the telemetry they already produce. The work covers detection logic, validation in a private cyber range, and the documentation a security team needs to run the detections after handover.
How we scope
- Confirm which server software components, web servers, application servers and network device platforms are in the written scope for T1505
- Inventory the sub-techniques that apply to the client's platforms, mapped to the ATT&CK version the team targets
- Record which telemetry sources exist today, such as process creation, command execution and application log content, and where gaps remain
- Agree in writing the deliverables, timelines and any retainer for ongoing support before work begins
How we build
- Write detection logic in open-source formats such as Sigma rules, mapped to ATT&CK data components and detection strategies
- Deploy collection and alerting in the client's Wazuh, Security Onion or Zeek stack, as scoped, without moving data outside their environment
- Review the Audit and Disable or Remove Feature or Program mitigations against the platforms in scope and document the configuration changes
- Set up a private cyber range that mirrors the client's server platforms so detections can be tested before production rollout
How we hand over
- Deliver detection documentation covering the data sources, logic, known false positives and the ATT&CK version each rule targets
- Provide range exercise runbooks so the client's analysts can rehearse detection and response for T1505 on their own schedule
- Record validation results and open gaps so the security team and any external auditor can trace how each control was evidenced
- Walk the operations and security teams through the handover, including what to re-test when ATT&CK releases change technique mappings
How we support
- Offer ongoing support and continuous testing as a retainer, scoped separately from the initial engagement
- Review detection content when ATT&CK releases rename, deprecate or revoke techniques or sub-techniques relevant to T1505
- Re-run range exercises after platform upgrades, configuration changes or new server software is added to the environment
- Confirm with the client's auditors or certification bodies which evidence they require, since DeployOpen prepares evidence but does not issue attestations
