Kawaiicon 2026 Day 1

Turns out that if you show up early enough there is no queue for lanyard and t-shirt pickup. Of course, in this context, “early enough” means “before 8 am” so I guess that’s probably not an answer for everyone. The Michael Fowler also has the happy situation of being a pleasant space to kill an hour before things get underway.

Sput and Bogan are co-hosts this year. Candles! Capes! Spooky tales!

Want me to take it from here? Changing how we work, live, and relate to the criminal justice system
Dylan Ayrey & Michael Nolan

The spooky tale starts with AI doomers. And stand ups. And vibe coding. And nerd fights. This would be funnier if it was not such a horrifying reflection of how stand ups actually work. I feel like I’m living a bad day at work, that’s how well-executed it is. The terrifying tale of a model turned loose on the internal systems of a company the owner was fired from is still less upsetting than the meetings and work betrayals. 

As a dramatic way of showing how workplace dynamics and technology choices intersect with legal dynamics it was both well-done but also ran on a little over-long. And I’m not sure riffing on a firing squad was a good look, to be honest.

The Cost of Stunt Cryptography
Peter Gutmann
Peter is one of those people that looks a particular age when you first see him two decades ago, and then sticks there forever; his rapid-fire deliver is as hammer-quick as ever, and this year discusses the history of cryptography attacks that never deliver a practical attack vector; he kicks off with the 1996 publication of the first side-channel attack, which he highlights as a constant source of theoretical attacks that never actually compromise security.

Dr Gutmann notes that in and of itself the research and publication of these attacks would be fine, except the noise generated is a huge time-waster for the developers who are constantly pestered to spend a great deal of time producing patches with no practical benefit - or worse yet actually make software less security by moving to less secure or performant code paths where there are real problems to avoid theoretical problems.

He works through some specific examples showing how artificial specific vulnerabilities, often raised as CVEs, actually are

The cookie is a lie: Handing Canarytoken sessions to infostealers
Will & Jacob

• Will runs Restealer which monitors Infostealers.
• Jacob works at ThinkstCanary.

The talk is focused on the behaviour they’re seeing from real-world Infostealers. One of the more disturbing evolutions is attackers adapting to MFA by attacking session tokens - usually via attacking the browser.

Some deterrents could be “Impossible travel” (detected by e.g. Entra P2 or an E5) - where logins show up within minutes on the other side of the world.

Infostealers search for sensitive data on a system, and typically return the compromised information to a central point, then delete themselves. Infostealers will loot everything they can - local copies of credentials, cookies, software manifests, texts and emails.

Canary tokens are fake tokens that can fool attackers into stealing them and trying to use them on a system that will trigger an alert. AWS tokens are a great canary token - attackers are almost bound to use them when they find them, and the attackers will also try to use the sessions as well. Flagging use of a canary token can let you note a compromise; for example, if a token on an admin’s laptop is used, you should assume the laptop is compromised and rotate everything you know is there.

AWS is one great example; M365 is a great one. Entra’s `ESTAUTHPERSISTENT` is the critical cookie. It’s a long-term session cookie (90 days) and is exchanged for short-term sessions. The exchange is logged as a login event - so it’s an easy tell for use of a canary token. 

For this monitoring activity, they set up a fake company with some developer machines with a bunch of dev tools and software, as well as some fake browser history and their own web site. The Infostealers took 24 hours to 5 days to trigger, with thousands of hits per fake company in the week. The attackers went through everything they found in the fake companies, including attempting to make payments. Most of the fake creds and logs were available for sale fairly quickly.

Attackers do make mistakes though: one attacker forgot to turn on his VPN. Others browsed YouTube from the compromised machines. Another submitted TrustPilot reviews from the compromised machines. A different attacker accidentally pushed one of the tokens to a public GitHub repo.

The presenters strongly recommend that you deploy impossible travel rules and AWS canary tokens on your developer machines, and be ready to react when they ping. It’s good timing for this talk that it happens with a background unfolding that a huge, multi-billion heist against Binance has occurred and the initial signs being reported through the day suggest it’s via a compromised developer machine.

A SecOps manager, an epidemiologist and a bacterium walk into a bar
Izzi

Izzi starts with the Great Exhibition and the building of Crystal Palace in Hyde Park. London has doubled in population in recent years. “Soho was a neighbourhood so dense you could hear people breath through the walls.” That summer, 137 people died in 3 days in Soho, and 600 within a few weeks. 

