PERE - PE Risk Engine
An attacker doesn't necessarily need to bring their own executable. It's enough to hide a malicious DLL inside the installation folder of legitimate software - Microsoft Teams, for example, or any other trusted application - and rely on Windows loading theirs instead of the original. This technique, known as DLL hijacking, works precisely because the suspicious file sits exactly where no one would think to look.
But how do you find a file like that? A legitimate software folder can contain dozens or hundreds of PE binaries. Going through them manually is slow. EDR systems are excellent, but not every environment has one deployed. So I wrote PERE - a simple CLI tool for Windows that performs rapid static analysis and assigns each binary a risk score.
What It Does
PERE recursively walks a target directory, finds all .exe and .dll files, and runs each one through static analysis. The result is a color-coded terminal output and, optionally, a JSON report.
The analysis covers four areas:
Import table is the first thing PERE looks at. Imported API functions are the most direct signal of what a binary does - or is capable of doing. The tool matches imports against categorized dictionaries:
- Memory APIs -
VirtualAlloc,WriteProcessMemory,NtWriteVirtualMemory, and similar - Injection APIs -
CreateRemoteThread,NtCreateThreadEx,QueueUserAPC - Execution APIs -
CreateProcessA/W,WinExec,ShellExecuteW - DLL APIs -
LoadLibrary,GetProcAddress,LdrLoadDll - Persistence APIs -
RegSetValueEx,RegCreateKeyExEach API carries a point value. Certain combinations also trigger composite detections - for example, the presence ofVirtualAlloc+WriteProcessMemory+CreateRemoteThreadin the same file is a classic injection chain and adds 80 points on top of the individual API scores. Similarly,OpenProcess+NtCreateThreadExflags stealth injection via native NT APIs.
Digital signature - PERE extracts and parses Authenticode metadata directly from the PE structure, without relying on the Windows API. It distinguishes three states: unsigned, selfsigned, and valid. Binaries signed by trusted publishers (currently Microsoft, Google, and Adobe) skip scoring entirely. Other signed binaries add 20 points to the score; self-signed or unsigned binaries add 40.
Section structure - PERE inspects individual PE sections and looks for several things: non-standard or invalid section names, overlay data appended after the last section (a typical indicator of packers or an attached payload), and known packer byte signatures such as UPX, ASPack, or Themida.
Entropy — high entropy in a file or its sections suggests compressed or encrypted content. Sections with entropy ≥ 7.0 are flagged as suspicious. The optional --timestamps flag enables timestamp analysis - files dated 3+ years away from the median of the scanned directory are treated as statistical outliers and add another 20 points.
Scoring
The final score is the sum of all detected signals. Three levels:
| Score | Level |
|---|---|
| < 50 | LOW |
| 50–119 | MEDIUM |
| ≥ 120 | HIGH |
No single signal is enough to reach HIGH on its own. If a file scores HIGH, it's the result of multiple overlapping indicators - missing signature, injection-related imports, high-entropy sections. That combination is exactly what real malware tends to look like.
Why It's Not an EDR Replacement
PERE is intentionally simple. It does one thing: quickly walk a directory and identify which files are worth a closer look. It doesn't perform dynamic analysis, doesn't monitor runtime behavior, and can't see into obfuscated code that only unpacks itself in memory. If a binary imports GetProcAddress and LoadLibraryA and resolves its injection APIs dynamically at runtime, PERE won't score it any higher than a legitimate loader.
That's not a flaw - it's the scope. If you suspect an attacker left a malicious binary somewhere inside a legitimate software installation, PERE will tell you in seconds which files in that directory are anomalies. What comes next is standard procedure: dynamic analysis, EDR telemetry, sandbox.
Usage
python main.py --path "C:\Program Files\Microsoft\Teams" --extensions exe,dll --timestamps --json --output findings.json
The flags are straightforward: --path sets the target directory, --extensions filters file types (default: exe,dll), --timestamps enables timestamp anomaly scoring, and --json saves results to a file.
Source code is available on GitHub.