AN1433: Analytic 1433
Detection focuses on unauthorized manipulation of .NET AppDomainManager behavior. Defenders may observe suspicious creation of new AppDomains within trusted processes, anomalous loading of assemblies via non-standard configuration files, or registry/environment variable changes redirecting AppDomainManager to malicious assemblies. Correlated events include config file tampering, new process creation of .NET host processes (e.g., w3wp.exe, powershell.exe) with modified runtime parameters, and module loads of unusual or unsigned .NET DLLs.
Analyst context for executives and security teams
This analytic is about spotting abuse of .NET AppDomainManager behavior on Windows, where trusted .NET-hosting processes may be redirected to load unexpected assemblies through configuration, registry, or environment changes. For leaders, the significance is that abuse can hide inside legitimate processes such as web or scripting hosts, making prevention and detection depend on whether the organization can see process starts, file/config changes, registry/environment modifications, and unusual .NET DLL loads together.
Executive priority
Prioritize this where Windows .NET applications, web services, or administrative scripting are material to operations. The business question is not simply “do we monitor PowerShell or IIS,” but whether SOC and IR teams can prove that trusted .NET host processes have not been quietly reconfigured to load unauthorized code. This supports resilience, incident scoping, and audit evidence around change control, application integrity, and privileged modification paths.
Technical view
For Windows environments, validate visibility around trusted .NET host processes, including examples named by MITRE such as w3wp.exe and powershell.exe. Detection engineering should correlate suspicious AppDomain creation or assembly loading with nearby configuration-file tampering, registry or environment variable changes, new process creation using modified runtime parameters, and module loads of unusual or unsigned .NET DLLs. Because no official detection logic is supplied, teams should treat this as a behavioral detection strategy requiring local baselining of legitimate .NET application behavior.
Likely telemetry
- Windows process creation events for .NET host processes and command/runtime parameters
- File integrity or file creation/modification events for non-standard or unexpected .NET configuration files
- Registry change telemetry related to AppDomainManager redirection behavior
- Environment variable change telemetry where available
- Module/DLL load telemetry for .NET assemblies, especially unusual or unsigned DLLs
Detection direction
- Correlate config-file changes, registry/environment modifications, process creation, and module loads rather than relying on any single event type.
- Baseline expected .NET assembly loads for high-value Windows services and administrative hosts to reduce noise from legitimate application updates or deployments.
- Review w3wp.exe, powershell.exe, and other trusted .NET-capable processes for unexpected runtime parameters or non-standard configuration file usage.
- Tune for authorized developer, deployment, and operations activity, which may legitimately modify .NET configuration or load custom assemblies.
- Validate whether current EDR/SIEM coverage captures module loads and registry/environment changes with enough fidelity to reconstruct the behavior during incident response.
Mitigation priorities
- Restrict write access to application configuration paths, relevant registry locations, and environment settings that can influence .NET runtime behavior.
- Enforce change control and monitoring for production .NET applications and Windows services.
- Use application integrity controls, code-signing expectations, or allowlisting where appropriate to reduce unauthorized .NET DLL loading.
- Apply least privilege so routine users and service accounts cannot modify runtime configuration or load paths unnecessarily.
- Prepare IR procedures to compare current .NET host configuration, loaded modules, and recent file/registry changes against known-good baselines.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a technique description, and it provides no ATT&CK tactics or relationship context. The strongest defensive value comes from validating telemetry joins across process, file, registry/environment, and module-load data for Windows .NET hosts.
Official detection logic is not provided, and no relationships, threat actors, campaigns, or active exploitation context are supplied. Local baselines are required to distinguish malicious manipulation from legitimate .NET application deployment, administration, or development activity.
Analytic 1433
Detection focuses on unauthorized manipulation of .NET AppDomainManager behavior. Defenders may observe suspicious creation of new AppDomains within trusted processes, anomalous loading of assemblies via non-standard configuration files, or registry/environment variable changes redirecting AppDomainManager to malicious assemblies. Correlated events include config file tampering, new process creation of .NET host processes (e.g., w3wp.exe, powershell.exe) with modified runtime parameters, and module loads of unusual or unsigned .NET DLLs.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 9d029efbe347… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1433Open source URL
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.