Coder Legion - Recent posts tagged infosec

Gravwell AI Security Agents Have One Hard Limit. Everything Else Is a System Prompt They Can Ignore.

Mon, 14 Sep 2026 12:00:00 +0000

An alert fires in one of Gravwell's own data centers at 3 a.m. Before PagerDuty wakes anyone up, an agent runs a set of scoped queries, pulls together enough context to orient a half-asleep analyst, and drops a plain-language playbook in Slack. By the time the phone rings, there's something to act on instead of a raw alert and a blinking cursor.

That's the job of the new Alert Triage Agent, one of five AI agents the security data platform shipped this week in its 5.10 release, alongside agents for case investigation, admin questions, nightly summaries, and platform hygiene. All five live inside Logbot, Gravwell's chat interface, and pull their own context straight from live telemetry, detections, and system state through an MCP server, instead of working from a case file a human assembled.

That's also exactly the kind of autonomy Gravwell CEO Corey Thuen told me he's wary of. At Black Hat, Thuen said unsupervised junior analysts paired with LLMs is "a recipe for disaster," and argued security work should be broken into deterministic pieces — scripts, API calls, steps with knowable outcomes. Five agents deciding on their own what to query sound like the opposite of that. So I put it to David Fritz, Gravwell's VP of research, who built the framework these agents run on.

Fritz didn't dodge it. Full autonomy — "loop forever, open-source-agent style," as he put it — is already possible in the framework, but Gravwell hasn't exposed it to customers yet; that's coming with the 6.0 release later this year. What ships today is built as a graph: steps that fan out, fan in, and loop, with constraints set at each step. An alert triage run can execute certain queries and nothing else — no new assets, no reaching the public internet — before handing findings to the next step, which writes the playbook.

"That graph is the only deterministic part," Fritz told me. Inside any single step, there's no script running the show — it's "essentially just a system prompt, a list of tools it's allowed to hit, and off it goes." State from each step folds into the next until the whole thing produces a final write-up. In practice, that's asking case-agent to check for ingest spikes and getting back a runnable query — start=-24h tag=* count over 1h | chart count — with a button straight to the query editor, not a paragraph of advice.

I asked what actually stops an agent from pulling more than it should — whether "read-only until told to save" is a permission the model respects or a technical wall it can't cross. Mostly the former. Grant an agent write access, and it can create or modify assets. The one thing it can't do under any configuration is delete. Past that, Gravwell relies on the same tool every AI product relies on: telling the model what not to do, and hoping it listens. Fritz pointed to Claude Code's own system prompt as the same problem. "It can choose to ignore that."

That extends to data quality. If the telemetry an agent works from is incomplete or has been quietly manipulated, Fritz said flatly, "the agent is not going to be any more useful than a human looking at that bad data" — everything downstream still presumes what's in Gravwell is ground truth. And on Thuen's point that most teams keep only 60 to 70 percent of their logs due to storage cost, Fritz argued agent frameworks reward the opposite instinct: ingest everything raw and structure it at query time, since an LLM can hold context no human could, and whatever's thrown away at ingestion can't be recovered later.

What's real about the audit trail, versus an LLM narrating its own reasoning after the fact? The tool calls, Fritz said — those are logged and reconstructable regardless. A separate telemetry layer fingerprints otherwise stateless chat sessions with a transaction ID, so an analyst can rebuild one "the same way you'd reconstruct a session in Wireshark," including any MCP calls Gravwell makes as a client to other servers. Running their own Claude Code traffic through that pipeline, Fritz found a simple "hello world" logs three megabytes of text — mostly Claude's own 70-kilobyte system prompt. "It kind of dispels some of the magic," he said, "when you see just how dumb these things are, literally."

Access is scoped through what Gravwell calls CBAC in its own admin documentation — an MCP server inherits exactly what its token was granted, nothing more, and an agent runs as the user who invoked it, with tools whitelisted per step. Gravwell also pays outside teams to audit the product, including the MCP layer: prompt injection attempts, binary extraction, the works.

