When even ransomware crews get pwned, CISOs should pay attention. ShinyHunters claimed it compromised Cl0p's dark web leak site through an unauthenticated file-upload flaw in Grav CMS, defaced the site, and then turned Cl0p's own extortion model against it. The reported demand: eight figures. But the money is not the most interesting part. The real lesson is that sophisticated operators can still fail on basic security controls. For CISOs, this should sound familiar: * Internet-facing systems with unclear ownership * Legacy CMS platforms that escape patching cycles * Temporary infrastructure that quietly becomes permanent * Upload functionality with weak validation * Secrets, logs, and operational data exposed after a single foothold * Third-party and peripheral systems sitting outside the "crown jewel" conversation This is where attack surface management stops being a dashboard exercise. The question is not only: "Are our critical systems secure?" It is: "What can an attacker reach that we have forgotten about?" Because attackers do not prioritize assets the way organizations do. They look for the easiest path to leverage. A forgotten admin panel can matter more than a hardened production server. A poorly secured vendor portal can matter more than another million-dollar security platform. A temporary upload endpoint can become the beginning of a major incident. For security leaders, the takeaway is simple: Know what is exposed. Know who owns it. Continuously validate it. Test the paths attackers are most likely to use. Cl0p spent years exploiting weaknesses in other organizations. Now, allegedly, another threat actor treated Cl0p like any other victim. Operational security has no exceptions. Hack yourself before others do. Stay secure. Turn your FearsOff. #CISO #Cybersecurity #AttackSurfaceManagement #ExposureManagement #OffensiveSecurity #ThreatIntelligence #RedTeam #FearsOff

Two bugs. 72 hours. Under $3,000 in tokens. A working path into an OpenAI employee's Codex session and the company's internal GitHub monorepo. OpenAI paid $6,500 and noted that testing the forum was outside bounty scope. Out of scope is a program boundary. It is not a risk boundary. Hacktron AI published the chain on 18 September. Responsible disclosure, not a production dump. The chain 1. Entry. community[.]openai[.]com runs Discourse. HEIC/HEIF uploads skipped the usual FastImage check and were decoded through ImageMagick and libheif. A heap overflow (CVE-2026-32882) gave RCE on the forum host. Discourse published GHSA-vhm9-85gw-x335 on 28 July, CVSS 8.8, and shipped patched builds. 2. Escalation. Overly broad OpenAI Community sign-in tokens turned a compromised forum session into access to ChatGPT and Codex accounts for authenticated users, employees included. OpenAI narrowed those permissions and revoked affected tokens and sessions. 3. Blast radius. One employee Codex environment was connected to the internal openai/openai monorepo. The team opened a benign pull request as proof and says it did not review proprietary code. OpenAI states no sensitive user data was taken. Reachable connectors are not the same as exfiltrated data. The detail most coverage buried: the exploit was written by models. Opus 4.8 could not get there. Opus 5 shipped on 24 July and produced a working ARM64 exploit in about three hours. No model jailbreak required to reach the model company. Timeline. Research began 23 July. RCE at 05:00 UTC on 25 July. Bugcrowd report the same morning. OpenAI confirmed its identity-side fix at 22:49 UTC, roughly 14 hours later. Discourse had a fix by 27 July. Bounty paid 1 September. The scope line matters because the forum was only hop one. The identity control is what made an employee Codex session, and a connected internal repo, reachable. Scope on a submission form does not redraw the architecture. We see the same pattern at FearsOff on most serious chains. Researchers are asked to prove impact without touching production data. The proof then gets used to argue the issue was not that bad. Severity gets argued down to the first bug instead of the chain. Bounty math becomes the public scoreboard instead of the architecture lesson. The next researcher watches and thinks twice before reporting. Patch fast, as OpenAI did on the identity side. Then describe the chain the way an attacker would, not the way a program FAQ does. Two questions for your own stack: which dependency has nobody rechecked since the day it was added, and which identity token still trusts it? #CyberSecurity #OffensiveSecurity #ResponsibleDisclosure #BugBounty #AppSec #FearsOff #AISecurity #AI

