Detections

The OS may show a notification to the user that the Signal or WhatsApp account has been linked to a new device.

The defender correlates application loading or invoking native libraries through JNI or NDK-backed execution paths with subsequent lower-level activity such as native thread creation, sensor access, file operations, or outbound network communication that is inconsistent with the app's declared role or recent user interaction. The analytic prioritizes defender-observable control-plane effects: native library load or JNI bridge use, transition into native execution context, and immediate post-load behavior occurring from background state, locked-device state, or non-baselined app categories.

The defender correlates an application establishing outbound retrieval to a non-baselined external source with immediate local creation of a new executable, module, staged payload, overlay asset, or secondary file in app-controlled or shared storage, followed by optional load, invocation, handoff, or repeat retrieval behavior. The analytic prioritizes Android-observable effects: network download activity, DownloadManager or direct HTTP retrieval, file creation in package-specific or external paths, and execution context inconsistent with recent user interaction or the app’s declared role.

The defender correlates managed-app network retrieval from a non-baselined external source with immediate creation of a new local artifact, staged resource, module-like file, or opaque payload inside the app container, followed by optional dynamic loading, handoff, or repeat retrieval behavior. Because iOS offers weaker direct visibility into tool staging internals than Android in many environments, the analytic anchors first on network acquisition plus managed app identity and then strengthens confidence with file creation or process-activity effects where mobile telemetry is available.

Correlates (1) device posture changes indicating root or elevated privilege state, (2) runtime framework manipulation or injection into application processes, and (3) anomalous API behavior or suppressed security signals. The defender observes a causal chain where an application gains privileged execution context, interacts with system frameworks (e.g., ART/Zygote), and modifies expected API outputs or suppresses security-relevant signals such as permission checks, sensor access reporting, or process visibility.

Defender correlates a sandboxed app writing high-entropy or encoded artifacts (often in app-private or shared storage), performing decode/decompress/reassembly, then dynamically loading/execing the resulting code (DexClassLoader/JNI dlopen) or spawning a helper process. Sequence: high-entropy file writes → decode/unpack bursts → new .dex/.so/.jar creation in temp/obfuscated paths → dynamic load or shell spawn within a tight window.

Defender correlates a sandboxed app downloading or receiving opaque/encoded blobs, writing high-entropy content into container/tmp, performing decode/decompress/reassembly, and then executing/loaded as Mach-O or bundle (dlopen) or leveraging JIT/RWX pages to run the decoded payload. Sequence: opaque download or IPC → high-entropy writes/split-file bursts → decode/unarchive → new Mach-O/bundle in tmp → dlopen/posix_spawn or RWX region activity.

The defender correlates the arrival, installation, or update of a trusted or expected application with a subsequent deviation in package trust characteristics, permission posture, protected-resource use, framework behavior, or network communication that is inconsistent with the known-good role of that app. The strongest Android evidence is a managed or trusted package whose first-run or post-update behavior introduces unexpected special access, sensitive sensor use, unusual background execution, privileged framework interaction, or outbound communication to destinations outside the app's baseline shortly after installation or update.

Anchor on supervised managed-app install/update or version drift, then correlate with unexpected background activity, managed-app state changes, or egress inconsistent with the app's historical and policy baseline.

Monitor for API calls that can be used to install a hook procedure, such as the SetWindowsHookEx and SetWinEventHook functions.[1][2] Also consider analyzing hook chains (which hold pointers to hook procedures for each type of hook) using tools[2][3][4] or by programmatically examining internal kernel structures.[5][6] Verify integrity of live processes by comparing code in memory to that of corresponding static binaries, specifically checking for jumps and other instructions that redirect code flow.

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 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. Monitor for application logging, messaging, and/or other artifacts that may result from Denial of Service (DoS) attacks which degrade or block the availability of services to users. In addition to network level detections, endpoint logging and instrumentation can be useful for detection. Monitor operational data for indicators of temporary data loss which may indicate a Denial of Service. 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 for an authentication attempt by a user that may obtain and abuse credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Monitor for logon behavior that may abuse credentials of existing accounts as a means of gaining Lateral Movement or Persistence. Correlate other security systems with login information (e.g., a user has an active login session but has not entered the building or does not have VPN access). Monitor for suspicious account behavior across systems that share accounts, either user, admin, or service accounts. Examples: one account logged into multiple systems simultaneously; multiple accounts logged into the same machine simultaneously; accounts logged in at odd times or outside of business hours. Activity may be from interactive login sessions or process ownership from accounts being used to execute binaries on a remote system as a particular account.

