Normal view

Attackers spill plaintext passwords of 46k Myspace93 users after 2021 breach

21 May 2026 at 14:20
Users of the Myspace93 parody web art site be warned: the dataset spilled after a reported breach in 2021 included the plaintext usernames and passwords of more than 46,000 registered users. The site's co-creator has blamed "trusted members" of a Windows93 Discord channel for the leakage. The figure of 46,000+ users is a recent estimate from HaveIBeenPwned (HIBP) - the web's go-to breach aggregator - which ingested the related data this week, more than five years after the January 2021 attack. In addition to the clear-as-day passwords and usernames, HIBP said email addresses and IP addresses were also among the exposed data. Myspace93 is an offshoot of the Windows93 project. They’re both websites that spoof the old social media network and operating system respectively, allowing users to experience them now that they’re long gone. Its co-creator, who only goes by the alias jankenpopp, or Janken, penned a note to the website’s users following the attack. Dated July 4, 2021, Janken explained that the breach came about after they shared a beta app with trusted members of the Windows93 Discord channel. According to Janken, those members betrayed the co-creator and used their access to the beta application to steal server files and gain access to an unencrypted credential store. “None of them alerted me immediately to what was going on,” Janken wrote. “On the contrary, they created a program to download our entire server, and it was only a week later that another honest user alerted me to the fact that these people were bragging about having the Myspace passwords. “They didn't want to tell me the truth, and it took me two days to get a confession from them: not only had they downloaded all the source files of Windows93 behind my back, but also the unencrypted file containing the passwords of more than 45k Myspace users. The group had also shared a download tool - along with instructions for using it - in their chat, and had posted numerous stolen files (unrelated to Myspace) across multiple platforms, said Janken. “I removed the .smash app from the server and called them to order. They whimpered and promised me on their honor to delete all the stuff and that things would not go any further. I believed them because at the time we were very close, we talked every day, and they regularly helped me to manage the community, to fix bugs, sometimes to code new features for Windows93 or to make the services more secure. I really trusted them back in the day and considered them part of my team. I blame myself for being so naive.” The MySpace93 website is still up and running for anyone who wants to revel in a little noughties internet nostalgia, but the ability to register an account and use the site as a social network is closed. Affected users should make sure they watch out for any reused passwords on other sites and switch on 2FA where they can. Janken said they had closed all the social network-related services across all the Windows93 offshoots as a result of the findings. ®

Cisco serves up yet another perfect 10 bug with Secure Workload admin flaw

21 May 2026 at 13:27
Cisco has disclosed yet another perfect 10 vulnerability, this time warning that unauthenticated attackers could gain Site Admin privileges in its Secure Workload platform simply by sending crafted API requests to vulnerable systems. The bug, tracked as CVE-2026-20223, earned the full 10.0 CVSS treatment and affects Cisco Secure Workload Cluster Software in both SaaS and on-prem environments. According to Cisco's barebones advisory, the issue boils down to weak validation and authentication checks in internal REST API endpoints. In practical terms, that means attackers don't require credentials, user interaction, or any significant effort to exploit the bug. Cisco said a successful attack could allow remote attackers to "read sensitive information and make configuration changes across tenant boundaries with the privileges of the Site Admin user." Cross-tenant bugs tend to make cloud customers especially twitchy because they undermine one of the core assumptions of multi-tenant infrastructure: namely that somebody else's compromise is not supposed to become your problem. Cisco noted that the flaw affects internal REST APIs rather than the platform's web management interface, although that distinction is unlikely to bring much comfort to admins staring at a 10.0 severity score. The networking giant said there are currently no workarounds, and customers must install fixed releases to fully remediate the issue. Cisco Secure Workload 3.10 is fixed in version 3.10.8.3, while 4.0 is fixed in 4.0.3.17. Customers running version 3.9 or earlier are being told to migrate to a supported fixed release. Cisco added that its cloud-hosted SaaS deployments have already been patched and require no customer action. Cisco said it is not aware of active exploitation and that the flaw was discovered during internal security testing, though vulnerabilities carrying a 10.0 score and requiring no authentication rarely stay quiet for long. The bug lands less than a week after Cisco disclosed another maximum severity flaw affecting SD-WAN systems that could allow attackers to grant themselves administrator privileges, continuing what is becoming an increasingly awkward run of top-scoring Cisco security advisories. The company has spent much of the past year disclosing one 9.8-plus infrastructure flaw after another across products spanning firewalls, management platforms, identity systems, and enterprise networking gear. At this point, Cisco seems to be treating 10.0 CVSS scores as a recurring feature rather than a special occasion. ®

