AN0182: Analytic 0182
PowerShell or script execution with parameters that suppress errors or ignore user interrupts, such as `-ErrorAction SilentlyContinue`. Defender perspective: detecting discrepancies between suppressed error arguments and continued execution behavior.
Analyst context for executives and security teams
This analytic matters because error-suppression arguments in PowerShell or scripts can hide failures, reduce visible prompts, and make suspicious automation harder for responders to interpret. For leaders, the value is not that every `-ErrorAction SilentlyContinue` is malicious, but that excessive or contextually unusual use can weaken SOC visibility during Windows script execution and complicate incident reconstruction.
Executive priority
Prioritize this as a Windows logging and detection-quality question: can the organization prove which scripts ran, with what command-line parameters, under which identities, and whether suppression flags were used in sensitive contexts? It supports incident readiness and compliance evidence by validating that script execution is observable even when commands intentionally suppress errors or user interruption signals.
Technical view
For SOC and detection teams, validate visibility into Windows PowerShell or script execution parameters, especially arguments that suppress errors or ignore interrupts such as `-ErrorAction SilentlyContinue`. Because no ATT&CK tactic or relationship context is supplied, treat this as a behavioral analytic component rather than a complete detection story. Focus on discrepancies between suppressed-error arguments and continued execution behavior, and enrich with user, host, parent process, script path, command line, and execution outcome context where available.
Likely telemetry
- Windows process creation events with command-line arguments
- PowerShell execution logs or equivalent script execution records
- Parent-child process context for script hosts and shells
- User, host, and timestamp context for executed scripts
- Script path, module, or command content where collected
Detection direction
- Baseline legitimate administrative and automation use of error-suppression parameters to reduce false positives.
- Alert more strongly when suppression parameters appear in unusual users, hosts, parent processes, script locations, or time windows.
- Correlate suppression arguments with continued execution behavior rather than treating the argument alone as proof of malicious activity.
- Confirm command-line and PowerShell/script logging are retained and searchable; otherwise this analytic may have major blind spots.
- Use this analytic as a supporting signal with other Windows execution evidence because no ATT&CK tactic, technique relationship, or official detection logic is supplied.
Mitigation priorities
- Ensure Windows script and process execution telemetry captures command-line parameters and relevant PowerShell/script details.
- Restrict or govern script execution according to administrative need and least privilege where operationally feasible.
- Review approved automation that uses error-suppression arguments and document expected patterns for SOC tuning.
- Improve incident response playbooks so responders check for suppressed-error parameters during Windows script execution investigations.
- Retain sufficient logging to support audit, compliance evidence, and post-incident reconstruction of scripted activity.
Analyst notes and limits
The supplied object is a detection analytic for Windows focused on PowerShell or script execution parameters that suppress errors or ignore user interrupts, with an example of `-ErrorAction SilentlyContinue`. Its practical value is as a visibility and triage enhancer: it helps defenders distinguish ordinary automation from suspicious attempts to reduce error visibility when combined with local context.
Official detection logic, tactics, technique relationships, labels, aliases, and relationship context were not supplied. This take therefore avoids claims about specific attacker objectives, exploitation, attribution, impact, or guaranteed coverage. Local baselining is required because error-suppression parameters can be common in legitimate administrative scripts.
Analytic 0182
PowerShell or script execution with parameters that suppress errors or ignore user interrupts, such as `-ErrorAction SilentlyContinue`. Defender perspective: detecting discrepancies between suppressed error arguments and continued execution behavior.
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 | 337d996d20b0… |
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 AN0182Open 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.