DEV Community: David McHale

Why Attack Surface Management Breaks in OT (and What Actually Works)

David McHale — Wed, 27 May 2026 23:22:17 +0000

Attack surface management has a comfortable story.

You enumerate your domains, discover the hosts behind them, fingerprint the services, find the holes, and feed the whole thing into a dashboard that refreshes on a schedule. For IT assets, that story mostly works.

Then someone hands you an industrial network, and every assumption breaks at once.

The protocols were never designed to be questioned

Most of the industrial protocols still running plants today predate the threat model we now apply to them. Modbus was published by Modicon in 1979. It has no authentication, no encryption, and no concept of a session that could be hijacked, because none of that was relevant when the device on the other end sat three meters away on a serial loop (Modbus Organization, 2012). DNP3, S7comm, and BACnet carry the same inheritance. The ISA and IEC codified the modern expectations later, in the IEC 62443 series, but the installed base does not get rewritten because a standard arrives.

This matters for attack surface management in a specific way. On an IT asset, an unauthenticated service is a finding. On an OT asset, unauthenticated is the protocol working as designed. The exposure is real, but you cannot treat the device as misconfigured and move on. You are looking at a structural property of a system that may have a fifteen year service life and a vendor contract that voids the moment you touch the firmware.

You often cannot run the scan at all

The second wall is harder. The core move of ASM is active interrogation: send a probe, read the response, infer the service. In OT, that move can take the asset down.

This is not folklore. NIST's Guide to Operational Technology Security treats availability and safety as first-order constraints and is explicit that security testing on live OT must be approached with caution, favoring passive monitoring over active interrogation wherever possible (NIST, 2023). The reason active scanning is risky is mundane:

A PLC's network stack is sized for deterministic control traffic, not for a scanner opening a thousand connections a second. The device does not misbehave because it is insecure. It misbehaves because it is busy keeping a physical process inside its safe envelope, and the scan is competing for the same scarce CPU.

So the practitioner faces a constraint with no equivalent on the IT side. The most informative tool in the kit—the active scan—is frequently the one tool you are contractually and operationally forbidden to point at the target. Many industrial environments will only grant you a span port and a packet capture.

The inventory problem compounds everything

You cannot install an agent on a relay. You cannot expect a thirty year old RTU to answer an SNMP query. There is no EDR for a turbine governor. The endpoint-centric inventory methods that IT security leans on have no purchase here, which is why so many operators genuinely do not know what is on their own networks. Dragos has reported that the large majority of OT networks still lack meaningful network monitoring, which keeps poor asset visibility among the most persistent gaps it finds across the environments it assesses (Dragos, 2026).

And the surface is not as air gapped as the org chart implies. IT and OT convergence, remote vendor access, and historian servers that bridge both worlds mean industrial assets routinely surface on the public internet. Internet-wide exposure of ICS protocols has been documented for over a decade, going back to the Project SHINE research (Radvanovsky & Brodsky, 2014), and you can still watch it live on any internet-wide scan engine today.

The incidents that followed are not hypothetical:

Stuxnet reprogrammed centrifuge controllers (Falliere et al., 2011).
The 2015 and 2016 attacks on the Ukrainian grid manipulated protection and switching equipment directly (Cherepanov, 2017).
Triton targeted a safety instrumented system, the layer of last resort designed to prevent physical harm (Dragos, 2017).
The 2021 intrusion at the Oldsmar, Florida water treatment facility, where an actor raised the sodium hydroxide dose through the SCADA interface, showed how low the bar for reaching a control system can be (CISA, 2021).

None of these required exotic protocol exploits. They required reaching devices that assumed no one hostile would ever speak to them.

What actually works, and the tools that do it

The discipline OT demands is the inverse of the ASM instinct in IT.

Lead with passive. Earn the right to be active. Default to safe.

Start passive

Start with passive discovery that never touches the plant. Internet-wide scan data from Shodan and Censys already indexes exposed ICS services by protocol, banner, and vendor, so you can map a client's externally reachable industrial footprint without sending a single packet to their network. A tool like uncover lets you query several of these engines from one interface and pull the candidate host list before deciding whether any active step is warranted at all. For the many industrial assessments that pass procurement on a passive-only attestation, this is the entire engagement.

Earn the right to go active

When active enumeration is authorized, reach for the gentlest tool that answers the question. Nmap is the right starting point, not because it is exotic but because its ICS coverage is mature and well understood. The standard NSE library already ships protocol-aware scripts such as:

modbus-discover
s7-info
bacnet-info

Digital Bond's Redpoint NSE bundle extends that to a broader device set. These do identity and version enumeration rather than register manipulation, which is exactly the line you want to stay behind. The scripts are old and the repos are dormant, but the NSE invocations are stable against current Nmap and add no new toolchain to vet.

For protocol-level detail, use a purpose-built scanner with a real safety posture. scada-scanner (MIT licensed) detects Modbus TCP, S7, DNP3, BACnet, EtherNet/IP, IEC 60870-5-104, OPC UA, and CODESYS, and ships a safe-mode flag that should be your default rather than your fallback. Protocol-specific tools such as s7scan and plcscan fill gaps when a vendor or device family needs closer attention.

The selection criterion is not coverage breadth. It is whether the tool offers a passive or read-only mode, and whether its license actually lets you use it. Several of the broadest ICS scanners carry noncommercial licenses that unfortunately disqualify them from any paid engagement.

Build the guardrails in

Build the guardrails into the workflow, not into the operator's memory:

Safe mode on by default
Active OT scanning gated behind explicit per-target opt-in
Conservative concurrency and rate limits
An audit-log line on every active probe that records what ran, against what, and with which safety settings

This is where orchestration earns its keep: when the safe configuration is the shipped default, a tired analyst at the end of a long assessment cannot accidentally fast-scan a live PLC. The point of building it into the platform, rather than leaving it to discipline, is that the safe choice becomes the path of least resistance.

The honest summary

ICS and OT attack surface management is hard not because the tools are missing but because the field's central technique is the one move you frequently cannot make. The protocols answer honestly to anyone who asks. The devices misbehave when asked too loudly. The inventory resists every agent-based shortcut.

The teams that do this well are not the ones with the most aggressive scanners. They are the ones who treat passive discovery as the default, active probing as a privilege, and safe mode as a starting position rather than a setting they remember to enable.

In OT, the most professional thing your tooling can do is know when not to send the packet.

References

Cherepanov, A. (2017). Win32/Industroyer: A new threat for industrial control systems. ESET.
Cybersecurity and Infrastructure Security Agency. (2021). Compromise of a U.S. water treatment facility (Alert No. AA21-042A).
Dragos. (2017). TRISIS: Analyzing safety system targeting malware.
Dragos. (2026). OT/ICS cybersecurity year in review.
Falliere, N., Murchu, L. O., & Chien, E. (2011). W32.Stuxnet dossier (Version 1.4). Symantec.
Modbus Organization. (2012). Modbus application protocol specification V1.1b3.
National Institute of Standards and Technology. (2023). Guide to operational technology (OT) security (NIST SP 800-82 Rev. 3).
Radvanovsky, B., & Brodsky, J. (2014). Project SHINE (SHodan INtelligence Extraction) findings report. Infracritical.

Tools referenced

Tool	Purpose	Link
Nmap	Baseline scanner with mature ICS NSE coverage	github.com/nmap/nmap
Redpoint	Digital Bond ICS NSE script bundle	github.com/digitalbond/Redpoint
scada-scanner	Multi-protocol ICS scanner with safe mode (MIT)	github.com/geeknik/scada-scanner
uncover	Unified frontend for Shodan/Censys/etc.	github.com/projectdiscovery/uncover
s7scan	Siemens S7 protocol scanner	github.com/klsecservices/s7scan
plcscan	PLC enumeration	github.com/meeas/plcscan
Shodan	Internet-wide exposure search	shodan.io
Censys	Internet-wide exposure search	search.censys.io
HailBytes ASM	Open source ASM with OT-aware safe defaults	github.com/HailBytes/hailbytes-asm

Production-Ready MCP Servers in 60 Seconds (Auth, Rate Limits, Audit Logs Included)

David McHale — Sun, 24 May 2026 16:52:00 +0000

A TypeScript scaffold for production MCP servers that ships with pluggable auth, per-tool rate limiting, structured audit logs, and OpenTelemetry — so you can build the actual tools and not reinvent the boring parts.

Every MCP server tutorial I've read shows you how to register a single tool that echoes a string. Then they wave at "production concerns" and end the post.

Production concerns are the post.

@hailbytes/mcp-server-template is the opinionated TypeScript scaffold I use when I need to ship an MCP server that an enterprise will actually run. It comes with:

Auth — pluggable middleware for API keys, OAuth, and JWT
Rate limiting — per-client and per-tool, so one runaway agent can't take the whole server down
Audit logging — structured logs for every tool call and session event
OpenTelemetry — traces and metrics, so you can actually debug what your model did
Multi-transport — SSE, stdio, and HTTP, picked at scaffold time

Scaffold a new server

npx @hailbytes/create-mcp-server my-server --transport=sse

You get a directory you can cd into and npm run dev immediately.

Or embed it programmatically

import { createMcpServer, defineTools } from "@hailbytes/mcp-server-template";

const tools = defineTools([
  {
    name: "echo",
    description: "Echoes the input back.",
    inputSchema: { type: "object", properties: { message: { type: "string" } } },
    handler: async ({ message }) => ({ content: [{ type: "text", text: message }] }),
  },
]);

const server = await createMcpServer({
  name: "my-server",
  version: "1.0.0",
  transport: "sse",
  tools,
  auth: { type: "api-key", header: "X-Api-Key" },
  rateLimit: { requestsPerMinute: 60 },
  audit: { destination: "stdout" },
});

await server.start();

That's the entire "production MCP server" diff vs. the tutorial echo example.

Pair it with @hailbytes/mcp-security-scanner and you'll have a server that comes up secure by default and stays that way as you add tools.

npx @hailbytes/create-mcp-server my-server

Source: github.com/hailbytes/mcp-server-template — MIT licensed.

Your MCP Server Is Probably Overprivileged - Here's a Scanner For It

David McHale — Fri, 22 May 2026 20:51:00 +0000

MCP servers expose tools to LLMs, but most configs grant tools broader permissions than they need, ship without auth, and leak prompt-injection surface in tool descriptions. This scanner finds it before your model does.

Most MCP servers I've audited in the last few months had the same three issues:

A shell or fs tool was scoped to the entire filesystem when the use case needed exactly one directory.
The transport ran without auth because the local-dev SSE config got promoted to prod.
Tool descriptions echoed verbatim into prompts with no sanitization — a perfect injection surface.

@hailbytes/mcp-security-scanner is what I wish I'd had on day one of building MCP servers. It's a static + dynamic scanner for MCP configs and live endpoints that flags these patterns.

CLI

# Scan a local config
npx @hailbytes/mcp-security-scanner ./mcp-config.json

# Scan a live endpoint
npx @hailbytes/mcp-security-scanner https://my-mcp-server.example.com

# SARIF output + fail the build
npx @hailbytes/mcp-security-scanner ./config.json --output=sarif --exit-code

Programmatic

import { scan } from "@hailbytes/mcp-security-scanner";

const report = await scan({ configPath: "./mcp-config.json" });

if (!report.passed) {
  console.error(report.findings);
  process.exit(1);
}

What it checks

Overprivileged tools — broader permissions than the declared function needs (filesystem scope, shell access, network egress)
Missing or weak authentication — unauthenticated transports, missing token validation, plaintext secrets in config
Prompt injection surface — tool descriptions and output paths that pass through to model context without sanitization
Unsafe defaults — insecure transport defaults, verbose error exposure, CORS wildcards

The SARIF output drops straight into GitHub Code Scanning, so findings show up as alerts on PRs — same place your SAST results live.

npm install -g @hailbytes/mcp-security-scanner

Source: github.com/hailbytes/mcp-security-scanner — MIT licensed. Pairs nicely with @hailbytes/mcp-server-template if you want a scaffold that comes up secure by default.

Lint Your Phishing Templates Like You Lint Your Code

David McHale — Thu, 21 May 2026 15:50:00 +0000

You spent two hours crafting a convincing IT helpdesk pretext. You ship the campaign. The click rate is 2%.

It's not because employees got more savvy. It's because half your emails landed in spam, your tracking pixel was broken so you never saw the opens, and your {{.FirstName}} was actually {{.first_name}} and rendered as a literal string in every recipient's inbox.

I built @hailbytes/phishing-template-linter after the third campaign in a row where this happened.

Lint a directory of templates

npx @hailbytes/phishing-template-linter ./templates/

You get a per-template report of:

Broken or unknown merge tags
Missing tracking pixel / link rewrite hooks
Spam-trigger phrases (the obvious ones, but also Gmail's newer heuristics)
Deliverability red flags (mismatched display names, suspicious from-domain handling, bare URLs in plaintext)
Missing or malformed HTML/text alternatives

Use it programmatically

import { lint } from '@hailbytes/phishing-template-linter';

const result = lint(templateHtml);

// Errors fail the campaign launch; warnings get reviewed by a human
if (result.errors.length > 0) process.exit(1);

Wire it into CI

npx @hailbytes/phishing-template-linter ./templates/ --format=json > report.json

Drop that into your campaign-management pipeline and your phishing sims get the same pre-flight guardrails your production code already has.

It's GoPhish-format aware, so the merge-tag rules know about {{.FirstName}}, {{.URL}}, {{.TrackingURL}}, and the rest of the GoPhish template grammar.

npm install @hailbytes/phishing-template-linter

Source: github.com/hailbytes/phishing-template-linter — MIT licensed. Built as a companion to the HailBytes SAT platform but works standalone with any GoPhish-format templates.

Stop Pasting URLs into Security Header Sites - Use This CLI

David McHale — Wed, 20 May 2026 15:47:00 +0000

Get an A–F grade for your site's HTTP security headers without leaving the terminal. Use it as a library, a CLI, or a CI gate that fails deploys on regression.

The flow goes like this:

Ship a deploy.
Alt-tab to securityheaders.com.
Paste in the URL.
Squint at the report.
Realize someone removed the CSP three weeks ago and nobody noticed.

I wanted step 2 to be npx.

CLI

npx @hailbytes/security-headers https://example.com

Prints a color report to the terminal. Add --json to feed it into other tools, or just rely on the non-zero exit code on grade D or F to use it as a CI gate:

npx @hailbytes/security-headers https://staging.example.com || exit 1

Library

import { analyze } from '@hailbytes/security-headers';

const report = await analyze('https://example.com');
// { grade: 'A+', score: 95, percentage: 95, headers: [...] }

Or pass raw headers (for unit tests, or middleware that wants to grade its own response before sending):

import { analyzeHeaders } from '@hailbytes/security-headers';

const report = analyzeHeaders({
  'strict-transport-security': 'max-age=31536000; includeSubDomains',
  'content-security-policy': "default-src 'self'",
  'x-frame-options': 'DENY',
  // ...
});

What it checks

Seven categories — HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and the Cross-Origin family (COEP/COOP/CORP). Each header gets a numeric score, a status (good / warning / missing / error), and specific remediation strings you can drop straight into a ticket.

The grading scale is the obvious one:

Grade	Score
A+	≥ 90%
A	≥ 75%
B	≥ 60%
C	≥ 40%
D	≥ 20%
F	< 20%

npm install @hailbytes/security-headers

Source: github.com/hailbytes/security-headers — MIT licensed.

Score Any CVSS Vector Offline - v3.1 and v4.0, Zero Dependencies

David McHale — Wed, 20 May 2026 02:45:10 +0000

A 4 KB JavaScript library that parses and scores CVSS vectors with no network calls, no build step, and no third-party API. Use it in CI or drop a web component into any page.

Every vuln management tool eventually needs to score a CVSS vector. Most of them either call out to NVD's API (slow, rate-limited, requires network egress from your scanner) or pull in a fat dependency that drags an old crypto library along for the ride.

I built @hailbytes/cvss-calc because I wanted to score vectors inside a CI runner that didn't have internet access. It's a single, zero-dependency package that handles both CVSS v3.1 and v4.0.

Score a vector in two lines

import { calculate } from '@hailbytes/cvss-calc';

const result = calculate('CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H');
// { score: 9.8, severity: 'Critical', version: '3.1', vector: '...' }

v4.0 works the same way — the library parses the version from the vector string and dispatches to the right scorer. No flag, no branching at the call site:

const v4 = calculate('CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N');
// { score: 10.0, severity: 'Critical', version: '4.0', vector: '...' }

Or drop it into any page as a web component

<script type="module" src="https://cdn.jsdelivr.net/npm/@hailbytes/cvss-calc/dist/element.js"></script>

<hailbytes-cvss-calc vector="CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"></hailbytes-cvss-calc>

The component renders a full interactive calculator. Listen for cvss-calculated events to read the score from JS.

Where I'm using it

A pre-deploy CI gate that fails the build if any new CVE in the SBOM scores ≥ 7.0
A ticketing integration that auto-prioritizes Jira issues by severity
A static status page where each disclosed CVE renders a live, interactive calculator

Scoring follows the official FIRST CVSS v3.1 and v4.0 specs.

npm install @hailbytes/cvss-calc

Source and docs: github.com/hailbytes/cvss-calc — MIT licensed.

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.