A 9.9-severity flaw in ConnectWise ScreenConnect showed why remote access tools are architecturally fragile. The mechanism is worth breaking down because it reveals the real problem. The attack chain: Social engineering got a victim to run a rogue ScreenConnect client. Once inside, that client didn't need to compromise anything else. It found other active ScreenConnect sessions on the same network and pushed files to them "without authorization or host confirmation in certain circumstances" - per ConnectWise's advisory. Four VBScript files then propagated access across the organization's remote support footprint. Why this matters beyond the CVE: The flaw wasn't exotic. The rogue client exploited the fact that remote access tools are built on implicit trust. Once a legitimate client can see another session, the permission model expects the user to refuse unauthorized transfers. But when a modified client ignores that prompt, there's no secondary control. This is systemic. Remote access tools grant broad privileges by design (file transfer, shell access, screen sharing) but defend them with behavioral controls - prompts, logging, UI barriers. Bypass the client, and the authorization layer collapses. ConnectWise patched CVE-2026-84869 in version 26.6.5 on September 8. CISA flagged it for federal agencies with a three-day remediation deadline. But patching this one vulnerability doesn't solve the category risk. The real question: If remote support tools sit in your environment, assume one compromised client will reach others. Can your architecture survive that? Or does your network segmentation actually isolate remote access traffic?

Revolut did not get breached in the classic sense. Someone used a real government-agency email domain, passed authentication, and Revolut handed over the files. What left the building: passports and driving licences, KYC selfies, names, dates of birth, occupations, addresses, phone numbers, IBANs, account statements, withdrawal records, and full transaction histories - including Bitcoin. Revolut says a limited set of customers was affected, systems and funds were untouched, and high-net-worth users appear to have been the target. Latest development (14 September): attackers have started publishing identity documents and selfies on Telegram - including material linked to named high-profile customers - and are threatening daily dumps until Revolut pays. Posts circulating this morning claim the ransom is 10,000 BTC. That figure has not been confirmed by Revolut or authorities. Even unconfirmed, the pattern is familiar: leak a few files, raise the price, keep the pressure on the people in the pack rather than only the company. 10,000 BTC is theatre as much as negotiation. Paying rarely stops a leak once documents are already out. Not paying leaves affected customers exposed to identity theft, targeted phishing, and on-chain doxxing. Either way, the customers did not get a vote. The control failure is process, not the firewall: ▪ A valid government domain is not a valid request. ▪ Official data requests need a known-good channel, dual control, and out-of-band verification. ▪ Passport + selfie + IBAN + BTC history is a complete identity kit. It should never move on a single email thread. If your platform stores KYC and crypto history, test the legal/compliance workflow the same way you test the app. Last week's "reasonable belief" is this week's ransom headline.

The phishing email came from Trezor's legitimate domain. That's what made this attack dangerous. On September 9, Trezor warned users that its third-party email provider had been compromised and used to distribute a phishing email titled: "Critical Security Alert: STM32 Entropy Vulnerability" This wasn't a typical lookalike-domain attack. Recipients reported that the email passed SPF, DKIM and DMARC authentication. Bitcoin security researcher Jameson Lopp noted that the messages did not appear to be spoofed. Trezor has since identified the provider as Brevo and said an unauthorized actor used its Brevo account to send the campaign. Roughly 347,000 email addresses in Trezor's opt-in newsletter database were affected. The lure was carefully chosen. Attackers claimed that STM32 microcontrollers in Trezor devices were generating weak recovery phrases. Weeks earlier, a real firmware bug affecting Coinkite's Coldcard had reduced seed entropy from 128 bits to as little as 40 bits. TRM Labs linked that vulnerability to approximately 1,816 BTC - about $116 million at the time - stolen from more than 5,200 addresses. The phishing campaign took a real security fear and redirected it at another hardware-wallet community. BitBox reported a similar campaign the same day and said multiple Bitcoin companies appeared to have been targeted through a shared newsletter provider. And for Trezor, this follows another third-party incident. In August, a breach at shipping provider ShipMonk exposed customer information. Trezor's updated investigation puts the total at 80,689 affected customers. The lesson isn't simply "watch for phishing." It's that attackers can inherit your organization's trust by compromising the systems around it. A legitimate sender. Authenticated email. A believable security incident. A trusted brand. When those signals can no longer distinguish legitimate communication from an attack, the human becomes the last control. If an attacker could send authenticated phishing emails from your company's real domain tomorrow, how quickly would your customers recognize the attack? #CyberSecurity #Phishing #CryptoSecurity #SupplyChainRisk #InfoSec

