Detecting and Mitigating User Execution (T1204)

User Execution (MITRE ATT&CK T1204) is what happens when an adversary relies on a person to take a specific action to get code running. That action might be opening a document, clicking a link or running something they were told to run. MITRE files it under the Execution tactic and lists Containers, IaaS, Linux, Windows and macOS as platforms.

It has five sub-techniques, covered in their own posts: malicious link (T1204.001), malicious file (T1204.002), malicious image (T1204.003), malicious copy and paste (T1204.004) and malicious library (T1204.005). This post covers the parent.

How attackers use it

MITRE describes user execution as typically following phishing. It often comes soon after initial access, but it can happen at other phases too, for example when an attacker puts a file in a shared directory or on a desktop and waits for someone to click it. It may also follow internal spearphishing.

The page lists what adversaries may deceive users into doing:

• Enabling remote access tools, which gives the attacker direct control of the system
• Running malicious JavaScript in a browser, which may let the attacker steal web session cookies
• Downloading and executing malware
• Copying, pasting and running malicious code by hand

Tech support scams are one example. They can be set up through phishing, vishing or other user interaction, sometimes by spoofing and promoting toll-free numbers or call centers that direct victims to malicious sites, where payloads or remote access tools are delivered.

The MITRE examples include actors who recruit employees or contractors to provide credentials and approve an MFA prompt or install remote management software, malware delivered through a fake CAPTCHA that tells the user to open the Windows Run window and paste clipboard contents, and malicious LNK files that users open directly.

The common point is that no software flaw is needed. The user is the exploit.

How to detect it

MITRE's detection strategy is a multi-surface behavior chain: documents or links, then a helper or unpacker, then a living-off-the-land binary or child process, then outbound traffic.

Windows. A user-facing app (Office, a PDF reader, an archiver, a browser) records an open or click. A downloaded file is created in a user-writable path or unpacked. The parent app then spawns a binary such as powershell, cmd, mshta, rundll32, msiexec, wscript or an archive tool, or an installer. Immediately after, HTTP(S), DNS or SMB traffic comes from the same process lineage.

Linux. The same idea with different names: a new executable, script or archive extracted into the home directory, Downloads, /tmp or ~/.cache, a parent app that spawns bash, sh, python, node, curl or wget, and new outbound connections from the child.

macOS. Unified logs show an app open or crash for Safari, Chrome, Office, Preview or an archiver. Files are written or extracted into ~/Downloads, /private/var/folders or ~/Library. The parent app spawns osascript, bash, zsh, curl or python, or opens a quarantined app with Gatekeeper prompts, and the child makes network connections.

Containers and cloud. For developer desktops and CI, MITRE describes a user running a container pull or run after opening a document, link or script, with a new image from an unexpected registry or entrypoint that starts and immediately sends data to suspicious places. In cloud consoles, it describes a user clicking a link and then creating an instance or image from an external AMI or unknown image, followed by outbound traffic or payload retrieval.

The key log source on endpoints is process creation with parent process and command line. Office or PDF apps starting a script host are rarely normal.

How to reduce the risk

MITRE lists these mitigations:

• Prevent risky behavior on the endpoint. On Windows 10, Attack Surface Reduction (ASR) rules can stop executables from running unless they meet prevalence, age or trusted list criteria, and stop Office applications from creating potentially malicious executable content. Cloud-delivered protection must be on for some rules.
• Use execution prevention. Application control may stop executables that masquerade as other files.
• Limit software installation. Where possible, make developers pull from internal repositories of verified and approved packages.
• Use network intrusion prevention and download scanning to block malicious links and remove malicious downloads.
• Restrict web-based content. Block unknown or unused file types in transit by default, such as .scr, .exe, .pif and .cpl, and consider scanning compressed and encrypted archives such as zip and rar.
• Train users on phishing and spearphishing and how to raise suspicion about odd events.

Check your own environment

• Is application control in place on user workstations, and are there exceptions that have outlived their reason?
• Are ASR rules enabled in block mode, or only audit mode?
• Do you log process creation with parent process and command line on all endpoints?
• Can your tooling alert when Office, a PDF reader or a browser starts a script host or shell?
• Do users have local administrator rights they do not need?
• Do developers pull container images and packages only from approved sources?

On Windows, this read-only PowerShell command shows which ASR rule IDs are configured:

Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids

Pair it with the actions property (AttackSurfaceReductionRules_Actions) to see whether each rule is set to block, audit or disabled.

Quick check

Sources

• MITRE ATT&CK T1204: User Execution