When I asked whether a security vendor's own agent layer becomes the next attacker target, Fritz pushed back on the premise. The bigger blind spot, he argued, is that nobody has real visibility into what ordinary LLM use is already doing — even enterprise tiers of Claude or GitHub Copilot don't expose what data users are sending out. "It's like not knowing how many printers are on your network," he said, except worse, since making sense of it means running AI against your own AI logs. "That's a billion-dollar idea" nobody's built yet.

Asked about the honest failure mode a month in, Fritz named two unglamorous ones: storage cost catching Splunk migrants off guard once they stop discarding data they didn't realize they'd been discarding, and detection rot — rules that quietly stop firing when an upstream source changes. Gravwell's own audit agent found one internally that had gone silent since March, because someone switched ingestion to a different tag, and offered to fix it on the spot.

His real 12-month worry isn't security. It's economics — whether LLM token pricing, propped up by venture money, survives an eventual "reckoning," his word for the day, when costs stop being subsidized. That's part of why Gravwell runs its own GPU compute for customers who want it, even though open-weight models still trail the frontier. It's also where he landed, unprompted, on data sovereignty: Gravwell's hosted LLM service doesn't train on or retain customer prompts, since sending cybersecurity telemetry to a model that might train on it is "concerning." For a company selling agents that read your logs, that's arguably the guardrail doing the most work.

Finite State's Larry Pesce: Attackers Are Coming Back for Infrastructure Everyone Forgot to Watch

Tue, 08 Sep 2026 19:57:45 +0000

Over the past week, attackers have been hijacking MikroTik routers at scale, exploiting a chain of RouterOS vulnerabilities CERT Polska calls "MikroTrick." Two flaws, an SSH authentication bypass and a privilege escalation triggered by a specially crafted username, combine to give an unauthenticated attacker full administrative control of any exposed device. As of a September 5 scan, the Shadowserver Foundation counted more than 122,500 MikroTik devices with SSH reachable from the open internet, concentrated in Brazil, the U.S., Indonesia, the Czech Republic, and Ukraine. Exploitation began September 2, a day before MikroTik shipped patches and three days before CERT Polska published the technical detail defenders needed to detect it.

There's a detail in how these flaws were found that's easy to miss under the exploitation headlines: CERT Polska's team used OpenAI's GPT-5.5-cyber and GPT-5.6-sol models, through the vendor's Government and Trust Agency Collaboration program, to automate version comparison, RFC analysis, and binary review, with researchers independently verifying every finding before disclosure. That's AI accelerating the defensive side for once, not just the offensive one, though the exploitation timeline that followed shows how little breathing room that head start actually buys.

The pendulum, not the CVE, is the real story

Larry Pesce, VP of Services at Finite State, argues the specific vulnerabilities matter less than the pattern they fit into. "This is a very old argument dressed up in new CVEs," he said. "Network infrastructure was the original attack surface, back when worms and DNS cache poisoning and route hijacking were the front page news."

His read on the last two decades of attacker behavior is a pendulum, not a straight line. Defenders hardened the network perimeter, so attackers moved to the endpoint: client-side exploits, macros, phishing. EDR got good at watching endpoints, so attackers moved to cloud and identity, then to the sprawl of IoT and connected devices nobody was monitoring at all. Now, Pesce argues, the swing is back toward infrastructure. "Edge appliances, VPN gateways, and routers like these MikroTik boxes are attractive again for exactly the reason they were attractive twenty years ago: almost nothing runs an agent on them, almost nobody patches them promptly, and almost nobody actually knows how many of them they have exposed to the internet."

The inventory gap nobody closed

Pesce's sharpest point is about where organizational attention actually went over the past ten years. "Most organizations have spent the last decade building real inventory and telemetry for laptops and servers. Very few have done the same for the network gear sitting between those systems and the internet," he said. A router doesn't show up in an EDR console. It usually isn't in the CMDB unless someone remembered to add it. It gets touched during install and then left alone until something breaks.

