Malware · behavior
Signed binary, unsigned intent.
A Microsoft signature tells you who built the file. It says nothing about who is driving it. A lot of intrusions use tools that were already installed.
Why this ages well
A new hash is not a new behavior argued that hashes and file names expire with every repack. Built-in tools are the other side of the same coin. The attacker does not ship a file you could hash at all. They borrow one that is on every machine, signed and allowed. What is left to detect is how it is used.
Five behaviors, not five flags
| Behavior | Typical tool | Why it stands out |
|---|---|---|
| A certificate utility fetching content from the internet | certutil.exe | Its job is certificates. Users almost never run it. |
| The HTML application host running content from a remote address | mshta.exe | Few business applications still need it at all. |
| A DLL loaded from a user-writable directory | rundll32.exe, regsvr32.exe | Legitimate DLLs live in Program Files or System32, not in Downloads, Temp or AppData. |
| A script host started by Office or a browser | wscript.exe, cscript.exe | Documents should not launch interpreters. |
| An installer pulling a package from a URL | msiexec.exe | Your software deployment tool uses a known path and parent. This does not. |
The LOLBAS project keeps the long list, with the legitimate purpose of each binary next to the abuse. Read it for coverage, not as a blocklist.
What to record
- Parent process and its command line. The parent is usually the story: Outlook, a browser, a document viewer.
- The tool's own command line.
- Any network connection the tool made, with destination.
- Any file it wrote, with full path.
- User, and whether that user has ever run this tool before.
Where the noise comes from
Administrators use these tools. Deployment systems call msiexec all day. Some line-of-business applications still use mshta. Baseline by parent and user for two weeks, the same way as in the session note. Exceptions are written as parent path plus user group, never as "ignore rundll32".
Remove the option
Detection is the second line. The first is that most users never need these tools, so they can lose them:
- Attack surface reduction rules in Microsoft Defender include blocking Office applications from creating child processes and blocking JavaScript or VBScript from launching downloaded content. Run them in audit mode first and read the results.
- Application control with App Control for Business or AppLocker can deny binaries such as
mshta.exeto users who have no reason to run them. Microsoft publishes a list of signed binaries it recommends blocking for this reason.
What this note does not contain
No command lines that fetch or run anything, no sample, no family name we cannot source. Those would help a copy-paste attacker more than a defender, and the defender needs the parent, not the payload.