Monitor for newly constructed services/daemons that may attempt to manipulate features of their artifacts to make them appear legitimate or benign to users and/or security tools. Monitor for changes made to files outside of an update or patch that may attempt to manipulate features of their artifacts to make them appear legitimate or benign to users and/or security tools. Monitor for file names that are mismatched between the file name on disk and that of the binary's metadata. This is a likely indicator that a binary was renamed after it was compiled. For added context on adversary procedures and background see Masquerading and applicable sub-techniques. Monitor executed commands and arguments that may attempt to manipulate features of their artifacts to make them appear legitimate or benign to users and/or security tools.[1] Monitor for changes made to scheduled jobs that may attempt to manipulate features of their artifacts to make them appear legitimate or benign to users and/or security tools. Monitor for changes made to services that may attempt to manipulate features of their artifacts to make them appear legitimate or benign to users and/or security tools. Collect file hashes. Monitor for file names that do not match their expected hash. Perform file monitoring. Files with known names but in unusual locations are suspect. Look for indications of common characters that may indicate an attempt to trick users into misidentifying the file type, such as a space as the last character of a file name or the right-to-left override characters"\u202E", "[U+202E]", and "%E2%80%AE". For added context on adversary procedures and background see Masquerading and applicable sub-techniques. Monitor for newly constructed scheduled jobs that may attempt to manipulate features of their artifacts to make them appear legitimate or benign to users and/or security tools.

Monitor login sessions for new or unexpected devices or sessions on wireless networks. Monitor application logs for new or unexpected devices or sessions on wireless networks. New or irregular network traffic flows 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 ICS automation network protocols for functions related to reading an operational process state (e.g., “Read” function codes in protocols like DNP3 or Modbus). In some cases, there may be multiple ways to monitor an operational process’ state, one of which is typically used in the operational environment. Monitor for the operating mode being checked in unexpected ways. Monitor applications logs for any access attempts to operational databases (e.g., historians) or other sources of operational data within the ICS environment. These devices should be monitored for adversary collection using techniques relevant to the underlying technologies (e.g., Windows, Linux).

Monitor for loss of network traffic which could indicate alarms are being suppressed. A loss of expected communications associated with network protocols used to communicate alarm events or process data could indicate this technique is being used. 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 for loss of operational process data which could indicate alarms are being suppressed. 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 for loss of expected device alarms which could indicate alarms are being suppressed. As noted in the technique description, there may be multiple sources of alarms in an ICS environment. Discrepancies between alarms may indicate the adversary is suppressing some but not all the alarms in the environment. 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 for loss of expected operational process alarms which could indicate alarms are being suppressed. As noted in the technique description, there may be multiple sources of alarms in an ICS environment. Discrepancies between alarms may indicate the adversary is suppressing some but not all the alarms in the environment. 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.

No standard detection method currently exists for this technique.

Use verification of distributed binaries through hash checking or other integrity checking mechanisms. Scan downloads for malicious signatures.

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 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] Monitor ICS management protocols / file transfer protocols for protocol functions related to firmware changes.

No standard detection method currently exists for this technique.

Monitor for newly executed processes that execute from removable media after it is mounted or when initiated by a user. If a remote access tool is used in this manner to move laterally, then additional actions are likely to occur after execution, such as opening network connections for Command and Control and system and network information Discovery. Monitor for newly constructed files copied to or from removable media. Monitor for newly constructed drive letters or mount points to removable media. Monitor for files accessed on removable media, particularly those with executable content.

Monitor for any suspicious attempts to enable script execution 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. Monitor executed commands and arguments for actions that could be taken to collect internal data. Monitor for unexpected files (e.g., .pdf, .docx, .jpg) viewed for collecting internal data. Monitor for information collection on assets that may indicate deviations from standard operational tools. Examples include unexpected industrial automation protocol functions, new high volume communication sessions, or broad collection across many hosts within the network.

Monitor command-line arguments for script execution and subsequent behavior. Actions may be related to network and system information Discovery, Collection, or other scriptable post-compromise behaviors and could be used as indicators of detection leading back to the source script. Scripts are likely to perform actions with various effects on a system that may generate events, depending on the types of monitoring used. Monitor log files for process execution through command-line and scripting activities. This information can be useful in gaining additional insight to adversaries' actions through how they use native processes or custom tools. Also monitor for loading of modules associated with specific languages. Monitor contextual data about a running process, which may include information such as environment variables, image name, user/owner, or other information that may reveal abuse of system features. Monitor for events associated with scripting execution, such as the loading of modules associated with scripting languages (e.g., JScript.dll, vbscript.dll). Monitor for any attempts to enable scripts running on a system would be considered suspicious. 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.

Analyze network data for uncommon data flows (e.g., new protocols in use between hosts, unexpected ports in use). Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious. Monitor for mismatches between protocols and their expected ports (e.g., non-HTTP traffic on tcp:80). Analyze packet contents to detect communications that do not follow the expected protocol behavior for the port that is being used.[1]

Monitor operational process data for write commands for an excessive number of I/O points or manipulating a single value an excessive number of times. 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. Some asset application logs may provide information on I/O points related to write commands. Monitor for write commands for an excessive number of I/O points or manipulating a single value an excessive number of times. Monitor network traffic for ICS functions related to write commands for an excessive number of I/O points or manipulating a single value an excessive number of times.