That gap is exactly what a campaign like this is built to exploit, and it's why Pesce doesn't find 122,500 exposed devices a shocking number so much as a predictable one. "Nobody set out to leave that many boxes reachable on purpose. It's an accumulation of the same basic inventory gap, repeated at scale."

A numbers game, not a single-target intrusion

Pesce also draws a distinction worth sitting with: compromising a router at scale usually isn't about that one router. "It's about building a broad, disposable base, proxy points, relay infrastructure, a wide net of footholds, rather than a single surgical intrusion into one high-value target," he said. That's a different economic model than the supply-chain-style precision compromise that tends to dominate security headlines, and it changes what defense needs to look like. "You're not trying to stop one determined actor from reaching one target. You're trying to avoid being one anonymous node in somebody's infrastructure, which is a numbers game, and numbers games get won or lost on unglamorous things like patch cadence and knowing what you actually have exposed."

What MikroTik is asking affected users to do

Beyond patching, MikroTik's advisory asks administrators to actually check whether they've already been compromised. Updated RouterOS versions can flag a device's status after checking logs; a device marked "Flagged" should be treated as compromised outright, not just patched and left alone. Simply updating isn't sufficient on its own; the compromise can predate the fix. CERT.LV, for its part, said it had already confirmed a dozen compromised devices in Latvia out of several thousand exposed there, notified critical infrastructure operators, and continues tracking the fallout.

Not really a MikroTik story

Pesce's closing point is the one worth carrying into any infrastructure review this prompts. "None of this is new. It's the same swing the industry has made every few years: infrastructure, then endpoint, then cloud, then device, and back to infrastructure again, each time landing wherever defenders most recently stopped paying attention," he said. "The lesson isn't really about MikroTik. It's that 'know your inventory' never stopped being step one, and the network layer is overdue for the same rigor we finally applied to endpoints."

For developers and architects, the practical takeaway isn't a MikroTik-specific patch checklist. It's a question worth asking about every edge appliance, VPN gateway, and router sitting on the network: does it show up anywhere your team actually looks, or has it just been sitting there since install, waiting for its turn?

AI Can Find Your Vulnerabilities. It Still Can't Own What Happens Next

Thu, 27 Aug 2026 12:00:00 +0000

Earlier this year, Anthropic gave Apple, Microsoft, Google, Amazon and a handful of other companies access to an AI agent called Mythos and turned it loose on their code. Project Glasswing, as the initiative became known, found bugs that had survived decades of human audits and fuzzing, including one flaw that had been sitting in OpenBSD for 27 years. It also found a lot more than anyone could fix. Fewer than 1% of the vulnerabilities Mythos discovered ever got patched.

That gap is the story Victor Wieczorek keeps coming back to. Wieczorek is SVP of Offensive Security at GuidePoint Security, where his teams run penetration tests and red team engagements across application security, cloud, infrastructure and operational technology. When I asked him where AI still falls short against a human pen tester, he pushed back on the question itself.

"It's really a human versus a steam engine kind of idea," Wieczorek said. "AI [is] so good at finding needles in a haystack. What I prefer to focus on is everything downstream of that. After you find the bug, after you identify the remediation, then what do you do about it?" Glasswing, he said, "talks to a lot of complexity" in that narrative. Finding the flaw was never really the bottleneck. Getting an organization to understand it, trust it and act on it always was.

That downstream work is where Wieczorek says large language models still run into trouble, and not in the way most people expect. His teams see hallucinated CVEs and misread exploitation chains, but the deeper issue is how AI systems handle failure. "You're putting a lot of trust in what amounts to a coin flip of that AI's attention," he said. A tool can misread its own output — an error message, a log line — as a new instruction and steer off in an unpredictable direction. A human pen tester, hitting the same dead end, intuits what to try next. An LLM is just as likely to hallucinate a new one.

