<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en"><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://blog.copperwyre.com/feed.xml" rel="self" type="application/atom+xml" /><link href="https://blog.copperwyre.com/" rel="alternate" type="text/html" hreflang="en" /><updated>2026-10-05T17:35:54+02:00</updated><id>https://blog.copperwyre.com/feed.xml</id><title type="html">Copperwyre</title><subtitle>Blog posts, research, and experiments from Bertug Yemen.</subtitle><author><name>Bertug Yemen</name></author><entry><title type="html">What My MCP Honeypot Didn’t See</title><link href="https://blog.copperwyre.com/what-my-mcp-honeypot-didnt-see/" rel="alternate" type="text/html" title="What My MCP Honeypot Didn’t See" /><published>2026-10-05T12:15:16+02:00</published><updated>2026-10-05T12:15:46+02:00</updated><id>https://blog.copperwyre.com/what-my-mcp-honeypot-didnt-see</id><content type="html" xml:base="https://blog.copperwyre.com/what-my-mcp-honeypot-didnt-see/"><![CDATA[<p>Over a month ago, I deployed an MCP honeypot. A fake enterprise gateway with tools like <em>read_file, execute_command,</em> and <em>get_credentials</em>. Tempting names but no access to real systems. I wanted to see whether scanners would actually speak MCP, rather than treat it as another HTTP service.</p>

<pre class="protocol"><code>initialize &rarr; tools/list &rarr; tools/call</code></pre>

<h2>What I was watching for</h2>
<p>In its current configuration, the service advertises its MCP endpoint and simulated tool names through GET /. A visitor can send JSON-RPC requests to POST /mcp, with POST / accepting the same requests. There is a difference between checking whether an HTTP service exists and understanding what it offers.</p>

<p>A request to / tells me someone found the service. An initialize request suggests protocol awareness. A tools/list request shows an attempt to discover capabilities. A tools/call request gives me something more interesting: which capability they selected and what arguments they supplied. That progression was what I wanted to observe.</p>

<h2>What showed up instead</h2>
<p>What showed up instead was generic scanning. That was expected, but I was hoping to see MCP-aware attacks. In the logs I reviewed, I counted 64 scanner-like events: 41 with Nmap user agents and 23 with browser-like user agents in recurring scan bursts. <em>This count excludes deployment checks and ambiguous or test-like scripted traffic.</em></p>

<p>One recurring pattern stood out: pairs of requests targeting /, arriving at roughly the same time each evening. That is consistent with scheduled scanning, but it does not tell me who was behind it or whether the intent was malicious.</p>

<p>No external requests to /mcp were recorded. No external MCP-aware sequence appeared.</p>

<h2>My hypothesis: attack economics</h2>
<p>My hypothesis is that this comes down to <strong>attack economics</strong>. Speaking MCP is not particularly difficult. You do not need an autonomous AI agent to initialize a connection and list tools. The interesting question is whether finding accessible MCP servers and turning their capabilities into something valuable offers a better return than familiar attack paths.</p>

<p>My expectation is that the economics could change as deployments become more common and discovery and testing become easier to automate. The incentive would come from useful access, not simply from the protocol being new. This honeypot does not prove that explanation. Low traffic, limited visibility, or never encountering an MCP-focused scanner could explain the same result.</p>

<p>If your existing scanning playbook still produces results, why change it?</p>

<p>The question I&rsquo;m watching is not just whether attackers can speak MCP.</p>

