AN1871: Analytic 1871
Detecting software exploitation may be difficult depending on the tools available. Software exploits may not always succeed or may cause the exploited process to become unstable or crash.
Detection strategies and analytics from ATT&CK where present.
Results are validated against normalized ATT&CK source records when available; sample records are used only in development or empty-data environments.
Detecting software exploitation may be difficult depending on the tools available. Software exploits may not always succeed or may cause the exploited process to become unstable or crash.
Monitor for files (such as /etc/hosts) being accessed that may attempt to get a listing of other systems by IP address, hostname, or other logical identifier on a network that may be used for Lateral Movement from the current system. Monitor for newly executed processes that can be used to discover remote systems, such as ping.exe and tracert.exe , especially when executed in quick succession.[1] Consider monitoring for new processes engaging in scanning activity or connecting to multiple systems by correlating process creation network data. Monitor for anomalies related to discovery related ICS functions, including devices that have not previously used these functions or for functions being sent to many outstations. Note that some ICS protocols use broadcast or multicast functionality, which may produce false positives. Also monitor for hosts enumerating network connected resources using non-ICS enterprise protocols. Monitor for new ICS protocol connections to existing assets or for device scanning (i.e., a host connecting to many devices) over ICS and enterprise protocols (e.g., ICMP, DCOM, WinRM). For added context on adversary enterprise procedures and background see Remote System Discovery.
Detecting software exploitation may be difficult depending on the tools available. Software exploits may not always succeed or may cause the exploited process to become unstable or crash. Web Application Firewalls may detect improper inputs attempting exploitation. Use deep packet inspection to look for artifacts of common exploit traffic, such as known payloads.
Monitor asset application logs for information that indicate task parameters have changed. Monitor device alarms that indicate controller task parameters have changed, although not all devices produce such alarms. Program Download may be used to enable this technique. Monitor for program downloads which may be noticeable via operational alarms. Asset management systems should be consulted to understand expected program versions. Engineering and asset management software will often maintain a copy of the expected program loaded on a controller and may also record any changes made to controller programs and tasks. Data from these platforms can be used to identify modified controller tasking.
Devices that provide user access to the underlying operating system may allow the installation of custom software to monitor OS API execution. Monitoring API calls may generate a significant amount of data and may not be useful for defense unless collected under specific circumstances, since benign use of API functions are common and may be difficult to distinguish from malicious behavior. Correlation of other events with behavior surrounding API function calls using API monitoring will provide additional context to an event that may assist in determining if it is due to malicious behavior.
Purely passive network sniffing cannot be detected effectively. In cases where the adversary interacts with the wireless network (e.g., joining a Wi-Fi network) detection may be possible. Monitor for new or irregular network traffic flows which may indicate potentially unwanted devices or sessions on wireless networks. In Wi-Fi networks monitor for changes such as rogue access points or low signal strength, indicating a device is further away from the access point then expected and changes in the physical layer signal.[1] [2] Network traffic content will provide important context, such as hardware (e.g., MAC) addresses, user accounts, and types of messages sent.
Monitor for network traffic originating from unknown/unexpected hardware devices. Local network traffic metadata (such as source MAC addressing) may be helpful in identifying transient assets. Networking devices such as switches may log when new client devices connect (e.g., SNMP notifications). Monitor for any logs documenting changes to network connection status to determine when a new connection has occurred, including the resulting addresses (e.g., IP, MAC) of devices on that network.
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.
Various techniques enable spoofing a reporting message. Consider monitoring for Rogue Master and Adversary-in-the-Middle activity which may precede this technique. Monitor asset logs for alarms or other information the adversary is unable to directly suppress. Relevant alarms include those from a loss of communications due to Adversary-in-the-Middle activity. Various techniques enable spoofing a reporting message. Monitor for LLMNR/NBT-NS poisoning via new services/daemons which may be used to enable this technique. For added context on adversary procedures and background see Name Resolution Poisoning and SMB Relay. Spoofed reporting messages may be detected by reviewing the content of automation protocols, either through detecting based on expected values or comparing to other out of band process data sources. Spoofed messages may not precisely match legitimate messages which may lead to malformed traffic, although traffic may be malformed for many benign reasons. Monitor reporting messages for changes in how they are constructed.
Various techniques enable spoofing a reporting message. Consider monitoring for Rogue Master and Adversary-in-the-Middle activity.
No standard detection method currently exists for this technique.
Monitor for unexpected/abnormal access to files that may be malicious collection of local data, such as user files (e.g., .pdf, .docx, .jpg, .dwg ) or local databases. Monitor for newly executed processes that may search local system sources, such as file systems or local databases, to find files of interest and sensitive data. Monitor for any suspicious attempts to enable scripts running on a system. If scripts are not commonly used on a system, but enabled, scripts running out of cycle from patching or other administrator functions are suspicious. Scripts should be captured from the file system when possible to determine their actions and intent. Data may also be acquired through Windows system management tools such as Windows Management Instrumentation and PowerShell. Monitor for API calls that may search local system sources, such as file systems or local databases, to find files of interest and sensitive data. Monitor executed commands and arguments that may search and collect local system sources, such as file systems or local databases, to find files of interest and sensitive data. Remote access tools with built-in features may interact directly with the Windows API to gather data. Data may also be acquired through Windows system management tools such as Windows Management Instrumentation and PowerShell.
Monitor executed commands and arguments that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor for API calls that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor for changes made to Windows Registry keys or values that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. For added context on adversary procedures and background see Indicator Removal and applicable sub-techniques. Monitor for contextual file data that may show signs of deletion or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor Windows registry keys that may be deleted or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. For added context on adversary procedures and background see Indicator Removal and applicable sub-techniques. Monitor for a file that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor for changes made to a file may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Monitor for newly executed processes that may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware.
Monitor executed commands and arguments that may attempt to take screen captures of the desktop to gather information over the course of an operation. Monitoring for screen capture behavior will depend on the method used to obtain data from the operating system and write output files. Detection methods could include collecting information from unusual processes using API calls used to obtain image data, and monitoring for image files written to disk, such as CopyFromScreen, xwd, or screencapture.[1][2] The data may need to be correlated with other events to identify malicious activity, depending on the legitimacy of this behavior within a given network environment.
Monitor device alarms for program downloads, although not all devices produce such alarms. Monitor for protocol functions related to program download or modification. Program downloads may be observable in ICS automation protocols and remote management protocols. Consult asset management systems to understand expected program versions. Monitor devices configuration logs which may contain alerts that indicate whether a program download has occurred. Devices may maintain application logs that indicate whether a full program download, online edit, or program append function has occurred.
Devices that provide user access to the underlying operating system may allow the installation of custom software to monitor OS API execution. Monitoring API calls may generate a significant amount of data and may not be useful for defense unless collected under specific circumstances, since benign use of API functions are common and may be difficult to distinguish from malicious behavior. Correlation of other events with behavior surrounding API function calls using API monitoring will provide additional context to an event that may assist in determining if it is due to malicious behavior.
Monitor for newly constructed logon behavior within Microsoft's SharePoint can be configured to report access to certain pages and documents.[1] Sharepoint audit logging can also be configured to report when a user shares a resource.[2] The user access logging within Atlassian's Confluence can also be configured to report access to certain pages and documents through AccessLogFilter.[3] Additional log storage and analysis infrastructure will likely be required for more robust detection capabilities. In the case of detecting collection from shared network drives monitor for unexpected and abnormal accesses to network shares. Monitor for third-party application logging, messaging, and/or other artifacts that may leverage information repositories to mine valuable information. Information repositories generally have a considerably large user base, detection of malicious use can be non-trivial. At minimum, access to information repositories performed by privileged users (for example, Active Directory Domain, Enterprise, or Schema Administrators) should be closely monitored and alerted upon, as these types of accounts should generally not be used to access information repositories. If the capability exists, it may be of value to monitor and alert on users that are retrieving and viewing a large number of documents and pages; this behavior may be indicative of programmatic means being used to retrieve all data within the repository. In environments with high-maturity, it may be possible to leverage User-Behavioral Analytics (UBA) platforms to detect and alert on user-based anomalies.
Monitor ICS management protocols for functions that change an asset’s operating mode. Monitor device application logs which may contain information related to operating mode changes, although not all devices produce such logs. Monitor alarms for information about when an operating mode is changed, although not all devices produce such logs.
Monitor network traffic for default credential use in protocols that allow unencrypted authentication. Monitor logon sessions for default credential use.
No standard detection method currently exists for this technique.
Monitor for changes made to a large quantity of files for unexpected modifications in both user directories and directories used to store programs and OS components (e.g., C:\Windows\System32). Monitor for newly executed processes of binaries that could be involved in data destruction activity, such as SDelete. Monitor for unexpected deletion of files. Monitor executed commands and arguments for binaries that could be involved in data destruction activity, such as SDelete.
Monitor and analyze traffic patterns and packet inspection associated to protocol(s) that do not follow the expected protocol standards and traffic flows (e.g., extraneous packets that do not belong to established flows, gratuitous or anomalous traffic patterns, anomalous syntax, or structure). Consider correlation with process monitoring and command line to detect anomalous processes execution and command line arguments associated to traffic patterns (e.g., monitor anomalies in use of files that do not normally initiate connections for respective protocol(s)). Monitor for known proxy protocols (e.g., SOCKS, Tor, peer-to-peer protocols) and tool usage (e.g., Squid, peer-to-peer software) on the network that are not part of normal operations. Also monitor network data for uncommon data flows. Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious.
On Windows and Unix systems monitor executed commands and arguments that may use shell commands for execution. Shells may be common on administrator, developer, or power user systems depending on job function.
On network device and embedded system CLIs consider reviewing command history if unauthorized or suspicious commands were used to modify device configuration. Monitor logs from installed applications (e.g., historian logs) for unexpected commands or abuse of system features. Monitor for processes spawning from known command shell applications (e.g., PowerShell, Bash). Benign activity will need to be allow-listed. This information can be useful in gaining additional insight to adversaries' actions through how they use native processes or custom tools.
Program uploads may be observable in ICS management protocols or file transfer protocols. Note when protocol functions related to program uploads occur. In cases where the ICS protocols is not well understood, one option is to examine network traffic for the program files themselves using signature-based tools. Monitor device communication patterns to identify irregular bulk transfers of data between the embedded ICS asset and other nodes within the network. Note these indicators are dependent on the profile of normal operations and the capabilities of the industrial automation protocols involved (e.g., partial program uploads). Monitor for device alarms produced when program uploads occur, although not all devices will produce such alarms.
No standard detection method currently exists for this technique.
No standard detection method currently exists for this technique.
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.