Mission and Exile - Operating a Scalable, Stealthy Lab

Posted Aug 1, 2025 Updated Aug 5, 2025

By Athanasius of Alexandria

13 min read

⚠️ The infrastructure, code, and methodologies described in this blog are designed solely for lawful, educational, and ethical purposes. This series is intended to help red team professionals, security researchers, and students build controlled environments for testing, training, and strengthening defensive postures.
As those made in the image of God and called to walk in integrity, we affirm that knowledge must be governed by wisdom. The Apostle Paul reminds us, “All things are lawful, but not all things are helpful” (1 Cor. 10:23). Accordingly, these tools are not to be used for harm, unauthorized access, or malicious activity of any kind.
Let it be clear: this work is to be conducted with a clear conscience before both God and man (Acts 24:16). Those who weaponize such knowledge outside the bounds of legality and virtue not only violate human law, but grieve the moral law of the Creator Himself.
“Whatever you do, in word or deed, do everything in the name of the Lord Jesus…”
— Colossians 3:17

“These all died in faith… having acknowledged that they were strangers and exiles on the earth.”
— Hebrews 11:13

Theological Framing: From Sinai to the Wilderness

The people of God are never static—they are a pilgrim people.

After Sinai came the wilderness. After Pentecost came persecution. God’s covenant people were always on the move—not aimless, but guided by cloud and fire, driven by promise, and shaped by testing. Their tabernacle was modular and portable, their camp designed for movement, their hearts prepared for formation through affliction.

In the same way, your red team infrastructure must not be built like a temple—but like a tabernacle.

From Sinai to the Field: Simulating Exile

Red team labs are wilderness environments. They are not the final destination; they are training grounds, proving grounds, staging areas for greater engagement.

In the wilderness, Israel learned obedience. They experienced scarcity, pressure, and war. They failed, repented, adapted. So too must your infrastructure be built for:

Mobility: Ready to spin up and tear down as engagements shift
Resilience: Hardened against detection, takedown, and drift
Evasion: Capable of operating in contested space
Formation: Shaping operator skill and discipline through constraint

Your lab is not the promised land—it’s the preparation. But if you design it well, it will carry you from Sinai to Canaan. From training to assessment. From internal simulation to live operation.

Typology: The Tabernacle as Infrastructure-as-Mission

God’s presence dwelled not in a static structure but in a movable sanctuary. The tabernacle had clear dimensions, encoded holiness, layered access controls (cf. court, holy place, most holy place). It could be deployed in stages, and torn down rapidly. It had to be durable, sacred, and mobile.

That’s your infrastructure model.

Each module you design—whether it’s your C2 framework, operator VM, or phishing box—must be built to travel well, to endure the wilderness, and to prepare for the promised land: production engagement.

Production as the Promised Land

Just as Israel crossed the Jordan to take hold of the land, you too must cross from lab to production. Your red team lab is not the end—it is the means of entry into a real-world environment where your tools, operators, and tactics are tested against live defenders.

So build with that goal in mind:

Will this hold up under active defense?
Can this adapt if forced to pivot mid-operation?
Is this cloud-native, region-agnostic, modular, and disposable?

A promised land awaits—but only if your wilderness training shapes you to take and hold it.

“Remember how the Lord your God led you all the way in the wilderness these forty years, to humble and test you…”
— Deuteronomy 8:2

Your red team infrastructure is not a monument—it is a mission-ready tabernacle. From Sinai to the field, from code to covenant, build with movement in mind.

1. Scaling the Lab for Realism

A wilderness tabernacle wasn’t just a tent—it was a mobile ecosystem of worship, hierarchy, access, and security. Likewise, your red team lab must move beyond simple deployments and reflect the complexity of real-world environments.

This is where your infrastructure grows from basic provision to battlefield simulation—training for the promised land of production engagements.

Therefore, to prepare your team for live assessmensts, labs should reflect the layered defenses and operaitonal nuances of real-world organizations.

Add Enterprise Depth

Active Directory Forests: Introduce domain trust relationships, user roles, and GPO policies.
DNS and Internal Resolution: Simulate name-based pivoting, misconfigurations, and internal discovery.
Multiple Subnets: Build out DMZs, admin networks, endpoint networks, and segmented zones for lateral movement.
Jump Boxes and Routing Rules: Teach operators to think in terms of chokepoints and internal segmentation.

The goal is not complexity for complexity’s sake, but fidelity. Realism trains for responsibility.

Lab Toolkits for Building Depth

To avoid reinventing the wheel, consider leveraging some incredible community-driven lab projects:

GOAD (GitHub – Orange-Cyberdefense/GOAD)
A ready-to-deploy Active Directory lab using Terraform and Ansible. Includes two forests and three domains—ideal for training forest trust abuse, GPO enumeration, and advanced post-exploitation.
Ludus
A modular offensive security training platform. Easily integrates with Docker and cloud infra. Offers scenarios ranging from internal lateral movement to phishing and beacon staging.
LudusHound
A companion project for Ludus that performs automated enumeration and scoring of red team behaviors. Great for validating AD abuse, group membership manipulation, and event visibility.

Tip: Use LudusHound to simulate a “blue team presence” inside your GOAD environment—then challenge your operators to pivot without triggering the honeypots.

These tools can be layered together or swapped modularly to build enterprise-grade training arenas that reflect the environments you’re preparing to engage in production.

“Train up a child in the way he should go; even when he is old he will not depart from it.”
— Proverbs 22:6

Build your lab like you’re raising up operators who will one day walk into hardened networks with nothing but their wits and .tfvars.

Let your lab be a place not only of attack, but of discernment. Add tools that simulate blue team pressure and telemetry:

SIEM Decoys: Forward logs to mock Splunk/Elastic setups and teach log evasion.
- Splunk Free — Deploy a free Splunk instance to simulate event ingestion and detection pipelines.
- Elastic Stack (ELK) — Use Filebeat, Logstash, and Kibana to simulate centralized logging and dashboards.
- DetectionLab — A turnkey blue team lab with Elastic, Splunk, Sysmon, and Windows hosts preconfigured.
Audit Zones: Add NSGs and logging rules to capture behavioral patterns.
- Azure NSG Flow Logs — Enable and analyze flow logs in your Azure lab.
- Sysmon + Logstash — Collect deep process and network telemetry from Windows hosts.
- Falcon SIEM Integration Guide — Simulate ingesting EDR alerts into your SIEM.
Honeypots: Place lures in tempting places—exposed SMB shares, fake admin accounts, hidden canaries.
- OpenCanary — Lightweight honeypot that emulates multiple services (SMB, FTP, HTTP).
- CanaryTokens — Free and simple tokens that alert when accessed (URLs, documents, AWS keys).
- Heralding — Credential-catching honeypot for SSH, FTP, and RDP.

Tip: Combine OpenCanary with Filebeat to forward honeypot alerts into your ELK or Splunk pipeline for full telemetry feedback.

Red teams who don’t train in defended terrain risk becoming idealists, not warriors.

2. Stealth & Evasion: Hidden Yet Faithful

“Daniel resolved that he would not defile himself… and God gave Daniel favor and compassion in the sight of the chief…”
— Daniel 1:8–9

Daniel didn’t run from Babylon — he remained, adapted, and endured. He learned the language, entered the king’s court, even bore a Babylonian name. But he did so without compromise. He lived within the system without being consumed by it.

That’s your infrastructure model.

Your red team lab should simulate environments where the offensive tooling must blend in, persist, and adapt under hostile surveillance. Stealth isn’t cowardice — it’s wisdom under fire.

We must remember that the ultimate goal of red teaming is not merely to remain hidden, but to reveal. Our work exists in partnership with the blue team—designed to strengthen the organization’s overall security posture, validate detection and response capabilities, and promote long-term resilience.

Red teams are not adversaries to defenders, but refining agents. We operate in the shadows not for concealment’s sake, but to expose the gaps, sharpen the edge, and help our clients align with security standards and best practices. The mission is not stealth for its own glory—it is clarity for the sake of the kingdom.

Obfuscate Resource Names

Names like kali-vm, c2-teamserver, or payload-stager are red flags to blue teams and security tools. Babylon will scan your inventory.

Instead of…	Use…
`kali-vm`	`vm-dev-syd-02`
`c2-teamserver`	`ts-app-prod01`
`phishing-box`	`webnode-vnet1`

Naming is part of your evasion strategy. Let your infrastructure blend in like Daniel among Babylon’s officials.

Use Stealth C2 Infrastructure

Your lab must simulate evasive command-and-control practices that survive in well-defended environments:

Redirectors: Use Caddy or nginx as reverse proxies to isolate and cloak C2 backends
HTTPS-only listeners with randomized URIs
Domain fronting through CDNs like Azure Front Door or CloudFront
TLS certificate and header rotation to mimic real SaaS traffic (Microsoft, Google, etc.)

Train for the kind of C2 that lives past initial detection — the kind Daniel would’ve quietly maintained in the king’s court.

In future posts, we’ll explore how to integrate Azure Front Door and Azure Functions into your C2 communication chain—enabling redirectable, resilient, and cloud-native payload delivery that blends seamlessly with modern enterprise traffic patterns.

Mirror Defender for Cloud Alerts

Operating in Azure? Enable or emulate Microsoft Defender for Cloud to simulate blue team pressure.

Use your lab to monitor and respond to:

Excessive port scanning
Failed logins and brute force attempts
PowerShell and WMI execution
Unusual lateral movement patterns