That's not a reason to keep AI out of offensive security. Wieczorek's team has used it since the earliest ChatGPT releases, first for open-source intelligence gathering and understanding how a target organization's systems fit together. It's a reason to keep a human owning what the AI produces. Wieczorek doesn't mince words about teams that let an agent run without watching how it got its results: "I would say it is... negligence." He compares it to a hammer. "If I'm swinging a hammer and I slam my thumb, I'm not blaming the hammer." A pen tester is hired to deliver a professional judgment a client can act on, and no model can carry that obligation. It can only feed the person who does.

That principle gets tested constantly on the defensive side too, where Wieczorek says agentic tools keep creating problems nobody planned for. Three years ago, when Copilot first landed inside Microsoft 365, one of his testers logged into a client's portal, asked Copilot who the security leaders were and where they kept sensitive files, and got refused — then simply said he'd been hired to run a security audit. Copilot handed over the domain administrator credentials. Microsoft has since closed that specific hole, but Wieczorek says the underlying pattern hasn't gone away: agents deployed with real access, coaxed into acting outside their intent by nothing more sophisticated than a well-worded prompt.

The scale of that exposure is what worries him most now. Organizations are standing up AI agents faster than they can track them, often without an expiration date on the access those agents hold. "We're seeing where long-tooth agents who have been around for a long time... could be running now in perpetuity," he said, with nobody watching what they can still touch. He's only half-joking when he calls it "agentic debt" — the security equivalent of the technical debt teams already know how to ignore, except this version comes with standing credentials.

None of this means organizations should wait for the tooling to mature. Wieczorek's advice for developers and security engineers evaluating agentic AI tools is to stop grading them pass/fail against a benchmark and start tracking how they drift over weeks and months of real use — whether the failure modes are getting caught and fixed, or quietly piling up. It's the same discipline his team applies to its own tools, and the same discipline he says most deployments skip.

Where this ends up, in Wieczorek's view, looks less like AI replacing pen testers and more like a security operations center: agents handling first-line monitoring, discovery and alerting, escalating up through tiers to the humans who own the judgment calls that matter. He's most impatient about applying that model to operational technology — the systems running energy, manufacturing and pharmaceutical infrastructure, where a patch can't just be pushed at 2 a.m. without knowing what happens to the people depending on that system staying up. "You can't just automatically turn them off," he said. Getting AI-assisted security into that world will take more than a better model. It'll take the same thing offensive security has always required: someone willing to own the outcome.

I Handed Claude Code the Keys. Turns Out I'm Not the Only One Using Them.

Tue, 16 Jun 2026 23:30:08 +0000

For two years the pitch on AI coding agents has been "let it run, you don't need to watch it." I've been pulling on what actually breaks when you take that literally, and the uncomfortable answer is that the scariest failures aren't the agent going rogue. They're the agent doing exactly what it's told -- faithfully -- while someone other than you is the one feeding it the instructions.

A supply chain worm this spring figured that out before most of us did. It didn't hide in a shell profile or a cron job. It wrote itself into the AI agent's own config file, because that's the process that boots every time you sit down to work, holds your tokens, opens your files, and runs commands on a loop. Pull the bad package, clear the cache, do everything muscle memory tells you -- and it's still sitting there waiting for the next session.

What stuck with me is that none of the controls we lean on failed by accident. The approval prompt, the command allowlist, the provenance attestation -- every one was designed for a human reviewing the step before it happens. Then the same vendors shipped walk-away mode on top. You can't sell "you don't need to watch it" and "the allowlist will protect you" in the same breath. One of those is load-bearing and the other isn't, and attackers already know which.

I wrote the full breakdown -- three real CVEs, three layers of the same stack failing along the same fault line. Where's your line on letting an agent run unsupervised?

Read the article here: https://coderlegion.com/20732/i-handed-claude-code-the-keys-turns-out-im-not-the-only-one-using-them

Understanding HTTP Request Smuggling Beyond the Basics