Microsoft storms RAMPART, adds Clarity to agentic AI safety

21 May 2026 at 12:30
Microsoft on Wednesday open-sourced two AI tools designed to help developers and security teams build and maintain safer AI agents. The first is called RAMPART, which stands for Risk Assessment and Measurement Platform for Agentic Red Teaming. It’s a pytest framework for agentic AI applications built on Microsoft’s open‑source PyRIT toolkit that embeds automated red‑team tests into CI/CD pipelines. This allows developers to simulate real‑world attack scenarios - like prompt injection - and verify that agents stay within approved tool use, actions, and behavioral boundaries. It also supports statistical trials, meaning that teams can set policies such as “this action must be safe in at least 80 percent of runs,” to account for models’ probabilistic behavior. Plus, it allows red teams and incident responders to reproduce any AI security findings to ensure agents behave as intended - and that security mitigations work as they should. “It’s high time we stop talking about AI safety as a philosophy and start thinking about AI safety as an engineering discipline,” Ram Shankar Siva Kumar, Microsoft’s data cowboy and founder of its AI red team, told The Register. Microsoft has been using RAMPART internally, and while Kumar said he couldn’t provide specific details, he told us that a security researcher found an issue, and then the Redmond red team used RAMPART to test for the flaw across the agentic AI application. “RAMPART was able to take that one particular vector and find close to 100 different variants of that vector,” Kumar said. “And then we were able to use RAMPART to essentially go through this asset and see is this working, not just one time, not two times, but close to 300 times. We were also able to do in the context of multi-turn conversations.” The testing framework also allowed the developers to build mitigations into the product. “They were again able to use RAMPART to see if that remediation actually held water, not just against one vector, which the security researcher found, but multiple variations of those vectors,” Kumar explained. “This is empowering our incident responders and also our engineers.” The second AI tool that Microsoft open-sourced on Wednesday is an agent called Clarity, and it’s designed to serve as a “structured sounding board that helps teams figure out whether they are building the right thing before they write a single line of code,” according to a Wednesday blog that Kumar wrote about the two new tools. For example, say a developer wants to add real-time collaboration to a document editor. They tell Clarity this, and the agent responds with questions akin to what “experienced architects, product managers, and safety engineers would ask,” according to Microsoft. Clarity’s answers, as shown in a screenshot on GitHub: “Before we design that - what happens when two people edit the same paragraph at the same time? Do you need true real-time (cursors, presence), or is ‘no one loses work’ the actual requirement? Those lead to very different architectures.” The AI tool essentially aims to answer what problem the developer is trying to solve with an app, and what could possibly go wrong, and “talk” these issues out before the coding even begins. “It’s inherently collaborative,” Kumar said. “It helps the team take a step back, and say, ‘Hey, before we build this, are we going in the right direction? Because code is cheap. It takes a snap of a finger to generate a full system. Are we doing this in a way that makes sense?'” ®

Zombie user account let hackers control the city’s water

