User Activity Based Checks (T1497.002)
User Activity Based Checks [T1497.002]
Last updated
User Activity Based Checks [T1497.002]
Last updated
Name: User Activity Based Checks
ID: T1497.002
Tactics: ,
Technique:
User Activity Based Checks (T1497.002) is a sub-technique within the MITRE ATT&CK framework under the parent technique "Virtualization/Sandbox Evasion." Attackers leverage this sub-technique to determine if a compromised system is actively used by a legitimate user or if it is a sandbox or virtual environment intended for malware analysis. By checking user activity indicators, adversaries can evade detection, analysis, and defensive measures by behaving differently or terminating execution when user interactions are not detected.
Attackers employing User Activity Based Checks typically monitor various indicators of genuine user interactions and system usage. The absence or presence of these indicators helps adversaries identify if the environment is real or a sandbox. Common indicators monitored include:
Mouse movements and clicks:
Malware may track cursor movement frequency and pattern.
Lack of mouse activity often indicates automated sandbox environments.
Keyboard activity:
Keypress frequency and patterns can indicate human interaction.
Automated sandboxes may lack realistic typing patterns.
Window and application interactions:
Malware checks for active windows, application focus, and user interactions with GUI elements.
Automated analysis environments often run headless or minimal GUI interactions.
System idle times:
Malware checks the system idle time to detect prolonged inactivity, common in sandbox environments.
User login/logout events:
Monitoring login events and session durations to detect genuine user presence.
Technical mechanisms employed by malware include:
Querying Windows API functions such as GetLastInputInfo() to determine idle times.
Monitoring event hooks (SetWindowsHookEx) to detect keyboard and mouse events.
Inspecting system event logs for recent user login sessions.
Checking running processes and window titles for typical user applications (e.g., browsers, email clients, office suites).
Real-world procedures involve malware dynamically altering its behavior based on these checks. If user activity is not detected, the malware might:
Terminate execution immediately.
Remain dormant and periodically re-check for user activity.
Execute benign actions to deceive sandbox analysis.
Attackers typically utilize User Activity Based Checks in the following scenarios and stages:
Initial Access and Execution stages:
Malware delivered via phishing emails or malicious downloads may check immediately upon execution whether the environment appears genuine.
Defense Evasion:
Malware uses these checks to evade sandbox analysis, automated malware detection systems, and virtualized environments.
Persistence and Privilege Escalation:
Malware may periodically verify user activity before initiating sensitive operations to avoid detection.
Command and Control (C2) communications and Exfiltration stages:
Malware may delay or avoid communication with C2 servers if user activity is not detected, preventing detection by network-based monitoring tools.
Detection of User Activity Based Checks involves identifying suspicious behaviors and artifacts indicative of malware attempting to determine user presence:
Behavioral analysis:
Sandbox environments can simulate user interactions (mouse/keyboard events) to trigger malware activity.
Monitoring for malware processes querying specific Windows API calls like GetLastInputInfo() or setting event hooks (SetWindowsHookEx).
Endpoint Detection and Response (EDR) tools:
EDR solutions can detect unusual process behaviors, suspicious API calls, and hooks into user input events.
Static and dynamic malware analysis:
Identification of code patterns and API calls related to user activity checks during static analysis.
Dynamic analysis environments can detect the conditional execution paths based on user activity presence.
Indicators of Compromise (IoCs) specific to User Activity Based Checks:
Unusual API calls:
Frequent calls to user input APIs (GetAsyncKeyState(), GetForegroundWindow(), GetLastInputInfo()).
Suspicious hooks:
Malware setting global hooks (SetWindowsHookEx) to monitor keyboard/mouse inputs.
Conditional behavior:
Malware that remains dormant or terminates quickly if no user activity is detected.
Detecting User Activity Based Checks is critical due to the following potential impacts on systems and networks:
Evasion of security controls:
Malware capable of detecting sandbox environments can bypass automated security analysis, increasing the risk of undetected infections.
Increased dwell time:
Malware may remain dormant or delay malicious actions, complicating detection and response efforts.
Targeted attacks:
Advanced persistent threats (APTs) and sophisticated malware often utilize this technique to ensure they target only legitimate user environments, increasing the effectiveness of their attacks.
Potential for data theft and damage:
Early detection prevents malware from executing malicious payloads, exfiltrating sensitive data, or conducting destructive actions.
Early detection and mitigation are essential to:
Reduce the risk of successful malware infections.
Minimize dwell time and limit potential damage.
Improve security posture by identifying sophisticated evasion techniques used by attackers.
Real-world examples of malware employing User Activity Based Checks:
Dridex Banking Trojan:
Dridex samples have been observed checking for mouse movement and keyboard inputs. If no activity is detected, Dridex terminates execution to evade sandbox analysis.
TrickBot Trojan:
TrickBot variants monitor system idle time using the GetLastInputInfo() API. If the system remains idle beyond a threshold, TrickBot delays execution or remains dormant.
Ursnif Malware:
Ursnif checks for active window titles and user interactions. In sandbox environments lacking realistic user interaction, Ursnif terminates or delays malicious activities.
Cerber Ransomware:
Cerber monitors mouse movements and keyboard events. If no realistic user activity is detected, Cerber refrains from encrypting files, preventing analysis in automated environments.
Attack scenarios and impacts:
Scenario:
Malware delivered via phishing email executes on a user's endpoint.
Malware checks for user activity; if detected, it downloads additional payloads, establishes persistence, and initiates data exfiltration.
If no user activity is detected, malware remains dormant or terminates, evading sandbox analysis.
Tools used:
Windows API functions (GetLastInputInfo(), GetAsyncKeyState(), SetWindowsHookEx).
Custom malware scripts and binaries specifically designed to detect user interactions.
Impacts:
Successful evasion of automated sandbox detection.
Increased difficulty in malware detection and analysis.
Potential compromise of sensitive data, financial losses, or operational disruptions if malware executes successfully in legitimate user environments.