akuma0x1.world (home)

Hybrid SOC simulation: XDR and automation

A hybrid on-premises and Google Cloud security-monitoring lab built on limited hardware. Firewall logs from OPNsense and Google Cloud are centralized in Wazuh, 15+ custom detection rules are mapped to MITRE ATT&CK, and n8n SOAR automates the incident-response workflow.

  • Documented
  • Updated
Type
Lab project
Environment
Hybrid: on-prem lab + Google Cloud
Scope
Authorized lab only; simulated attacks
Key result
15+ custom ATT&CK-mapped detection rules
Stack
Wazuh, OPNsense, GCP firewall logs, n8n

Problem

SOC work happens across layers. Firewalls at the network edge and cloud workloads all produce telemetry, and an analyst needs it in one place, turned into alerts that mean something, with a repeatable response. I wanted a single environment where I could practice that whole chain end to end, from collecting logs to detecting and then responding, across both on-premises and cloud infrastructure.

The constraint was hardware: the whole environment had to run on limited resources, so every component had to earn its place.

Architecture & approach

Hybrid SOC lab architecture On the on-prem side, simulated attacks target an internal lab segment behind an OPNsense firewall that handles rules, NAT and traffic control. OPNsense firewall logs and Google Cloud firewall logs both flow into Wazuh SIEM/XDR, which runs 15+ custom MITRE ATT&CK-mapped rules. n8n SOAR automates the incident-response workflows. on-prem lab Attack simulation brute-force · lateral movement phishing Internal segment lab hosts OPNsense firewall rules · NAT · traffic control google cloud Google Cloud firewall cloud firewall logs Wazuh SIEM/XDR collect · analyze · 15+ ATT&CK rules n8n SOAR incident-response workflows firewall logs IR workflows
simplified lab topology. Logical view only, no real addressing.

The design follows the path a real alert takes:

  1. Segment and control the network. OPNsense sits between the internal and external segments and enforces firewall rules, NAT and traffic controls.
  2. Collect from both worlds. OPNsense firewall logs and Google Cloud firewall logs are shipped into one SIEM, so on-prem and cloud activity can be seen together.
  3. Detect with intent. Custom Wazuh rules, each mapped to a MITRE ATT&CK technique, turn raw events into alerts that state what an attacker is attempting.
  4. Respond consistently. n8n SOAR workflows automate the incident-response steps.
  5. Prove it. Connectivity, firewall controls and detection logic are tested against simulated attack scenarios in the authorized lab.

What I did

  • Built a hybrid on-premises and cloud network and security-monitoring environment on limited hardware.
  • Deployed Wazuh SIEM/XDR for centralized log collection, monitoring and event analysis.
  • Configured OPNsense firewall rules, NAT, traffic controls and connectivity between internal and external network segments.
  • Integrated OPNsense firewall logs and Google Cloud firewall logs into the SIEM.
  • Developed and validated 15+ custom MITRE ATT&CK-mapped detection rules.
  • Automated incident-response workflows using n8n SOAR.
  • Tested connectivity, firewall controls and detection logic against simulated brute-force, lateral-movement and phishing scenarios in an authorized lab environment.

Tools

Tools used and their role in the lab
ToolRole in the lab
Wazuh SIEM/XDRCentralized log collection, monitoring, event analysis, custom detection rules
OPNsenseFirewall rules, NAT, traffic controls, internal/external segmentation; log source
Google CloudCloud firewall logs as a second log source alongside on-prem
n8n SOARAutomated incident-response workflows
MITRE ATT&CKFramework every custom rule is mapped to

Result

15+ custom MITRE ATT&CK-mapped detection rules, developed and validated against simulated brute-force, lateral-movement and phishing scenarios, with on-prem and cloud firewall telemetry centralized in a single Wazuh SIEM and incident response automated through n8n.

Scenarios tested

Simulated scenarios and the MITRE ATT&CK entries they relate to
ScenarioATT&CK reference
Brute forceT1110 Brute Force (Credential Access)
Lateral movementTA0008 Lateral Movement (tactic)
PhishingT1566 Phishing (Initial Access)

Lessons learned

  • A rule isn't done until it has been tested. Pairing each detection with a simulated scenario showed whether the rule fired, and whether it fired on things it shouldn't.
  • Log integration is network work. Getting firewall and cloud logs into the SIEM depended on the same fundamentals as any connectivity problem: segments, NAT and firewall policy.
  • Mapping to ATT&CK changes the conversation. An alert that names the technique is faster to triage and easier to explain than one that only names a log pattern.
  • Constraints force good design. Limited hardware meant choosing what each component was for, which kept the architecture simple to reason about.