incident-response-trainer
Incident response training · Rule-based scoring
DemoCatalogDiagnosticHistoryDashboardCoach Notes
Attempt report

4.8 GB outbound from production web server to low-reputation IP overnight

CybersecuritySuspicious OutboundDifficulty · Hard

Attempt 1 of 1 · cmp554qqd000157zs73kgrryr

← All attempts↻ Retry this scenarioNew scenario
Progress vs previous attempt

This is your first attempt for this scenario. Retry the scenario to generate a side-by-side comparison against your previous response.

Progression · Not enough data yet

Not enough data yet · Cybersecurity

You have 1 of 3 attempts at Hard. Complete 2 more to unlock a recommendation. (Track: Cybersecurity)

Track · Cybersecurity
Hard

Sample size: 1

Submission · what was sent and how you responded
Suspicious OutboundDifficulty · hardCritical asset
[ALERT] Anomalous outbound traffic from WEB-PROD-02
From
Network Detection <ndr@acme-corp.local>
To
soc@acme-corp.com
Date
2026-04-19 06:15 UTC
NDR flagged sustained outbound traffic from WEB-PROD-02 (10.12.44.18) to 45.61.152.77 (AS209588, hosting provider, non-business country). Volume: 4.8 GB total between 02:00 and 04:00 UTC. Protocol: TLS over TCP/443 (SNI: cdn-static-img[.]info — certificate self-signed, CN=localhost). Host metrics: CPU 94% peak during the window, unusual for this host (baseline ~25%). WEB-PROD-02 serves the customer portal (prod.acme-corp.com) and reads from DB-PROD-01 which stores customer PII. No scheduled backup, patch, or deployment job matches this window. Please triage and respond. — NDR / NetSec
Evidence
Flow summary + process snapshot
# NetFlow summary (WEB-PROD-02 → 45.61.152.77)
02:01:44  start   bytes_out=12KB
02:01:46  ...     bytes_out growing at ~670 KB/s
03:59:22  end     total bytes_out=4.81 GB  bytes_in=3.2 MB

# Process snapshot captured 04:05 UTC by EDR
PID   USER    %CPU  CMD
 811  www     94.0  /tmp/.cache/sysmond -c /tmp/.cache/.conf
 812  www      2.1  nginx: worker process
 190  root     0.8  /usr/sbin/sshd

/tmp/.cache/sysmond — not signed, SHA256 8f1a...c4e2 — VirusTotal: 44/72 (linux.backdoor.*).
Persistence: cron entry "*/5 * * * * /tmp/.cache/sysmond" under www user.

# DNS
cdn-static-img[.]info -> 45.61.152.77 (registered 11 days ago, privacy-protected registrar)
Affected asset
Name
WEB-PROD-02 (10.12.44.18)
Type
Production Linux web server (customer portal front-end)
Owner
Platform Team · SRE
Level
Critical
Your submitted response
2 words
test 2
Final score
0/ 100
2 words submitted
Verdict · Fail

The response is missing several critical incident response steps. Review the rubric and try again. Score: 0/100. Strongest area: Clarity & structure (3%). Weakest area: Attack understanding (0%) — expand this next time. The response is quite short; aim for a more structured, step-by-step plan.

Category breakdown

Where points came from

coverage × weight = points
  • Attack understanding0/4 · 0.0 / 15
  • Asset impact0/3 · 0.0 / 10
  • Prioritization0/2 · 0.0 / 10
  • Containment0/5 · 0.0 / 20
  • Investigation0/6 · 0.0 / 15
  • Recovery0/4 · 0.0 / 10
  • Evidence preservation0/4 · 0.0 / 10
  • Clarity & structure0/2 · 0.3 / 10

Strengths

No category reached 70% coverage.

Missing / weak

  • Attack understanding
  • Asset impact
  • Prioritization
  • Containment
  • Investigation
  • Recovery
  • Evidence preservation
  • Clarity & structure

Dangerous actions detected

None detected in your response.

Learning · Coaching

Learn from this attempt

Post-submission coaching for this scenario. Score and verdict are unchanged — these notes are for your next attempt.

