AN1878: Analytic 1878
Monitor for unexpected network share access, such as files transferred between shares within a network using protocols such as Server Message Block (SMB). Monitor for alike file hashes or characteristics (ex: filename) that are created on multiple hosts. Monitor for file creation in conjunction with other techniques (e.g., file transfers using Remote Services). Monitor for unusual processes with internal network connections creating files on-system which may be suspicious. Monitor executed commands and arguments for abnormal usage of utilities and command-line arguments that may be used in support of remote transfer of files. Monitor newly constructed processes that assist in lateral tool transfers, such as file transfer programs. Monitor for network traffic originating from unknown/unexpected hosts. Local network traffic metadata (such as source MAC addressing) as well as usage of network management protocols such as DHCP may be helpful in identifying hardware.
Analyst context for executives and security teams
This analytic is about spotting lateral file movement in an ICS environment: unexpected access to network shares, repeated creation of similar files across hosts, unusual internal connections that create files, and abnormal command-line use of file transfer utilities. For leaders, the value is not just “detect SMB activity,” but validating whether the organization can see tools or files being staged across internal systems before they affect operations.
Executive priority
Prioritize this as an operational resilience and incident response readiness question: can the SOC prove it can identify unexpected internal file transfer behavior, especially over network shares and from unknown or unexpected hosts? This supports better containment decisions, evidence for control effectiveness, and prioritization of logging across critical internal network segments. Because the object is in the ICS ATT&CK domain, teams should also consider whether monitoring covers environments where business IT and operational networks intersect.
Technical view
Validate visibility for unexpected network share access, including SMB-based transfers; file creation events where matching hashes, filenames, or characteristics appear on multiple hosts; processes that make internal network connections and create files locally; executed commands and arguments associated with file transfer behavior; newly constructed processes that support lateral tool transfer; and traffic from unknown or unexpected hosts. Since no ATT&CK platform or tactic is specified and no separate detection logic is provided, this should be treated as detection engineering guidance rather than a ready-to-deploy analytic.
Likely telemetry
- Network share access logs, including SMB where available
- File creation telemetry with filename, path, hash, host, and timestamp
- Process creation telemetry with command line and arguments
- Process-to-network connection telemetry for internal connections
- Network traffic metadata for internal source and destination activity
Detection direction
- Correlate file creation across multiple hosts using hashes, filenames, or other file characteristics rather than relying on a single event.
- Review unexpected or abnormal network share access, especially transfers between internal shares.
- Tune for unusual processes that both connect internally and create files on the local system.
- Analyze command-line arguments for abnormal use of utilities that may support remote file transfer, while accounting for legitimate administration and maintenance activity.
- Use network metadata, MAC addressing, and DHCP context to distinguish known managed assets from unknown or unexpected hosts.
Mitigation priorities
- Confirm logging is enabled and retained for network shares, file creation, process creation, command execution, internal network connections, and DHCP or asset-identification sources.
- Baseline expected internal file transfer paths, administrative utilities, and known hosts so unusual transfer behavior can be triaged quickly.
- Reduce unnecessary network share exposure and review access controls for internal shares where operationally feasible.
- Ensure incident response playbooks include containment decisions for suspected lateral file transfer, including host isolation, share access review, and preservation of file/process evidence.
- Use asset inventory and network management data to strengthen identification of unknown or unexpected hosts on internal networks.
Analyst notes and limits
The supplied object provides detection-oriented monitoring guidance but no explicit tactic, platform, relationship context, or separate detection implementation. The strongest defensive value comes from correlating endpoint, network, file, and asset identity evidence rather than building a single narrow SMB rule.
No platforms, tactics, relationships, or official detection logic were supplied. This take does not infer active exploitation, attribution, specific ICS device exposure, or guaranteed detection coverage. Local baselines are required to distinguish legitimate administration, engineering activity, and maintenance transfers from suspicious behavior.
Analytic 1878
Monitor for unexpected network share access, such as files transferred between shares within a network using protocols such as Server Message Block (SMB). Monitor for alike file hashes or characteristics (ex: filename) that are created on multiple hosts. Monitor for file creation in conjunction with other techniques (e.g., file transfers using Remote Services). Monitor for unusual processes with internal network connections creating files on-system which may be suspicious. Monitor executed commands and arguments for abnormal usage of utilities and command-line arguments that may be used in support of remote transfer of files. Monitor newly constructed processes that assist in lateral tool transfers, such as file transfer programs. Monitor for network traffic originating from unknown/unexpected hosts. Local network traffic metadata (such as source MAC addressing) as well as usage of network management protocols such as DHCP may be helpful in identifying hardware.
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 | bf64050f93ba… |
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 AN1878Open 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.