DET0735: Detection of Scripting
DET0735 is a detection strategy entry for identifying use of scripting related to ATT&CK for ICS technique T0853. For leaders, the value is not the ATT&CK...
Analyst context for executives and security teams
DET0735 is a detection strategy entry for identifying use of scripting related to ATT&CK for ICS technique T0853. For leaders, the value is not the ATT&CK entry itself—which provides no detailed detection logic—but the reminder that scripts can become a flexible way to run arbitrary code in environments that support interpreters. In an ICS context, that makes scripting visibility important for resilience, incident triage, and change-control assurance.
Executive priority
Treat this as a coverage validation item rather than a finished detection. Security and operations leaders should ask whether scripting activity is expected, authorized, logged, and reviewable in the parts of the ICS environment where interpreters or automation are present. The priority is to reduce blind spots that could complicate incident response, audit evidence, or operational recovery if unauthorized code execution is suspected.
Technical view
The official detection strategy does not provide platforms, tactics, description, or detection analytics. The only supplied relationship is that DET0735 detects T0853 Scripting, where adversaries may use scripting languages and interpreters to execute pre-written or user-supplied code. SOC and IR teams should therefore validate whether they can observe interpreter execution, script content or file activity, command-line context, parent-child process relationships, user identity, host location, and timing against approved operational workflows. In ICS environments, detection should be tuned around known engineering, maintenance, automation, and administrative use so that abnormal scripting is not lost among legitimate activity.
Likely telemetry
- Process execution records for scripting interpreters where available
- Command-line and argument logging
- Script file creation, modification, deletion, and execution metadata
- Parent-child process relationships involving interpreters and operational tools
- User, service account, and session context associated with script execution
Detection direction
- First inventory where scripting languages or interpreters are present, because ATT&CK does not specify platforms for this detection strategy.
- Baseline legitimate scripting tied to engineering, maintenance, automation, and administrative workflows before creating high-severity alerts.
- Look for scripting activity outside approved hosts, users, times, or change windows.
- Correlate interpreter execution with script file activity, command-line arguments, initiating user, and parent process to reduce false positives.
- Validate whether logs retain enough context to distinguish approved automation from unusual or user-supplied code execution.
Mitigation priorities
- Define and document where scripting is authorized in the ICS environment.
- Limit scripting capability and interpreter access to approved users, systems, and operational purposes where feasible.
- Align script use with change control, maintenance approvals, and identity governance so telemetry has business context.
- Harden logging and retention for systems where scripts are permitted or operationally necessary.
- Test incident response playbooks for investigating unexpected script execution without disrupting operations.
Analyst notes and limits
This take is based on the DET0735 detection strategy object, its MITRE external reference, and the supplied relationship to ICS technique T0853 Scripting. Because the ATT&CK object contains no official description, detection text, tactics, or platforms, the guidance is framed as validation direction rather than as a specific analytic.
The supplied ATT&CK fields are sparse. No specific platforms, data sources, detection logic, adversary use, or mitigations are provided in the object. Local asset inventory, logging architecture, operational workflows, and change-control evidence are required to determine actual coverage and risk.
Detection of Scripting
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
All related ATT&CK context
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 | 5fdd1817312f… |
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 DET0735Open 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.