Forem: David McHale

Why your phishing simulations land in spam (and the SPF / DKIM / DMARC fix that actually works)

David McHale — Mon, 04 May 2026 02:56:41 +0000

Every security awareness program eventually has the same conversation:

"We sent the campaign yesterday. The dashboard says it went out. But
nobody clicked, and three people on Slack are asking why they didn't get
the test email."

Then somebody opens their spam folder and finds the simulated phish
sitting next to a Nigerian prince. The campaign isn't broken. The
deliverability is.

I've spent enough time debugging this for HailBytes SAT customers that I
can write the post-mortem from memory. Here it is.

The core problem

A phishing simulation is, by construction, an email designed to look
suspicious. Modern mail providers (Microsoft 365, Google Workspace,
Mimecast, Proofpoint) are trained on suspicious email and will quarantine
it aggressively unless you give them strong signals to trust the sender.

There are exactly four signals that matter at scale:

SPF — does the sending IP have permission to send for this domain
DKIM — is the message body cryptographically signed by the domain
DMARC — what should receivers do if SPF/DKIM disagree
Sender reputation — has this IP / domain pair sent good mail before

Get all four right and your campaigns hit the inbox. Miss any one and
you're fighting probabilities.

Step 1: do not send from your real corporate domain

This is the most common mistake. Teams deploy a phishing platform, point
it at noreply@theirrealcompany.com, and immediately damage their own
domain reputation when receivers flag the test as suspicious.

Use a separate purpose-built domain for simulated phishing.
security-training.example-corp.com or a fresh look-alike domain owned
by you. Publish DMARC on the real domain in p=reject. Run the sim
domain in p=none (or p=quarantine once warm) so receivers can
classify it as deliverable-but-suspicious — exactly the behaviour you
want for training.

Step 2: SPF that actually authorizes the sender

If you're running HailBytes SAT (or any platform) on your own EC2
instance and sending direct to MX, the SPF record on your sim domain
needs to authorize that IP:

v=spf1 ip4:203.0.113.42 -all

If you're relaying through SES, SendGrid, or Postmark:

v=spf1 include:amazonses.com -all

The two -all (hardfail) records will get you the strongest signal.
~all (softfail) is acceptable while warming up.

Step 3: DKIM, properly

DKIM is the part that breaks silently. Generate a 2048-bit key
(openssl genrsa -out dkim.key 2048) and publish the public half as a
TXT record at selector._domainkey.sim-domain.example.com. In SAT we
default to selector s1 — change it if you rotate keys.

The signature must cover at least From, Subject, Date, and
To. If your SMTP relay is rewriting headers, your signature will
break and DKIM will fail without an obvious error in the dashboard.

Verify with:

dig +short TXT s1._domainkey.sim-domain.example.com

Then send yourself a test message and check Authentication-Results in
the raw headers. You want dkim=pass.

Step 4: DMARC alignment

DMARC requires that either SPF or DKIM passes and the authenticated
domain matches the From: domain. This trips up almost everyone who uses
a relay service.

If your From: is security@sim.example.com but DKIM is signed by
amazonses.com, DMARC alignment fails even though DKIM itself passes.

Fix: either sign with your own domain (best) or set the relay to use a
custom MAIL FROM that aligns with your domain (acceptable).

Publish DMARC at _dmarc.sim-domain.example.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100

The p=none is intentional during warming. Move to p=quarantine once
your reports show consistent SPF and DKIM passes.

Step 5: warm the IP

A brand-new IP sending 5,000 phishing simulations on day one will go
straight to spam, no matter how clean your DMARC is. Reputation is
volume-and-pattern based.

Realistic warming schedule for a new sim IP:

Day	Volume	Notes
1-3	50	Internal-only test accounts
4-7	200	Volunteer pilot group, mark "not spam" actively
8-14	500	First small department
15+	2k+	Full org, monitor postmaster tools

Microsoft and Google both expose postmaster dashboards. Use them. If
you see reputation dropping to "low" or "bad" you're sending faster
than the receiver trusts.