Why points were deducted

  • Containment0% coverage

    Pull from LB + isolate + block egress + kill process + rotate every secret the host touched; any one of these alone leaves the attacker live or the credentials still good.

  • Attack understanding0% coverage

    Name the chain: Linux backdoor (`sysmond`) on a production web server with cron persistence beaconing C2 and exfiltrating data — not just `unusual outbound`.

  • Investigation0% coverage

    Capture RAM before reboot, hash + pivot the binary, reconstruct the 02:00–04:00 timeline, and answer the patient-zero question — do not stop at `we found the binary`.

Model answer outline

From: Incident Response Lead (SOC on-call)To: IT Leadership · Affected Asset Owner · On-call SOCSubject: [SEV-1][INC-CYB-HEE21] 4.8 GB outbound from production web server to low-reputation IP overnight — status update
Incident · INC-CYB-HEE21 · SEV-1 / P1Status · Investigating — containment in progressCybersecurity · Suspicious Outbound · HardWEB-PROD-02 (10.12.44.18) · Critical criticalityDetected ~ 2026-04-19 06:15 UTC
Situation & summary

WEB-PROD-02 (customer portal front-end, talks to DB-PROD-01 with customer PII) shipped 4.8 GB outbound to 45.61.152.77 between 02:00 and 04:00 UTC over self-signed TLS to cdn-static-img[.]info (11-day-old domain). EDR captured `/tmp/.cache/sysmond` running as `www` at 94% CPU, with a `*/5 * * * *` cron persistence under that user — VirusTotal: 44/72 Linux backdoor. This is a confirmed live exfiltration of production data, not a noisy alert.

Severity & priority

Rated SEV-1 / P1. Treat as a P1 confirmed live exfil from a production system that talks to customer PII — not a CPU / utilization alert.

Prioritization & impact
  • Treat as a P1 confirmed live exfil from a production system that talks to customer PII — not a CPU / utilization alert.
  • Sequence containment before forensics, but capture volatile state before powering off — the order matters.
  • Loop in CISO / IR commander, Legal / Privacy (because of the DB-PROD-01 PII downstream), and SRE on-call.
Containment (actions taken / in progress)
  • Pull WEB-PROD-02 from the load balancer, network-isolate it, and block 45.61.152.77 + cdn-static-img[.]info at egress.
  • Kill PID 811 (`sysmond`) and remove the `*/5 * * * *` cron entry under `www`; do not delete the binary before hashing it.
  • Treat any service / DB credential the host had (DB-PROD-01 connection, OAuth client secrets, S3 creds) as compromised — rotate before unisolation.
Investigation (in progress)
  • Capture RAM / volatile state (LiME / AVML or equivalent) before any reboot — process tree, network state, mounted FDs.
  • Hash `/tmp/.cache/sysmond` (sha256 8f1a..c4e2), pull strings, and pivot on every host with the same hash, persistence path, or beacon to 45.61.152.77.
  • Reconstruct the exfil window (02:01:44 → 03:59:22) from NetFlow + proxy + EDR; correlate with what data WEB-PROD-02 fetched from DB-PROD-01 in that window.
  • Identify initial access (recent web vulns, exposed admin endpoint, supply-chain dep, leaked SSH key) — the patient-zero question matters more than the binary.
Recovery & next steps
  • Rebuild WEB-PROD-02 from a clean image on a verified golden tag — do not `clean` an active backdoor in place.
  • Rotate all secrets the host touched (DB credentials, S3 / object storage keys, app signing keys, internal certs).
  • Patch / harden the initial-access vector once it is identified, and review the rest of the production fleet for the same exposure.
Evidence preservation
  • Capture memory image, full disk image, and the malware binary (with sha256 8f1a..c4e2) before reimage.
  • Preserve EDR telemetry, NetFlow for the exfil window, web access logs, and the cron / systemd persistence artifacts.
  • Record DNS resolutions for cdn-static-img[.]info and the threat-intel context for 45.61.152.77.
Stakeholder communication
  • Brief CISO / IR commander immediately with a tight timeline and the customer-data exposure question front-and-center.
  • Engage Legal / Privacy because DB-PROD-01 holds customer PII; let them decide notification thresholds.
  • Coordinate SRE for graceful traffic drain and customer-portal failover; keep external comms tight while scope is unconfirmed.
