NexaCorp DFIR: INC-2026-001 - Kompromittierung der Linux-Infrastruktur

DFIR-Untersuchung und Detection Engineering zu einem simulierten Einbruch in die NexaCorp-Infrastruktur. Durchgeführt als viertägiges Einzelprojekt (BeCode Brussels Blue & Red Team Bootcamp, Mission 01). Das Ergebnis ist ein 54-seitiger Befundbericht (PDF) sowie 7 validierte Suricata-Regeln, die den erfassten Vorfall im PCAP-Replay erkennen.

Dieses Repository dokumentiert einen SOC-Analysten-Einsatz, der im Rahmen des BeCode Cybersecurity Bootcamps (Jahrgang 2025-2026) durchgeführt wurde. Es rekonstruiert einen vollständigen Einbruch anhand von Netzwerk- und Log-Beweisen und liefert anschließend einen validierten Satz von Suricata-Erkennungsregeln. Es ist der erste Vorfall in der NexaCorp-DFIR-Serie.

Inhalt

• Betriebshinweis
• Auf einen Blick
• Auftragskontext
• Zusammenfassung
• Zusammenfassung der Kill Chain
• So lesen Sie diesen Bericht
• Methodik
• Verwendete Werkzeuge
• Zusammenfassung der Befunde
• Detection Engineering
• Repository-Struktur
• Reproduzierbarkeit
• Bekannte Grenzen
• NexaCorp-DFIR-Serie
• Danksagungen
• Über
• Lizenz

Betriebshinweis

Dies ist ein Labor-Einsatz gegen fiktive Infrastruktur. NexaCorp ist ein fiktiver Kunde, der als Szenario für BeCode Brussels Mission 01 dient. Beim kompromittierten Host handelt es sich um eine Metasploitable-2-VM, die für Sicherheitsschulungen absichtlich verwundbar ist, und der Caldera-Sandcat-Implant gehört zum Labor, das dem Analysten vermittelt, wie der Beacon-Datenverkehr eines echten Angreifers aussieht. Es wurde keine reale Organisation, kein reales Netzwerk und kein realer Mensch angegriffen.

Alle in diesem Bericht veröffentlichten IP-Adressen, Hostnamen und Kompromissindikatoren (172.16.50.10, 192.168.10.10, 10.40.0.200, blue11, mesdec usw.) sind laboreigene Artefakte und keine reale Threat Intelligence. Führen Sie sie einem SIEM nicht als IOCs zu.

Veröffentlichung freigegeben durch den BeCode-Labortrainer (Thomas B.) am 17.05.2026. Die vollständige Vertraulichkeitserklärung befindet sich im Befundbericht (Abschnitt „Distribution and Classification“).

Auf einen Blick

Auftragskontext

Szenario (fiktiv). NexaCorp, ein mittelständischer Unternehmenskunde, kontaktierte das Blue Team von BeCode Corp, nachdem das interne Monitoring unerwarteten ausgehenden Datenverkehr von einem ihrer internen Linux-Server gemeldet hatte. Die Firewall protokollierte den Datenverkehr, löste jedoch keinen verwertbaren Alarm aus. Die Geschäftsleitung benötigte eine Bewertung, bevor sie über Offenlegung und behördliche Meldung entschied.

Auftrag. Untersuchen Sie das vermutete Vorfallfenster, charakterisieren Sie den Einstiegsweg und die Post-Exploitation-Aktivitäten des Angreifers, bewerten Sie, was der vorhandene Detection-Stack erkannt (und übersehen) hat, und liefern Sie einen priorisierten Sanierungsplan. Eine zweite Phase ergänzte das Detection Engineering: Erstellung einsatzbereiter Netzwerk-IDS-Regeln, die ein erneutes Auftreten in Echtzeit erkennen.

Vom Kunden erhaltenes Beweispaket.