Step 6: per-recipient header rules

Even with all of the above, individual mailboxes can have transport
rules that quarantine specific patterns. The single most useful thing
you can do as a security team is publish an internal allowlist
document that mail admins can apply to bypass quarantine for the
sim domain only. Most receivers support per-domain or per-IP overrides.

A reasonable Microsoft 365 example: add the sim IP to the IP Allow
List in the connection filter, and create a transport rule that sets
SCL to -1 for messages from *@sim-domain.example.com. This bypasses
spam filtering but, importantly, not the user's perception — the
email still arrives looking suspicious, which is the whole point.

The result

When customers walk through this checklist with HailBytes SAT, inbox
placement on Microsoft 365 typically goes from 30-40% (campaign
launched cold) to 90%+ (campaign launched after a 2-week warm). The
single biggest jump comes from getting DKIM alignment right, not from
any IP-warming voodoo.

If you want to skip the homework, the platform handles SPF / DKIM /
DMARC scaffolding and IP warming as part of deployment — full guide at
hailbytes.com/sat. But honestly, the
above checklist is product-agnostic. Whatever sim platform you're
running, work through these six steps before you blame the tool.

Giving an AI agent a recon toolbox: wiring 30+ security tools into an MCP server

David McHale — Mon, 04 May 2026 02:56:19 +0000

If you've watched a junior pen-tester spend a Monday morning typing the same
six commands into a fresh EC2 box, you've seen the recon setup tax up close.
amass enum -passive -d $TARGET, subfinder -d $TARGET -silent, pipe to
httpx, pipe to naabu, feed surviving hosts into nuclei, dump JSON
somewhere, repeat next quarter when the scope changes.

The work isn't hard. The glue is. Every team I've talked to has rebuilt this
glue at least twice, usually in a different language each time.

This post is about a different shape of the problem: what happens when you
stop writing the glue yourself and instead expose the recon toolbox as
MCP tools that an AI agent can call?

Why MCP, specifically

Agents have been doing "tool use" for a couple of years now via bespoke
function-calling adapters. The problem with those adapters is that every
agent framework wants its own JSON shape, every tool needs its own auth, and
every team writes its own retry/timeout/rate-limit middleware.

MCP (Model Context Protocol) collapses
all of that into one server-side contract. Once your tools are MCP tools,
any compliant client — Claude Desktop, Cursor, your own LangGraph agent —
can drive them.

For recon, the value is asymmetric. Recon is one of the rare security
workflows that's iterative and branching:

enumerate subdomains → resolve → port-scan live hosts →
fingerprint services → run targeted vuln checks → pivot to new assets →
loop

That loop is exactly the shape an LLM is good at orchestrating, provided
the tools return structured data and the agent can hold the inventory in
state. You don't want the LLM running nmap. You want it deciding when
to run nmap and on what.

What we wrapped

In HailBytes ASM (full disclosure, this is our product — built specifically
for pen-test firms and MSSPs), the MCP server exposes the same surface as
the REST API:

Discovery: start_subdomain_scan, start_port_scan, start_dns_scan
Vulnerability: start_nuclei_scan, start_template_scan
Inventory: list_assets, get_asset_history, diff_scans
Reporting: export_findings, get_scan_summary

Each tool returns JSON with stable schemas — not log scrapes — so the agent
can plan multi-step workflows without the model having to parse stderr.

A working loop

A real session looks like this (paraphrased from one of our internal eval
runs):

User: "Map the external attack surface for example.com and flag anything
       that looks like an exposed staging environment."

Agent → start_subdomain_scan(domain="example.com")
Agent → list_assets(scan_id=...)  // 312 hosts
Agent → start_port_scan(targets=[...], top_ports=1000)
Agent → start_nuclei_scan(targets=live_hosts, severity=["medium","high"])
Agent → list_assets(filter="hostname matches /staging|stg|dev|qa/")
Agent → get_asset_history(asset_id=...)  // appeared 6 days ago
Agent → "Found 4 hosts matching staging-like patterns; one
        (stg-admin.example.com) appeared 6 days ago and exposes a Jenkins
        instance with a known CVE..."