What was the problem? Miasma. Bad air. That was the answer from the experts of the day. But it was also the wrong answer - because it was actually cholera, vibrio cholerae. It is spread via dirty water. Most of the time, it dies in the stomach; sometimes it gets to the intestine, where it reverses the absorption of water in the gut lining. You can lose a litre a day; the skin turns blue-grey and the blood thickens to a tar-like consistency. 

The doctors weren’t stupid or lazy; they were working as hard as they could on the problem, but because they believed the disease was airborne, their efforts were in the wrong direction. John Snow is an exception; without germ theory or modern microscopes he did not have an easy answer. He did, however, have a long-term interest in cholera, and a hunch that it was waterborne. He was, however, short on evidence, and so his hunch was unconvincing.

What he did was interview every ill household, documenting the activities of the household over the past few days before each person had become ill: where people had been, what they had eaten, where they had drunk. When he mapped out the deaths something that stood out was they no-one in the brewery was ill. If cholera was airborne, shouldn’t that be ill? A widow who became sick no-where near Soho turned out to be getting water delivered from the pump.

Snow went to the local community committee and managed to persuade them to take the pump handle off the well that was actually the source of the cholera. They were dubious, but they tried: illness declined, and the deaths stopped. Snow, who had not been to the same set of schools, but apprenticed to a surgeon, had done different analysis, and mapped them.

Something striking was that the deaths mapped to the distance from the pump - not a perfect circle, but wiggly circle whose borders were a function of how long it would take to walk from the pump.

So what does this have to do with security: well, Snow had come to epidemiology via a different route, which meant he asked different questions, and structured the information that he gathered in a different way. That difference was his value. Izzi has come from a comms background; she used to feel apologetic about it, but it is actually a strength. If everyone agrees quickly, if no-one asks questions? People are finding the smell, not the pump. If you all agree to an incorrect premise, you can’t come to the correct conclusion.

• Is this the actual cause, or just the obvious thing?
• We all agree straight away? Has anyone checked?
• Who isn’t in the room?

Test it: does your theory actually work? Does it work for all the cases, or are you overlooking convenient exceptions?

Make it stick: “If they can’t read it from across the room, it won’t stick”. You will need to repeat, reiterate.

• Can someone outside the team understand this at a glance?
• What is the person I’m trying to convince worried about?
• Does this still work when I’m not in the room?

It’s about people: how do you get the people in the room, especially the people who don’t always agree. People who will challenge with respect. Find your John Snow.

Breaking Bad Routers: 6 Vendors, 6 Shells, 0 Days

MrBruH

Described by Bogan as a “bug hunting machine” who “finds zero days in his sleep”. A 22 year old autodidact who worked on the LG TV microphone exposé. He starts off with TP-Link and Netgear breach, which took almost 90 days for the vendor to respond; this was the catalyst for the talk: how many could he achieve unauthenticated remote code execution (RCE) - the most serious class of breach, which allows you to imply run commands on a device as long as you can reach it over the network - which for a router, means anywhere in the world.

His first effort, an Asus consumer router, which had a large number of potential weaknesses. Going from the list of candidates to an actual exploit was fairly straightforward, but required an auth token to work, which is no fun (“sick of jailbreaks”). Happily the Asus mobile app provided a code base to understand how the tokens are built and used; from there, it was easy to fake tokens by presenting a fake device, and from there to send a command that would break the on-router NTP process and give a remote shell.

The scope? Every router since 2018.

Next up? D-Link. Their code is GPLed, but not online. When asked for the source code, D-Link ignored him, which is a license breach. Nevertheless, D-Link was very vulnerable: creating a token lets you bypass auth, upload a malformed file gives you code exec.

D-Link still haven’t fixed the problem more than 90 days after notification.

What about Motorola? They don’t make copies of their firmware readily available. One nice feature is you can upload your own firmware, which is great except the code that is supposed to validate that the firmware upload is broken: it relies on a bad check mechanism, and accepts the upload before checking that it’s being performed by an authenticated user. It does correctly check for a valid user before running the update processes, but a bug in the HTTP call means if can be trivially bypassed by adding a web form. He let Motorola know about the flaw, but they discontinued and EOL at 2023.