Schulungskontext. Dieser Einsatz wurde im Rahmen des BeCode Brussels Blue & Red Team Bootcamps (November 2025 bis September 2026) als Mission 01 durchgeführt: eine Einzeluntersuchung mit festem Zeitrahmen, die ein reales DFIR-Beratungsprojekt simuliert. Die Laborinfrastruktur, die NexaCorp-Identität und die IOC-Werte sind bewusst fiktiv. Methodik, Werkzeuge und Berichtsformat folgen praxisüblichen Standards (NIST SP 800-61r2, SANS PICERL, MITRE ATT&CK).

Zusammenfassung

📄 Der vollständige 54-seitige Befundbericht ist das maßgebliche Ergebnis. PDF herunterladen (215 KB) oder Markdown-Quelle durchsuchen für grep/Zitierungen.

Am Abend des 09.05.2026 um 22:53 UTC kompromittierte ein externer Angreifer (172.16.50.10) einen internen NexaCorp-Server (192.168.10.10) durch Ausnutzung von CVE-2011-2523, der in vsftpd 2.3.4 vorhandenen Hintertür (ein Build, der seit Juli 2011 öffentlich als kompromittiert dokumentiert ist). Eine einzelne FTP-USER-Anfrage, die mit :) endete, löste eine unauthentifizierte Root-Bind-Shell auf TCP/6200 aus. Der Angreifer führte über eine 20-sekündige Sitzung 8 Reconnaissance-Befehle aus (keine Persistenz, keine Exfiltration, keine Seitwärtsbewegung über diesen Zugriffsvektor) und trennte die Verbindung.

Unabhängig davon wurde auf demselben Host ein bereits vorhandener MITRE-Caldera-„Sandcat“-Agent unter /opt/caldera/sandcat (root, als Daemon) gefunden, der während des gesamten erfassten Zeitfensters alle 40-50 Sekunden im Klartext-HTTP an 10.40.0.200:8888 Beacons sendete. Dabei handelt es sich um die ursprünglich vom Kunden gemeldete „ungewöhnliche ausgehende Verbindung“, die auf eine frühere Kompromittierung hindeutet, die nicht im Beweispaket enthalten ist (das Implantat war bereits im ersten PCAP-Frame aktiv).

Der bestehende Wazuh-SIEM hat 397 Ereignisse vom Zielhost aufgenommen, erzeugte jedoch nur 4 Alarme mit hoher Schwere (1,0 % der Gesamtzahl), die alle als generisches Brute-Force (MITRE T1110) eingestuft wurden. Keiner identifizierte den CVE-2011-2523-Exploit-Payload, die Bind-Shell auf TCP/6200 oder den Caldera-C2-Kanal: Das Exploit-Byte (USER baduser:)) wird von vsftpd selbst nie protokolliert, und der SIEM hatte keine Netzwerktelemetrie, um den Rest zu sehen. Die 7 in Phase 2 gelieferten Suricata-Regeln schließen alle drei Lücken.

Wichtigste IOCs (nur für das Labor – nicht in ein echtes SIEM einspeisen):

Zusammenfassung der Kill Chain

Der erfasste Vorfall besteht aus zwei unterschiedlichen Strängen, die aus dem PCAP rekonstruiert wurden:

1. Offengelegter Dienst: vsftpd 2.3.4, ein Build mit öffentlich dokumentierter Hintertür (CVE-2011-2523), war im internen Netz erreichbar (Befund I1).
2. Exploit: Eine einzelne FTP-USER-Anfrage, die mit :) endete, löste die Hintertür aus (Befund I3).
3. Root-Bind-Shell: Auf TCP/6200 öffnete sich eine unauthentifizierte Root-Shell; der Angreifer führte über eine 20-sekündige Sitzung 8 Reconnaissance-Befehle aus und trennte dann die Verbindung, ohne Persistenz oder Exfiltration über diesen Vektor (Befund I4).
4. Paralleler C2 (bereits vorhanden): Unabhängig davon sendete ein MITRE-Caldera-Sandcat-Implantat während des gesamten Zeitfensters bereits Beacons im Klartext-HTTP an 10.40.0.200:8888 – ein Hinweis auf eine frühere Kompromittierung, die nicht im Beweispaket enthalten ist (Befund I5).