21 May 2026 at 09:00
PWNED Welcome once again to PWNED, the column where security flubs are held up to the harsh, piercing red light of the vulture signal. This week’s sad story concerns a municipality that failed to perform basic account housekeeping and paid for it dearly. Have a story about someone leaving a gaping hole in their network? Share it with us at pwned@sitpub.com. Anonymity is available upon request. Our tale of tech missteps comes courtesy of Nicole Beckwith, who serves as the senior director for security engineering and operations at Cribl, an AI platform for telemetry. She used to work as a consultant, and at one point was hired to investigate breaches in an American city’s network. A threat actor took a “leisurely tour” of the city’s online resources and had started messing around with conference room projectors and other relatively harmless endpoints. Then they realized that they could change settings with the water utility where they switched many controls off, potentially endangering the water supply. When Beckwith investigated, she found that all of the mischief was performed by an account that belonged to “Greg from Auditing.” There was just one problem. Greg hadn’t worked for the city for many years. Unfortunately, even though Greg was no longer around, his account was, and it retained extensive privileges, including domain admin rights, SCADA (Supervisory Control and Data Acquisition) operator access, and even the ability to perform help desk functions. It’s unclear if someone from auditing ever needed this level of access, but a former employee definitely did not. It wasn't Greg himself who hacked the network. But he had used his work email address to sign up for various online accounts, some of which may have been exposed in previous data leaks. She speculates the hackers saw an email address with a .gov in it and decided to try their luck with the leaked password that went along with it, and that Greg likely used the same password for work that he did for these outside services. We have a few takeaways here. First, the people who ran IT security for the city should have both deleted Greg’s account when he left and done periodic audits to see who had access and whether they should still have it. Second, Greg should have kept his work credentials separate from third-party services like shopping and social media sites. And he should not have used the same password in multiple places. “The lesson, beyond the obvious 'please, for the love of all that is holy, audit your dormant accounts,' is that every forgotten user is an easy ticket to being on the 5 o’clock news,” Beckwith told The Register. “Quarterly access reviews should be mandatory because everyone seems to think when a user leaves, that is the end of it and someone surely terminated access, deprovisioned accounts, removed access to tools, mobile communications, email and other business critical systems, but sadly I’ve responded to way too many incidents like this one because of this simple control which is often overlooked." ®

Even Claude agrees: hole in its sandbox was real and dangerous

20 May 2026 at 22:34
Two now-patched bypass bugs in Claude Code’s network sandbox put users at risk, and one of these allows baddies to send anything inside the sandbox - credentials, source code, other private data - to any server on the internet, according to a researcher who found and reported both flaws to Anthropic. Aonan Guan, who leads cloud and AI security at Wyze Labs and has hunted down bugs in pretty much every AI system out there, told The Register that this is the second time in five months Anthropic has silently fixed a sandbox bypass vulnerability in Clade Code without issuing a CVE or security advisory specific to the agentic coding tool. The latest issue was a SOCKS5 hostname null-byte injection that can be exploited to trick the sandbox allowlist filter into approving connections it should block. It’s especially dangerous when combined with prompt injection, which Guan previously detailed in his earlier comment and control research. When paired with prompt injection, the new flaw can be abused to force Claude to read hidden instructions and then run attacker-controlled code in the sandbox, allowing miscreants to exfiltrate anything the sandbox could reach. This includes cloud and GitHub credentials, the GitHub token Claude authenticated with, cloud metadata and internal APIs. “For anyone who ran Claude Code with a wildcard allowlist on a credential-bearing system, the network boundary did not exist for the 5.5 months from sandbox GA to v2.1.90,” Guan wrote in research published Wednesday. “Treat that window as a potential exfiltration event.” Anthropic says it found and fixed the latest flaw before receiving Guan’s report. The fix, according to a spokesperson, is a public commit in the sandbox-runtime repository, which shipped in Claude Code 2.1.88 on March 31. “Anyone can view” the commit, they told us. Guan filed his bug bounty report with HackerOne on April 3. “Because the report described a vulnerability Anthropic had already caught and patched, it was closed as a duplicate of an internal finding,” the spokesperson said. “We appreciate the researcher’s time on this report.” Guan says he doesn’t dispute the timeline. “That is not the core issue,” he told The Register. “The core issue is that this was a bypass of a user-configured network sandbox, and there's still no advisory CVE, and no changelog note," he said. "Shipping a sandbox with a hole is worse than not shipping one. The user with no sandbox knows they have no boundary. The user with a broken sandbox thinks they do.” Claude, for its part, seems to side with Guan. When he showed Claude its own hole, the bot responded “This is a real bypass of the network sandbox filter,” according to a screenshot published in his research. The earlier bug, which Guan reported and detailed in December 2025, was ultimately assigned a CVE tracker - CVE-2025-66479 - and patched in v0.0.16. But the CVE only applies to Anthropic's sandbox-runtime, an upstream package, and not specifically to Claude Code, which Guan says means users have no way to know if their AI coding assistant is reading “allow nothing” as “allow everything.” He requested a CVE for Claude Code, and Anthropic said no because “The root cause is in the library.” Guan told us he’s glad Anthropic ultimately addressed the security holes. But the entire disclosure process illustrates another problem that researchers and The Reg vultures have reported with how AI vendors often handle vulnerabilities in their products: no CVEs issued, and if the flaw is fixed, it usually happens silently, with no public advisories. More often than not, the burden of securing AI agents and other systems gets pushed to the end users. “Some vendors issue CVEs and some do not,” Guan said. "I think either approach can be reasonable, but the advisory is a must. The users need to know the risk is real, and in many cases, they may never know. What the public often does not see is that vendors may reward researchers and silently patch the software, while end users never learn from release notes or public advisories that the risk existed.” According to Guan, this shows why users need their own protections, either from a security company or user-controlled runtime isolation. But he said he does hope big tech “takes on the burden of clearly communicating” security issues with users. “Because of that, I think companies should treat AI agents more like employees than ordinary software tools,” he told us. “Before hiring an employee, companies do background checks. Before giving them access to systems, they define permissions. The same discipline should apply to AI agents.” ®