Finally, Linksys: a Velop mesh that runs an sct_server and sct_client presumably to build and maintain the mesh. It can run in one of three modes: UNCONFIGURED, MASTER, or SLAVE. MASTER is the default on any configured router, and the sct_server process calls to other MASTER routers to maintain the mesh via a standardised protocol called TLS-SRP.

So how do you compromise? Call another router and tell it you want it to execute commands. And it does. Also, the vendor closed the attempted report as a “theoretical vulnerability”. Another person had the same non-response via Linksys’ bug-handling company, BugCrowd, back in 2025. That person - Christian Zãske - actually found six vulnerabilities. He went to the German security agency, which finally prompted Linksys to act - on one vulnerability. Which took 18 months to resolve.

TP-Link were, in the end, the only company that actually fixed a reported problem within 90 days. “It’s funny because they have the worst reputation”. 

So what can you do? OpenWrt or Ubiquiti. The latter are the only vendor who didn’t have a problem. And of the rest, TP-Link are the only remotely capable option. But if you do have a TP-Link, he would strongly advocate you use it with OpenWrt, not least because it’s very well supported.

My Accidental Neopets Crime Ring
Zelle Marcovicci

A hiccup with the presentation gear delays the start by a quarter hour, which always leaves me feeling tremendous sympathy with the presenter who needs to recover from things beyond their control; the pain continues with the clicker not working. Zelle grew up in San Francisco during the dot com boom. His desire to impress girls lead him to get good at Neopets - and long after the classmates moved on, he stuck with it. 

Neopets has had a checkered history, with cryptocurrency and Scientologists getting involved, but the core game remains simple: you get a pet, and the coolness and rarity of your Neopets is determined by their pose or, later on, clothes. Zelle was of the opinion was the cool (posed) version was better that the hat version of the same pet - and if you have a legacy pet you’re cooler than the new version. Each Neopet’s name is globally unique. So there should be a market in trading Neopets for old unconverted names with rare names. Which means there’s a black market.  Zelle got drawn into a trading group, supporting one another in getting the pets they wanted. 

The other thing to know is that Neopets security was garbage with plain text storage of birthdays, passwords, players’ physical locations, you name it. That’s terrible! But also an opportunity. Because when Neopets started requiring a password reset, it became possible to force resets to old, unused accounts. And they send it to email addresses - which may have become available because the person ditched it.

Or you could take the easy route and tell their support team that you need help resetting the password. After all you have the account owner’s email, date, and location. You can use this for evil (stealing Neopets) or good (helping people get back an account from their childhood).

Inside NZ's Digital Identity Stack (And How Do You Even Test This Thing?)
Nick von Dadelszen

Digital identity pulls together a lot of Nick’s research in once place: NFC, mobile devices, identity.

What’s the current state? People are demanding copies of drivers’ licenses or passports as the price of entry. We don’t know what they’re doing with it - like the pub that was putting drivers’ licenses online. So how do we fix that?

The credential goes on a phone, not on a server. The credential needs to be stored securely device. Nick notes that we won’t be destroying the existing servers. If someone needs a set of your credentials, you get a sharing request, and you choose whether you share the subset of your data - if a pub wants to know your age they only need that shared. Not your age, not your address.

There’s an issuer, a holder, and a verifier. The issuer provides the credentials - a passport or a drivers license; the holder is (for example) your phone, which keeps a copy; this needs to be managed by the secure hardware on the device. The verifier is the entity - a police officer or an airport or a pub - that wants to see some of the data. The verifier can talk to the holder, and only the holder, and looks to see if the material is from an issuer that it trusted. The verifier must never report back to the issuer.

That’s the technical part - Nick notes that there have been changes to the law to support this, across AML, driving legislation, you name it. We are far enough down the road that the first credentials are being issued. In some countries, the legal framework mandates that the creds are government owned; in NZ we have followed the EU with having strong regulation, but the ownership is with the various entities.

Going back to the holder side of the equation, the secure elements for managing the held data is tricky. Old devices, or devices which have been rooted, will not have that capability, or have potential compromises. Nick wants to enable those classes of devices to participate, but this is not a solved problem right now.

The hardest problem right now is the testing: Nick is speaking to his peers around the world; these are new protocols, new transports, and the system is designed to be highly secure. Trying to break small parts to test other parts will prevent the test working - but Nick has built out an automated test harness to solve a decent chunk of the problem across the various moving parts; there are still limits to the automation, since some of the code paths require biometrics as part of the holder auth flows. This represents about two years of work.