So lesen Sie diesen Bericht

Das Repository ist so organisiert, dass Sie je nach Rolle in der passenden Tiefe einsteigen können:

Maßgebliches Ergebnis: das PDF in reports/. Die Markdown-Quelle enthält denselben Inhalt und wird im Repository für Durchsuchbarkeit und Versionskontrolle aufbewahrt.

Ermittlungsspur: notes/journal.md ist das Arbeitsnotizbuch des Analysten (getestete und widerlegte Hypothesen, Beweisbestand, Planstatus). Es ergänzt den formellen Bericht, indem es zeigt, wie die Schlussfolgerungen erreicht wurden – nicht nur die Schlussfolgerungen selbst.

Detection-Regelsatz: detection/lab.rules enthält die 7 Suricata-Regeln mit vollständiger Begründung je Keyword in Inline-Kommentaren. detection/README.md dokumentiert den Bereitstellungs- und Replay-Validierungsworkflow, mit dem bestätigt wurde, dass jede Regel auf den erfassten Vorfall anspricht.

Methodik

Der Einsatz folgt drei branchenüblichen Frameworks, die übereinandergelegt werden.

NIST SP 800-61r2: Computer Security Incident Handling Guide

Das 4-Phasen-Modell von NIST (Preparation, Detection & Analysis, Containment / Eradication / Recovery, Post-Incident Activity) liefert die übergeordnete Struktur. In diesem Einsatz entspricht Phase 1 des Ergebnisses NIST „Detection & Analysis“ (PCAP-Forensik, SIEM-Korrelation, Rekonstruktion der Angreifer-Timeline). Phase 2 entspricht dem NIST-„Lessons Learned“ und wird in präventive Kontrollen übersetzt (die 7 Suricata-Regeln und die priorisierte Empfehlungsliste in Berichtsabschnitt 7).

SANS PICERL: taktischer Untersuchungsablauf

PICERL (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned) ist der SANS Incident-Response-Prozess. Angewendet in diesem Einsatz:

MITRE ATT&CK: Zuordnung von Techniken

Jeder Befund ist einer oder mehreren MITRE-ATT&CK-Techniken zugeordnet, damit der Kunde diesen Vorfall mit seinem bestehenden Bedrohungsmodell abgleichen kann. 14 verschiedene Techniken werden über die 10 Befunde referenziert:

• Reconnaissance: T1595.002, T1592.002, T1589
• Initial Access: T1190 (Exploit Public-Facing Application via CVE-2011-2523)
• Execution: T1059.004 (Unix Shell)
• Discovery: T1033, T1082, T1087.001, T1083, T1016, T1049, T1046
• Credential Access: T1110 (Brute Force)
• Command and Control: T1071.001, T1102 (Caldera-Sandcat-Beacon)
• Privilege Escalation: T1078.003, T1548.003 (vermutete sudo-Aktivität)

Die vollständige Technik-Tabelle je Befund finden Sie in Berichtsabschnitt 4 (IOCs) und die Detailanalysen je Befund in den Abschnitten 3 und 5.

Reproduzierbarkeit

Jede Aussage im Bericht ist auf ein Artefakt im Beweispaket zurückführbar, einschließlich des exakten tshark-Filters, der Wazuh-Abfrage oder des Suricata-Replay-Befehls, der zur Reproduktion erforderlich ist. Siehe Anhang A (Reproduktionsbefehle) im Bericht und den Abschnitt Reproduzierbarkeit unten für einen Schnellstart.

Verwendete Werkzeuge

Netzwerkforensik

• tshark: Wireshark-CLI für PCAP-Triage, TCP-Stream-Rekonstruktion (-z follow,tcp,ascii), Protokollfilterung und Feldextraktion
• tcpreplay und tcprewrite: PCAP-Replay auf eine Live-Überwachungsschnittstelle zur Validierung der Suricata-Regeln, mit MTU-Anpassung für das Labor-ens19 (1450 Byte)
• Base64-Decoder: Rekonstruktion der Caldera-Sandcat-C2-Payloads (Beacon-Body und Operator-Antwort)

