Unauthorized 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. Unauthorized messages may not precisely match legitimate messages which may lead to malformed traffic, although traffic may be malformed for benign reasons. Monitor messages for changes in how they are constructed.

Monitor for anomalous or unexpected messages that may result in changes to the process operation observable via asset application logs (e.g., discrete write, logic and device configuration, mode changes, safety triggers).

Consider monitoring for Rogue Master and Adversary-in-the-Middle activity which may precede this technique.

Monitor for the termination of processes or services associated with ICS automation protocols and application software which could help detect blocked communications.

Monitor for lack of operational process data which may help identify a loss of communications. This will not directly detect the technique’s execution, but instead may provide additional evidence that the technique has been used and may complement other detections.

Monitor application logs for changes to settings and other events associated with network protocols that may be used to block communications.

Monitor for a loss of network communications, which may indicate this technique is being used.

Monitor asset alarms which may help identify a loss of communications. Consider correlating alarms with other data sources that indicate traffic has been blocked, such as network traffic. In cases where alternative methods of communicating with outstations exist alarms may still be visible even if messages are blocked.

Monitor for firmware changes which may be observable via operational alarms from devices.

Monitor device application logs for firmware changes, although not all devices will produce such logs.

Monitor ICS management protocols / file transfer protocols for protocol functions related to firmware changes.

Monitor firmware for unexpected changes. Asset management systems should be consulted to understand known-good firmware versions. Dump and inspect BIOS images on vulnerable systems and compare against known good images.^[1] Analyze differences to determine if malicious changes have occurred. Log attempts to read/write to BIOS and compare against known patching behavior. Likewise, EFI modules can be collected and compared against a known-clean list of EFI executable binaries to detect potentially malicious modules. The CHIPSEC framework can be used for analysis to determine if firmware modifications have been performed.^[2][3][4]

References:

1. Butterworth, J. (2013, July 30). Copernicus: Question Your Assumptions about BIOS Security. Retrieved December 11, 2015.
2. Beek, C., Samani, R. (2017, March 8). CHIPSEC Support Against Vault 7 Disclosure Scanning. Retrieved March 13, 2017.
3. Intel. (2017, March 18). CHIPSEC Platform Security Assessment Framework. Retrieved March 20, 2017.
4. Intel Security. (2005, July 16). HackingTeam's UEFI Rootkit Details. Retrieved November 17, 2024.

Monitor network traffic for insecure credential use in protocols that allow unencrypted authentication.

Monitor logon sessions for insecure credential use, when feasible.

Monitor for unexpected changes to project files, although if the malicious modification occurs in tandem with legitimate changes it will be difficult to isolate the unintended changes by analyzing only file systems modifications.

Monitor for new processes engaging in scanning activity or connecting to multiple systems by correlating process creation network data.

Monitor for hosts enumerating network connected resources using non-ICS enterprise protocols.

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. 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.

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.

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.

Monitor asset alarms which may help identify a loss of communications. Consider correlating alarms with other data sources that indicate traffic has been blocked, such as network traffic. In cases where alternative methods of communicating with outstations exist, alarms may still be visible even if messages are blocked.

Monitor for a loss of network communications, which may indicate this technique is being used.

Monitor for lack of operational process data which may help identify a loss of communications. This will not directly detect the technique’s execution but instead may provide additional evidence that the technique has been used and may complement other detections.

Monitor application logs for changes to settings and other events associated with network protocols that may be used to block communications.

Monitor for the termination of processes or services associated with ICS automation protocols and application software which could help detect blocked communications.

Monitor asset alarms which may help identify a loss of communications. Consider correlating alarms with other data sources that indicate traffic has been blocked, such as network traffic. In cases where alternative methods of communicating with outstations exist, alarms may still be visible even if Ethernet messages are blocked.

Monitor for a loss of network communications, which may indicate this technique is being used.

Monitor for lack of operational process data which may help identify a loss of communications. This will not directly detect the technique’s execution but instead may provide additional evidence that the technique has been used and may complement other detections.

Monitor application logs for changes to settings and other events associated with network protocols that may be used to block communications.

Monitor for the termination of processes or services associated with ICS automation protocols and application software which could help detect blocked communications.

Monitor asset alarms which may help identify a loss of communications. Consider correlating alarms with other data sources that indicate traffic has been blocked, such as network traffic. In cases where alternative methods of communicating with outstations exist, alarms may still be visible even if Wi-Fi messages are blocked.

Monitor for a loss of network communications, which may indicate this technique is being used.

Monitor for lack of operational process data which may help identify a loss of communications. This will not directly detect the technique’s execution, but instead may provide additional evidence that the technique has been used and may complement other detections.

Monitor application logs for changes to settings and other events associated with network protocols that may be used to block communications.

Monitor for the termination of processes or services associated with ICS automation protocols and application software which could help detect blocked communications.

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.

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.

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.