Simulator

Simulator

prohori simulate writes realistic attacks as log files, so you can try Prohori without real logs and see how well its rules work.

Nothing is attacked and nothing is sent anywhere. The simulator only writes files, every IP address comes from the ranges reserved for documentation, and every account is made up.

uv run prohori simulate --list                                  # scenarios and parameters
uv run prohori simulate account-takeover --seed 1 --out out/    # write one
uv run prohori triage out/account-takeover.jsonl -o triage/     # and investigate it
uv run prohori simulate ssh-bruteforce --out out/ --variant heldout
uv run prohori simulate web-scanning --out out/ --set rate=10 --set attempts=300

The same seed always gives exactly the same files.

Scenarios

Scenario	Log	What happens
ssh-bruteforce	auth.log	Password guessing against root and common user names
password-spraying	app JSON	One password tried against many accounts
credential-stuffing	app JSON	Stolen logins replayed; a few still work
token-reuse	app JSON	Stolen session tokens replayed
account-takeover	app JSON	One account's password guessed, then 2FA disabled and the payout number changed
web-scanning	access log	A scan for admin tools, backups and leaked files
injection	access log	SQL injection, cross-site scripting and path traversal attempts
admin-misuse	app JSON	A hijacked admin session at night grants admin rights to another account

Each attack is hidden in normal activity: staff and customers signing in, mistyped passwords, many customers behind one office network, a search-engine crawler, owners changing their own settings, and planned admin work. These are the cases that cause false alarms.

Two versions of each attack

• default: the attack as the rules were designed to catch it.
• heldout: the same attack done the way a careful attacker would: slower, from more addresses, with a normal browser's name, disguised, or at a different hour.

What you get

--out DIR receives the log, a labels file saying for every line whether it is part of the attack, and manifest.json with the settings, the parser to use (and the year for auth.log), file fingerprints and the rules expected to catch each attack.

How well the rules work

scripts/evaluate_rules.py runs every scenario five times in both versions and scores the alerts against the labels. All 40 default attacks are caught; 35 of 40 held-out attacks are caught by at least one expected rule. The misses (slow guessing, credential stuffing from 30 addresses, a disguised scanner, admin activity at 21:30) and the per-rule precision and recall are in docs/SIMULATOR.md.

These are synthetic results, and the same person wrote the rules and the attacks; test the rules on your own logs before relying on them.