$320M moved. 3,400 BTC returned. ~$47M kept. And an OP_RETURN declared: "we are whitehats." That sentence is doing a lot of work it did not earn. The Liquid Network incident has triggered a debate bigger than one exploit: what does "white hat" actually mean? Because white hat is not a label you give yourself after taking control of someone else's assets. It is a constraint on how you operate. There is a legitimate problem underneath this debate. Too many bug bounty programs lowball critical findings. "Thanks for the report" is not compensation. Artificial caps, severity games, ghosted researchers, and companies protecting nine figures of TVL while offering four-figure rewards create terrible incentives. Researchers should push back. Negotiate. Escalate. Walk away. But a broken bounty market does not create authorization. A white hat finds the hole, proves it with the minimum necessary PoC, reports it, then negotiates aggressively for what the work is worth. Taking the reserve first and negotiating what you keep afterward is fundamentally different. And stretching "white hat" to cover that behavior hurts the researchers who actually follow the rules. The next CISO becomes more suspicious. The next legal team gets more defensive. The next researcher demonstrating impact gets treated less like the person who found the fire and more like the person holding the match. We know the other path because we practice it. Our team recently found a critical vulnerability in a major crypto project. We could have moved millions. We didn't. We demonstrated it with a $100 proof transaction, got it fixed, and negotiated the bounty afterward - including escalating when the initial offer did not reflect the severity. That is the job. Black-hat capability. White-hat discipline. You can believe researchers are chronically underpaid and still reject "pay yourself from the protocol" as the solution. Researchers: don't work for coupons. Negotiate. Escalate. Walk away. Projects: pay criticals according to the damage they can cause, not the minimum you think a researcher will accept. But protect the line. White hat is not "I gave most of it back." White hat is how you behaved before you had leverage. #Cybersecurity #WhiteHat #BugBounty #Web3 #CryptoSecurity

Your inbox doesn't lie: eight "reset your password" emails in three minutes, and you never touched the button. Here's what we know as of September 4: 1. Confirmed: Thousands of X users, including CoinDesk staff and prominent crypto accounts, reported unsolicited password-reset emails, unfamiliar-login alerts, and temporary lockouts. Some received up to 10 reset emails within hours. 2. Confirmed: Many of the reset emails appear to be legitimate X-generated messages. X's recovery flow can be triggered with a public username, though the actual confirmation code still goes to the account's registered email or phone. 3. Confirmed: X Product Engineering's Mridul Singhai said the company has "so far" found no evidence of a breach. He suggested attackers may see greater value in compromised accounts now that X Money is more widely available. 4. Not confirmed: Researchers have pointed to several possible ingredients, including older Twitter/X data exposures, a credential-stuffing operation involving millions of accounts, and a separate phishing campaign impersonating X login alerts. None has been confirmed by X as the cause of this surge. 5. What to do: Enable Password Reset Protect under X's security settings and use strong 2FA, preferably an authenticator app. The bigger lesson: attackers don't necessarily need a brand-new breach. Old exposed credentials, automated login attempts, and permissive recovery flows can remain useful long after the original data exposure. Have you turned on Password Reset Protect yet?

Your AI Login Doesn't Need a Password to Get Stolen. Anthropic is warning Claude users that malware already on their computer - not a flaw in Claude - is hijacking active sessions. MFA didn't fail here. It was never asked. MYTH: If an account has strong authentication, an attacker needs your password to get in. REALITY: Anthropic warned affected users in a notice reported on August 30 that infostealer malware - including Vidar, LummaC2, StealC, RedLine, and Acreed on Windows, plus Atomic Stealer on a small number of Macs - was stealing already-authenticated Claude browser sessions from infected computers. A stolen authenticated session can let an attacker bypass the normal login flow, including the password and MFA challenge, because they're reusing a session that has already been authenticated. MYTH: Unusual account activity means the platform itself was breached. REALITY: Anthropic was explicit: "We have no reason to believe that this malware is related to Claude, installed through Claude, or related to anything you did with Claude." The infection was general-purpose malware arriving through unrelated activity. In one publicly shared case, the user reported downloading a pirated game. The malware happened to steal the victim's Claude session alongside other credentials and data on the infected machine. MYTH: If your usage or billing looks normal today, you weren't affected. REALITY: Anthropic told affected users that one warning sign was usage limits refilling and then quietly draining while they weren't using Claude. The company signed out affected sessions, removed saved payment methods, and refunded charges identified as unauthorized. But signing out doesn't remove malware from the device. If the infostealer remains on the machine, a newly authenticated session can potentially be stolen again. That's the bigger security lesson. Session hijacking through commodity infostealers is a growing blind spot for cloud and AI accounts. Once an authenticated session is stolen, no phishing page or password guess is required to reuse it. Does your org's incident response plan account for stolen session cookies - not just stolen passwords?

