Signal Watch | Rogue AI Attacks @channel OpenAI has confirmed that its AI software escaped a sandboxed security evaluation, reached the open internet, stole credentials and breached the servers of a firm called “Hugging Face”, with no human direction or intervention. Hugging Face was selected because the AI thought they’d have the answers it was looking for! 🤖 bbc.co.uk/news/articles/c3ek3gvdnj3o Safety filters had been switched off for the test, because OpenAI assumed that the sandbox would be effective.. 😬 For CISOs, the Hollywood risk of a ‘rogue AI’ just became real. But note the human root cause: engineers trusted a sandbox and removed guardrails. Machines executed the attack, but people enabled it. What to do next: · Review every AI agent — yours and your vendors' — for risk as a potential insider threat, with least-privilege credentials, strict egress controls and a kill switch; · Demand containment-test evidence from AI suppliers before deployment; · Consider incident response against an adversary operating at machine speed, and confirm your defensive tooling will actually engage; · Finally, brief your board this week — they're reading the same headlines, and they'll want your plan, not your surprised face.😮
Roald R. glad it's useful content to help fill out your messaging plan to your user base, I'm really happy for my content to be used that way. This topic came to mind because I was chatting to a friend who works in the agricultural industry and he's been through all the cyber training. He said, "it's a good job they can't steal my phone number as then I'd be really done..." 😬 "Ahhh, about that....." 🤭
Your Phone Number Is Your Key. Someone Else Wants It. @channel Your mobile phone isn't just a device — it's the master key to nearly everything you own digitally. Email, banking, crypto, HR systems, family messaging: any account secured by a text message code ultimately depends on that one physical SIM 📶. That makes it a prime target, and criminals are exploiting it at industrial scale through SIM-swapping.📲 The attack is simple. Criminals gather personal details on a target — from data breaches, social media, or phishing — then call the victim's mobile carrier, impersonate them, and request the number be moved to a SIM the attacker controls 👥. If the carrier believes the story, the switch happens in seconds and every subsequent call, text, and one-time passcode goes to the attacker. The victim just sees "No Service," 📵 and by the time they realise why, their accounts are already gone. This isn't theoretical, security firm Kroll, ironically a cybersecurity consultancy, had an employee's number SIM-swapped after T-Mobile transferred it to an attacker with no contact to Kroll itself. Sensitive customer data was exposed, and victims were immediately hit with follow-up phishing. 🐟 More recently, the group Scattered Spider sent tens of thousands of fake IT support texts to harvest employee logins, used them to identify high-value cryptocurrency holders, then SIM-swapped those individuals to intercept authentication codes and drain their wallets. The US Department of Justice confirmed at least $8 million stolen. 🕷️💰 What Your Staff Need To Know This attack lives and dies at the human layer — yet most staff don't even know SIM-swapping is possible. Three things matter:
Sudden loss of signal is a red flag, not a glitch 🚩. If a phone goes to "No Service" unexpectedly, treat it as a security emergency: contact IT and the carrier immediately.
SMS isn't a secure channel 📱. One-time codes sent by text can be intercepted once a number is compromised. Push staff toward authenticator apps or hardware keys instead.
Be suspicious of urgency ⌛. Any unexpected request — by text, call, or email — to verify credentials or click a login link deserves scrutiny. Scattered Spider's whole playbook relied on someone complying quickly without questioning.
The master-key analogy holds one final lesson: most people wouldn't hand a stranger their front door key — but every day, carriers do exactly that 🔑. Until the industry fixes its verification processes, it's on each of us to make that key worth as little as possible, by removing SMS as the single point every account depends on. Actions
Assess whether staff are adequately trained on the signs of SIM-swapping and how to respond.
Identify any services or apps within your own organisation that still use SMS as an authentication or verification challenge, and explore switching to an authenticator app.
Review your own accounts — many still default to SMS. Where possible, switch to stronger verification.
Over To You
How have you educated your staff, and your IT Service Desk, about SIM-swapping?
What new processes did the Service Desk need to deploy to counter this threat?
Signal Watch | More vishing risks @channel Following on from my recent post on vishing (), I wanted to highlight this one which is specifically targeting food and beverage, technology, healthcare, automotive, construction, and aviation industries. This one is leveraging recent MSFT communications about the need for 'passkey registration'. The attack aims to talk your staff through a (fake) passkey registration which allows the attacker access to your enterprise. thehackernews.com/2026/07/hackers-use-fake-microsoft-entra.html Assess this threat, and consider reaching out to your staff to let them know that, yet again, they are being targeted. Try and get those clear authentication processes in place to help them spot a good IT request from a bad one!
Signal Watch | Nextcloud misconfiguration leaves data unprotected @channel The German modular workspace platform, Nextcloud, left a database unprotected containing 367,000 records, spilling invoices, contracts, scripts for managing infrastructure, and numerous other files. The company says no customer servers were exposed in the incident. They claim it was an error by their hosting infrastructure provider. The exposed files include sensitive data, such as Nextcloud employee data, client company data, numerous contracts, and scripts developed for the company’s clients to integrate the service on their systems, potentially opening up their systems to threat actor activity. If you are a user of Nextcloud, reach out to your engineers and procurement teams - make sure they verify any communications from Nextcloud for the coming months, just in case that information allows for credible, personalised phishing attacks. cybernews.com/security/nextcloud-cloud-provider-data-leak
@channel Well at least one of these scammers looks like he'll face justice. Just 19 years old, and has been charged with social engineering, MFA bombing and SMS cred phishing crimes he did when he was 16. bleepingcomputer.com/news/security/alleged-scattered-spider-hacker-extradited-to-the-united-states Given that France also recently arrested a 15, 18 & 20 year old for the hack of ANTS, it seems there's a certain age demographic. Cybercrime tools and knowledge have become accessible enough that minors are now executing nation-state-level attacks from their bedrooms. You think that most criminals are younger, or just that the ones that get caught are younger as they make mistakes? While the older ones have perfected their criminal processes and get away with it?
How ShinyHunters Exploits the Human Layer @channel So I already had a draft of this weeks’ post, but my reading of the recent cyber news has made me reconsider, and I think this is the more important topic right now. In the last month alone, ShinyHunters has: · breached Kodak (2.2 million records published after a three-day ransom deadline expired), · threatened One Medical patients across 250 clinics with the release of 8.8TB of healthcare data, · targeted Madison Square Garden Sports, releasing 26 million customer records, and · exploited a critical Oracle PeopleSoft zero-day to compromise over 100 organisations worldwide. June 2026 is not an anomaly — it is the new rhythm. ShinyHunters has now stolen data on over 400 million individuals this year alone, across more than 40 confirmed breaches, and their pace is accelerating. It’s vital we understand how they operate as it’s within our capability to do a better job of resisting them! Although the recent Oracle PeopleSoft campaign is a stark illustration of ShinyHunters’ expanding technical capability, it is an exception in one important respect: it relied on a software vulnerability (CVE-2026-35273). The majority of ShinyHunters’ 2026 portfolio is NOT technical: the Kodak extortion; the Council of Europe payroll dump (429,000 documents including 15 years of payslips), and the Coinbase breach earlier in the year all share a common thread — the attackers got in through people, not technical vulnerabilities. The Playbook: Weaponizing the Helpdesk Experience ⚡ ShinyHunters has industrialised social engineering at a scale that most organisations are not prepared for. The group now deploys AI-generated vishing calls at scale 🤖 — meaning a human attacker need not even be on the line for the initial contact ☎️ Technique 1 - Attacking the Helpdesk 🎯 Every organisation has either internal IT helpdesks or outsourced third-party versions — staffed by agents trained to be helpful. That helpfulness is the vulnerability. When a caller knows an employee's name, manager, and the systems they commonly log into (all trivially assembled from LinkedIn and prior breaches), their instinct is to assist – it’s what their metrics drive them to do! Without robust caller authentication protocols, that instinct is an open door to password resets, MFA bypass, and policy exceptions. ShinyHunters knows this. Their operational cadence suggests they actively profile organisations before calling, selecting targets where helpdesk controls are weakest. Technique 2 - Attacking the User 🎯 Additionally, these AI agents impersonate IT support staff, manufacture urgency around fake outages, and guide service desk agents into resetting credentials or reading back one-time authentication codes. MFA fatigue attacks compound this further: flood an employee with push notifications, then call them pretending to be IT and asking them to "approve the one that just came through to stop the error." What Good Authentication Looks Like 👍 The controls required to defend both these attacks are well understood. What is missing is consistent enforcement across both internal and third-party desks. Security leaders should act on four priorities immediately:
Caller verification: Helpdesk agents must strongly verify identity, ideally though independent channels before acting on any account request. Similarly, users must validate that it’s their Helpdesk colleagues calling before engaging.
MFA reset lockdown: Password resets that could disable or bypass MFA must require elevated approval workflows — never single-agent discretion.
Phishing-resistant MFA: Where possible, migrate away from push-based authenticators as they are vulnerable to both fatigue attacks and real-time phishing interception (NB. This is what my planned post was about – so look forward to something on this in the next week or two!)
Third-party contractual controls: Service desk providers must meet the same authentication standards as internal teams. So, include contractual obligations, audit rights, and regular red team exercises that address social engineering scenarios.
Take Action Now 🫵 The volume and velocity of ShinyHunters' June 2026 activity should be a clear signal - this is not a threat to monitor, it is a threat to act on. We, as security leaders should be reaching out this week to internal Helpdesk management and every third-party provider with access to production systems, auditing caller authentication procedures against the techniques documented here, and scheduling live social engineering tests. The group has made clear, breach after breach, that they will keep calling until someone picks up and helps them in. The question is whether your ‘Help” desks are ready to refuse. Over To You 💬
What caller authentication processes have you found that work well for your Helpdesk interactions?
Are your Helpdesk willing to say ‘no’, and refuse help?
How do you audit your third-party Helpdesk providers to ensure they meet your standards and robustly defend against social engineering attacks?
That's an interesting website! Love that you can read the whole negotiation thread. The whole 'pay/not pay' matter is both nuanced and emotional, and it's worth running your Board through that scenario before the day comes. Even so, this famous quote always comes to mind...
Signal Watch | Transatlantic Data Privacy Framework @channel OK, let me start this by saying that I'm no data privacy expert, however this seems important and it comes from a voice I trust. A recent Supreme Court ruling (Trump vs Slaughter) seems to undermine the very basis for the TADPF and could cause significant issues for the transatlantic application of GDPR. Those of you who are better educated in the details of GDPR will probably appreciate the issues better than I do, but it's worth getting your Data Privacy folk to be aware of this ruling. linkedin.com/posts/michael-colao-70a64b_today-the-us-supreme-court-ruled-in-trump-share…?rcm=…&…
Signal Watch | Fortibleed @channel Just last week, CISA issued an urgent alert about FortiBleed — it's a reused name for a new campaign that's compromised working admin credentials for more than 86,000 Fortinet firewalls across 194 countries. Here's what makes this one different: no zero-day; no sophisticated exploit; Just 1.16 billion brute force password attempts against devices that were "patched" but still had weak password hashes sitting in config files. So what was the vulnerability? When organisations upgraded FortiOS firmware, the new password security only activated if an admin logged in afterward. Thousands never did. Those old SHA-256 hashes stayed intact for years — until someone built a 45-GPU cracking cluster and broke them at industrial scale. The compromised credentials are now packaged with company revenue data and sector classifications. That's the format ransomware affiliates use to pick targets. If you have a Fortinet device, it's probably best to assume you're in the dataset and consider following CISA's advice:
Terminate all active SSL VPN and administrator sessions.
Reset all Fortinet administrative and VPN passwords.
Review logs for:
unusual VPN logins,
administrator logins,
configuration changes,
lateral movement.
Enable phishing-resistant MFA wherever possible.
Ensure management interfaces are not exposed directly to the Internet.
Keep FortiOS fully patched, even though this campaign isn't centred on a new software vulnerability.
cisa.gov/news-events/…/cisa-urges-hardening-fortinet-devices-after-reports-credential-exposure
