[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"post:honeypots-see-attacks-first":3},{"post":4,"author":19,"controls":26,"vendors":43,"more":44},{"slug":5,"kind":6,"title":7,"excerpt":8,"cover_image_url":9,"cover_image_alt":10,"author_name":11,"published_at":12,"body_md":13,"author_title":14,"regulation_refs":15,"ai_assisted":16,"cover_ai_generated":16,"updated_at":17,"reading_minutes":18},"honeypots-see-attacks-first","analysis","Honeypots see attacks before the patch, but how do companies act on it?","Amazon's decoys are probed within 90 seconds of going online. What deception and honeypots do for the security community, and six small steps that let an ordinary team act on early warnings with the people it has.","https:\u002F\u002Fzbqafrnxsxwbarztrtqp.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fresources\u002Fblog\u002Fai-1f0002b6-fc7e-49f4-9d6c-fb41c50beb17.png","A decoy server is immediately surrounded by incoming attack probes and attempts on a dark digital background.","Marcus Lenngren","2026-10-26T06:27:00+00:00","In 2023 Amazon described what happens when it puts a new decoy server on the internet. Within about 90 seconds, scanners have found it. About three minutes later, on average, someone tries to break in. The decoys are part of MadPot, Amazon's own global network of honeypot sensors, and at the time they logged more than 100 million probes a day.\n\n> **90 seconds** until a new server on the internet is found.\n>\n> **3 minutes** until someone tries to break in.\n>\n> **80 percent** of attack spikes on VPNs and firewalls were followed by a new vulnerability within six weeks.\n\nThose numbers are worth keeping in mind. They are the time it takes for an exposed system to become a target. They are also a reminder that someone, somewhere, sees most attacks before they reach you. The hard part is not finding out but being able to act on it with the people and processes you actually have.\n\nThis piece comes in two parts. First: what deception and honeypots really do, and why the security community gets so much out of them. Secondly: what an ordinary company can do with that without a research team and without adding one more feed nobody reads.\n\n## Part 1: What deception does\n\n### A system nobody should touch\n\nA honeypot is a system that has no legitimate users. No customer logs in to it, no colleague opens it, no business process depends on it. That is the whole trick. Because nobody has a reason to touch it, every touch means something. A scan, a login attempt, an exploit: all of it is signal, with almost none of the noise a normal production system produces.\n\nDeception is the broader family. It covers full decoy servers, but also much smaller things: a fake cloud access key left in a config file, a document on the file share that phones home when opened, an admin account that exists only to be stolen. Security people call the small ones canaries or honeytokens. They do not stop an attack, but they tell you very reliably and early that one is happening. When one of the fakes is used or leaked, an alert goes off, and you also learn which guardrail failed.\n\nThe idea works at two very different scales.\n\n### On the internet: early warning for everyone\n\nAt internet scale honeypots are how the community learns what attackers are doing right now. Amazon is the large example, but not the only one. GreyNoise, the Shadowserver Foundation and the SANS Internet Storm Center all run sensor networks that watch the background traffic of the internet and publish what they see.\n\nSome of what comes out of this is remarkable:\n\n- **Sandworm against firewalls.** Amazon's sensors caught Sandworm, the Russian military group behind Cyclops Blink, trying to exploit WatchGuard firewalls. Amazon warned an affected customer, who fixed the problem.\n\n- **Volt Typhoon, years early.** The same sensors had been receiving a payload with a distinctive signature since August 2021. Amazon passed what it found to government authorities, and it fed into the May 2023 joint advisory on Volt Typhoon, the Chinese group that pre-positions inside critical infrastructure.\n\n- **Warnings before the vulnerability is public.** GreyNoise studied 216 spikes in attack traffic against edge products from September 2024 onwards. In 80 percent of cases a new CVE for the same technology followed within six weeks, and in half of them within three weeks. The pattern showed up only for edge products: VPNs, firewalls and remote access tools.\n\nThat last finding is the one to remember. Attackers often start probing a product before the flaw they are probing for has a name. When the honeypots see a sudden surge against one VPN brand, something is usually coming.\n\nThe community also turns this into action that protects everyone, not only the people who read the reports. Amazon says it shared close to 2,000 botnet command servers with hosting providers and national CERTs in the first half of 2023, and that some were taken offline within 48 hours. Blocklists, takedowns and advisories all start with someone watching a system nobody should touch.\n\n### Inside your network: tripwires\n\nInside a company, deception does a different job. It is not intelligence about the whole internet, it is a tripwire for your own environment.\n\nAttackers who get in have to look around. They search file shares for passwords, read config files for keys, and query the directory for admin accounts. Put a few believable fakes exactly where they will look, and the attacker's own reconnaissance becomes your alarm. A real employee has no reason to use a fake AWS key or log in as an admin account that does nothing, so when it happens, you know.\n\nThis is why deception has an unusual property for a security tool: it is quiet. Most detection struggles with false positives. A well-placed canary barely produces any, because the only way to trigger it is to do something nobody legitimate does. For a small team that cannot staff a 24\u002F7 SOC, that is the attraction.\n\nIt is also honest to say what deception does not do. It does not patch anything and does not block anything. It buys you time and certainty, and it is only worth something if someone acts on it.\n\n---\n\n## Part 2: What you can actually do\n\nHere is the uncomfortable part. Most companies already have more warnings than they can handle. The vulnerability scanner lists thousands of findings. The threat intelligence feed sends a dozen advisories a week. A new exploit is interesting, and reading about it feels productive, but the patch queue does not move faster because of it.\n\nThe bottleneck is rarely information. It is people, time and the decision about who does what. So the useful question is not \"how do we get more early warning?\" but \"what would we do with one, on a Tuesday afternoon, with the team we have?\"\n\nThese steps are small on purpose. Most can be done this quarter.\n\n| Step | What you end up with | Rough effort |\n|---|---|---|\n| 1. Know your edge | A list of internet-facing systems, each with one named owner | A few days |\n| 2. Decide the first move | A pre-approved emergency change, signed once | One meeting |\n| 3. Three tripwires | A fake cloud key, a decoy document, a honey admin account | An afternoon |\n| 4. The runbook | One page: who gets the alert, what they check, when they escalate | Half a day |\n| 5. A fix order | A three-line rule for which vulnerabilities go first | One meeting |\n| 6. Measure the gap | Two numbers, reported with owners and dates | Minutes a month |\n\n### 1. Know your edge, and give every box an owner\n\nThe early warnings point at edge products: VPN gateways, firewalls, remote access portals, file transfer servers. Make a short list of every internet-facing system you run, the product and version, and one named owner for each. Not a team, a person (but maybe not a name, a role\u002Fposition that is connected by a person, staff churn).\n\nThis list is the single most useful artefact in this article. Without it, a warning about a VPN brand turns into a day of asking around whether you even run it. With it, the answer takes a minute. It is also the list your [attack surface management](\u002Fcontrols\u002Fattack-surface-management) work should keep current.\n\n### 2. Decide the first move before you need it\n\nWhen a warning lands about a product on your list, most of the delay is not technical. It is waiting for a change board, an approval, someone who is on holiday.\n\nAgree in advance what the owner may do without asking, for example:\n\n- take the management interface off the internet, or limit it to known addresses\n- turn on extra logging and look at the last two weeks of logins\n- apply a vendor workaround or an emergency patch outside the normal window\n\nWrite it down as a pre-approved emergency change and get it signed once, by whoever owns IT risk. That signature turns a three-day debate into a thirty-minute job, and it is the kind of thing auditors and NIS2 supervisors like to see.\n\n### 3. Put three tripwires in this month\n\nYou do not need a deception platform to start. Free tools such as Thinkst's Canarytokens can create most of these in minutes:\n\n- **A fake cloud key** in a config file or repository that an attacker would search\n- **A decoy document** with a tempting name, such as a password list or a salary file, on the main file share\n- **A honey admin account** in the directory, with an attractive name, that nothing ever uses\n\nEach one should send its alert to the place your team actually looks. If you later want decoy servers across the network, look at the [deception and honeypots](\u002Fcontrols\u002Fdeception) category, but three tripwires that work beat a platform nobody tunes.\n\n### 4. Write the fifteen-minute runbook\n\nA tripwire is worth nothing if the alert lands in an inbox at 22:00 and nobody knows what to do. Write one page that answers:\n\n- who gets the alert, and who is the backup\n- what they check in the first fifteen minutes\n- when they escalate, and to whom\n- who may isolate a machine or disable an account\n\nThen trigger each tripwire yourself once a quarter and see what happens. That test tells you more about your detection than any dashboard.\n\n### 5. Stop treating every vulnerability the same\n\nThe honeypot data says the same thing again and again: attackers concentrate on a small set of products, and they exploit them fast. Ranking fixes by CVSS score alone ignores that.\n\nA simpler order works for most teams. First, anything on your edge list that is being exploited, for example in CISA's Known Exploited Vulnerabilities catalogue. Then anything on your edge list that is critical. Then everything else, on the normal schedule. That is a policy you can explain to management in one sentence, and it is what [vulnerability management](\u002Fcontrols\u002Fvulnerability-management) should look like when capacity is the constraint.\n\n### 6. Measure the gap, not the feed\n\nTwo numbers tell you whether any of this works:\n\n- **Time from warning to first action** on an edge product. How long between an advisory about something you run and the owner taking the pre-agreed step?\n- **Tripwire test result.** When you triggered one, did the right person react within the time you agreed?\n\nReport those, with the edge list, its owners and any open items with a date, to whoever carries the risk. It is a far better conversation than the number of vulnerabilities closed last month.\n\n## The gap is not the sensor\n\nAmazon can watch the whole internet. You do not need to. The community already publishes most of what its honeypots see, often before the vendor does. What decides whether that helps you is much more ordinary: knowing what you have at the edge, having agreed what you will do, and a handful of tripwires that tell you when someone is inside.\n\nNone of it is exciting, and that is the point. The exciting part of security is finding the next exploit. The useful part is being ready for it.\n\n*Sources: Amazon Web Services, [How AWS threat intelligence deters threat actors](https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fsecurity\u002Fhow-aws-threat-intelligence-deters-threat-actors\u002F) (September 2023); GreyNoise, [Early warning signals for emerging vulnerabilities](https:\u002F\u002Fwww.greynoise.io\u002Fblog\u002Fgreynoise-uncovers-early-warning-signals-emerging-vulnerabilities) (July 2025); CISA, [advisory AA23-144A on Volt Typhoon](https:\u002F\u002Fwww.cisa.gov\u002Fnews-events\u002Fcybersecurity-advisories\u002Faa23-144a) (May 2023).*",null,[],true,"2026-10-26T07:12:33.554+00:00",8,{"name":11,"slug":20,"same_as":21,"job_title":22,"photo_url":23,"short_bio":24,"linkedin_url":25},"marcus-lenngren",[],"Founder, ThreatNoir","https:\u002F\u002Fzbqafrnxsxwbarztrtqp.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fresources\u002Fauthors\u002Fmarcus-lenngren-ca3a2dad9da5.jpg","Founder of ThreatNoir. Security and technology leader: CTO and CISO in a regulated industry, head of applications, network and data centre at Schibsted Sverige, and today security engineering for a global retailer's SOC. CISSP, CISM and AAISM.","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fmarcuslenngren",[27,31,35,39],{"slug":28,"name":29,"problem":30},"vulnerability-management","Vulnerability scanning and prioritisation","You know which systems are vulnerable, and which ones to fix first.",{"slug":32,"name":33,"problem":34},"attack-surface-management","External attack surface management (EASM)","You find your forgotten internet-facing systems before attackers do.",{"slug":36,"name":37,"problem":38},"deception","Deception and honeypots","An attacker who gets in quietly can explore the network for weeks before any alarm goes off.",{"slug":40,"name":41,"problem":42},"threat-intelligence","Threat intelligence","Attack campaigns reach your sector, suppliers or software before your team hears about them.",[],[45,54,61],{"slug":46,"kind":47,"title":48,"excerpt":49,"cover_image_url":50,"cover_image_alt":51,"author_name":11,"published_at":52,"reading_minutes":53},"gheist-campaign-abuses-stolen-github-tokens-to-dump-private","rapid-alert","Gheist campaign abuses stolen GitHub tokens to dump private repo and cloud secrets via Actions logs","Since 15 Sep 2026, the Gheist campaign has planted a sync-check workflow in over 13,500 branches using stolen GitHub tokens, printing secrets to Actions logs and pulling them before deleting the run. Public repos are protected by a GitHub hold, but private repos and GitHub Enterprise Server are not.","https:\u002F\u002Fzbqafrnxsxwbarztrtqp.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fresources\u002Frapid\u002Fgheist-campaign-abuses-stolen-github-tokens-to-dump-private-1032a4f5-cover.png","Gheist rapid alert: Stolen GitHub token, private repo? Every secret in it got printed.","2026-10-27T05:06:27.466+00:00",3,{"slug":55,"kind":47,"title":56,"excerpt":57,"cover_image_url":58,"cover_image_alt":59,"author_name":11,"published_at":60,"reading_minutes":53},"node2shell-node-js-brotli-decoder-rce-cve-2026-111497","Node2Shell: Node.js Brotli decoder RCE (CVE-2026-111497) patched in all supported lines","Node.js fixed an out-of-bounds write in its bundled Brotli decoder on 21 October. Imperva's Node2Shell PoC ran code on an official 24.22.0 build. Upgrade to 22.23.4, 24.22.1 or 26.12.1. There is no workaround in Node.","https:\u002F\u002Fzbqafrnxsxwbarztrtqp.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fresources\u002Frapid\u002Fnode2shell-node-js-brotli-decoder-rce-cve-2026-111497-e52ba6df-cover.png","Node2Shell rapid alert: Does your service decode Brotli? One crafted stream can run code.","2026-10-23T16:42:51.248+00:00",{"slug":62,"kind":47,"title":63,"excerpt":64,"cover_image_url":65,"cover_image_alt":66,"author_name":11,"published_at":67,"reading_minutes":53},"arista-patches-third-exploited-velocloud-orchestrator-zero","Arista Patches Third Exploited VeloCloud Orchestrator Zero-Day in Four Months (CVE-2026-114625)","CVE-2026-114625 is a critical SQL injection in VeloCloud Orchestrator on-prem, CVSS 9.9, actively exploited. Any authenticated user with the lowest tenant role can become a superuser operator. Patch to 5.2.3.18, 6.1.3.10 or 6.4.2.12 and hunt for abuse now.","https:\u002F\u002Fzbqafrnxsxwbarztrtqp.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fresources\u002Frapid\u002Farista-patches-third-exploited-velocloud-orchestrator-zero-714429b3-cover.png","VeloCloud VCO rapid alert: Your SD-WAN runs VeloCloud? One low tenant login owns the box.","2026-10-23T15:26:13.908+00:00"]