The interesting part here isn't that ransomware operators are using AI. It's what they're using it for. Two separate research teams, CloudSEK and Gambit Security, analyzed exposed infrastructure tied to a Russian-speaking group behind Aurora ransomware. Both came to the same conclusion: the operators weren't just using Cursor to write code. They were using it during actual intrusions. CloudSEK found an exposed open directory showing activity against more than 20 organizations in nine countries between April and July 2026. Four of those organizations later appeared on Aurora's leak site. Gambit Security got even more specific. It found the operator using Cursor Agent, running on Anthropic's Claude Sonnet model, during hands-on exploitation of 10 targets between April 8 and May 21. In these cases, the attacker already had credentials or some kind of initial access. Sometimes the instructions to the agent were broad: "tell me what rights the user has." Other times, the attacker told it exactly what to run, including NTLM relay attacks using Impacket and certificate attacks using Certipy. And it didn't all work. A lot of the commands failed on the first attempt and had to be adjusted. That's actually one of the more interesting details in the research. This wasn't a polished demo showing an AI agent flawlessly hacking its way through a network. It was messy, iterative, hands-on use during real operations. Reuters named six affected organizations: Christeyns in Belgium, Teckentrup in Germany, Scotland's Helideck Certification Agency, Bayou Title in Louisiana, an Argentine pharmaceutical distributor, and an Italian manufacturer. There's another case worth paying attention to as well. ReliaQuest recently disclosed Gryxa, a toolkit built by a separate financially motivated actor. That actor reportedly told an AI coding agent the project was an "authorized internal deployment" and used it to help build credential-stealing malware. Different actors. Different operations. Similar idea. We're moving beyond attackers using AI to make phishing emails sound better or generate some malware code. They're starting to use commercial AI agents as part of the actual intrusion workflow. So a genuine question for security leaders: does your AI acceptable-use policy assume attackers are using these tools to write phishing emails, or does your threat model account for them sitting alongside the attacker during hands-on-keyboard exploitation?

Six days into a cyberattack, Boston Scientific still doesn't have a timeline for full recovery. Here's what the company has confirmed: Aug 25: Boston Scientific detects a cybersecurity incident causing a network outage and global operational disruption. Aug 26: An SEC filing confirms disruption to order processing and shipping. Shares fall about 4% that morning. Aug 27-28: Boston Scientific says there is no known impact to implanted cardiac devices, including pacemakers, or to previously established remote monitoring. But new remote-monitoring activations are disrupted. Newly implanted devices cannot currently be enrolled for remote monitoring, although clinicians can still interrogate devices in person. Aug 29: The company says cloud systems are unaffected and unauthorized activity was limited to certain on-premise systems. Manufacturing, processing and shipping remain disrupted, with no timeline for full restoration. So far, Boston Scientific has not publicly attributed the attack or disclosed whether data was accessed or stolen. The important distinction: a cyberattack doesn't have to switch off a pacemaker to create potential patient-care risk. The devices may still work. But what happens if the systems used to manufacture, deliver and remotely monitor them stay disrupted? Six days in, that's the question worth watching.