Sat, 02 May 2026 18:18:48 +0000

HTTP Request Smuggling is often described as a technique to bypass WAFs or exploit parsing inconsistencies. That explanation is technically correct, but incomplete.

The real issue is not about crafted payloads. It is about how different components in a web architecture interpret the same HTTP request differently.

Where the problem actually occurs

In modern web systems, a single request may pass through multiple layers:

reverse proxy or load balancer
CDN or caching layer
application server

Each layer may implement HTTP parsing slightly differently, especially when handling request boundaries.

This creates a situation where one request can be interpreted in more than one way depending on the component processing it.

The core vulnerability

At its core, HTTP Request Smuggling is caused by:

inconsistent interpretation of where one HTTP request ends and the next begins.

This mismatch creates a desynchronization between frontend and backend systems.

Impact of this inconsistency

Depending on the environment and configuration, this can lead to:

request desynchronization between users
cache poisoning through malformed request boundaries
session handling inconsistencies
bypass of security controls implemented at proxy level
unexpected request routing behavior

Key insight

Techniques like CL.TE or TE.CL are not the root issue. They are simply ways this inconsistency becomes exploitable in practice.

The fundamental problem is:

different HTTP parsers following slightly different rules in a distributed system.

Why this class of bug is dangerous

This issue is difficult to detect because it does not rely on breaking application logic directly. Instead, it exploits ambiguity in protocol interpretation across infrastructure layers.

Traditional security controls such as WAFs are often not sufficient because they typically operate on a single perspective of the request.

HTTP Request Smuggling is ultimately not an application vulnerability in the traditional sense. It is a system-level parsing inconsistency.

I Built an OSINT Tool to Automate Recon Across 100+ Platforms

Tue, 31 Mar 2026 16:52:29 +0000

Manual reconnaissance is slow, repetitive, and honestly… pretty inefficient.

So I built GhostIntel — a lightweight OSINT tool that automates recon across multiple platforms in one place.

https://github.com/ruyynn/GhostIntel

What is GhostIntel?

GhostIntel is an open-source tool designed to simplify how you gather publicly available information.

Instead of jumping between different tools or manually searching, GhostIntel helps automate the process and return structured results.

⚙️ Features

Username enumeration across 100+ platforms
Email footprint analysis
Domain reconnaissance
Basic phone lookup
Modular and easy to extend

Why I built this

While learning about OSINT and reconnaissance, I noticed that most tools are either too complex or too fragmented.

I wanted something that is:

Simple
Fast
Actually useful

So I built GhostIntel as a personal project to learn while solving a real problem.

️ Tech Stack

Python
CLI-based interface
JSON-based configs

Getting Started

git clone https://github.com/ruyynn/GhostIntel
cd GhostIntel
pip install -r requirements.txt
python ghostintel.py -h

What’s next?

I’m currently working on:

Report generation (HTML / PDF)
Better data correlation
Graph visualization
More platform integrations

Feedback

This project is still evolving, and I’d really appreciate feedback from the community

If you find it useful, consider giving it a ⭐ on GitHub

Thanks for reading

Human-in-the-Loop AI - The New Attack Surface in Industry 5.0

Wed, 07 Jan 2026 16:16:24 +0000

Industry 5.0 brought humans back into automated industrial systems with good intentions. The idea was simple: combine machine intelligence with human judgment to make better, safer decisions.
The common belief is that
"If a human is involved, the risk goes down."

What Really Changed in Industry 5.0

In Industry 4.0:

AI analyzed data
Automation executed actions
Humans supervised the systems

In Industry 5.0:

AI makes recommendations
Humans make the final decision
Systems carry out that decision

This shift creates a new trust boundary. The human becomes the final decision point, effectively, the last control interface in the system.
Unlike machines, humans:

Don't behave consistently
Don't always document decisions
Don't fail in obvious ways
Can be influenced without touching the network at all

This is where the risk begins.