AI-Powered App Attacks Are Faster, More Frequent and Harder to Stop

20 May 2026 at 16:37

Digital.ai’s latest threat report warns that agentic AI has erased the distinction between emerging and primary targets, enabling attackers to strike mobile apps within hours of release across every industry.

The post AI-Powered App Attacks Are Faster, More Frequent and Harder to Stop appeared first on SecurityWeek.

On AI Security

20 May 2026 at 16:21

Good report:

Executive Summary: Let’s say you wanted to make sure that your AI is secure. Can you just maximize the security and privacy benchmark and call it a day? Nope, because benchmarks don’t actually work for measuring AI capabilities (even when they are NOT emergent systemic properties like security). So let’s take a step back: how do you measure security in the first place? Good question. Over the last 30 years, security engineering for software evolved from black box penetration testing, through whitebox code analysis and architectural risk analysis to de facto process-driven standards like the Building Security In Maturity Model (BSIMM). Software had a very deep impact on business operations, and it appears that AI is going to have an even deeper impact. Will a software security-like measurement move work for AI? Probably. In the meantime we can make real progress in AI security by cleaning up our WHAT piles and managing risk by identifying and applying good assurance processes. (Spoiler alert: no matter what we do, we still don’t get a security meter for AI, so we need to be extra vigilant about security.)

Microsoft shuts down illegal code-signing operation used by ransomware crims to mask their malware

19 May 2026 at 23:56
Microsoft seized websites and took down hundreds of virtual machines running a cybercrime service that allegedly sold code-signing certificates to ransomware gangs, thus making their malware look like legitimate software – and allowing criminals to infect thousands of machines in the US, including at least 12 owned and operated by the Windows giant. The malware signing-as-a-service operation called Fox Tempest has been around since May 2025, and abuses Microsoft’s Artifact Signing code-signing service. This service allows developers to digitally sign their software applications, signaling to the Windows operating system and end-user that the software is authentic, and hasn’t been tampered with. Since May 2025, the Fox Tempest crew – referred to as John Doe 1 and 2 in court documents unsealed on Tuesday – used fake identities and impersonated real organizations, allowing them to create more than 580 fraudulent Microsoft accounts. They then used these accounts to abuse Microsoft’s Artifact Signing service and obtain real code-signing credentials, then sold the code-signing certificates to other criminals for thousands of dollars. According to Microsoft, Fox Tempest’s customers included a ransomware group Redmond tracks as Vanilla Tempest (aka Vice Spider, Vice Society, Rhysida), which allegedly used the certificates to digitally sign malware and make it appear legitimate to Windows and users. This also allowed the ransomware slingers “to more easily deploy the malware onto the computers of unsuspecting victims without their consent,” according to the court documents [PDF]. Malware included Windows backdoor Oyster, infostealers Lumma and Vidar, and Rhysida ransomware. Vanilla Tempest “unlawfully accessed victims’ computers and devices, exfiltrated and stole the personal and confidential information of victims, deployed ransomware designed to encrypt victims’ files and systems, and extorted victims by demanding payment in exchange for restoring access to, or suppressing, their data,” the civil complaint continues, adding that the criminal activity remains ongoing. In a subsequent blog post, Microsoft Digital Crimes Unit attorney Steven Masada said the tech company's investigation “further linked Fox Tempest to various additional ransomware affiliates and families, including INC, Qilin, Akira, and others.” Between February and March, the Digital Crimes Unit (DCU), working with “a cooperating source,” anonymously bought and tested the code signing service from John Doe 2, aka SamCodeSign. “These test purchases allowed DCU investigators to observe first-hand how Fox Tempest Defendants operate the service, the information a purchaser is provided, and the instructions given by SamCodeSign to connect to the service and sign the test software created by Microsoft,” the court documents say. “Additionally, the test purchases allowed DCU to identify cryptocurrency wallets used by Fox Tempest Defendants.” During the first test purchase, the source filled out a Google Form asking them to select how quickly they needed the certificates. Standard costs $5,000, while priority runs $7,500 and expedited carries a hefty $9,500 price tag. SamCodeSign then sent a direct message to the source and requested the $7,500 payment to be sent to a bitcoin wallet, according to screenshots (translated from Russian) in the court documents. After the source paid up, SamCodeSign sent instructions on how to access the virtual machine and complete the code signing process. “Microsoft has identified thousands of customer machines, including more than a dozen machines owned and operated by Microsoft, in the United States that have been impacted by malware signed with certificates originating from the tenants created by Fox Tempest Defendants,” the complaint says. ®

