AN1914: Analytic 1914
Monitor for unusual network traffic that may indicate additional tools transferred to the system. Use network intrusion detection systems, sometimes with SSL/TLS inspection, to look for known malicious scripts (recon, heap spray, and browser identification scripts have been frequently reused), common script obfuscation, and exploit code. Firewalls and proxies can inspect URLs for potentially known-bad domains or parameters. They can also do reputation-based analytics on websites and their requested resources such as how old a domain is, who it's registered to, if it's on a known bad list, or how many other users have connected to it before. Monitor for behaviors on the endpoint system that might indicate successful compromise, such as abnormal behaviors of browser processes. This could include suspicious files written to disk. Monitor for newly constructed files written to disk through a user visiting a website over the normal course of browsing. Monitor for newly constructed network connections to untrusted hosts that are used to send or receive data.
Analyst context for executives and security teams
AN1914 is an ICS ATT&CK detection analytic focused on finding signs that a system received additional tools or exploit-related content through unusual web or network activity. For leaders, the value is not the analytic name itself; it is whether the organization can prove it sees suspicious browser-driven downloads, newly written files, and new connections to untrusted hosts before they become an incident-response blind spot.
Executive priority
Prioritize this as a visibility and resilience question: can security teams monitor network traffic, web/proxy activity, and endpoint behavior well enough to identify suspicious transferred tools or exploit code? This matters for incident triage, audit evidence, and cyber-physical risk reduction in ICS environments, especially where normal browsing or trusted network paths could obscure malicious downloads. Budget and control decisions should focus on telemetry coverage, proxy/firewall inspection capability, endpoint monitoring, and clear escalation paths rather than assuming any single control will detect the behavior.
Technical view
Validate whether SOC and IR teams can correlate unusual network traffic with endpoint outcomes. The supplied analytic calls for network intrusion detection, optional SSL/TLS inspection, URL/domain reputation checks, inspection of suspicious script content or obfuscation, browser process behavior monitoring, newly created files written during browsing, and newly constructed connections to untrusted hosts. Because no platforms, tactics, or ATT&CK relationships are supplied, implementation should be environment-led: define what 'unusual,' 'untrusted,' and 'newly constructed' mean for the local ICS and enterprise network zones.
Likely telemetry
- Network intrusion detection alerts and packet/session metadata
- Firewall, proxy, and URL filtering logs
- SSL/TLS inspection metadata where legally and operationally approved
- DNS and domain reputation/context data
- HTTP/HTTPS request metadata, including URLs, parameters, and requested resources
Detection direction
- Confirm that web, proxy, firewall, NIDS, DNS, endpoint, and file-creation telemetry can be correlated by host, user, time, and destination.
- Tune for suspicious combinations rather than isolated events: unusual browser activity plus new file writes, known-bad or low-reputation domains, obfuscated scripts, exploit-like content, or new outbound connections.
- Account for encrypted traffic blind spots; where SSL/TLS inspection is not deployed or not appropriate, compensate with endpoint, DNS, proxy metadata, and reputation analytics.
- Define false-positive handling for legitimate software downloads, administrator activity, vendor support portals, and routine web browsing.
- Use local baselines for ICS zones because the object provides no platform or tactic scope and no relationship context.
Mitigation priorities
- Establish complete logging for proxy/firewall, NIDS, DNS, endpoint process, file creation, and outbound connection events before relying on this analytic.
- Apply reputation and policy controls at web gateways, firewalls, and proxies to reduce access to known-bad or suspicious destinations where appropriate.
- Implement endpoint monitoring capable of identifying abnormal browser behavior and unexpected files written during browsing activity.
- Review SSL/TLS inspection feasibility with privacy, legal, operational, and ICS safety constraints in mind.
- Create IR playbooks for triaging suspicious downloads or transferred tools, including host isolation decision points appropriate for operational environments.
Analyst notes and limits
The official object is a detection analytic in the ICS ATT&CK domain and describes monitoring guidance rather than a fully specified detection rule. It emphasizes unusual network traffic, malicious or obfuscated scripts, URL and domain reputation, browser-process anomalies, suspicious files written to disk, and new connections to untrusted hosts.
No official detection field, platforms, tactics, labels, aliases, or relationship context were supplied. This take therefore avoids claims about specific ATT&CK techniques, affected technologies, active exploitation, attribution, or guaranteed coverage. Local network architecture, ICS segmentation, logging depth, encryption policy, and endpoint telemetry determine practical effectiveness.
Analytic 1914
Monitor for unusual network traffic that may indicate additional tools transferred to the system. Use network intrusion detection systems, sometimes with SSL/TLS inspection, to look for known malicious scripts (recon, heap spray, and browser identification scripts have been frequently reused), common script obfuscation, and exploit code. Firewalls and proxies can inspect URLs for potentially known-bad domains or parameters. They can also do reputation-based analytics on websites and their requested resources such as how old a domain is, who it's registered to, if it's on a known bad list, or how many other users have connected to it before. Monitor for behaviors on the endpoint system that might indicate successful compromise, such as abnormal behaviors of browser processes. This could include suspicious files written to disk. Monitor for newly constructed files written to disk through a user visiting a website over the normal course of browsing. Monitor for newly constructed network connections to untrusted hosts that are used to send or receive data.
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 | d14a7222b89d… |
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 AN1914Open 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.