The interesting part is what the agent doesn't do: it doesn't shell out,
doesn't manage AWS credentials, doesn't worry about rate limits, doesn't
re-implement scan diffing. The MCP tools take care of all of that. The
agent's job is the part that's actually hard — choosing the next action.

What broke (and what we changed)

A few honest notes from running this at customer sites:

Pagination kills agents. Our first cut returned all assets in a single response. With 30k+ subdomains in a real engagement, the agent's context filled up before it got to the analysis step. We added cursor pagination and a summarize_assets tool that returns aggregates.
Implicit state is hostile. Agents are bad at remembering "the most recent scan." Every tool that takes a scan_id now requires it explicitly, even if there's only ever one running.
Long-running scans need a status protocol. Recon scans take minutes to hours. We added wait_for_scan(scan_id, timeout) so the agent can block politely instead of polling in a tight loop.

Where this fits

If you're already running recon in-house, you don't need to buy anything to
try this pattern — wrap your own scripts in an MCP server and you'll get
70% of the value. The harder parts are the things that show up at
production scale: scan diffing, asset deduplication across runs, multi-
tenant isolation, scheduled cadence, audit trails for compliance. That's
the part we've spent the last year on.

If you want to see it end-to-end, the platform is at
hailbytes.com/asm — deploys from the AWS or
Azure Marketplace, runs in your account, and exposes the MCP endpoint out
of the box.

Either way, I think MCP-native security tooling is going to be the
default within 18 months. The gap between "agent can read a Splunk
dashboard" and "agent can drive a recon engagement" is closing fast, and
the teams that wire their own toolbox up early are going to have a real
edge.

That Time SQLite File Existence Lied to Us

David McHale — Wed, 11 Feb 2026 16:57:00 +0000

The bug

Our bootstrap script was killing GoPhish before database migrations could finish. Took us way too long to figure out why.

Here's what we had:

while [ ! -f "$DB_FILE" ]; do
    sleep 1
done
kill $GOPHISH_PID  # DB exists, we're good right?

Nope.

SQLite creates the database file the moment you open a connection. Migrations run after that. We were killing the process as soon as gophish.db appeared, before the schema was even built.

Result: weird SQL errors about missing columns. Only in production. Fun times.

The fix

Wait for the schema, not just the file:

# Wait for file
while [ ! -f "$DB_FILE" ]; do
    sleep 1
done

# Wait for migrations (check for a column we know should exist)
while ! sqlite3 "$DB_FILE" ".schema users" 2>/dev/null | grep -q "password_change_required"; do
    sleep 1
done

Pre-flight checks

While we were in there, we added checks before starting the service:

preflight_check() {
    local missing=()

    [ ! -d "$MIGRATIONS_DIR" ] && missing+=("migrations directory")
    [ ! -f "$CONFIG_FILE" ] && missing+=("config.json")
    [ ! -d "$STATIC_DIR" ] && missing+=("static directory")

    if [ ${#missing[@]} -gt 0 ]; then
        echo "ERROR: Missing required files: ${missing[*]}"
        exit 1
    fi
}

Catches broken deployments immediately instead of failing mysteriously later.

Debugging output that actually helps

When stuff breaks, we now dump:

Directory contents
Database schema (if it exists)
Common causes checklist
All output unbuffered with stdbuf -oL so you can actually see it in real time

That last one matters a lot when you're debugging through a cloud serial console.

Cloud VM patterns we use now

Network waiting. Cloud VMs don't always have network at boot:

wait_for_network() {
    local max_attempts=30
    for ((i=1; i<=max_attempts; i++)); do
        if curl -s --max-time 5 https://example.com > /dev/null; then
            return 0
        fi
        sleep 2
    done
    return 1
}

Docker readiness. Service "started" doesn't mean Docker is actually ready:

wait_for_docker() {
    while ! docker info > /dev/null 2>&1; do
        sleep 1
    done
}

State files. Know if this is first boot or a restart:

STATE_FILE="/var/lib/myapp/state"
if [ -f "$STATE_FILE" ]; then
    do_routine_restart
else
    do_initial_setup
    touch "$STATE_FILE"
fi

Systemd stuff

Use network-online.target, not network.target. They're different and it matters:

[Service]
Type=oneshot
RemainAfterExit=yes
ProtectSystem=full
PrivateTmp=true
NoNewPrivileges=true

After=network-online.target docker.service
Wants=network-online.target
Requires=docker.service

SSH key cleanup for marketplace images

If you're publishing VM images, clean up your dev keys:

rm -f ~/.ssh/id_* ~/.ssh/*.pub ~/.ssh/known_hosts ~/.ssh/config
find ~/.ssh -type f -exec rm -f {} \;

# Verify it worked
if find ~/.ssh -type f 2>/dev/null | grep -q .; then
    echo "WARNING: SSH files still present!"
fi

TL;DR

Don't trust file existence as a completion signal
Pre-flight checks save debugging time
Cloud VMs need patience (network, Docker, everything)
Unbuffer your output (stdbuf -oL)
Verify your cleanup actually worked

These changes took us from "why does this randomly break" to "oh, it failed because X." That's the goal.

We Shipped 79 PRs in a Few Weeks. Claude Code Did Most of the Work.

David McHale — Wed, 28 Jan 2026 15:01:00 +0000

We maintain HailBytes GoPhish, a fork of the open-source phishing simulation toolkit. We wanted to add a bunch of enterprise features (MFA, SSO, encryption at rest, audit logging, white-labeling) and honestly didn't have the bandwidth to do it the traditional way.

So we tried something different. Claude Code is now our most prolific contributor.

The Setup

GoPhish is kind of a pain to work on. Go backend, JavaScript frontend, systemd services, bash deployment scripts, SQL migrations, webpack. When you touch one thing, you often need to touch five others.

We had a feature list that would take a small team months. We have... not that.

What It Actually Looks Like

Here's a real morning:

$ claude
> Fix the bootstrap script killing gophish before migrations complete

Claude reads the bash scripts, traces the systemd dependency chain, finds the race condition, fixes it, commits. Done.

commit cd29bc7
Author: Claude <noreply@anthropic.com>

    Fix bootstrap killing gophish before migrations complete

That's it. That's the workflow.

Some Real Examples

Service debugging:

> Fix Linux services not starting after VM image restart

Claude traced through the systemd units, found the missing dependencies, fixed the boot sequence.

Frontend bugs:

> Fix privacy settings not saving due to deprecated jQuery methods

Our jQuery upgrade broke .attr() on checkboxes (should be .prop()). Claude found all the occurrences and fixed them.

Big refactors:

> Update bootstrap script with patterns from cloud_tools and scripts

666-line diff. Network waiting, readiness checks, state file tracking, proper error handling. One commit.

What Actually Works

Describe the problem, not the solution. "Fix the bug where X happens" beats "change line 47 to Y"
Let it explore. Claude reads related files and often finds issues you didn't know about
Review the diff. It commits with clear messages. You review, test, merge
You still own the final call. We run tests and do manual QA. Fast doesn't mean careless

What Surprised Us

The bash scripts. We expected Claude to be good at Go and JavaScript. We didn't expect it to nail systemd services and deployment scripts. It gets the whole stack.

Cross-cutting changes too. Adding SSO touched Go handlers, SQL migrations, JavaScript, CSS, docs. Claude handled the full vertical.

And bug hunting. "The sidebar is pushing down the main content" and Claude reads the CSS, finds the position: fixed conflict, fixes it, explains why.

The Numbers

From our recent git log:

15 Claude-authored commits in the last two weeks
Changes across Go, JavaScript, Bash, SQL, CSS, systemd
Features enterprise customers are paying for

Try It

If you maintain an open-source project and your issue backlog haunts you:

npm install -g @anthropic-ai/claude-code
cd your-project
claude

Start with a real bug. Something annoying that's been sitting there forever. See what happens.

We're HailBytes. We build security tools for pentesters and security awareness teams. GoPhish 0.14.2 ships this month.

What's your experience using AI on real projects? I'm curious what's working for people.

We Hardened Ubuntu 24.04 for Security Tools (And Broke Everything First)

David McHale — Wed, 21 Jan 2026 16:50:00 +0000

We Hardened Ubuntu 24.04 for Security Tools (And Broke Everything First)

We maintain HailBytes reNgine, a web recon platform. Wanted to deploy hardened golden images to AWS and Azure following industry benchmarks.

Should be simple. Run hardening script, create AMI, done.

Except our scanning tools immediately stopped working. 🔥

# Our "secure" kernel settings:
kernel.unprivileged_bpf_disabled = 1  # Block BPF
net.core.bpf_jit_harden = 2           # Maximum BPF hardening

# What our tools actually needed:
# BPF access. For packet capture. For scanning. For everything.

Here's the thing: security tools often need the exact privileges that security hardening removes. Fun paradox.

How Claude Code Helped

We used Claude Code to iterate on the hardening scripts. Three problems it helped us solve:

1. Azure VMs Were Detected as AWS

Both clouds use the same metadata IP. Our detection was just checking if the endpoint responded.

# This is wrong
METADATA_URL="http://169.254.169.254"
curl -s "$METADATA_URL/latest/meta-data/" && echo "AWS!"

The fix: actually validate the response format.

detect_cloud_provider() {
    # Check Azure FIRST (it has a specific field)
    local azure_check=$(curl -s -H "Metadata:true" \
        "http://169.254.169.254/metadata/instance?api-version=2021-02-01" \
        --connect-timeout 2 2>/dev/null)

    if echo "$azure_check" | grep -q '"azEnvironment"'; then
        echo "azure"
        return
    fi

    # Then check AWS (validate instance ID format)
    local aws_check=$(curl -s \
        "http://169.254.169.254/latest/meta-data/instance-id" \
        --connect-timeout 2 2>/dev/null)

    if [[ "$aws_check" =~ ^i-[a-f0-9]+ ]]; then
        echo "aws"
        return
    fi

    echo "generic"
}

Azure returns JSON with azEnvironment. AWS returns plain text. Check the actual content, not just connectivity.

2. Ubuntu 24.04 Renamed the SSH Service

Worked fine on 22.04. Then:

systemctl restart sshd  # "Unit sshd.service not found" 💀

Ubuntu 24.04 changed it from sshd to ssh. Cool. Cool cool cool.

if systemctl restart ssh 2>/dev/null || systemctl restart sshd 2>/dev/null; then
    log "SSH hardened"
else
    error "Failed to restart SSH"
fi

3. Finding the Right Security Tradeoffs

This was the real work. Hardening that doesn't break the app:

Setting	CIS Says	What We Used	Why
`unprivileged_bpf_disabled`	1 (blocked)	0 (allowed)	Scanning needs packet capture
`bpf_jit_harden`	2 (max)	1 (moderate)	Performance matters
AppArmor	enforce all	complain for Docker	Containers need flexibility

Each deviation is documented. Auditors will ask. Have your answers ready.

What You Get

# Auto-detect cloud provider
sudo ./harden_ubuntu_2404.sh

# Or force it
sudo ./harden_ubuntu_2404.sh --cloud azure
sudo ./harden_ubuntu_2404.sh --cloud aws

The script handles:

SSH hardening (Ed25519, modern ciphers only)
UFW firewall (ports 22, 443, 8082)
Kernel hardening (ASLR, SYN cookies, anti-spoofing)
Fail2Ban
Auditd logging
Auto security updates
Still runs Docker and security tools

What I Learned

Test on the actual target platform. Ubuntu version differences will get you.
Cloud metadata APIs are tricky. Validate the response format, not just reachability.
Document your security tradeoffs. Future you and your auditors will need this.
AI assistants catch edge cases. Claude flagged the SSH rename before we hit production.

Grab It

git clone https://github.com/HailBytes/rengine-ng-rc
cd rengine-ng-rc/scripts
sudo ./harden_ubuntu_2404.sh --help

Works for any Ubuntu 24.04 server, not just reNgine.

How do you handle the security vs. functionality tradeoff? Would love to hear what's worked for you. Update incoming this week.

#security #devops #ubuntu #cloudcomputing #opensource

Our Godot Game Only Crashed on Expensive PCs (Here's Why)

David McHale — Fri, 16 Jan 2026 21:02:35 +0000

Players started reporting that our game was freezing during boss fights. No crash logs. No Sentry reports. Just "Not Responding" and then... nothing.

The weird part? It was happening on RTX 4090s while working fine on older hardware. Yeah.

My brother and I run Lost Rabbit Digital together, and we've been building Starbrew Station (a space coffee shop idle game, it's a whole thing) in Godot 4.5. Here's what we found and how we fixed it.

The Actual Problems

We tracked it down to four separate issues that were all making things worse together.

1. Loading Resources During Gameplay

This looks harmless:

func start_boss_fight():
    var boss_scene = load("res://scenes/InspectionBossFight.tscn")
    var boss = boss_scene.instantiate()

It's not. That load() call freezes everything for 100-500ms while it reads from disk. Combine that with shader compilation and you hit Windows TDR (Timeout Detection and Recovery). Windows kills any process that doesn't respond to the GPU driver within ~2 seconds. No crash report, just dead.

Fix: Preload at startup instead.

const InspectionBossFightScene = preload("res://scenes/InspectionBossFight.tscn")

func start_boss_fight():
    var boss = InspectionBossFightScene.instantiate()  # instant

Same thing for shader materials. Don't create them at runtime, create templates at startup and duplicate them.

2. Awaits That Wait Forever

func _on_achievement_unlocked():
    await EventBus.game_saved
    show_notification()

If the save fails and never emits that signal? This waits forever. The game just hangs.

Fix: Fire and forget.

func _on_achievement_unlocked():
    EventBus.request_save.emit()
    show_notification()  # don't wait for confirmation

3. Tweens Piling Up

Every UI animation created a new tween. We never killed the old ones. After a few hours of gameplay, thousands of dead tween references just sitting in memory.

Fix: Track them and kill the old one before making a new one.

var _active_tweens: Dictionary = {}

func fade_ambient_light():
    if _active_tweens.has("ambient_fade") and _active_tweens["ambient_fade"].is_valid():
        _active_tweens["ambient_fade"].kill()

    var tween = create_tween()
    _active_tweens["ambient_fade"] = tween
    tween.tween_property(light, "energy", 0.5, 1.0)

4. Loops With No Safety Limits

Our fighter cleanup loop could churn through thousands of invalid entries in one frame:

func cleanup_fighters():
    for i in range(fighters.size() - 1, -1, -1):
        if not is_instance_valid(fighters[i]):
            fighters.remove_at(i)

Fix: Add iteration limits.

const MAX_ITERATIONS_PER_FRAME = 100

func cleanup_fighters():
    var iterations = 0
    for i in range(fighters.size() - 1, -1, -1):
        iterations += 1
        if iterations > MAX_ITERATIONS_PER_FRAME:
            break
        if not is_instance_valid(fighters[i]):
            fighters.remove_at(i)

For bigger operations (like applying buffs to 100+ units at once), chunk it across frames:

func apply_cascade_inspiration(units: Array):
    var index = 0
    while index < units.size():
        for i in range(10):  # 10 per frame
            if index >= units.size():
                break
            units[index].apply_inspiration()
            index += 1
        await get_tree().process_frame

TL;DR

Preload resources at startup. Runtime load() on Windows can trigger GPU driver timeouts.
Don't await signals that might never fire. Fire and forget instead.
Track your tweens. Kill old ones before creating new ones.
Put limits on loops. Especially ones processing dynamic arrays.
Chunk big operations across frames. Your players will thank you.

The kicker: high-end PCs hit these bugs faster because they ran more game loops per second. Sometimes the best hardware finds the worst problems.

We're Lost Rabbit Digital on GitHub. Starbrew Station is built with Godot 4.5.

Run Phishing Simulations for $37/Month Instead of $30,000/Year

David McHale — Thu, 15 Jan 2026 23:39:34 +0000

Most enterprise phishing simulation tools charge $3-5 per user per year. For a 10,000 person company, that's $30,000-50,000 annually.

We run unlimited simulations on a $37/month Azure VM.

The Tool: GoPhish

GoPhish is an open-source phishing simulation framework. It's been around for 10+ years, has 10,000+ installations, and is MIT licensed.

I've supported it for the last 8 years or so, since early 2018, maintaining the core repo and answering issues as they've popped up.

You can:

Create realistic phishing campaigns
Track who opens, clicks, and submits credentials
Measure improvement over time
Import thousands of targets via CSV

The problem? Vanilla GoPhish lacks enterprise basics: no MFA, no encryption at rest, no audit logging.

What We Added

We forked GoPhish and added what production environments actually need:

Feature	Why It Matters
MFA/TOTP	Your admin panel shouldn't be a security hole
SSO (Google/Microsoft)	One-click login for your team
AES-256 encryption	Stored credentials aren't plaintext anymore
Audit logging	SIEM export for compliance
White-label branding	Your logo, not ours
One-click deployment	Azure/AWS in ~5 minutes

Quick Start (Azure)

Create Ubuntu 24.04 VM from GoPhish 0.14.2 public image on Azure (Standard_B2s = $37/month)
Get your auto-generated admin password from Azure Serial Console
Login at https://your-ip:3333

The setup script handles systemd services, TLS certificates, and Ubuntu hardening.

Cost Comparison

Solution	10,000 Users/Year
KnowBe4	~$30,000
Proofpoint	~$40,000
Cloud-hosted GoPhish	~$3,600
Self-hosted GoPhish	~$360

Same capabilities. Fraction of the cost. Your data stays on your infrastructure.

Forem: David McHale

Why your phishing simulations land in spam (and the SPF / DKIM / DMARC fix that actually works)

The core problem

Step 1: do not send from your real corporate domain

Step 2: SPF that actually authorizes the sender

Step 3: DKIM, properly

Step 4: DMARC alignment

Step 5: warm the IP

Step 6: per-recipient header rules

The result

Giving an AI agent a recon toolbox: wiring 30+ security tools into an MCP server

Why MCP, specifically

What we wrapped

A working loop

What broke (and what we changed)

Where this fits

That Time SQLite File Existence Lied to Us

The bug

The fix

Pre-flight checks

Debugging output that actually helps

Cloud VM patterns we use now

Systemd stuff

SSH key cleanup for marketplace images

TL;DR

We Shipped 79 PRs in a Few Weeks. Claude Code Did Most of the Work.

The Setup

What It Actually Looks Like

Some Real Examples

What Actually Works

What Surprised Us

The Numbers

Try It

We Hardened Ubuntu 24.04 for Security Tools (And Broke Everything First)

We Hardened Ubuntu 24.04 for Security Tools (And Broke Everything First)

How Claude Code Helped

1. Azure VMs Were Detected as AWS

2. Ubuntu 24.04 Renamed the SSH Service

3. Finding the Right Security Tradeoffs

What You Get

What I Learned

Grab It

Our Godot Game Only Crashed on Expensive PCs (Here's Why)

The Actual Problems

1. Loading Resources During Gameplay

2. Awaits That Wait Forever

3. Tweens Piling Up

4. Loops With No Safety Limits

TL;DR

Run Phishing Simulations for $37/Month Instead of $30,000/Year

The Tool: GoPhish

What We Added

Quick Start (Azure)

Cost Comparison

Links