Evaluate a host from its configuration
Read a host configuration snapshot and find the misconfigurations that let an attacker persist — the hardening review a sysadmin does.
web01 was compromised this morning. The incident is contained; now it is your call whether the host can safely return to production. You have a configuration snapshot. A hardening review is not just a checklist — some of what you find is ordinary weakness, and some is the attacker's fingerprints. Telling them apart is the job.
1 Guided walkthrough
Create a workspace and upload host-audit.txt — a snapshot of one server's configuration.
Ask for a hardening review.
Paste this into the assistantThis is a configuration snapshot of a Linux host. List every security misconfiguration you can find, rate each as low / medium / high risk, and give the fix for each.You should see: Root SSH login enabled, password auth on, firewall inactive, a world-writable db.php, and unpatched sudo/openssl CVEs — each with a remediation.
Then push it past "weak" to "breached".
Paste this into the assistantWhich findings here are not just weak configuration but actual evidence that this host is ALREADY compromised?You should see: The second UID 0 account (svc_backup) and the cron job pulling a script from 203.0.113.47 every 10 minutes.
If you teach to a standard, line it up.
Paste this into the assistantMap the misconfigurations you found to the general CIS Benchmark categories they violate (SSH hardening, host firewall, account management, patch management).You should see: A rough mapping you can check against a real CIS Benchmark — where it aligns, and where it is vague.
Check it against your own read. Did it miss anything real, or flag anything that is actually fine?
2 Decide the host's fate
No prompts given this time — you write them. Forming the right question is the skill. Work these on your own; compare with a neighbour if you can.
- Produce a remediation runbook: an ordered list of steps to safely bring this host back. Order matters — do you kill the malicious cron before or after rotating credentials, and why?
- Make the call: can this host be cleaned in place, or must it be rebuilt from known-good media? Write the justification — you will be asked to defend it.
- Draft the change-control ticket for your top three fixes: what changes, why, and the rollback if a change breaks something.
What to notice
- Root SSH login enabled, firewall off, a world-writable db.php, unpatched sudo/openssl CVEs — a stack of ordinary misconfigurations, each individually "small".
- Two findings are not misconfigurations but evidence of compromise: a second UID 0 account, and a cron job pulling a script from the attacker's IP every ten minutes.
- Telling "weak" apart from "already breached" is the judgment the AI can assist but should not make for you.
Think about it
- The assistant will happily hand you commands to "fix" the host. Would you paste them into a production shell as-is? What could go wrong?
- Which findings could a scanner catch automatically, and which needed a human to read as "compromise, not just weakness"?
Take it further — for fast finishers
- Ask the AI to map each finding to a specific CIS Benchmark control number, then spot-check two against the real benchmark. How accurate was it?