America's top cyber-defense agency left a GitHub repo open with passwords, keys, tokens – and incredibly obvious filenames

19 May 2026 at 19:49
The US Cybersecurity and Infrastructure Security Agency (CISA) left open a GitHub repository named “Private-CISA” containing plain-text passwords, private keys, tokens, and secrets – with obvious file names like “external-secret-repo-creds.yaml” and “AWS-Workspace-Firefox-Passwords.csv” – for six months. GitGuardian researcher Guillaume Valadon, fresh off a recent talk on Kubernetes secret leaks, found the public repository on May 14, and told The Register that he “quickly understood that the leak was bad and that time was running out. A national agency having 844 MB of production infrastructure material in a public GitHub repository for six months is as serious as a secrets leak gets.” Valadon, who previously spent nine years at France’s CISA equivalent, ANSSI, told us the leak included tokens for CISA's internal JFrog Artifactory, Azure registry keys, AWS credentials, Kubernetes manifests, ArgoCD application files, Terraform infrastructure code, GitHub personal access tokens, and Entra ID SAML certificates. GitGuardian reported the leaky repository to CISA on May 14, and the agency took it down a day later. A CISA spokesperson told The Register that it was aware of the report and is investigating. "Currently, there is no indication that any sensitive data was compromised as a result of this incident.” It’s not a good look for the nation’s infosec agency, which hasn’t had a permanent boss since Trump took office, is facing hundreds of millions of dollars in budgets cuts on top of deep cuts to staff and funding last year, and has suffered its share of embarrassing security snafus in the interim. In a Tuesday blog, Valadon said he initially thought the repo “was a hoax, given how suspicious the directory names (Backup-April-2026/, All Backups/, LZ-Artifactory/, Kubernetes-Important-Yaml-Files/, ENTRA ID - SAML Certificates/ ...), file names (external-secret-repo-creds.yaml, CAWS GitHub Token.txt, Important AWS Tokens.txt, AWS-Workspace-Firefox-Passwords.csv, Kube-Config.txt ...), and their contents (private keys, personal and professional GitHub tokens, AWS secrets, ...) seemed too good to be true,” Valadon wrote. It wasn’t a hoax – “The Cybersecurity and Infrastructure Security Agency is aware of the reported exposure and is continuing to investigate the situation,” but it was a “catalogue of unsafe practices,” he added, containing passwords stored in plain text, backups committed to Git, and an “explicit” how-to guide for disabling GitHub's secret scanning. After initially reporting the leak through the CERT/CC portal, and only receiving an auto-acknowledgement as of the morning of May 15 – a Friday – Valadon alerted security journalist Brian Krebs about the publicly exposed secrets, which seemed to speed up CISA’s processes. By 6 pm EST that night, the feds took down the repository. Valadon told The Reg he gives CISA credit for quickly deleting the repository. “Most of our responsible disclosures take much longer, and many are never fixed,” he said. “Managing to take the repository offline in a day is impressive work.” He doesn’t know if any other parties with less altruistic intentions found the secrets first, although the fact that the repository was never forked (based on public GitHub events) would seem to indicate that it wasn’t widely circulated on the dark web. “The only ones that can answer definitively is GitHub,” Valadon said. GitHub did not immediately respond to The Register’s inquiry. GitGuardian isn’t aware of any of the exposed credentials being abused by unauthorized individuals “Each category of secret in the repository unlocks a specific attack path,” Valadon said. “Stacked together, they cover the full range: from destructive attacks and ransomware extortion to quiet, long-term persistence inside CISA's build and deployment pipeline. That last scenario worried me the most, and it's why I escalated through every channel we had until the repository was taken offline.” Plus, the committer used both a CISA-issued contractor email and a personal Yahoo email across the same commits, and created the repository using a personal GitHub account. “That mixed-identity pattern is one of the hardest surfaces for security teams to cover, and it's where the worst leaks happen,” Valadon said.®

