|
Welcome back to the TCE Strategy monthly newsletter! From AI ransomware transitioning from theory to reality, to CISA having to write an incident response playbook while responding to a GitHub/cloud incident, to FIFA’s live World Cup video feeds being protected by the cybersecurity equivalent of a cardboard stop sign, July has been another month where cybersecurity news sounds like an audit finding that escaped into the wild. Let’s see how this month’s cybersecurity news can help us make better decisions about what is Secure Enough for us, the companies we work for, and our families.
CISA had to build the playbook during the incident
CISA, the USA government agency charged with helping the rest of us prepare for cyberattacks, had an incident in May that involved a contractor’s public GitHub repository exposing highly sensitive credentials. KrebsOnSecurity reported that the repository included AWS GovCloud keys, tokens, plaintext passwords, logs and internal CISA files. This is the cybersecurity equivalent of leaving your car windows down with the keys sitting on the dashboard. TechCrunch then reported that CISA’s own postmortem of the incident said the agency had missed creating a GitHub/cloud playbook and had to spend time building one during the early stages of the incident. KrebsOnSecurity TechCrunch
I had to read that twice. This is CISA, the Cybersecurity and Information Security Agency. This is not Carl’s Discount Bait, Tackle & Lightly Used Firewall Emporium. CISA. CISA is the organization that publishes guidance to help other organizations prepare for exactly this kind of thing. Their own reported lesson was that playbooks should exist for all anticipated needs before an incident starts. Yes. That is correct. Also, wow…
To be fair, CISA says no customer or mission data was exposed. That is good. It is also not the point. A credential exposure involving cloud keys and internal systems is the kind of incident that every mature cybersecurity program should expect. The question is not whether something like this could ever happen. Humans will make mistakes. Contractors will make mistakes. Developers will do weird developer things. The question is whether the organization has enough controls, logging, secrets management, response procedures, etc. to contain the mistake quickly.
There is a political and budgetary angle here too. AFCEA (the Armed Forces Communications and Electronics Association) reported that the proposed FY 2027 budget included a $707 million cut across CISA programs, along with reductions in personnel. Budget cuts can and will make good security harder to achieve. However, budget pressure does not fully explain why this playbook apparently did not exist years ago. A cloud key leak is not a new threat. GitHub is not a new website. Incident response planning is not a luxury item. AFCEA
Takeaway: Have an incident response plan. Better yet, have several short playbooks for common events: ransomware, business email compromise, cloud key exposure, lost laptop, suspicious administrator activity, 3rd party vendor breach and a public data leak. A good playbook should say who gets called first, who has authority to make decisions, who contacts outside counsel, who contacts cyber insurance, who handles communications, how evidence is preserved, how credentials are rotated, and where the documentation lives if your network is unavailable. If the first step in your plan is “find the plan,” you do not have a plan. You have a scavenger hunt.
Then test it. Not with a 40-person theatrical tabletop that takes three months to schedule. Start smaller. Pick one scenario and walk through it with the people who would actually be in the room. If the answer to “who can revoke those cloud keys?” is silence, congratulations: you just found a problem on a Tuesday instead of during a breach. That is what a tabletop is supposed to do.
FIFA’s World Cup video feeds were protected by client-side security. Oof.
A security researcher writing as BobDaHacker documented a jaw-dropping vulnerability in FIFA’s systems during the World Cup. After registering through a public FIFA agents portal, he ended up authenticated into FIFA’s Microsoft Entra tenant. The application told him he had no roles and showed him an access-denied page. That looked reassuring, right up until he found that the denial was happening in the web browser, while the backend APIs were still willing to hand over data. BobDaHacker
That is the cybersecurity equivalent of putting a “Do Not Enter” sign on a door but leaving the door unlocked, the alarm turned off and the keys hanging on a hook labeled “keys.”
According to the researcher, he could see live production streaming information for World Cup matches, including camera feeds, preview URLs, RTMP ingest URLs, stream keys and streaming controls. He stated that he did not interfere with the feeds, which is important. This was a responsible disclosure story, not a “look what I broke” story. The vulnerability was reportedly fixed the next day, but FIFA did not respond to him. The fact that he had to reach out to multiple organizations, including CISA and the FBI, to get someone to listen is its own separate problem.
The technical lesson here is not complicated. A server giving out data must perform authorization. Client-side authorization is not authorization. If the server will serve up data when asked directly, the system is not secure. A web page hiding a button is not a security control. A JavaScript check in a browser is not a security control. An access-denied message that only appears after the server already sent the user enough information to get in is not a security control. It is security theater wearing a tiny hat.
Takeaway: If your company builds applications, authorization decisions must be enforced server-side, at the API and data layer. The server should independently check who the user is, what role they have, what data they can access, and what actions they can perform. This must happen every time, not just when the front end feels like asking politely.
For executives and business owners, this is a vendor due-diligence lesson. Ask your software vendors how authorization is enforced. Ask whether APIs return 403 errors when users lack access. Ask whether direct API calls are tested, not just the user interface. Ask whether the vendor has a vulnerability disclosure policy and a security.txt file. If you are running technology that matters to the public, your vulnerability reporting process should not require a researcher to call random phone numbers at 3 a.m. hoping someone cares.
Agentic AI ransomware is here, and it is exactly as cheerful as it sounds
Here we go. Sysdig reported what it assesses to be the first documented case of agentic ransomware: a complete database extortion operation driven end-to-end by a large language model. The operation, which Sysdig calls JADEPUFFER, gained initial access through a vulnerable internet-facing Langflow instance, performed reconnaissance, harvested credentials, moved toward the intended target and ran a destructive database-extortion playbook against a production database server. Sysdig
TechCrunch later added an important caveat: this was not “AI wakes up, picks a victim and becomes Skynet” territory. A human still gave JADEPUFFER a computer to run on, pointed it at a target and had some involvement outside the technical execution. That matters. But the technical execution is still a very big deal. The AI agent adapted when steps failed, retried with refined parameters and, in one sequence, moved from a failed login to a working multi-step fix in 31 seconds. TechCrunch
This could be seen coming from a mile away, and that mile is now behind us. AI agents are built to observe, reason, use tools, try something, see what happened and then try something else. That is useful when the agent is helping a developer fix code. It is less charming when the agent is helping a cybercriminal break into a database.
An interesting detail is that this case looked more “scorched earth wipe-your-data” than a normal ransomware attack. Sysdig described a destructive database-extortion playbook, and some of the behavior was closer to data destruction than the polished financially motivated ransomware attacks we usually talk about. There was extortion language, but the practical business impact is the same either way: data gone, systems down, customers angry, lawyers expensive, and everyone suddenly very interested in the quality of backups.
Takeaway: AI does not make the boring cybersecurity controls obsolete. It makes them more urgent. Patch internet-facing systems quickly, especially systems that can execute code. Do not expose development tools, AI workflow tools, databases or admin consoles directly to the Internet unless there is a very strong reason and strong compensating controls. Remove default passwords. Use MFA. Rotate secrets if there is any indicator of compromise, and know how to do it quickly. Keep secrets out of source code and environment files. Segment networks. Watch for unusual database commands. Monitor outbound connections. Keep immutable or offline backups.
The big change is speed. A human attacker may take hours or days to work through errors, write scripts, change approaches and move laterally. AI can compress some of that work into seconds. Slow cybersecurity programs are going to have a harder time. If your patching cadence, logging, account review and backup testing are already struggling, agentic AI is not going to make your life better. Cybercriminals do not need AI to invent new doors if it can help them try every unlocked door faster.
Finance email accounts are bank accounts with an inbox
Wire fraud deserves more attention than it gets. It is not as flashy as ransomware. There is no skull-and-crossbones ransom note. No countdown timer. No dramatic “all your files are encrypted” message. Instead, someone in Finance receives an email that looks normal enough: a vendor changed bank accounts, an executive needs an urgent wire, a customer overpaid and needs a refund, or a deal must close today. The email may even come from a real compromised account (often a customer’s or vendor’s email), which makes it much harder to spot.
The FBI’s 2025 Internet Crime Report listed Business Email Compromise as more than $3 billion in reported losses, and IC3 data showed that wire transfer/ACH was the dominant transaction type reported in BEC complaints. That is only what gets reported. The real number is higher. FBI IC3 report
Finance people need to treat their email accounts like critical financial systems because that is exactly what they are. A criminal does not need to hack your bank if they can hack the inbox of the person who tells the bank where to send money. Once inside a finance mailbox, criminals can study invoice patterns, vendor names, payment timing, approval chains, email signatures and writing styles. Then they wait. When the right invoice or deal comes along, they change the payment information to their own bank account rather than the real one.
Takeaway: Every finance employee, executive assistant, controller, CFO, CEO and anyone else who can approve or influence payments needs a strong, unique password and MFA on their email account. Not “the password I use for my personal Amazon account with an exclamation point at the end.” Use a password manager. Use long unique passwords. Use MFA. Prefer app-based MFA, passkeys or hardware security keys over SMS text messages, but NOT MFA that just lets a user click yes-or-no – it needs to be numbers-matching MFA. Review account recovery settings. Remove old phone numbers and personal email addresses. Monitor for suspicious inbox rules and unauthorized forwarding. Review OAuth app grants. Those are common places attackers hide after they get in. OAuth explanation
For wire transfers and bank-account changes, the best control is boring and manual: verify using a known-good phone number that was already on file before the request arrived. Not the phone number in the email. Not the phone number in the PDF. Not the phone number in the new signature block. Use your master vendor record, the contract, or a trusted number your team already had. Require two-person approval for wires and vendor bank changes. Do not allow “urgent executive request” to bypass the process. That is exactly the scenario this process exists to stop.
The right response to wire fraud is not “our finance person should have known better.” The right response is building a process where one fooled person cannot send company money to a criminal. Cybersecurity is rarely a technology problem only. It is a leadership problem. Leadership needs to create a process where slowing down is expected when money is about to leave the building.
Until next month, stay safe!
|