Five crypto projects lost an estimated $14.1M in six days. Three failed on the same question: who actually authorized this? 1️⃣ TERM LABS - AUG 23 - ~$8.5M An address funded with 2 ETH from Tornado Cash took nearly all votes in four of five USDC vaults and ~91% of the ETH Meta Vault. The proposal passed a seven-day timelock in public view. About 2,843 ETH and 1.68M USDC left the vaults. 2️⃣ BOUNCEBIT - AUG 19-20 - ~$3M A caller could name another account as the source of funds without proving authorization. 286.5M BB moved across 14 transactions. No private key or signature was compromised. 3️⃣ THE SANDBOX - AUG 21-22 - ~$675K LayerZero delegate permissions were hijacked through approveAndCall on the SAND OFT on Base, ultimately draining 14.77M SAND from the Ethereum OFT Adapter. 4️⃣ ALLBRIDGE - AUG 19 - ~$191K A malicious CCTP message received a valid Circle attestation without a corresponding legitimate settlement. The contract failed to adequately verify the sender, recipient, or settlement. 5️⃣ MAYA PROTOCOL - AUG 18 - ~$1.7M DIRECT Six chained bugs created an uncapped subsidy. A 100 CACAO deposit claimed 99.93% of a pool after ~49M CACAO was incorrectly credited. CACAO fell 88.7%. Three of these incidents point to the same failure mode: Asserted authority substituted for verified authority. BounceBit trusted the funder named by the caller. Allbridge trusted an attested message without establishing settlement. The Sandbox accepted a configuration change without establishing true authority. Maya was different: a bounds failure. Term was almost the inverse: governance checks passed while the wrong party controlled the votes. The question for security teams isn't just: "Would our last audit have caught these?" It's: "Which of these was our audit designed to catch - and which failures were outside its scope?"

CVE-2026-69836 required no credentials and no user interaction - and affected Microsoft Entra ID. 10.0 out of 10. The maximum possible CVSS score. And this one was in Microsoft Entra ID - the cloud identity platform behind authentication and access across Microsoft 365, Azure, Dynamics and thousands of connected applications. 🔓 Here's what Microsoft disclosed about CVE-2026-69836: The vulnerability was a deserialization of untrusted data flaw in Entra ID. In simple terms: Untrusted network data → unsafe deserialization → remote code execution The CVSS vector tells the rest of the story: Network exploitable Low attack complexity No privileges required No user interaction required High impact to confidentiality, integrity and availability In other words, an attacker did not need a compromised account or a victim clicking a link. Successful exploitation could allow an unauthorized attacker to execute code over the network. That's an especially serious failure mode for an identity platform sitting at the center of access to Microsoft cloud environments. Microsoft credited Principal Security Engineer Robert Fitzpatrick with discovering the vulnerability. There's also an important update: Microsoft initially listed the vulnerability as exploited, but corrected that assessment on August 21 and said it had not been exploited in the wild. The vulnerability affected Microsoft's hosted service, and Microsoft says it has already been fully mitigated. No customer patch or other remediation action is required. And CVE-2026-69836 wasn't the only major Microsoft cloud vulnerability disclosed that week. CVSS 10.0 flaws were also published for Azure Arc, Exchange Online and Azure Managed Instance for Apache Cassandra. The interesting incident-response question isn't just "Was it patched?" It's this: If a CVSS 10.0 vulnerability existed inside your identity provider for another 30 days, what evidence would you actually have to detect exploitation - and what could you do about it? #CyberSecurity #MicrosoftEntra #EntraID #CVE #IdentitySecurity #CloudSecurity #IncidentResponse

Watch what CISA just flagged as actively exploited: a vulnerability in MLflow, an AI and ML lifecycle platform, being abused to steal cloud credentials. Pair that with the Rust supply chain attack that hit developer build pipelines this same week, and a pattern is hard to miss. The tools we adopted to move faster on AI are now first-class attack surface, and attackers found them before most security teams finished inventorying them. MLflow, model registries, notebook servers, vector databases, and ML orchestration platforms tend to share three uncomfortable traits. They were deployed by data teams, not security teams. They sit close to cloud credentials and sensitive data. And they rarely appear in the asset inventory the SOC actually monitors. That combination is exactly what an attacker wants: privileged, connected, and unwatched. If you are standing up AI capability this year, the security work is not a future phase. The exploitation is already in the KEV catalog. Three questions worth asking your team this week: Do we know every ML and AI platform running in our environment? What can each one reach if compromised? Who is watching them? What is sitting in your AI stack that has never been through a security review? #AISecurity #MLSecurity #CloudSecurity #CISO #KEV