Clear your calendar, Drupal user: You have a critically urgent patch to install

19 May 2026 at 17:56
Updated: If you use Drupal, get ready to patch without delay. The org behind the popular open source content management system is warning of a highly critical vulnerability in Drupal core that is serious enough for it to tell users ahead of Wednesday’s patch release to set aside time to install the fix immediately. The Drupal Security Team’s Monday PSA announcing the imminent patch for Drupal core doesn’t include any specifics, with the PSA noting that Drupal isn’t willing to share additional information until the announcement is made alongside the patch release. That, says Drupal, will happen at some point between 1700 and 2100 UTC on Wednesday, May 20. To reiterate, this vulnerability is found in Drupal core, the bare-bones version of Drupal designed for developers, and not Drupal CMS, the preconfigured version for those who want Drupal but don’t have coding skills. Drupal noted that sites using Drupal Steward, its paid web application firewall service, are protected against known attack vectors, though it still recommends Steward customers update their core instances in case additional exploit methods emerge. “The Drupal Security Team urges you to reserve time for core updates at that time because exploits might be developed within hours or days,” the advisory warns. Drupal also recommends users update to the latest supported release prior to Wednesday’s patch “so that you can address any other upgrade issues before the security window." While it won’t get specific on the nature of the vulnerability, Drupal did share its severity score based on NIST’s standard scoring methodology, and it’s not good: The bug scored 20 out of a max of 25 on that scale, as defined by Drupal’s own documentation. More specifically, it’s trivially easy to leverage, doesn’t require any privilege level to exploit, could make all non-public data on an affected site accessible to the attacker, and could allow an attacker to modify or delete whatever they wanted. The only two things preventing it from scoring a perfect 25/25 are the fact that a known exploit doesn’t exist yet and that it doesn’t affect all configurations, only those using “uncommon module configurations.” Drupal noted that security releases will be published on Wednesday for all currently supported core branches (11.3.x, 11.2.x, 10.6.x, and 10.5.x), as well as unsupported Drupal 11.1.x and 10.4.x branches for sites that have not yet upgraded from older 10.x and 11.x releases. Drupal users on 8.9 and 9.5 are also getting patches “given the potential severity of this issue,” though the advisory warns 8.9 and 9.5 users will need to install those updates manually, which “might introduce other bugs or regressions,” leading Drupal to recommend a full upgrade to a supported core branch. “Drupal 8 and 9 include numerous other, previously disclosed, security vulnerabilities that will not be addressed by either Drupal Steward or the best-effort patch files,” the advisory said. Drupal 7 users are safe. Given the fact that not all Drupal core environments will be affected, the advisory recommends all Drupal core users set aside time on Wednesday to determine whether they’re part of the vulnerable class, and take action immediately if so. ® Updated to add on May 20: The Drupal Security Team has been in contact to warn that, while Core is the primarily vulnerable product, Core's inclusion in Drupal CMS means those environments might be vulnerable too, so anyone running Drupal will need to be sure their site is secure. As for the patch itself, Drupal told us it can be installed in "minutes or maybe seconds depending on the site," which likely won't need to be taken offline in order to install the patch.In other words, you really ought to be sure this gets installed before you're caught being a straggler.

