Welcome to the OPFORGE project blog — a hands-on portfolio exploring cyber operations, detection engineering, and AI-enabled threat emulation.
Below you’ll find write-ups on the infrastructure, VM build processes, segmentation logic, and automation techniques powering OPFORGE.
Stay sharp, build clean, and emulate purposefully.
“In theory there is no difference between theory and practice. In practice, there is.” — Yogi Berra 🎉 TRAM Deployment and First Report Upload This post documents the successful standalone deployment of TRAM (Threat Report ATT&CK Mapper) on an isolated OPFORGE host, culminating in our first working ML-assisted ATT&CK report ingestion. 📌 Abstract Problem: TRAM relies on Django, Python 3.10+, and a consistent static file pipeline. Errors during install (missing encodings, STATICFILES_DIRS, etc.) and UFW blocked access to the web UI. ...
“In the middle of every difficulty lies opportunity.” — Albert Einstein 🧠 Migrating to OpenSearch with Data Prepper for Log Ingestion This post chronicles the replacement of Filebeat OSS with OpenSearch Data Prepper in the segmented OPFORGE lab. It captures troubleshooting, configuration, and validation processes that highlight modern, modular ingestion practices suited for a realistic Blue Team SIEM environment. 📌 Abstract Problem: Filebeat OSS 7.12.x caused ingestion failures with OpenSearch 2.13.0 due to unsupported _type metadata in bulk events. ...
“Divide and rule, the politician cries; unite and lead, is watchword of the wise.” — Johann Wolfgang von Goethe ✨ VLAN Foundations and DMZ Segmentation This post documents the foundational setup of VLAN-based segmentation in the OPFORGE lab, focusing on the transition from flat subnets to trunked interfaces and routed VLANs. It marks a major step in the network maturity of the lab, preparing for more realistic Red Team lateral movement simulations and Blue Team detection scenarios. ...
“It is not because things are difficult that we do not dare, it is because we do not dare that they are difficult.” — Seneca 🌐 Routing + DNS Success Across the OPFORGE Lab In this post, I walk through the successful validation of DNS and routing configurations across segmented OPFORGE networks. After implementing static routes, DNS forwarding, and conditional resolvers, systems across RED, DMZ, INT, and CSOC segments can now resolve opforge.local and route correctly. ...
“If you know the way broadly, you will see it in all things.” — Miyamoto Musashi ✨ DNS & Routing End-to-End This post captures the initial end-to-end routing and DNS resolution across segmented subnets in the OPFORGE lab. It enabled reliable communication across infrastructure zones and laid the groundwork for centralized visibility and detection. 📌 Abstract Problem: The initial network configuration lacked reliable inter-segment routing and DNS resolution, limiting endpoint communication and visibility into host activity. ...
“In the midst of chaos, there is also opportunity.” — Sun Tzu ✨ Initial Connectivity – Red to DMZ Validation This post captures the preliminary test to confirm routed communication between the Red Team subnet and the DMZ prior to full lab routing. It served as a necessary checkpoint to ensure that the segmented network was behaving as expected before DNS, NAT, and VLAN tagging were added. 📌 Abstract Problem: With the new segmented topology in OPFORGE, we needed to verify that basic IP connectivity from RED → DMZ was functional before layering on DNS and full routing. ...
“Order and simplification are the first steps toward mastery of a subject.” — Thomas Mann ✨ Foundational Segmentation Setup This post captures the introduction of initial segmentation boundaries within the OPFORGE lab. Before advanced VLAN tagging and DMZ logic, basic subnet design and routing were validated to support scalable infrastructure development. 📌 Abstract Problem Statement: The original flat lab design limited control over traffic flow and security boundaries, making it unsuitable for advanced threat simulation or detection testing. ...
“You must understand the whole of life, not just one little part of it. That is why you must read, look at the skies, sing, and dance.” — Jiddu Krishnamurti 🧠 Routing the OPFORGE Lab This post outlines the implementation of static routing across segmented subnets in the OPFORGE lab using VyOS routers. With a baseline topology now established, we focus on connecting RED, INT, and DMZ zones through transit routers and validating initial east-west communication. ...
“First say to yourself what you would be; and then do what you have to do.” — Epictetus 🚀 Genesis of OPFORGE The launch of OPFORGE marks the deliberate beginning of a long-range effort to build a portfolio-driven, enterprise-grade cyber operations lab. This post documents the rationale, guiding principles, and initial actions to set up the OPFORGE lab environment using VMware Workstation Pro. 📌 Abstract Problem Statement: Many cyber professionals lack a personalized, practical testbed to validate tools, emulate adversaries, and showcase capabilities. OPFORGE fills that gap through structured lab design. ...
OPFORGE Network Internet Access Setup Guide This guide outlines the configuration steps used to enable full internet access from the Red Network within the OPFORGE lab environment. It includes configuration of VyOS routers opf-rtred and opf-rt-inet, as well as ensuring connectivity from a host such as opf-lnx01. 🔧 1. opf-rt-inet Configuration (Internet Gateway) Interfaces eth0: 192.168.10.2/24 (RED_NET) eth1: 192.168.1.25/24 (WAN - External/Internet-facing) Commands configure # Set interface IPs (if not set) set interfaces ethernet eth0 address 192.168.10.2/24 set interfaces ethernet eth1 address 192.168.1.25/24 # Default route to WAN gateway set protocols static route 0.0.0.0/0 next-hop 192.168.1.1 # Enable NAT for RED_NET to WAN set nat source rule 100 outbound-interface eth1 set nat source rule 100 source address 192.168.10.0/24 set nat source rule 100 translation address masquerade # Enable DNS forwarding set service dns forwarding listen-address 192.168.10.2 set service dns forwarding allow-from 192.168.10.0/24 set service dns forwarding name-server 1.1.1.1 set service dns forwarding name-server 8.8.8.8 commit save exit 🔧 2. opf-rtred Configuration (Red Network Router) Interfaces eth0: 192.168.10.1/24 (RED_NET) Commands configure # Set static default route to forward traffic to opf-rt-inet set protocols static route 0.0.0.0/0 next-hop 192.168.10.2 # Set DNS resolver to point to opf-rt-inet set system name-server 192.168.10.2 commit save exit 🧪 3. opf-lnx01 or Red Network Host Ensure the following are configured on your RED_NET endpoints: ...