🔗 Pair this with:

Don’t just simulate the offense — simulate the reaction. A lab without detection is a Babylon without guards.

Theological Reflection: Babylon, Not Canaan

Your red team lab is not the Promised Land.

It is Babylon—a place of exile, testing, and tension. It’s the environment where God’s people learn to remain faithful while under foreign rule, to endure without assimilation, and to influence without compromise.

Likewise, your red team infrastructure is built not in a vacuum, but in simulated hostile territory. You’re not creating comfort; you’re training for complexity. You’re learning to operate within environments where detection is real, pressure is high, and the cost of error is visibility.

Yet Babylon is not the end of the story—it is where faith is refined and where discipline is tested.

Let your infrastructure:

Live in hostile terrain — train where defenders are present, signals are watched, and evasion matters
Speak the native language — understand Azure, EDRs, SIEMs, flow logs, and the telemetry of modern enterprises
Remain uncompromised — don’t cut corners just to “win”; build it as if someone will read every .tf file you write
Serve faithfully — remember that red teams are not rogues; they are trusted prophets in exile, sent to reveal and refine
Go unnoticed — not for pride, but for purpose: to show what defenders must prepare for, without revealing the test

Babylon was a city of idols, bureaucracy, and control—but it was also the place where Daniel, Shadrach, Meshach, and Abednego stood firm.

Your infrastructure is not neutral—it will either form operators for humility and mission, or for pride and self-glory.

“Those who are wise shall shine like the brightness of the sky above, and those who turn many to righteousness, like the stars forever and ever.”
— Daniel 12:3

Let your lab be Babylon: not a place of compromise, but a place of clarity.
A place where red teamers are shaped not only as operators, but as watchmen, forged in pressure and deployed in peace.

Stealth is not the absence of power — it’s the expression of wisdom.
Build your lab like Daniel walked Babylon: hidden, yet faithful.

3. The Mission Continues

“Go therefore and make disciples of all nations…”
— Matthew 28:19

The Great Commission wasn’t a suggestion — it was a mandate to move outward with intention. To teach, baptize, and obey across geographic, cultural, and linguistic boundaries. It was a mission that required movement, structure, and faithfulness under pressure.

In the same way, your red team infrastructure is not designed to sit idle in a corner. It exists to be deployed, mobilized, and replicated across environments and engagements.

Purposeful Deployment, Not Haphazard Placement

Don’t just spin up random VMs and hope for operational readiness. Your infrastructure should be:

Planned — with naming conventions, subnets, tagging, and modules that mean something
Scoped — with C2 paths mapped, redirectors identified, and endpoints positioned with intent
Justified — every public IP, every storage blob, every NSG rule should exist for a reason

This is the missional discipline of red team engineering: every .tf file you write is a doctrinal statement about how your operations should be carried out.

Make It Reconstructable

The apostles didn’t stay in one place — they planted churches, appointed elders, and moved on. Likewise, your red team lab must be tear-down-and-rebuild friendly. Think:

Stateless wherever possible
Use Terraform state files and remote backends to track and reconstruct easily
Define output artifacts (IP addresses, DNS names, login creds) cleanly and automatically
Employ destroy and redeploy cycles between missions for hygiene

If it can’t be destroyed and rebuilt in one command, it’s not truly portable — it’s legacy.

Make It Invisible

Don’t let your deployment announce itself.

Deploy inside private subnets whenever possible
Route traffic through cloud-native infrastructure (Front Door, Load Balancer, CDN)
Use tags and names that match corporate conventions
Monitor for new Defender alerts or abnormal flow logs

The apostles were often invisible until it was time to speak. Your infrastructure should follow the same pattern — silent until effective.

Make It Scalable

Jesus didn’t say, “Go to a few people.” He said, all nations.

In red team terms:

Build modules that can accept JSON or YAML maps to define new regions, teams, or payloads
Leverage count and for_each to spin up operator boxes or redirectors on demand
Parameterize your entire stack to support multiple assessment tiers (internal-only, hybrid, fully external)

Your lab should scale horizontally (across environments) and vertically (in maturity and realism).

Theological Reflection: Infrastructure as Apostolic

Paul didn’t go anywhere without a team, a plan, and a gospel. He used the Roman road system to his advantage. He adapted to cities, villages, synagogues, and prisons. Your lab must reflect the same mindset:

Mobility
Cultural contextualization (infrastructure blending)
Repeatability (plant and train)
Obedience (build as a servant, not a celebrity)

“For though I am free from all, I have made myself a servant to all, that I might win more of them.”
— 1 Corinthians 9:19

Your red team lab is not your kingdom — it is your mission base.
Build it like a disciple-maker: lightweight, intentional, and always ready to go.

Red-Team, Infrastructure

This post is licensed under CC BY 4.0 by the author.