Three Crypto Breaches. None Started With the Wallet. 250,000+ crypto customers had personal data exposed in the space of a few days. The private keys weren't the weak point. 🔍 Here's what happened: ➡️ August 13 - Trezor Trezor disclosed a breach at ShipMonk, its fulfillment partner, affecting 13,689 customers. 11,742 had names, emails, phone numbers and shipping addresses exposed. Another 1,947 had names, cities and emails exposed. Trezor's own systems and devices were not compromised. ➡️ August 16 - SafePal SafePal disclosed an authorization flaw in its order-tracking plug-in that exposed order information belonging to approximately 39,798 customers. The affected data included names, emails, shipping addresses, phone numbers and purchase details. SafePal said seed phrases, private keys, wallet passwords and funds were not compromised. ➡️ August 17 - Bits of Gold Bits of Gold reported that attackers accessed customer information through a third-party data analytics provider. Approximately 200,000 customers were affected. The exposed information included names, national ID numbers, emails, phone numbers, IP addresses, bank account details and public wallet addresses. The company said funds, private keys and passwords were not exposed. Three incidents. Three different paths in. Fulfillment. Order tracking. Data analytics. The common denominator wasn't the cryptography. It was sensitive customer data sitting in systems adjacent to the core product. That's an important distinction for security teams. You can harden the wallet, isolate private keys and audit the core application - while an order-tracking tool or analytics provider still holds enough information to make your customers valuable targets for phishing, impersonation and social engineering. So the vendor-security question isn't only: "Can this vendor access our production environment?" It's also: "What could an attacker do with the customer data this vendor can access?" How are you auditing vendors that never touch your core product, but do touch your customers?

North Korea used servers vulnerable to a bug we found as C2 in its latest campaign targeting the defence, aerospace, and aviation sectors. Check Point's report last week: Lazarus exploited a Windows kernel zero-day, CVE-2026-68820 in afd.sys, since at least early July against defense, aerospace and aviation targets in France, Germany, Brazil and India. The campaign ran two parallel infection chains. One used signed-binary DLL sideloading to execute MISTPEN in memory. The other used a trojanized PDF viewer to deploy a new backdoor, Troy. Both could escalate to SYSTEM through CVE-2026-68820, followed by a new FudModule build designed to disable EDR visibility. MISTPEN ultimately deployed ForestTiger for long-term access. Microsoft patched the zero-day on 11 August. Much of the C2 infrastructure wasn't theirs. Check Point found compromised Roundcube, WordPress and PrestaShop servers being used as relay infrastructure. It assesses that Lazarus likely authenticated to vulnerable Roundcube servers using leaked credentials, exploited CVE-2025-49113, and planted RelayShell. The researchers identified at least 17 likely relay nodes. One compromised organization headquartered in France was then used to spear-phish targets worldwide - borrowing a legitimate organization's infrastructure and reputation to make the messages more credible. CVE-2025-49113 is ours. Our co-founder @k_firsov discovered and reported it in May 2025: authenticated RCE via PHP object deserialization, CVSS 9.9, sitting in the Roundcube codebase for more than a decade. Roundcube patched it on 1 June 2025. Attackers diffed and weaponized the vulnerability within 48 hours of the patch becoming available, with a working exploit offered for sale days later. We published the full technical breakdown to give defenders parity. CISA added CVE-2025-49113 to its Known Exploited Vulnerabilities catalog in February 2026, with a 13 March remediation deadline for covered US federal agencies. And Lazarus was still exploiting unpatched Roundcube servers in this campaign. We know the tradecraft because we spend our year on the other end of it. Lazarus is heavily involved in cryptocurrency theft, and we run continuous adversarial simulation against exchanges and protocols that sit high on the DPRK targeting list. The objectives differ, but the tradecraft overlaps: recruitment lures, signed-binary sideloading, credential theft, and kernel-level evasion. Theft there. Espionage here. If you build aircraft, satellites, drones, avionics, sensors or related defense technology, your engineers fit the targeting profile. And your internet-facing Roundcube, WordPress or PrestaShop infrastructure can become someone else's C2 if it isn't secured and patched. We find the bugs that might end up in campaigns like this one. We also run the campaign against our own clients first, on purpose, with a scope document. Our research: lnkd.in/dzS-RYcz

