Signed Windows tools are:
1. Trusted by the operating system
2. Often allowed by security policies
3. Installed by default
Attackers don’t need malware when they can blend in.
This tactic is commonly called Living Off the Land (LOLBins).
The result:
1. Fewer alerts
2. Higher success rates
3. Delayed detection
What “Signed” Really Means
A signed tool:
1. Is digitally signed by Microsoft or a trusted vendor
2. Appears legitimate to security controls
3. Is rarely blocked by default
Signing does not mean safe usage.
It only means the file is authentic.
Common Signed Windows Tools Abused in Real Attacks
PowerShell
Why attackers use it
1. Installed everywhere
2. Powerful automation features
3. Script execution built-in
What defenders see
1. Encoded commands
2. Hidden windows
3. Network activity from PowerShell
Real Example
A ransomware incident started with:
1. A phishing email
2. A PowerShell command executed by the user
No malware file was dropped initially.
The attacker stayed invisible for hours.
Indicators of Detection
1. Network connections created by PowerShell processes
2. Obfuscation of command-line options
3. Execution performed from user directories
certutil.exe
Used for storing digital certificates
Misuse
1. Downloading files
2. Encoding/Decoding payloads.
For Example
You might see certutil decoding an .exe file with the command certutil -decode input.txt output.exe.
Security Experts use these indicators to identify this behavior:
1. Certutil does not commonly decode .exe files
2. Certutil usage is not consistent with how system administrators use the tool.
mshta.exe
Used for running HTML applications
Misuse
1. Execute scripts remotely
2. Execute code without writing to disk.
An example of this behavior was when a hacker executed mshta to load a remote script and the files were not written to disk until they moved to another computer (lateral movement), which triggered detection alerts from EDR products.
rundll32.exe
Used for executing DLL functions
Misuse
1. Execute malicious logic in a DLL
2. Bypass control (such as access control policies)
Indicators of Detection
1. User executed rundll32 from a temporary location
2. Suspicious command-line options
3. Parent process is a document or browser.
wmic.exe
Used for system administration
Misuse
1. Reconnaissance
2. Remote execution
3. Lateral movement
Why Attackers are Successful
Attackers use tools to circumvent the majority of security solutions today. The reasons for this are as follows:
1. Because they come pre-installed
2. Digital signatures serve as proof that these tools are legitimate
3. Preventing these tools from being used could disrupt business operations
IT Security should monitor how users behave, not what they are using.
Detecting Tool Abuse - Methods for Detecting Tool Abuse
Monitor Command-Line Arguments When assessing Signed Tools for abuse, evaluate the Command-Line Arguments being utilized:
1. Evaluate for unrealistic Rationales compared to normal patterns of utilization
2. Identify Encoded Command
3. Assess for inappropriate execution context for your office environment (e.g. corporate environment).
Example: Suspicious PowerShell Pattern
powershell.exe -EncodedCommand
This is rare in normal user workflows.
Watch Parent–Child Process Chains
Red flags include:
1. Word → PowerShell
2. Browser → mshta
3. Excel → cmd
These chains often appear in real breaches.
Detection Support for Abuse - Tools Used for the Detection of Abuse by Defenders
Endpoint Security:
1. Microsoft Defender for Endpoint
2. CrowdStrike Falcon
3. SentinelOne
Log and telemetry sources:
1. Windows Event Logs
2. Sysmon
3. EDR process telemetry
Hunting & Testing
1. Atomic Red Team
2. MITRE ATT&CK Navigator
3. PurpleSharp
These help simulate real attacker behavior safely.
Ways Organizations Reduce Risk
A number of items help effective teams reduce risk, including:
1. Tracking command line usage.
2. Employing PowerShell Scriptblock logging.
3. Utilizing Constrained Language Mode.
4. Restricting access to tools by designated roles.
5. Generating alerts when execution activity is inconsistent with expectations.
In order to completely block all risk, you must also provide universal visibility.
Things to not do:
1. Trust signed tools without question.
2. Use hash-based detection alone.
3. Ignore command line logs.
4. Treat LOLBins as "false positives."
When many true attacks occurred, they did not start with custom malware.
Some takeaways:
1. Signed does not guarantee safety.
2. Attackers use trusted tools.
3. Intent can be determined by behavior.
4. Visibility outweighs blocking.
5. Detection engineering is important.
If there is power in the tool, there will be the opportunity for abuse.