Attack Surface 1: Manipulating Human Judgment

Human-in-the-Loop systems rely on people to validate AI output.
But validation is not the same as verification.
Attackers don't always need to tamper with the AI model or the data.
Sometimes, they only need to influence how the output is perceived.
For example:
An AI flags a fault as "moderate" instead of "critical"
Operators see similar alerts every day
Fatigue sets in
The shutdown recommendation is ignored
A failure follows

There is no malware involved, no intrusion alerts are triggered, and no systems appear compromised. Instead, the attack succeeds through carefully engineered doubt, hesitation, and human error, allowing failure to unfold quietly without ever touching the technical defenses

Attack Surface 2: Trusting the Interface Too Much

Human-in-the-Loop decisions depend heavily on what people see on screens:
Dashboards
HMIs
Confidence scores
Risk levels
"Recommended action" messages

Attackers increasingly focus on how information is presented, not just on the data itself.

If a system says:
"Low risk"
"85% confidence"
"Safe to defer maintenance."

Most people instinctively trust those signals. This is not traditional data poisoning; it is trust poisoning, and it remains a blind spot in most OT security programs

Attack Surface 3: When AI Quietly Becomes the Authority

In experienced plants, operators traditionally rely on:
Their training
Their experience
Their intuition

Industry 5.0 slowly changes that balance. Over time, the message becomes:
"The AI has more data than you."

As a result:
Operators challenge recommendations less
Overrides become rare
Manual checks disappear

The human may still be described as "in the loop," but in reality, control has quietly shifted away. As trust in the system grows, even a flawed AI recommendation can pass through without being challenged or questioned.

Attack Surface 4: No One Clearly Owns the Decision

hen AI suggests an action and a human approves it, responsibility becomes unclear.
After an incident:
Vendors blame misuse
Operators blame the AI
Engineers blame the configuration
Security says no breach occurred

This lack of ownership is a security weakness. Attackers benefit when:
Decisions don't have clear owners
Overrides aren't logged properly
Accountability is assumed instead of defined

Human-in-the-Loop systems without strong accountability create perfect blind spots.

Attack Surface 5: Increased Insider Risk

Industry 5.0 assumes humans add ethics and responsibility.

From a security perspective, humans also add unpredictability.
A malicious or compromised insider no longer needs:

PLC access

Network credentials

Administrative privileges

They only need:

Approval authority

The ability to override AI decisions

"Operational discretion"

Human-in-the-Loop design unintentionally amplifies insider impact.

Attack Surface 6: Pressure-Based Decision Exploits

Most HITL decisions are made under stress:

During alarms
During outages
During peak production
During shift changes
Attackers exploit timing, not technology.

They create situations where:

Decisions must be made quickly
Humans choose speed over analysis
Oversight is reduced
Urgency defeats even the best security controls.

Why Traditional OT Security Doesn’t Catch This

Firewalls cannot protect human judgment, intrusion detection systems cannot detect hesitation, and Zero Trust architectures offer no defense against misplaced confidence in human decision-making.

These risks exist above the network layer:

In workflows
In authority structures
In cognitive bias
In governance gaps
Most OT risk assessments never look there.

What Securing Human-in-the-Loop Really Means

This problem is not solved by:

Better AI models
More dashboards
Generic training sessions
It requires treating human decisions as security-critical events. That means:

Clear ownership of AI-assisted decisions
Logging and auditing human overrides
Dual approval for high-impact actions
Showing uncertainty, not artificial confidence
Limiting who can intervene and when
Preparing incident response plans for bad decisions, not just breaches

The Reality of Industry 5.0

Industry 5.0 did not automatically make industrial systems safer; instead, it made attacks quieter, more subtle, and harder to detect. Human-in-the-Loop AI is not an inherent safeguard but a new attack interface, one that rarely shows up in logs or security alerts. Until organizations recognize human judgment as part of the attack surface, Industry 5.0 will remain intelligent and human-centric, yet dangerously exposed.