Netzwerk-IDS / Detection Engineering

• Suricata 6.0.4 (afpacket-Modus, Single-Thread, Hyperscan im Labor deaktiviert): Die 7 Regeln dieses Ergebnisses wurden erstellt, validiert und getunt.
• suricata -T: Konfigurations- und Regelvalidierung während Bereitstellung und Tuning
• kill -USR2 $(pgrep suricata): Live-Neuladen der Regeln während des iterativen Tunings

SIEM- und Host-Telemetrie

• Wazuh (Manager + Dashboard): Ereigniskorrelation, Schweregrad-Verteilungsanalyse, Regelsuche (rule.id 11452, 5551 usw.), CSV-Export von 397 Ereignissen
• Standard-Linux-Textwerkzeuge (grep, awk, jq): Log-Mining und JSON-Parsing

Kontext der Gegner-Emulation (referenziert, nicht betrieben)

• MITRE Caldera (Sandcat-Agent): auf dem Zielhost vorhanden als das simulierte, bereits vorhandene C2-Implantat, das charakterisiert wird

Referenz-Frameworks

• NIST SP 800-61r2: Computer Security Incident Handling Guide
• SANS PICERL: taktischer Untersuchungsablauf
• MITRE ATT&CK: Technik-Zuordnung
• CVE-2011-2523 advisory: vsftpd-2.3.4-Hintertür-Referenz

Zusammenfassung der Befunde

Die 10 Befunde (I1 bis I10) sind im Befundbericht ausführlich dokumentiert. Jeder Eintrag enthält Beweise, Reproduktionsbefehle, MITRE-ATT&CK-Zuordnung und Sanierungsempfehlungen.

Schweregradverteilung: 3 KRITISCH / 3 HOCH / 2 MITTEL / 2 NIEDRIG

Empfohlene Lesereihenfolge: Beginnen Sie mit I1 (der verwundbare Dienst), dann I3 und I4 (die eigentliche Exploit-Kette), dann I5 (das parallele, unabhängige C2-Implantat). I2 und I6 liefern den Aufklärungskontext. I7 bis I10 sind die Befunde zur Defensivhaltung (was das Monitoring erkannt hat im Vergleich zu dem, was es übersehen hat).

Detection Engineering

In Phase 2 des Engagements wurden 7 Suricata-Regeln (SID 9000001 bis 9000007) erstellt, die den erfassten Vorfall aus drei Blickwinkeln abdecken: die Exploit-Signatur, die Post-Exploit-Shell und den parallelen C2-Kanal. Jede Regel wurde durch Offline-PCAP-Replay gegen eine Suricata-6.0.4-Instanz auf der SOC-Arbeitsstation validiert.

Die 7 Regeln

Validierungsübersicht

Die Spanne von 40 zu 314 spiegelt die bewusste Drosselung der Regeln 9000003, 9000004, 9000005 und 9000006 wider, um SOC-Analysten eine saubere operative Sicht zu geben und gleichzeitig den rohen Alarmstrom in eve.json für forensische Detailanalysen zu erhalten.

Bemerkenswerte Designentscheidungen

Vier iterative Korrekturen während der Bereitstellung sind in detection/README.md dokumentiert. Wichtigste Erkenntnisse:1. Portunabhängige HTTP-Erkennung. Die Regeln 9000004 und 9000005 (Caldera) wurden ursprünglich mit den Schlüsselwörtern alert http und http.uri geschrieben, die Suricatas HTTP-Parser nur auf Port 80 ansprechen. Caldera C2 läuft auf Port 8888, daher wurde der Parser umgangen und die Regeln feuerten nie. Fix: Umschreiben im TCP+Content-Modus (alert tcp ... content:"POST /beacon"; content:"Go-http-client/1.1";), der rohe HTTP-Bytes unabhängig vom Port abgleicht. 2. flow:established ist bei der PCAP-Wiedergabe unzuverlässig. Ein erfasster TCP-Handshake außerhalb des Wiedergabefensters hinterlässt die Flow-State-Maschine in einem unbestimmten Zustand. Das Entfernen von flow:established aus den Caldera-Regeln sorgt dafür, dass sie sowohl im Live- als auch im Wiedergabemodus greifen. 3. Explizite Flow-Richtung für reine SYN-Regeln. Regel 9000003 (Port 6200) löste SC_WARN_POOR_RULE: SYN-only ... w/o direction specified aus. Behoben durch Hinzufügen von flow:to_server,not_established. 4. HOME_NET vs. in reinen RFC1918-Laboren. Wenn Angreifer, Ziel und C2 alle im privaten Adressraum liegen, wird leer und Regeln der Form greifen nie. Labor-Fix: in beiden Feldern verwenden. Produktions-Fix: auf das geschützte Segment beschränken.