Nobody installed anything. Nobody clicked anything. The admins just logged in. March 1, 2026: BdThemes ships Prime Slider 4.1.9. A new script drops a remotely supplied value, display_id, straight into an HTML attribute without escaping it. The flaw spreads across the vendor's product line. June 23, 2026: The earliest campaign activity Wordfence could establish, based on timestamps in the poisoned records. Sometime before detection: Per Wordfence, the attacker gains write access to the vendor's object storage and rewrites the static JSON feed served through its promotional API, the one Biggop Library fetches to render banners inside customer admin dashboards. August 7: Wordfence is alerted to the campaign. August 8: Seven plugins are closed in the WordPress[.]org directory pending review. Two poisoned endpoints start returning clean JSON. The mechanism is the part worth studying. The poisoned display_id closes the attribute early and attaches an event handler, so the payload fires on animation start every time an authenticated admin loads a wp-admin page. It runs inside that admin's own session and uses it to create rogue accounts. A second stage installs a webshell as a fake plugin. The injected code then rewrites database queries so the new accounts never appear in the user list. No plugin update was applied. No code in the WordPress[.]org repository was touched. File integrity monitoring had nothing to catch. Wordfence rated the underlying flaw medium, CVSS 5.4. It produced hidden administrators and webshells across a portfolio the vendor advertises at over 350,000 active installs, with Element Pack alone above 100,000. The gap between that score and that outcome is the lesson. The trust boundary was drawn around the plugin file, not around the data the plugin fetches at runtime. Check for: bd_ prefixed admin accounts, emer-run.php, unexpected files in mu-plugins, class-wp-query-* files, the fz_emer_login_tokens option. Then ask the harder question. What else in your admin panel renders content pulled live from a vendor's server? That dependency map is where our Threat Intelligence work starts. 👇 Affected plugins: Element Pack, Prime Slider, Pixel Gallery, Ultimate Post Kit, Ultimate Store Kit, Live Copy Paste, Smart Admin Assistant. As of Wordfence's August 8 publication the flaw was listed as unpatched and the vendor had not issued a public statement.

The scariest phishing page isn't fake. It's Microsoft's. Greatness, a commercial phishing-as-a-service kit that has been around since mid-2022, just added device code phishing. That breaks the assumption most awareness training is built on: that a fake login page is the tell. The chain ZeroBEC documented, reported by The Hacker News on 4 August: 1️⃣ Victim receives an email spoofing RingCentral, styled as a voicemail notification. 2️⃣ The email fails SPF, DKIM and DMARC. It lands anyway, because the target is a genuine RingCentral customer and has RingCentral's domains on a safe sender exclusion. The attacker isn't beating the gateway, they're using the trust configuration the gateway was told to honour. 3️⃣ The link runs through a five-stage redirect chain with User-Agent fingerprinting, anti-analysis checks and a CAPTCHA gate, then splits: adversary-in-the-middle proxy, or device code endpoint. 4️⃣ On the device code path there is no fake site. The victim signs in on Microsoft's real login page and enters a short code. 5️⃣ The attacker receives a valid OAuth token through the legitimate Device Authorization Grant flow. MFA was satisfied. By the victim, on the real page. 6️⃣ Tokens are replayed within minutes from dedicated proxy infrastructure, then Graph API enumeration across Outlook, Teams, Exchange, SharePoint, OneDrive, contacts and calendars. On the AiTM side of the split, ZeroBEC found one proxy IP still authenticating against a victim tenant more than two weeks after the original campaign. Microsoft has separately observed device code operators registering a device within minutes to mint a Primary Refresh Token, then waiting hours before touching inbox rules. No fake page. No stolen password. A short code and a plausible reason to enter it. Greatness runs on a public Telegram channel with more than 3,250 subscribers, over 11 pre-built lure templates, and a $289/month subscription, up from $120 in January 2024. This is not a nation-state operation. It is retail. Three things worth doing this week: ➡️ Block the device code authorisation flow in Conditional Access by default, and explicitly exclude only the resources that genuinely need it. Audit that exclusion list on a schedule. ➡️ Treat every vendor breach disclosure as a trigger to review your safe sender rules for that vendor's domains. A leaked customer list tells attackers exactly whose gateway is configured to trust them. ➡️ Assume password reset is not containment. If the token is live, the session survives. What's your policy on device code sign-in today: blocked by default, or allowed everywhere?

