How T1176 software extensions keep an attacker's foothold
T1176 Software Extensions is a technique in which an adversary installs an extension, plugin or add-on into software that users already trust, so its code runs inside that application and continues to run after restarts. It sits under the Persistence tactic (TA0003), where the adversary is trying to maintain its foothold on the system. For a SOC lead, the concern is that extensions execute with the privileges of the logged-in user and the trusted host application, so they can avoid the scrutiny that standalone binaries often receive from endpoint controls and analysts.
The technique has two sub-techniques. One covers add-ons loaded by web browsers, and the other covers plugins loaded by developer tooling such as code editors. Both are mapped across Linux, macOS and Windows. Detection content for this page targets ATT&CK v20.0, and the team should record that version in every rule, analytic and coverage report. Because MITRE can rename, deprecate or revoke techniques between releases, confirm the version each detection was written against before reusing it after an upgrade.
Start with an inventory of installed extensions on managed endpoints and compare it with an approved baseline. Then confirm which telemetry your EDR or Wazuh deployment captures for file creation and process activity inside the extension directories used by each browser and developer tool. Decide who approves new extension sources and how exceptions are recorded. Those three decisions, made before an incident, determine whether an unexpected extension is found in hours or only after an attacker has relied on it for weeks.
Which telemetry reveals software extension installs
This table maps each telemetry source relevant to T1176 Software Extensions to the signal it gives, the open-source collector that gathers it, and its coverage limits. Read it as a starting point for choosing collectors, then confirm coverage for each sub-technique against the ATT&CK v20.0 data components before building detections.
| Telemetry source | Signal for extension installs | Open-source collector | Coverage notes |
|---|---|---|---|
| Process Creation (DC0032) | Package manager, browser or IDE plugin manager, or extension CLI invoked to add or enable an extension | Sysmon-style Windows process logging, auditd execve records on Linux, Wazuh agent process monitoring | Records the invocation, not the extension contents. Confirm the event fields your collector captures. |
| Command Execution (DC0064) | Command lines that install, enable or update extensions, including script and shell invocations | Wazuh command monitoring, Velociraptor artifacts, auditd with command capture | Command line visibility depends on logging policy. Confirm whether arguments are retained in your environment. |
| File Creation (DC0039) | New extension directories, unpacked plugin folders or new extension files in user and application profiles | Wazuh file integrity monitoring, Velociraptor file hunts, auditd file watch rules | Watch scope drives noise. Limit watches to known extension and profile paths. |
| File Modification (DC0061) | Changed extension manifests, configuration files or enabled-state flags for existing extensions | Wazuh file integrity monitoring with hash comparison, Velociraptor scheduled collection | Manifests change during normal updates, so pair changes with a known update window or a package manager event. |
| Windows Registry Key Modification (DC0063) | Registry entries that register or enable extension components on Windows hosts | Sysmon registry events, Wazuh Windows registry monitoring | Adds context for some Windows sub-techniques. Confirm coverage against the ATT&CK v20.0 data components. |
| Application Log Content (DC0038) | Application-level messages recording extension load, enable or failure events | Wazuh log collection, Security Onion log ingestion | Adds context where the application logs extension activity. Logging levels vary by product, so confirm what each application emits. |
| Coverage check against ATT&CK v20.0 | Which data components the detection strategies for T1176 and its sub-techniques reference | Enterprise ATT&CK STIX bundle for version 20.0 in the attack-stix-data repository | Data component mappings can change between versions. Record the ATT&CK version your detections target. |
Detection logic for extension installs on endpoints
Software extensions run with the trust of the application that loads them, so an unexpected install can persist quietly across restarts. The four detection ideas below work together: one watches where extensions land on disk, one compares installs against managed deployment channels, one flags loads from user-writable paths, and one catches installs driven by scripts. Tune each against your own baseline before treating an alert as an incident.
New unsigned extensions in profile paths
Watch File Creation events under browser profile directories and IDE plugin folders for new extension packages, especially ones without a valid signature or with a manifest that requests broad host or file permissions. Alert when a new extension appears on an endpoint that has no matching entry in the managed inventory, and record the creating process and user. Tune by excluding known package caches and updater staging folders, which create similar files. Expect false positives from developer tooling that sideloads extensions for testing and from browser profile sync, so confirm the source before escalating.
Installs outside managed channels
Compare extension installs against the approved deployment channel, such as the browser or IDE policy pushed by your endpoint management tool. An install that did not come through that channel is the core signal: it suggests a user or process added the extension manually or through a side path. Correlate the install with Process Creation events for the browser or editor and with Command Execution records for the installing process. Expect false positives from users who install approved extensions from a store before policy catches up, so require the extension to be absent from the approved list as well.
Plugin loads from user-writable directories
Alert when a browser, editor or application loads an extension or plugin from a directory that standard users can write to, such as a user home or temporary folder, instead of a system-wide install location. Use File Modification and Process Creation telemetry to identify the load and the write that preceded it. Tune the path list to your environment, since some developer frameworks legitimately load from user directories. Confirm with the owning team before disabling a plugin, because removing a required developer dependency can disrupt production builds.
Script-driven extension installs
Flag command-line activity that invokes a browser, IDE or package manager to install an extension, particularly when the parent process is a script interpreter, a scheduled task or an unfamiliar process. Command Execution telemetry with parent process context is the key input, and an install followed by a restart of the host application raises the priority. Expect false positives from configuration management, onboarding scripts and CI runners that install approved plugins, so maintain an allowlist of known automation accounts and parent processes.
How to confirm the detection fires before you trust it
This sequence checks that the T1176 Software extensions detections fire on the platforms in scope, that the alerts reach the SOC queue in a usable form, and that gaps are recorded before the rule is promoted. It runs in a private lab or cyber range so that benign and simulated extension installs can be tested without touching production hosts.
Define the test matrix per platform
The detection owner and a SOC analyst agree on a matrix that lists each platform in scope (Linux, macOS and Windows), the extension types that platform supports, and the benign and simulated extension installs to be run for each. The benign installs reflect approved change activity, such as a browser add-on or an approved editor plugin, and the simulated installs reflect the behaviors described in the technique and its sub-techniques. The matrix is complete when every row names a platform, an install type, an expected data component (for example Process Creation, Command Execution or File Creation) and an expected alert outcome.
Prepare isolated test hosts and baselines
The lab team builds clean test hosts for each platform in the range, forwards their telemetry to the same log pipeline used in production, and captures a baseline of existing extensions before any test runs. Hosts are kept off production networks and snapshotted so each test starts from a known state. The step is done when a baseline export exists for every host and a reviewer has confirmed that the telemetry sources arrive at the SIEM or Wazuh manager.
Run controlled benign and simulated installs
The test operator executes the planned benign and simulated installs in a timed, logged session and notes the exact start time, host and install type for each one. Simulated installs should be described in the test plan in general terms and handled by the detection engineer, not improvised on the day. The step is complete when every matrix row has a recorded run, and any run that did not execute as planned is marked for re-test.
Confirm the alert reaches the SOC queue
The SOC analyst checks whether each expected alert appears in the case management queue, is routed to the right analyst group and carries the host, user and extension name needed for triage. Benign runs should either be suppressed by an approved allowlist or produce a low-severity event with a clear reason. The step is done when each simulated run maps to a queued alert or a documented miss, and each benign run maps to a suppressed or low-severity outcome.
Record time to alert and captured fields
For every run, the analyst records the time between the install event and the alert being visible in the queue, and lists which fields were captured, such as the process name, parent process, file path, signer and user context. Missing fields are logged as gaps against the data component they depend on. The step produces a results table with one row per run, and a reviewer signs off that the timing and field coverage meet the thresholds the team set beforehand.
Log misses and tune against the matrix
Each simulated install that produced no alert, or produced an alert missing key fields, is logged with a root cause such as a missing log source, a rule condition that does not match the platform, or an upstream parsing error. The detection engineer fixes the rule or the pipeline and re-runs only the affected rows. The step is complete when every miss has either a fix and a passing re-test or a documented accepted risk owned by a named person.
Retain the evidence and version the rule
The team stores the matrix, baseline exports, run logs, queue screenshots and results table together, and records the ATT&CK version the detection targets so later releases can be checked against it. ATT&CK releases can rename or deprecate techniques, so the mapping must name its version. The step is done when the evidence package is filed with the detection rule, a retest date is set, and the rule owner has approved it for production.
Why extension detections miss in practice
The most common reason T1176 Software Extensions detections fail is that the extension install is not treated as a security event at all. Browsers and IDEs such as VS Code often update extensions silently in the background, so the file writes that occur during an update look identical to a malicious install on the file system. A rule that alerts on any new extension directory will fire constantly, and teams quickly learn to ignore it. Before tuning anything, confirm in your own environment whether each browser and IDE channel updates extensions automatically, which user accounts run those updates, and whether updates pass through a managed catalog or a vendor store. Those answers decide whether an update should be a baseline change or an alert.
Profile and extension locations also differ by operating system and by product, so a detection written for one path will silently miss the others. Chromium-based browsers, Firefox, and IDE extension folders each keep their data under per-user profile directories, and those paths vary between Linux, macOS and Windows and between stable and beta builds. Confirm the full list of extension and profile paths for every browser and IDE in use, including portable installs and roaming profiles on managed endpoints. Then confirm that your File Creation or File Modification telemetry actually covers each of those paths on each endpoint class, because coverage is often limited by audit policy or agent configuration.
The third gap is that file telemetry records that something was written but not what the extension does. A File Creation event can show a new file under an extension folder, but it will not show the manifest permissions, the requested host access or the scripts the extension runs, unless your pipeline collects and parses those contents. Decide whether you will collect manifest or package metadata, how you will hash or inventory extensions, and who reviews new permission grants. Managed installs add a further problem: policy-pushed extensions from an enterprise catalog generate the same events as an attacker-placed one, so alert fatigue grows unless approved extension identifiers are recorded in an allowlist that the detection can check against.
Mitigations that limit software extension installs
Software extension abuse depends on how easily new extensions reach a host or application. The four controls below narrow that path: they record what is installed, decide what may be installed, and funnel installs through channels someone can review. Each one maps to ATT&CK mitigations for T1176 Software Extensions, and each can be checked in your own environment.
Audit extension inventories
Audit (M1047) means recording extension activity and reviewing it on a schedule. For T1176, start with a current inventory of every browser add-on, IDE plug-in, office add-in and application extension on managed endpoints, including version, publisher and install path. Check that the inventory is collected from the endpoints directly and that a new entry raises an alert for review. Confirm that the records are kept long enough for an investigator to establish when an extension first appeared.
Allow-list approved extensions
Allow-listing means only extensions on a reviewed list can load. For T1176, each entry should name the extension, publisher, approved version or signature, and an owner who signs off on changes. Many browser, IDE and office platforms offer policy settings that block installs outside a set list, but confirm which settings your management tooling supports and pilot them on a small group first. Route blocked requests to a queue with a response time agreed by the owners, so business users do not stall and start working around the control.
Restrict installs to managed channels
Limit Software Installation narrows where extensions can come from. For T1176, that means approved stores, internal repositories or deployment tooling only, with direct installs from unknown sources disabled by policy. Check which channels your endpoint management can enforce, and whether users can still install from a local package file. Document the exception process, because an unmanaged install path left open will undo the other controls. Confirm the current mitigation identifier on its ATT&CK entry before citing it.
Pin the ATT&CK version
Mitigation mappings change between ATT&CK releases, and these pages use Enterprise ATT&CK 20.0. Before you cite a mitigation in a control matrix or audit file, open the T1176 entry in the 20.0 STIX bundle and confirm which mitigations it lists. Record the version in your evidence so an assessor can reproduce your mapping. Re-check after each release, because releases can rename, deprecate or revoke techniques.
Triage steps when an extension detection fires
When a T1176 Software Extensions detection fires, the first decision is whether the extension is approved. Check the detection against your software inventory, your browser or IDE extension allowlist, and your change records before anyone touches the host. Confirm with the owning team which extension ID, publisher and version are sanctioned for that user group. If the extension is on the approved list but the install came from an unexpected source, such as a sideloaded package or an unmanaged profile, treat that as a separate finding. Next, identify the user account, the host and the logged-on session so that the identity and endpoint owners can be engaged with the same facts. Record the detection's timestamp, the rule that fired and the ATT&CK version the mapping targets, so the analyst's notes stay tied to the exact detection logic.
Once the extension is confirmed as unapproved, collect its manifest and install context for analysis. Preserve the extension directory, its manifest file and the relevant profile or configuration entries from the endpoint, and capture the installing process and its parent from your Process Creation telemetry. Hash the collected files and record where they came from, so the chain of custody holds if the case moves to incident response or legal review. Do not open or execute the extension in a production browser or IDE to see what it does. Analysis belongs on an isolated analysis host. Then query other endpoints for the same extension ID, publisher and file hash. A single unapproved install often points to a pushed or shared deployment, and a clean search on one host does not prove the rest of the fleet is clean.
Decide on containment after you know the scope. Options include removing the extension on one host, disabling installation for the affected profile, or isolating the endpoint if the install is tied to suspicious process activity. Agree these steps with the identity owner, who can review sessions and tokens tied to the account, and with the endpoint owner, who executes removal and isolation. Write down who approves each action and when, and keep your forensic copy before any removal changes the evidence. For a fixed-scope engagement or a cyber range rehearsal, confirm these roles and approval paths in advance, because the cost of the rehearsal itself depends on how many teams must take part.
Rehearsing T1176 detection in a private cyber range
The Windows range should include a domain-joined workstation and a member server, each forwarding Sysmon and Windows Security events to the SIEM or Wazuh manager through agents. Extensions on Windows commonly arrive as browser add-ons, Office add-ins, shell extensions or service-related components, so the range should contain at least one profile for each category that your environment permits. Keep the lab on an isolated network segment with snapshots so every exercise starts from a known state.
- Benign install inject: Have a test user install an approved extension from a sanctioned internal catalog. Expect a process creation event and a file creation event in the user profile, which establishes the baseline your analytics should learn to tolerate.
- Simulated unapproved install inject: Stage an unsigned or unlisted extension package that the facilitator places under a user-writable path. Detection should fire on the file creation and on any registry key modification tied to the extension load.
- SOC console check: Confirm the alert names the host, user, parent process and extension path, and that the analyst can pivot to the process tree within the console.
- Response check: Verify that the playbook quarantines the extension, records the registry state before removal and notifies the application owner.
- Evidence check: Confirm the Sysmon configuration in use is the one documented for the range, so results can be compared across rehearsals.
After each run, confirm that the alert logic was tested against the ATT&CK version your detection mappings target.
The macOS range should use managed endpoints enrolled in your mobile device management or endpoint tool, with a standard user account and an administrator account for approval workflows. Extensions on macOS can include browser extensions, system extensions and kernel-adjacent components that the operating system gates through user approval, so the range should reflect the approval prompts your users actually see. Confirm which unified logging and endpoint telemetry your agent forwards before designing injects, because coverage varies by agent and configuration.
- Benign install inject: Install an approved browser extension through the managed catalog. Expect a file creation event in the user library and a process event from the browser, which becomes the baseline for normal behavior.
- Simulated unapproved install inject: Place an unsigned extension bundle in a user-writable location and trigger a load attempt. Detection should show the file creation, the signing status and the launching process.
- SOC console check: Confirm the analyst sees the code signing state and the originating application, and can determine whether the user approved a prompt.
- Response check: Verify that the playbook disables the extension through the management tool, captures the bundle for analysis and reviews other endpoints for the same bundle hash.
- Coverage check: Record which events were not visible, such as system extension loads, and log them as gaps for the platform team.
Confirm with your endpoint vendor which telemetry sources are available on your macOS versions before scheduling the exercise.
The Linux range should include a server image and a developer workstation image, both running an audit framework and a log forwarder that sends events to Wazuh or Security Onion. Software extensions on Linux often appear as shared libraries loaded by applications, editor plugins, package-managed modules or modules added to web servers and language runtimes. Build the range so that a small set of these components is managed by configuration tooling, which makes unmanaged changes easier to spot.
- Benign install inject: Install an approved plugin through the package manager or configuration management tool. Expect a package management event and a file creation under the expected path, which should match the change record.
- Simulated unapproved install inject: Have the facilitator drop an unregistered module into an application plugin directory and restart the affected service in the range. Detection should show the file creation, the file modification of the plugin configuration and the service restart.
- SOC console check: Confirm the alert lists the host, the account, the file path and the parent process, and that it correlates with any change ticket.
- Response check: Verify that the playbook isolates the affected service, preserves the file with its hash and metadata, and restores the configuration from the managed source.
- Baseline check: Confirm that the integrity monitoring rules and the audit rules are both active, since each detects different aspects of the same change.
Record which paths your production hosts treat as extension directories, because the lab results are only as useful as their match to real layouts.
After the platform exercises, run a joint review with the security team, the platform team, application owners and an auditor or compliance lead who needs evidence of the control. Each group reads the same exercise record but looks for different things: analysts check alert quality, platform engineers check whether the install path was controlled, owners check whether approvals matched intent, and auditors check whether the mitigation activities produced durable records. The review should decide what changes to tune, what to automate and what to accept as residual risk.
- Mitigation mapping: Confirm that the Audit and Limit Software Installation mitigations are mapped to the controls each platform actually enforces, and identify any gaps.
- Detection tuning: Compare benign and simulated results to find false positives and missed events, then document the changes with their version.
- Response timing: Record the steps that took longest, such as approval lookups or evidence capture, and decide whether to automate them.
- Ownership clarity: Confirm who can approve a new extension on each platform and who receives the alert at each hour of operation.
- Evidence package: Store the inject plan, the logs, the screenshots and the review decisions in a form your assessor can read.
Finally, confirm the ATT&CK version and sub-technique list used for the exercise, because releases can rename or deprecate techniques.
Questions SOC leads and detection engineers ask about T1176
How do I tell a managed extension push from an attacker install?
Compare the installation source, the publisher signature and the change record, because a managed push and an unauthorized install usually differ on all three. A managed deployment normally arrives through your endpoint management or browser policy channel, carries a signature from a publisher you have approved, and matches a change ticket. An attacker install often appears outside those channels, from a user profile path, with an unknown or missing signature and no matching change. Build an inventory of approved extensions and add-ins from your deployment tooling, then alert on any identifier that is absent from it. Confirm with each platform owner how their management tool records pushes, since log fields differ across Windows, macOS, Linux and browsers. Review alerts over a sample period before you enable blocking so you can tune known false positives.
Do Sigma rules cover browser extension install paths?
Public Sigma repositories include rules related to software extensions and add-ins, but coverage varies by platform and by rule maturity, so check each rule before relying on it. Start by searching the public Sigma repository for the technique ID and for file creation and registry modification rules that name extension directories or add-in keys. Treat each match as a starting point. Confirm that the log source it needs exists in your environment and that its field names match your SIEM or log pipeline. Gaps tend to appear for less common browsers and for Linux and macOS extension locations. Write local rules where the public set is thin, and record in your detection catalog which ATT&CK version and log source each rule targets.
How should we version T1176 detections against ATT&CK v20.0?
Tag every detection with the ATT&CK version it was written against, and record the technique and sub-technique IDs it maps to, so a later release can be compared without guessing. These pages use ATT&CK v20.0, which MITRE released on 2026-10-13 according to the attack-stix-data repository index. Releases can rename, deprecate or revoke techniques. ATT&CK v18 also moved detections into detection strategies and analytics with DET IDs, so mappings written against older versions may need rework. Keep a changelog for each detection, load the new STIX bundle for each release, and diff technique and data component references before you accept a new mapping. Review the ATT&CK updates page for each release to see what changed.
How often should T1176 detections be re-validated in production?
Re-validate after every change that affects the telemetry path, and on a fixed schedule that your change board approves. ATT&CK does not set a validation frequency, so base yours on how often your endpoints, browsers, Office suites and logging stack change. Common triggers include a browser or Office upgrade, a change to endpoint management policy, a new log forwarder, a SIEM schema change and any ATT&CK release that touches the mapping. Each validation should replay a known benign extension install and a known test install in your cyber range, confirm that the alert fires with the expected fields, and record the result with the date and detection version. Ask any provider for the schedule and the evidence format in writing before work starts.
Which telemetry sources matter most for detecting software extensions?
Three data components do most of the work for this technique, with a fourth for Windows add-ins.
- Process Creation (DC0032) shows which process or installer started an extension or add-in change.
- File Creation (DC0039) shows new extension files and manifests landing in user or system profile directories.
- Command Execution (DC0064) shows command-line installs and scripted changes to extension settings.
- Windows Registry Key Modification (DC0063) covers add-in registration on Windows.
Confirm which of these your endpoints actually emit before writing rules, because collection policy often omits file and command logging on user workstations. Map each source to the ATT&CK data component it satisfies so auditors can trace coverage.
Can our own team run T1176 detection work, or do we need a partner?
Your team can run this work if it already has log pipeline, SIEM rule and endpoint management skills, and a partner helps when those skills or hours are short. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and it runs security testing and private cyber ranges. A fixed-scope engagement can cover rule build, validation in a range and handover, with ongoing validation available as a retainer. Costs fall into people time, tooling you already run and the range environment, with one-time build work separated from recurring tuning. Ask for scope, deliverables and timelines in writing before work starts, and confirm which platforms and log sources the scope includes.
What should a T1176 cyber range exercise include?
A useful exercise covers both the expected and the unexpected paths: a managed extension push, an unapproved install on a test endpoint and a sanctioned update that should not alert. Run each scenario against a range that mirrors your browsers, Office suites and operating systems, and record which log sources fired. Check that alerts carry the fields your triage runbook needs, such as host, user, extension identifier and installer. Include a logging failure case, such as a forwarder that stops, so you can confirm that a silent pipeline raises its own alert. Finish with a short review that updates the detection, the runbook and the validation record together. Illustrative only: a range can replay these paths in a few sessions, but the exact scope depends on the platforms you run.
How DeployOpen builds and rehearses T1176 detections
DeployOpen approaches T1176 Software extensions as a fixed-scope engagement: the detection logic, telemetry and response steps are agreed in writing before work starts. The detections are built on self-hosted open-source tooling inside the client's own environment and rehearsed in a private cyber range.
How we scope
- Confirm which platforms are in scope for T1176 Software extensions, such as Linux, macOS and Windows hosts, and which sub-techniques apply.
- Inventory the telemetry the client already collects for Process Creation, Command Execution and File Creation, and record any gaps.
- Agree the ATT&CK version the detection mapping targets, so later releases do not silently change what is covered.
How we build
- Write detection logic in words and as Sigma rules, then map it to the client's SIEM or Wazuh rule set.
- Configure log collection and forwarding on the client's own infrastructure, including Security Onion or Zeek sources where they apply.
- Document the mitigation mapping for Audit and Limit Software Installation, with the controls the client needs to confirm locally.
How we hand over
- Deliver a written detection specification, data source map and known coverage gaps for T1176 Software extensions.
- Run a rehearsal in a private cyber range that replays benign and adversary-style software extension activity, with results recorded.
- Provide a response runbook and the evidence set that the client's internal or external assessors can review.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering rule tuning for T1176 Software extensions.
- Review detection mappings when MITRE ATT&CK releases rename, deprecate or revoke techniques or sub-techniques.
- Repeat cyber range rehearsals after environment changes, so detections are re-validated against current software and tooling.