Hinweise zu Fehlalarmen

Die regelweise Fehlalarm-Analyse ist in Berichtsabschnitt 8.5 dokumentiert. Die meisten Regeln tragen in einer gut abgegrenzten Umgebung ein vernachlässigbares Risiko; die Regeln 9000005 (aiohttp-Server-Header) und 9000006 (curl/Wget auf Admin-Pfaden) erfordern eine Feinabstimmung, wenn unbedenkliche interne Python-Dienste oder administrative Skripte vorhanden sind.

Repository-Struktur```text

NexaCorp-DFIR-INC-2026-001/ ├── README.md (this file) ├── LICENSE (MIT) ├── .gitignore ├── .github/ │ └── workflows/ │ └── ci.yml markdownlint + typography + Suricata rule check ├── reports/ │ ├── INC-2026-001_Findings_Report.pdf canonical 54-page deliverable │ └── INC-2026-001_Findings_Report.md same content, Markdown source ├── detection/ │ ├── lab.rules 7 Suricata rules (SID 9000001-9000007) │ └── README.md deploy + replay validation workflow ├── evidence-summary/ │ └── ioc-summary.md indicators of compromise (SIEM-ingestible) ├── methodology/ │ ├── attack-timeline.md incident timeline (UTC) │ └── attck-mapping.md MITRE ATT&CK mapping table └── notes/ └── journal.md analyst investigation journal (hypotheses, plan, IOCs, timeline)

**Dateiklassifizierungen:**

| Pfad | Rolle | Zielgruppe |
|---|---|---|
| `reports/*.pdf` | Kanonisches Ergebnisdokument, formeller Bericht | Kunde, Personalvermittler, Auditor |
| `reports/*.md` | Gleicher Inhalt, grep-freundliche Quelle | Alle, die zitieren oder diffen |
| `detection/lab.rules` | Produktionsreife Suricata-Regelsammlung | SOC / Detection Engineer |
| `detection/README.md` | Leitfaden für Bereitstellung + Replay-Validierung | Einarbeitung für Detection Engineers |
| `evidence-summary/ioc-summary.md` | Kompromissindikatoren, nach Kategorie | SOC / Threat Hunting |
| `methodology/attack-timeline.md` | Vorfall-Zeitachse (UTC) | DFIR-Praktiker |
| `methodology/attck-mapping.md` | MITRE ATT&CK-Zuordnungstabelle | DFIR / Detection Engineer |
| `notes/journal.md` | Arbeitsnotizbuch der Untersuchung | DFIR-Praktiker, der die Methode studiert |
| `.github/workflows/ci.yml` | Automatisierte markdownlint-, Typografie- und Suricata-Regelvalidierung (`suricata -T`, läuft, wenn `detection/*.rules` vorhanden ist) bei Push | CI |

## Reproduzierbarkeit

Jede Aussage im Ergebnisbericht ist auf ein Artefakt im Beweispaket zurückführbar. Die PCAP selbst wird nicht weitergegeben (Eigentum des BeCode-Labors), aber die Befehle und Abfragen sind dokumentiert, sodass jeder mit einer eigenen Kopie die Analyse reproduzieren kann.

### Zentrale Ergebnisse reproduzieren (PCAP-Analyse)

Erfordert `tshark` (Wireshark-CLI) und die originale `attack.pcap`:```bash
# 1. PCAP overview
tshark -r attack.pcap -q -z io,stat,0

# 2. TCP conversations (reveals attacker, target, C2)
tshark -r attack.pcap -q -z conv,tcp | head -30

# 3. Confirm vsftpd 2.3.4 banner exposure (Finding I1)
tshark -r attack.pcap -Y "ftp && ip.src == 192.168.10.10" \
  -T fields -e frame.time -e ftp.response.code -e ftp.response.arg | head -5

# 4. Find the CVE-2011-2523 exploit payload (Finding I3)
tshark -r attack.pcap -Y 'ftp.request.command == "USER"' \
  -T fields -e frame.time -e ftp.request.arg

# 5. Reconstruct the root shell session on TCP/6200 (Finding I4)
tshark -r attack.pcap -q -z follow,tcp,ascii,70

# 6. Reconstruct the Caldera C2 beacon (Finding I5)
tshark -r attack.pcap -q -z follow,tcp,ascii,6 | head -50

Regelvalidierung reproduzieren (Suricata-Replay)

Erfordert Suricata 6.0.x, tcpreplay und eine überwachte Schnittstelle (ens19 im Labor; durch Ihre eigene ersetzen):```bash

1. Install the ruleset

sudo cp detection/lab.rules /etc/suricata/rules/learner/lab.rules

2. Hot-reload Suricata without restart

sudo kill -USR2 $(pgrep -f suricata) sleep 5

3. Clear the alert log for a clean baseline

sudo truncate -s 0 /var/log/suricata/fast.log

4. Replay the PCAP at top speed

sudo tcpreplay --intf1=ens19 --topspeed attack_mtu.pcap

5. Count alerts per rule (expect 7 distinct SIDs)

sudo grep -oE '[1:[0-9]+:' /var/log/suricata/fast.log | sort | uniq -c | sort -rn

Erwartete Ausgabe (nach einem vollständigen Replay):```text
     30 [1:9000002:    (vsftpd banner repeated per session)
      3 [1:9000007:    (FTP USER enumeration threshold)
      3 [1:9000006:    (HTTP admin path enumeration)
      1 [1:9000005:    (Caldera C2 response)
      1 [1:9000004:    (Caldera Sandcat beacon, throttled)
      1 [1:9000003:    (Backdoor port 6200 SYN)
      1 [1:9000001:    (vsftpd USER smiley exploit)

7/7 Regeln lösen korrekt aus. Das vollständige Beweispaket (fast.log, eve.json, Throttling-Konfiguration, Suricata-Versions-Snapshot) ist in Anhang E des Findings-Berichts aufgeführt.

Bekannte Einschränkungen

• Das Beweispaket beginnt mitten im Vorfall. Der PCAP beginnt am 2026-05-09 um 20:08 UTC, aber der Caldera-Sandcat-Agent sendet in Frame 1 bereits aktiv Beacons. Die anfängliche Kompromittierung, die das Implantat installierte, ereignete sich früher und ist in den Daten nicht enthalten. Schlussfolgerungen über Aktivitäten vor dem Implantat sind aus Wazuh-full_log-Feldern extrapoliert, nicht direkt beobachtet.
• Host-Audit-Logs überlappen sich nicht mit dem Angriffszeitraum. Lokale auth.log- und syslog-Dateien beginnen ~5 Stunden nach dem Ende des PCAP, wobei der erste Eintrag syslogd restart ist (wahrscheinlich VM-Neustart). Es wurden keine rotierten Logdateien bereitgestellt. Dies ist als Finding I10 dokumentiert.
• Der Umfang war Forensik + Detection Engineering, nicht Live-Response. Containment, Eradication, forensische Sicherung (Speicherabbild, Festplattenabbild) und Persistenz-Enumeration sind im Bericht als P0-Empfehlungen dokumentiert, wurden aber nicht ausgeführt: das Engagement hatte keinen Live-Host-Zugriff. Ein Folge-Engagement wäre erforderlich, um diese Punkte abzuschließen.
• Die 7 Suricata-Regeln erkennen genau diese Vorfall-Signatur. Ein versierter Angreifer kann sie umgehen, indem er das Exploit-Byte-Muster ändert (alternative Null-Byte-Terminatoren beim USER-Argument), Caldera mit einem anderen User-Agent neu kompiliert oder das C2 auf verschlüsseltes HTTPS verlagert (TLS-Metadaten-Analyse wie JA3/JA4 wäre der Fallback). Die Regeln sind für das erfasste Bedrohungsszenario geeignet; eine längerfristige Erkennungsstrategie sollte verhaltensbasierte und metadatenbasierte Erkennungen ergänzen.
• Wazuh-Ingestion-Lücke während der Untersuchung. Die SIEM-Log-Ingestion-Pipeline war vorübergehend bis 2026-05-11 11:39 UTC nicht verfügbar (mitten in der Untersuchung, vom Lab-Coach wiederhergestellt). Die 4 Alarme mit hohem Schweregrad erscheinen daher im Dashboard mit Ingestion-Zeitstempeln (11. Mai 13:17-13:28) statt mit den tatsächlichen Vorfallszeitstempeln (9. Mai 21:00-22:53), was die scheinbare zeitliche Abfolge der Korrelationsereignisse verzerrt.
• In einer echten NexaCorp-Bereitstellung muss auf das geschützte Segment allein eingegrenzt werden (z. B. ), damit den Angreiferbereich korrekt abdeckt. Die gelieferten Regeln sind auf das Labor abgestimmt und benötigen vor dem Produktiveinsatz genau diese eine Konfigurationsänderung.

NexaCorp-DFIR-Serie

• INC-2026-001: dieses Repository
• INC-2026-002: Privilege Escalation und Persistenz (Tor-SSH, SUID, Backdoor-Konto)
• INC-2026-003: vorfallübergreifende Bewertung für Monat 1
• INC-2026-004: SQL-Injection (Webportal)
• INC-2026-005: OS-Command-Injection und Web-Shell (Webportal)
• INC-2026-006: gespeichertes XSS und Session-Hijacking (Webportal)
• INC-2026-007: IDOR und defekte Zugriffskontrolle (NexaPortal); Abschlussprojekt von Monat 2
• INC-2026-008: AD-Reconnaissance und Kerberoasting (erster Vorfall von Monat 3)

Danksagungen

• Thomas B. (BeCode-Lab-Coach): Szenariodesign, Behebung der Wazuh-Ingestion während der laufenden Untersuchung, Veröffentlichungsgenehmigung für die Portfolio-Nutzung.
• MITRE für das Caldera-Framework, das das simulierte C2-Implantat ermöglicht hat, und für die ATT&CK-Wissensdatenbank, die zur Zuordnung jedes Findings verwendet wurde.
• Suricata-Projekt für die Engine, die die 7 Regeln in unter 30 Minuten einsatzbereit machte.

Über dieses Projekt

Solo-DFIR-Engagement, durchgeführt während des BeCode Brussels Blue-&-Red-Team-Bootcamps (November 2025 bis September 2026), Mission 01, am 2026-05-15.

Autor: Johan-Emmanuel Hatchi (LinkedIn).

Offen für Praktikumsmöglichkeiten im Bereich Cybersicherheit ab September 2026 in Belgien. Auf der Suche nach SOC-/DFIR-/Detection-Engineering-Rollen, in denen diese Art von End-to-End-Untersuchungsarbeit (PCAP-Forensik, SIEM-Korrelation, IDS-Regelerstellung, formale Kundenberichterstattung) zum Aufgabenbereich gehört.

Lizenz

MIT, 2026 Johan-Emmanuel Hatchi.

Die Suricata-Regeln in detection/lab.rules und der Berichtstext sind beide unter derselben MIT-Lizenz veröffentlicht: frei kopierbar, anpassbar und mit Namensnennung erneut einsetzbar. Der PCAP, die Laborinfrastruktur und die Engagement-Briefings bleiben Eigentum von BeCode Brussels und werden nicht weitergegeben.