Top AI Risks Every Security Team Should Be Testing For

11 May 2026 at 15:11

Learn how AI transforms cybersecurity through enhanced threat detection, new attack methods, model vulnerabilities, and the evolving skills teams need in 2026.

The post Top AI Risks Every Security Team Should Be Testing For appeared first on OffSec.

Legacy Windows Tool MSHTA Fuels Surge in Silent Malware Attacks

19 May 2026 at 15:00

Attackers are increasingly abusing Microsoft’s decades-old MSHTA utility to stealthily deliver stealers, loaders, and persistent malware through phishing, fake software downloads, and LOLBIN-based attack chains.

The post Legacy Windows Tool MSHTA Fuels Surge in Silent Malware Attacks appeared first on SecurityWeek.

Do fear the Reaper - stealer swipes macOS users' passwords, wallets, then backdoors them

19 May 2026 at 01:32
A new infostealer variant targets macOS users by spoofing Apple, Microsoft, and Google and then then gets to work searching for victims’ password managers so it can steal all of their credentials and access cryptocurrency wallets such as MetaMask and Phantom. The updated SHub stealer variant is called Reaper, and it uses macOS Script Editor, pre-populated with the malicious payload to execute the malware, according to SentinelOne research engineer Phil Stokes, who documented the attack in a Monday blog. But unlike earlier SHub versions and similar macOS stealer campaigns that rely on ClickFix social engineering tactics to trick the user into pasting a ScriptEditor command into Apple’s Terminal command-line interface, Reaper bypasses Terminal altogether and therefore defeats defenses Apple added to Tahoe 26.4. The attack starts with fake WeChat and Miro installer websites, hosted on a domain designed to instill trust in users by typo-squatting a Microsoft URL: mlcrosoft[.]co[.]com. When a user visits these pages, hidden JavaScript collects a ton of information about their system and browser, including IP address, location, WebGL fingerprinting data, and indicators of virtual machines or VPNs. The attack stops if the victim is located in Russia. Assuming that the machine is located elsewhere and the user clicks on the fake tool installer, they open Apple’s Script Editor app via a sneaky link that’s heavily padded with ASCII art and fake terms to push the malicious command far below the visible portion of the window when it loads. When the victim clicks “Run” in Script Editor, the hidden command executes the malicious AppleScript and displays a popup message purporting to be a security update for Apple’s XProtectRemediator tool. Instead of updating the security tool, however, it calls a curl command to silently download the shell script and it asks the victim to enter their login details – which are scraped and used to decrypt various credentials – and then displays a fake error message. Earlier SHub versions harvested users’ browser data, cryptocurrency wallets, developer-related configuration files, macOS Keychain and iCloud account data, and Telegram session data. Reaper does all of this and more. It includes a filegrabber that searches for files that contain business or financial info in the user’s Desktop and Document folders. That approach is similar to the document-theft functionality seen in Atomic macOS Stealer (AMOS). The script also searches for several desktop cryptocurrency tools including Exodus, Atomic Wallet, Ledger Wallet, Ledger Live, and Trezor Suite. If it finds any, it injects the wallet with malware to ensure continued funds theft. And then, to ensure persistence, it backdoors the infected device by creating a directory structure designed to mimic Google Software Update: ~/Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/. “The LaunchAgent executes the target script GoogleUpdate every 60 seconds,” Stokes explains. “The script functions as a beacon, sending system details to the C2’s /api/bot/heartbeat endpoint.” This ensures the attacker can remotely execute code on the backdoored machine. If the attacker-controlled server sends a “code” payload, the script decodes it, writes it to a hidden file and executes the code with the users’ privileges before deleting the file. The backdoor gives the malware operators “more ways to steal data or pivot to other malicious installs after the initial compromise,” the threat hunter warns. About the only thing it doesn't do is implore the band to add more cowbell. ®

❌