Do NOT
  • Do not power off the host before memory capture — you destroy the volatile evidence that names the operator.
  • Do not reimage / wipe before forensic image and hash collection.
  • Do not delete `/tmp/.cache/sysmond` before hashing it.
  • Do not pay or contact the operator if a ransom note appears later.

Dangerous actions to avoid

  • Do not power off the host before memory capture — you destroy the volatile evidence that names the operator.
  • Do not reimage / wipe before forensic image and hash collection.
  • Do not delete `/tmp/.cache/sysmond` before hashing it.
  • Do not pay or contact the operator if a ransom note appears later.

How to improve next time

  • On a Linux server compromise, capture RAM before you touch the host — you do not get the volatile state back after reboot.
  • Always rotate every secret the host touched: keys leak through compromised hosts faster than the host gets cleaned.
  • Beaconing to a domain younger than the host's last patch cycle is a strong signal — pivot on the domain age in your hunt, not just the IP.
  • Patient-zero (initial access) is the most important question; the binary tells you what the operator wanted, but not how they got in.
  • Reimage from a verified golden tag, not from `the same image with the bad cron removed` — backdoors stash redundancy.
AI · Supplemental review

Request an AI review of this attempt

This AI review is supplemental coaching. It does not change your official score or verdict. The review is only kept for this page session and is not saved permanently.

Review language
AI Tutor · Explains your result

AI Tutor

This tutor explains your result. It does not change your score. Pick a question to see how the deterministic grading reached your verdict and where to focus next.

Generated deterministically from your graded result — no AI model was called.

Why did I get this score?

Your verdict was Fail at 0/100. That total is the sum of deterministic rubric points across 8 categories — each scores how much of its expected, ordered steps your answer covered, not an opinion about your writing. Your strongest coverage was Clarity & structure (3%). Points were held back mostly in Containment (0%), Attack understanding (0%), Investigation (0%).

Rubric focuscontainmentattackUnderstandinginvestigation
Next study step

Re-read the containment expectations for this scenario and list the concrete steps you missed.

This tutor explains your existing result. It does not change your score, verdict, or grade. Generated deterministically from your graded result — no AI model was called.

What should I improve first?

Focus on Containment first — it is your weakest rubric area at 0% coverage and carries weight 20. For this scenario: Pull from LB + isolate + block egress + kill process + rotate every secret the host touched; any one of these alone leaves the attacker live or the credentials still good.

Rubric focuscontainment
Next study step

Rewrite your containment section as a short numbered checklist before your next attempt.

This tutor explains your existing result. It does not change your score, verdict, or grade. Generated deterministically from your graded result — no AI model was called.

How does my answer compare to the model answer outline?

Compared with the model answer outline, the most useful sections to study are the ones matching your weak areas. Re-read the outline's containment, attack understanding, investigation guidance and check which listed points you did not cover. The outline is a high-level checklist of expected points — use it to find gaps, not to copy a finished answer.

Rubric focuscontainmentattackUnderstandinginvestigation
Next study step

Pick one model-answer section you missed and add its key points to your next response in your own words.

This tutor explains your existing result. It does not change your score, verdict, or grade. Generated deterministically from your graded result — no AI model was called.

Which rubric area mattered most here?

Containment mattered most here: it carries the highest rubric weight (20), so coverage there moves your score the most. You covered 0% of it this time, worth 0 points.

Rubric focuscontainment
Next study step

Prioritise the highest-weight categories first; make sure containment is fully addressed before lower-weight ones.

This tutor explains your existing result. It does not change your score, verdict, or grade. Generated deterministically from your graded result — no AI model was called.

What should I study next?

Based on this attempt, study containment, attack understanding, investigation next. Coaching tip for this scenario: On a Linux server compromise, capture RAM before you touch the host — you do not get the volatile state back after reboot.

Rubric focuscontainmentattackUnderstandinginvestigation
Next study step

On a Linux server compromise, capture RAM before you touch the host — you do not get the volatile state back after reboot.

This tutor explains your existing result. It does not change your score, verdict, or grade. Generated deterministically from your graded result — no AI model was called.

Coach Notes

Open full notebook →

Save study notes for this attempt. They also collect in your mistake notebook.

Loading notes…