From Ministry of Internal Affairs and Communications, Number of Japan Amateurs = 320977, as of Oct. 24th 2026 official announcement data. tele.soumu.go.jp/musen/Searc…

Since people are yelling at threat intelligence professional for "downplaying the severity of the PHP vulnerability" (communicating clear concise information about what they're actually seeing). It feels necessary to explain what threat intelligence actually is. Consider a hypothetical hospital or a power company. A lot of systems are built using very old PHP versions. It's not uncommon for PHP to add/remove/change features from version to version. So if you're a certain number of versions behind, updating to the latest version will break your software by removing or changing functionality it needs. In that case, the provider has two options: 1) take their software offline until they can update the code to match the latest PHP version. 2) panic install the patch and break their software, leading to a massive outage. In both cases, that is basically a 100% chance of an outage. On the other hand, maybe they get hacked, maybe they don't. Maybe that hack causes an outage, maybe it doesn't. Realistically, under these circumstances, the chance of an outage is actually higher with patching than with not patching. If that outage would result in the hospital having to shut its doors or a power company's infrastructure going offline, what is the correct move? Chance being hacked, or knowingly cause an outage that threatens lives? Cybersecurity is important and all, but there are risks far greater than being hacked. I would absolutely love it if I could just log onto IDontKnowWhyTheyRenamedThisSite dot Com, be like "vulnerability bad, pls patch" and everyone installs the patch. That is not the world we live in. Now, if I start seeing people building ransomware that can copy itself from system to system using the PHP vulnerability, and I communicate that, it changes a lot of people's risk calculations. Their option shift towards either a 100% chance of an outage, or an extremely high chance of an outage + catastrophic data loss. In this case they would most likely pull the trigger on patching or taking their software offline. While the hypotheticals I gave are extreme cases, many organizations accept being hacked as a cost of doing business. Taking offline software that's critical to organizational function is not an easy decision to make, and does not get taken lightly. We don't live in LaLa land where every org installs every patch for every vulnerability the day it goes live. Cybersecurity is expensive and time consuming. Getting people to even patch systems at all is an endless uphill battle. Most orgs know that something like 1 out of ever 10,000 critical vulnerabilities actually gets exploited. And probably less than 50% of these "this is the worst of the worst vulnerability ever, the sky is falling" type vulnerabilities leads to significant damages. It takes a lot of time to build trust, and very little time to lose it. Overhype a couple of vulnerabilities and people will very quickly stop listening to you. It's extremely easy to end up being the boy who cried wolf. There's only so many times you can spin security teams into a frenzy before they stop listening to you entirely. Orgs also have limited resources, so when you yell fire, there is a good chance they're committing resources they don't have. Making people stay up all night, pulling people off other issues, bringing in outside help. You probably don't want to be responsible for some org getting ransomwared because they redirected all their security resources to some vulnerability you think is really cool. Nobody is downplaying anything. They are communicating exactly what they see/know about the issue so that organizations can make the most informed risk management decisions possible. That is the game, and that is what threat intelligence exists for. If you want to handle an organization's security for them and personally take on the risk of potentially costing them billions or killing their customers, join an MSSP or a critical infrastructure provider. I can promise you it's way more stressful than you think. It's not our job to decide organization's own risk models for them. It's our job to give the most information possible to the people who do. And just because some vulnerability researcher thinks we're not hyping up the vulnerability enough doesn't make them right. Last I checked, only something like 9.3 million out of 42 million systems had installed the patch. This is the reality we live in. If we yell fire, then maybe we can bump that number up to 10 million, but if nothing happens, it'll be at the cost of maybe 2 million less systems getting patched next time around. These are real risks we have to live with. These aren't one-off incidents. People will remember how accurate our advice was the next time around. And more or less people may decide to install security fixes based on how accurately we communicated the risks during previous incidents. Threat intelligence is an extremely complex numbers game where there is never any right answer.

Security called me at 6:12 AM today. "Patch every PHP server immediately." I asked what happened. "Two critical vulnerabilities. Remote code execution. No authentication required." Cool. How many PHP servers do we have? According to inventory: 12 According to reality: Nobody knows. We found one running WordPress. Three running old internal tools. One under someone's desk. Two inside vendor appliances. A forgotten employee directory from 2016. And a server named: PHP-OLD-DO-NOT-TOUCH Naturally, that one runs payroll exports. Then we found a PHP 5.6 box. I asked who owned it. The documentation said: BRIAN. Brian left in 2019. We called Brian. He said: "Oh wow, that's still running?" Excellent. By 8 AM, leadership joined the incident call. CEO: "Can hackers actually get in?" Security: "Potentially yes." CEO: "Without a password?" Security: "Yes." CEO: "Then why do WE need passwords?" Not the lesson. Finance asked if we could wait until the weekend to patch because downtime affects revenue. Security explained that the alternative was letting strangers execute code on our servers. Finance asked for a cost comparison. At 9:17, someone suggested temporarily taking the vulnerable websites offline. Marketing refused. "Our campaign is live." So for the next hour, the company officially decided maintaining a landing page for 20% off webinar registration was more important than preventing remote server takeover. We finally patched everything we could find. Then our scanner discovered another PHP server. Hostname: TEMP-PHP-2014 Uptime: 4,512 days. Nobody knows what it does. Nobody owns it. Nobody can shut it down. But every time we block network access, the warehouse stops printing shipping labels. Security has classified it as critical infrastructure. It is running PHP 5.4. The vulnerability has existed longer than half our employees. The emergency patch took four hours. Finding out what PHP actually runs took eleven. The internet isn't held together with code. It's held together with servers everyone is afraid to turn off.

The guy in this famous Today is Friday in California clip, Hiroshi Tsuchida aka Ninja Blue Ranger, has passed away. He showed up for many more projects like Kakuranger 30th too, what a guy

At this point you're already on a list, so you better just come to terms with it

New Episode!

From Ministry of Internal Affairs and Communications, Number of Japan Amateurs = 321237, as of Oct. 17th 2026 official announcement data. tele.soumu.go.jp/musen/Searc…

Remember to always reboot your iPhone to get rid of … OH DAMN!!! 😜

InfoSec is for lovers.

From Ministry of Internal Affairs and Communications, Number of Japan Amateurs = 321707, as of Oct. 10th 2026 official announcement data. tele.soumu.go.jp/musen/Searc…

Be cringe. Join wizardry

From Ministry of Internal Affairs and Communications, Number of Japan Amateurs = 322019, as of Oct. 3rd 2026 official announcement data. tele.soumu.go.jp/musen/Searc…

Good morning #hamradio! ☕️ #NationalTechiesDay

You can't train without the right equipment. Are you ready for what's coming? Enter coupon code "TwitterMafia" today for 10% off your order now through Nov 3rd.

I've been using @N3FJP AC Log for years. Mike VA3MW talked about OpsLog on the latest HamRadio Workbench podcast. I loaded OpLog, imported my ADIF, and oh my, the look has jumped decades over AC Log. I haven't explored it much yet, but I will. #hamradio opslog.f4bpo.com

From Ministry of Internal Affairs and Communications, Number of Japan Amateurs = 322378, as of Sep. 26th 2026 official announcement data. tele.soumu.go.jp/musen/Searc…

I was cleaning up DNS and found a record called: OLD-PAYROLL-PROD It pointed to a server named: DO-NOT-DELETE No owner. No documentation. No tickets mentioning it since 2019. I asked three senior engineers what it did. Nobody knew. So naturally I deleted it. Four minutes later every hourly employee disappeared from the timeclock system. I restored the record. Everyone came back. We still don't know what the server does. We don't know where it physically lives. We don't know who pays for it. We don't know why DNS controls payroll. We only know that if it disappears, 600 people stop getting paid. I renamed the record: DO-NOT-DELETE-SERIOUSLY Audit asked me to document the dependency. I listed the system owner as: “Ancient forces beyond our understanding.”