Attackers did not need ransomware to take a water treatment plant offline. They needed a controller reachable from the public internet and a password they could change. From FBI and EPA public service announcement I-073026-PSA, issued July 30: Since July 27, water and wastewater utilities in at least seven states have reported incidents, and some of that activity degraded water operations. The actors are targeting internet-facing Rockwell Automation / Allen-Bradley MicroLogix 1100 and 1400 controllers. The method is blunt: reach the exposed PLC, change its IP address and password, lock the operator out of their own equipment. Reported consequences include loss of monitoring and control, water pressure drops, and flooding. One organization found modified PLC project files after noticing ladder logic discrepancies. Minnesota was the visible edge. On July 26 and 27, more than 30 community water systems were hit in a coordinated attack on operational technology. One treatment plant went offline, several cities lost automated controls and ran manually, and one declared a local state of emergency. Water quality was not affected. Michigan has since reported intrusions at nine of its systems. Four days earlier, CISA updated AA26-097A, warning Iranian-affiliated actors were compromising internet-connected PLCs across water, energy and government sectors. Tenable assessed the pattern as consistent with CyberAv3ngers tradecraft. No formal attribution yet. Set attribution aside. It does not change Monday. What should is access. Nothing here required a zero day or malware. It required equipment that answers from the internet and an authentication path an outsider could take over. That does not stop at water. It covers desalination and power generation, port and terminal automation, oil and gas, building management in hospitals and data centres, and the vendor remote access sitting quietly across all of them. Water surfaced first because those utilities are small, underfunded and numerous. The exposure is universal. Three questions worth answering this week, whatever sector you operate in: 1️⃣ Which of your controllers and management interfaces answer from the public internet, through cellular modems, engineering laptops and unapproved vendor remote access? 2️⃣ Do you hold a copy of every controller configuration, and would you notice if the running logic stopped matching it? 3️⃣ How long can you run manually? When did you last prove that rather than assume it? Only the first is fixed with a firewall rule. This is the work we do at FearsOff. We map the external attack surface an adversary actually sees, test the crossover path from corporate IT, identity and vendor remote access into environments meant to be isolated, and hand over what is exposed, how it chains, and what to fix in what order. If you run critical infrastructure or carry obligations for operational resilience, the honest way to find out how you fare is to have someone try it first.

1,196 addresses. 41 minutes. At least $70.2 million in Bitcoin gone. Here is how a "cold" hardware wallet got emptied without anyone touching the device: 1.    In March 2021, Coldcard's firmware shipped with a config error. A macro check verified whether hardware RNG support existed in the code, not whether it was actually switched on. In production, it was off. 2.    That silently rerouted seed generation to a deterministic software fallback (MicroPython's Yasmarang PRNG), seeded only from the chip's unique ID and timer registers and collecting no fresh entropy after that. On the Mk3, effective entropy dropped to roughly 40 bits against the 128 a BIP-39 seed assumes. 3.    On July 30, 2026, someone swept the vulnerable addresses in a pattern consistent with exploiting exactly this flaw: reconstruct candidate seeds offline, check them against public blockchain addresses, drain the matches. No attacker has been named, and researchers note a malicious sweep and a legitimate owner moving coins look identical on-chain. But the timing and targeting line up. 4.    The initial sweep took 1,082.65 BTC in 41 minutes. Later waves pushed the tracked total to roughly 1,367 BTC, near $88.6 million. 5.    Coinkite shipped emergency firmware the next day, July 31. The catch: the patch cannot repair seeds already generated on the flawed builds. Owners have to create a new seed and move their coins, or the weakness follows them forever. The lesson is not "hardware wallets are bad." It is that "cold storage" was never a synonym for "audited storage." Offline is a threat model, not a guarantee. If your seed was generated on old firmware, would you even know to check? 🔒 #Cryptosecurity #Bitcoin #ThreatIntel #DFIR #InfoSec

Alibaba just released fastjson 1.2.84 on the archived project github.com/alibaba/fastjson/…