<p><strong>It is when doing so becomes worth their effort.</strong></p>]]></content><author><name>Bertug Berkay Yemen</name></author><summary type="html"><![CDATA[Over a month ago, I deployed an MCP honeypot. A fake enterprise gateway with tools like read_file, execute_command, and get_credentials.]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://blog.copperwyre.com/assets/articles/mcp-honeypot-cover.png" /><media:content medium="image" url="https://blog.copperwyre.com/assets/articles/mcp-honeypot-cover.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">The Defender’s Window Is Closing. It’s Time to Defend at AI Speed.</title><link href="https://blog.copperwyre.com/the-defenders-window-is-closing/" rel="alternate" type="text/html" title="The Defender’s Window Is Closing. It’s Time to Defend at AI Speed." /><published>2026-07-28T01:55:14+02:00</published><updated>2026-07-28T01:55:45+02:00</updated><id>https://blog.copperwyre.com/the-defenders-window-is-closing</id><content type="html" xml:base="https://blog.copperwyre.com/the-defenders-window-is-closing/"><![CDATA[<p>Patch management has always rested on a quiet assumption: once a vulnerability goes public, defenders have <em>some</em> runway (often weeks) before it's exploited in the wild. Everything built on that assumption; the triage queue, the maintenance window, the monthly cycle depends on it being true. It isn't any more.</p>

<p><em>Source: <strong>Zero Day Clock: <a href="https://zerodayclock.com/">https://zerodayclock.com/</a></strong></em></p>

<figure class="article-figure">
  <a href="/assets/articles/zero-day-clock-tte.png" aria-label="View the Zero Day Clock chart at full size">
    <img src="/assets/articles/zero-day-clock-tte.png" alt="Zero Day Clock screenshot showing mean and median time-to-exploit alongside weaponized exploit counts for 2018 to 2026." width="1315" height="1000" loading="lazy" decoding="async">
  </a>
  <figcaption>Zero Day Clock TTE: <a href="https://zerodayclock.com/">https://zerodayclock.com/</a></figcaption>
</figure>

<p>The clock tracks Time-to-Exploit (TTE) the gap between a CVE's public disclosure and its first confirmed in-the-wild exploitation. The trend is unambiguous:</p>

<ul>
  <li>Mean time-to-exploit has collapsed from roughly 2.3 years in the earliest cohorts to about three weeks by 2025. In 2026 it reads in hours and keeps crossing zero, so it has stopped being a countdown at all.<em> (Figure moves daily)</em></li>
  <li>True zero-days, CVEs exploited on or before disclosure day, have climbed from under 20% toward ~80% in the most recent cohort.</li>
  <li>The one-year window disappeared around 2021 and the one-month window around 2025; the one-week / one-day thresholds fall in 2026, with a one-hour window <em>projected</em> for 2027.</li>
</ul>

<figure class="article-figure">
  <a href="/assets/articles/time-to-exploit-milestones.png" aria-label="View the Time-to-Exploit Milestones image at full size">
    <img src="/assets/articles/time-to-exploit-milestones.png" alt="Zero Day Clock milestone cards showing one-year, one-month, one-week, and one-day thresholds, plus projected one-hour and one-minute thresholds." width="744" height="241" loading="lazy" decoding="async">
  </a>
  <figcaption>Time-to-Exploit Milestones: <a href="https://zerodayclock.com/">https://zerodayclock.com/</a></figcaption>
</figure>

<p><em>(The pre-2026 figures are observed and settled; the current-year readings will keep moving as the data matures, but the direction is unmistakable: disclosure and exploitation now happen almost together.</em></p>

<p>When exploitation coincides with disclosure, "read the advisory, then react" stops working. You can't out-hire or out-hour a speed problem. Defense has to move onto a different footing: continuously perceive risk across the whole environment, reason about what actually matters, and act at machine speed, with humans setting direction and keeping control of the consequential calls.</p>

<p>That splits the problem in two. <strong>Upstream</strong>, you find and fix the vulnerabilities in code you own before they're ever published, so the bug never becomes a public CVE, and there's no disclosure-to-exploitation race to lose. <strong>Downstream</strong>, for everything you don't control, the third-party CVEs the clock is really measuring, you can't out-patch the window any more, so you have to go looking. That means thinking like the attacker continuously; probing your own estate for the paths that actually lead somewhere, deciding which of them genuinely matter, and closing them at the same tempo attackers now operate. Neither is something humans can sustain at the required speed alone; both are things a coordinated system of agents can.</p>

<p>This isn't hypothetical. Microsoft's "<strong>codename</strong> <strong>MDASH"</strong> (<a href="https://www.microsoft.com/en-us/security/blog/2026/05/12/defense-at-ai-speed-microsofts-new-multi-model-agentic-security-system-tops-leading-industry-benchmark/">Defense at AI speed: Microsoft&rsquo;s new multi-model agentic security system tops leading industry benchmark | Microsoft Security Blog</a>) is one public example of the<strong> upstream half</strong>, over a hundred specialized agents that discover, debate and prove exploitable bugs end-to-end, before disclosure.</p>

<p><strong>Project Perception (</strong><a href="https://blogs.microsoft.com/blog/2026/07/27/rethinking-security-for-the-age-of-ai/">Rethinking security for the age of AI - The Official Microsoft Blog</a><strong>) </strong>is an example of the <strong>downstream half</strong>. It's built as three teams of agents rather than one: red team agents that identify paths to compromise before an attacker can exploit them, blue team agents that investigate and reason over context to work out what represents meaningful risk, and green team agents that take corrective action and strengthen defenses across the environment. A closed loop of discover, evaluate, improve; running continuously, with humans in control of every consequential action.</p>

<p>The lesson underneath is worth holding onto, the advantage doesn't come from any single model or tool, but from the <strong>system and the discipline built around it</strong>. Chasing the newest model is the wrong reflex; building the loop that can perceive, reason, and act is the right one.</p>

<p>Put it together and the picture is clear. The Zero Day Clock quantifies the threat; agentic, machine-speed defense is the shape of the response. Human-speed discovery and triage are now structurally outpaced, which doesn't make security teams obsolete, it changes what we're for: setting the strategy and the guardrails, and keeping humans in control while the machines carry the load.</p>

<p>Whether organisations respond through agentic systems, automation, or other approaches, the underlying challenge is the same: security operations must increasingly operate at machine speed, while humans remain responsible for strategy, governance, and consequential decisions.</p>

<p><em>Disclosure: I work at Microsoft as a Cloud Solution Architect. The views expressed here are my own and all referenced sources are publicly available.</em></p>]]></content><author><name>Bertug Berkay Yemen</name></author><summary type="html"><![CDATA[Patch management has always rested on a quiet assumption: once a vulnerability goes public, defenders have some runway (often weeks) before it's exploited in the wild.]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://blog.copperwyre.com/assets/articles/defenders-window-cover.png" /><media:content medium="image" url="https://blog.copperwyre.com/assets/articles/defenders-window-cover.png" xmlns:media="http://search.yahoo.com/mrss/" /></entry></feed>