AN1381: Analytic 1381
Detects compilation activity using csc.exe, ilasm.exe, or msbuild.exe initiated by user-space processes outside typical development environments, followed by execution or network activity from newly written binaries.
Analyst context for executives and security teams
This analytic matters because unexpected Windows compilation can indicate that code is being built inside an environment where software development is not normally expected. The supplied ATT&CK description focuses on csc.exe, ilasm.exe, and msbuild.exe launched by user-space processes outside typical development environments, especially when newly written binaries then execute or initiate network activity. For leaders, the decision value is whether the organization can distinguish legitimate developer activity from suspicious build-and-run behavior on workstations and servers.
Executive priority
Prioritize this as a validation point for Windows endpoint visibility and incident readiness. If non-development systems can compile and immediately run new binaries without meaningful logging, triage, or control, responders may lose critical evidence during an intrusion investigation. Security leaders should ask which Windows assets are approved for development activity, whether exceptions are documented, and whether SOC workflows can escalate compile-plus-execute or compile-plus-network sequences without overwhelming analysts with legitimate engineering noise.
Technical view
For SOC and detection teams, validate visibility into Windows process creation, parent-child process relationships, file creation for newly written binaries, and subsequent execution or network activity. The analytic is specifically scoped to csc.exe, ilasm.exe, and msbuild.exe and to activity initiated by user-space processes outside typical development environments. Because no official detection logic or tactic mapping is supplied, teams should treat this as a detection design requirement rather than a ready-to-deploy rule. Build environment-aware baselines: developer workstations, build servers, CI systems, and administrative tooling may legitimately invoke these binaries, while general user endpoints or production servers may warrant higher scrutiny.
Likely telemetry
- Windows process creation events showing csc.exe, ilasm.exe, or msbuild.exe execution
- Parent process and user context for compiler or build-tool invocation
- File creation telemetry for newly written binaries or assemblies
- Process execution telemetry for newly created binaries
- Network connection telemetry from newly written or newly executed binaries
Detection direction
- Validate that compiler/build-tool execution is logged with command line, parent process, user, host, and timestamp context.
- Correlate compilation activity with subsequent execution or outbound network activity from newly written binaries.
- Tune by asset role to reduce false positives from developer workstations, build servers, and sanctioned development pipelines.
- Prioritize alerts where the initiating process is a user-space application not normally associated with software development on that host.
- Review blind spots where endpoint telemetry lacks file creation, command-line capture, or process-to-network correlation.
Mitigation priorities
- Define and maintain an inventory of Windows systems approved for development, build, or compilation activity.
- Use application control or policy restrictions where appropriate to limit compiler and build-tool use on non-development systems.
- Ensure endpoint logging captures process creation, command line, file creation, and network activity needed for correlation.
- Document approved exceptions for engineering, CI/build infrastructure, and administrative workflows to support SOC tuning and audit evidence.
- Prepare incident response playbooks for investigating unexpected compilation followed by execution or network activity.
Analyst notes and limits
The object is a detection analytic for Windows only. Its value depends heavily on local asset context: the same compiler activity may be normal on development systems and unusual on standard user endpoints or production servers. No relationship context, tactic mapping, or official detection body was supplied, so the take emphasizes validation of telemetry and operational tuning rather than a specific ATT&CK technique assertion.
This summary uses only the supplied STIX fields, external reference, and object description. It does not assert active exploitation, attribution, business impact, or guaranteed detection coverage. The official detection field is not provided, and no relationships were supplied, so local environment baselining is required before prioritization or alert severity can be finalized.
Analytic 1381
Detects compilation activity using csc.exe, ilasm.exe, or msbuild.exe initiated by user-space processes outside typical development environments, followed by execution or network activity from newly written binaries.
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 | c17ed0d1be41… |
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 AN1381Open 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.