Reading view

CrashStealer, a new infostealer for macOS: how it works and how to stay safe | Kaspersky official blog

Mac users have historically trusted their operating system to keep them safe. That peace of mind mostly comes from Apple’s strict control over its ecosystem, and the fact that macOS has historically faced fewer mass attacks than Windows. However, that doesn’t mean Macs are invulnerable: threats do exist, and new ones emerge all the time. Over just the past few weeks, security researchers have published reports on at least two new campaigns that target Apple devices.

The malware used in one of the campaigns has been dubbed CrashStealer, while the other is known as ClickLock. Both rely on different tricks to force users into entering their Mac password, which attackers then use to steal account credentials, crypto assets, documents, and much more. In today’s post, we take a close look at how CrashStealer operates — and how to avoid falling victim to it.

A videoconferencing app with CrashStealer inside

It was back in May 2026 that researchers spotted the first signs this malware was being developed, and by early July, they caught it operating in the wild. The malware earned its name because of its core mechanism: it disguises itself as the macOS built-in crash reporting tool (CrashReporter) while functioning as an infostealer designed to hijack sensitive data.

Researchers managed to trace one of the websites users visited to download the malware. The site poses as a legitimate platform for distributing the video conferencing tool Werkbit.

A website that distributes CrashStealer under the guise of the Werkbit app

According to researchers, this is the site victims used to download Werkbit, which secretly contained the CrashStealer malware loader. Source

However, you can’t just visit the site and download the software. Before downloading, visitors are asked to enter a special meeting PIN. This setup likely allows the attackers to limit the distribution scope by targeting only specific, pre-selected victims. Exactly how the cybercriminals choose their targets and deliver the PIN remains unknown.

The “lucky” users with a code end up installing the initial malicious payload — named Werkbit Setup. Interestingly, it carries a valid Apple developer certificate and has successfully passed Apple’s notarization process — meaning it cleared the automated prescan for malicious code. As a result, the attackers manage to bypass the operating system’s built-in Gatekeeper defense. This allows the payload to launch without triggering the usual untrusted software warnings.

Signed and notarized Werkbit Setup installer

The Werkbit Setup installer is signed with a valid Apple developer certificate and has passed notarization. Source

Once launched, Werkbit Setup first reaches out to GitHub. Researchers believe using this popular platform helps attackers blend in by making these initial network requests look far less suspicious to security tools. After retrieving instructions from a GitHub repository, the program connects directly to the attackers’ server to fetch CrashStealer itself.

The loader then saves the malware to a temporary macOS folder, launches it, and wipes most of the intermediate setup files. As a result, a fully functional infostealer is up and running within seconds of Werkbit Setup starting. By the way, the user never gets any videoconferencing app.

How CrashStealer works

Unlike the Werkbit Setup loader, the CrashStealer malware itself isn’t signed with an Apple developer certificate. To keep users from suspecting anything, the malware disguises itself as the built-in macOS crash reporting tool, CrashReporter, by using the exact same name, app identifier, and a similar icon.

Once launched, CrashStealer completes a sequence of steps to gain access to sensitive data, establish persistence in the system, and cover its tracks:

  1. Remove metadata — including the attribute that flags the app as an internet download.
  2. Display a fake system prompt asking for the user’s macOS password.
  3. Use the previously captured credentials to gain access to Keychain, the built-in macOS password manager.
  4. Check the computer for installed security tools and malware analysis software.
  5. Collect saved browser passwords, cookies, Keychain contents, and data from other password managers and crypto wallets.
  6. Encrypt the data it stole and prepare it for forwarding to the attackers’ server.
  7. Create a copy of itself and establish persistence to launch automatically every time macOS boots.
  8. Delete temporary files and other installation traces to make detection much harder.

Step two deserves a closer look. The password prompt that the user sees looks extremely convincing. What’s more, the malware immediately verifies whether the credentials are correct: if you make a typo and enter an invalid password, CrashStealer will pop the window right back up to ask you again.

Fake macOS password prompt

Once launched, CrashStealer displays a pop-up that mimics the standard macOS password request. Source

What data is CrashStealer after?

CrashStealer’s hit list is massive. First and foremost, its operators target Keychain: the built-in macOS password manager where the system stores account credentials, cryptographic keys, certificates, tokens, and more.

Users of third-party password managers aren’t safe either: the malware steals data from 14 of these services, including 1Password, Bitwarden, LastPass, Dashlane, Keeper, KeePassXC, NordPass, Enpass, and RoboForm.

In addition, the malware collects all credentials and cookies stored in Chromium-based browsers — Chrome, Brave, Edge, Opera, Opera GX, Vivaldi, Chromium, and NAVER Whale — as well as Firefox. The attackers clearly have a strong interest in crypto assets: CrashStealer specifically targets data from 80 different crypto wallet extensions, including MetaMask, Phantom, Coinbase Wallet, Trust Wallet, Rabby, Exodus, Keplr, and Solflare.

Finally, the malware scans the Documents and Downloads folders to pick files that might be of interest to the cybercriminals. CrashStealer encrypts all the stolen data with the AES-256-GCM algorithm, ZIP’s it up, and sends it to the attackers’ server.

How to protect your device

The spike in attacks on macOS is a clear wake-up call: Apple users need to get proactive about their security. We recommend:

  • Researching apps online before installing them
  • Sticking to utilities from official app stores whenever possible
  • Using a reliable security solution that blocks malicious websites and stops malware activity on your device
  • Keeping all your credentials and banking details in a secure password manager. One option is Kaspersky Password Manager— which, notably, wasn’t listed among the apps targeted by CrashStealer

Kaspersky security solutions detect the malware described in this post and assigns to it the verdicts HEUR:Trojan-Downloader.OSX.Agent.gen and HEUR:Trojan-PSW.OSX.Agent.gen.

  •  

UK’s state investments agency hit by data breach

Security lapse leaves sensitive information and contact details of 51 government officials exposed for 40 hours

The public body in charge of the UK’s state investments has been pushed to improve its internal security after a data breach left “high-level management information” publicly accessible for nearly two days.

UK Government Investments (UKGI), the agency that manages the taxpayers’ interest in a swathe of companies including Channel 4 and the Post Office, said the security failure also left more than 50 government officials’ personal details exposed for nearly 40 hours.

Continue reading...

© Photograph: Marina Demidiuk/Alamy

© Photograph: Marina Demidiuk/Alamy

© Photograph: Marina Demidiuk/Alamy

  •  

Vulnerability & Patch Roundup — July 2026

Vulnerability & Patch Roundup — July 2026

Running a website means a single unpatched vulnerability can take it offline, harm your reputation, or require cleanup. Most compromises begin with automated attacks exploiting known software flaws, usually reported and disclosed already.

To keep you protected from these threats, we’ve compiled this month’s key security updates and vulnerability patches for the WordPress ecosystem.

If you’re already using the Sucuri Firewall, you’re protected. These vulnerabilities are virtually patched for all clients.

Continue reading Vulnerability & Patch Roundup — July 2026 at Sucuri Blog.

  •  

HIPAA Security Rule on AWS – Technical Safeguards Implementation and Readiness Guidance

Today, we’re releasing the HIPAA Security Rule on AWS: Technical Safeguards Implementation and Readiness Guidance. This helps covered entities and business associates configure, implement, and evidence compliance with the HIPAA Security Rule Technical Safeguard requirements (45 CFR §164.312) when building healthcare workloads on AWS.

The HIPAA Security Rule’s Technical Safeguards (§164.312) define five standards and nine implementation specifications covering access control, audit controls, integrity, authentication, and transmission security.

The guidance also covers the 2025 NPRM proposed changes, including encryption at rest and in transit becoming required, multi-factor authentication (MFA) becoming mandatory for all electronic Personal Health Information (ePHI) access, and new specifications for network segmentation, configuration management, anti-malware protection, patch management, software removal, incident response and breach notification.

Key topics included

  • Shared responsibility for HIPAA on AWS – A responsibility matrix mapping each §164.312 specification to what AWS manages nd what the customer must configure and operate.
  • ePHI boundary architecture – Guidance on establishing a defined ePHI boundary
  • ePHI data flow and encryption – A reference architecture tracing ePHI with the applicable §164.312 specification
  • Foundation checklist – Prerequisite recommendation before configuring individual Technical Safeguard controls.

This guidance is written for cloud architects, security engineers, CISOs, and compliance teams at covered entities and business associates building or operating AWS healthcare workloads. It assumes familiarity with AWS services and is intended as a practical implementation reference, not a legal or regulatory interpretation. This guidance focuses exclusively on Technical Safeguards.

HHS published a Notice of Proposed Rulemaking in January 2025, proposing significant updates to the HIPAA Security Rule—including eliminating the Addressable designation, making encryption, MFA, and asset inventory mandatory, and introducing new technical requirements not present in the current rule. As of June 2026, the final rule has not been published. This guidance covers both the current rule and the proposed changes and recommends treating all specifications as Required for new workloads.

Download HIPAA Security Rule on AWS: Technical Safeguards Implementation and Readiness Guidance.

For questions about HIPAA readiness on AWS, including Administrative Safeguards, Physical Safeguards, risk analysis, and assessment preparation, contact the AWS Security Assurance Services team or your AWS account representative.

This guidance is provided by AWS Security Assurance Services, LLC, a HITRUST External Assessor Firm and PCI-QSAC along with contribution from AWS HCLS, AWS Compliance teams. It is for informational and guidance purposes only and does not constitute legal, regulatory, or compliance advice. Recipients are solely responsible for determining applicability to their specific environments and legal obligations.

If you have feedback about this post, submit comments in the Comments section below.


Abdul Javid

Abdul Javid

Abdul is a Senior Security Assurance Consultant at AWS Security Assurance Services. He holds HITRUST certifications and has led HITRUST r2 and i1 engagements across multiple healthcare technology companies. Abdul holds multiple security and auditing certifications and supports customers building responsible AI governance programs on AWS. He has over 25 years of experience and holds certifications across AWS, CMMC, PCI DSS, PMI, ISC2, and ISACA.

Shreya Singh

Shreya Singh

Shreya is a Security Assurance Consultant at AWS with more than eight years of experience in governance, risk, compliance, and cloud security. She holds the CISA and HITRUST Certified CSF Practitioner (CCSFP) certifications and supports healthcare and technology organizations with HITRUST, HIPAA, SOC 2, risk management, and audit readiness initiatives.She holds a Master of Engineering in Cybersecurity from the University of Maryland, College Park.

Kapil Temghare

Kapil Temghare

Kapil is a Security Industry Specialist at AWS with over 10 years of experience spanning compliance, cloud security, and regulatory operations. He manages HIPAA compliance within the Regulatory Operations Center (ROC), including service eligibility assessments, controls validation, and compliance sign-off. Beyond healthcare, Kapil supports various regulatory programs such as FedRAMP and the EU Data Act and holds CISSP certification.

Hector Rodriguez

Hector Rodriguez

Hector is a Principal Industry Specialist and Executive Security Advisor, AWS Health & Life Sciences. He has over 25 years of experience enabling Health & Life Sciences business and clinical transformation and innovation and with multiple industry and academic groups. He is a board advisor for healthcare startups, a founding member of the HITRUST Business Associate Council and a health industry and cybersecurity curriculum advisor and lecturer.

  •  

The most famous brand in physical security got pwned by ShinyHunters

A leading name in home and business physical security, Brinks Home, recently said it identified unauthorized access to a portion of its IT systems, an intrusion ShinyHunters claims it carried out to steal millions of records from the security provider's Salesforce instance. Brinks Home hasn’t named the intruder or identified the affected system, but said the responsible party has threatened to leak information it claims to have taken. “Brinks Home is working diligently to determine what information was involved and who may be affected,” the company statement said. “If the Company determines that personal information has been affected, it will notify those individuals as required and as appropriate.” An FAQ page for the incident said that Brinks Home products and services weren’t affected, as far as the company knows at this point, so alarms and other security tools should be working without issue. While Brinks may not have been very forthcoming with information, and lacks any sort of official way for media to communicate with it outside of sending a LinkedIn message it didn’t answer, the party that’s claimed responsibility has gone public with some details, and it’s none other than ShinyHunters with another claimed Salesforce breach. According to leak site monitoring outfit Ransomware.live, ShinyHunters claimed to have obtained more than 4.9 million Salesforce records from Brinks Home “containing some PII.” The group threatened this week to leak the data along with causing “several annoying digital problems” if Brinks Home didn’t reach out by Thursday, July 30, to negotiate a ransom payment. It’s not clear if Brinks Home has contacted ShinyHunters; Brinks Home didn’t respond to messages, and contacts The Register has for ShinyHunters appear to have changed, causing message and email rejections. ShinyHunters has been a prolific Salesforce intruder of late, with the group claiming earlier this year to have stolen data from around 100 high-profile companies’ Salesforce instances. Salesforce has previously warned that an unnamed known threat actor group was actively scanning for public-facing Salesforce instances and abusing misconfigured guest accounts to break in. Brinks Home is no longer part of the larger Brinks brand, with The Brinks Company telling us it sold the home security arm in 2010. Brinks Home’s parent company, Monitronics, has filed for bankruptcy twice since 2019; for customers’ sake, we hope its physical security services are better than its financial management and infosec. ®

  •  

Anthropic and OpenAI are competing to see whose agents can go rogue harder

One company's inventive campaign for an unreleased product has become a contest between Anthropic and OpenAI to see which can shout the loudest about its own failures. Readers who tuned in earlier today saw the latest episode in the drama – or sitcom – as Anthropic tried to outdo OpenAI's appropriation of the Mythos marketing playbook and made itself the punchline. Since first teasing Mythos in April, Anthropic has marketed the model through fear – declaring its cybersecurity models too dangerous for public release and offering access only to a select few trusted organizations via Project Glasswing. To its credit, the strategy has paid off. Anthropic has closely associated the Mythos name with cybersecurity, which may explain why OpenAI appeared to borrow its competitor's proven PR strategy last week. OpenAI agents exploited a zero-day to escape their sandbox, leading to the autonomous cyberattack on Hugging Face. The episode duly secured sensational headlines playing on the long-held fear that AI will one day go rogue and take over the world. Anthropic responded this week by lathering on even more clown makeup, squandering an opportunity in the process. The Claude maker sent its models into a testing environment to capture a flag. Their prompts said they had no internet access, but because of what Anthropic called "a misunderstanding" with evaluation partner Irregular, the connection was live. Anthropic's models then followed OpenAI's script: they reached the public internet and attacked systems belonging to outside organizations. This time, three were affected rather than one, the company admitted. In one scenario, Mythos 5 persuaded developers to download a poisoned PyPI package. It was installed on 15 machines, including one at a cybersecurity company that routinely scans such packages for malware. In Anthropic's words: "When that company's scanner installed the package, Claude's hidden code executed. We believe the company's security scanner treated PyPI packages as safe to install, and as a result, Claude was able to exfiltrate the company’s credentials to a collection point it had set up. Claude then used these credentials to access further infrastructure from this company." Worse still, the first of the three incidents occurred in April. Anthropic discovered them only months later, during a retrospective manual review prompted by OpenAI's disclosure. Had it not gone looking, they might never have been discovered, let alone disclosed. There are some caveats. Opus 4.7, the oldest model tested, attacked production systems despite apparently recognizing what it was doing. Mythos 5 recognized that accessing the internet violated its instructions, then reasoned its way into continuing anyway. It was also responsible for publishing the poisoned PyPI package. Only an unnamed research model stopped itself from attacking external organizations. Anthropic also said the models were not running with the production safeguards and monitoring that would normally surround a deployment. Most damningly, Anthropic ran Mythos 5 – the model it had deemed too dangerous for public release – without safeguards in an environment that unexpectedly had internet access. Following OpenAI's admission that it failed so badly in its responsibility to control its technology, Anthropic could have easily spun the story in its favor. You don't have to be fictional tapdancing political PR antihero Malcolm Tucker to see how Anthropic could have used the episode to make its case as the safer, more trustworthy AI company. Instead, realizing its own marketing playbook was being used to help a competitor, it went head-to-head with OpenAI, willingly admitted that it made similar sandbox-based blunders, and disclosed that the results were even more calamitous. Three companies hacked, not just one. So, while the AI biz has attempted to eclipse OpenAI's "rogue agent" story with its own, what's left behind is a new reputation for irresponsible handling of technology. Failed superheroes The incident does not instill a great deal of trust in either Anthropic or OpenAi to safeguard the world from its AI. Dr Ilia Kolochenko, founder of ImmuniWeb and practising cybersecurity and data protection lawyer, likened the two companies to failed superheroes. "While making conclusions would be a bit premature at this point in time, the incidents certainly do not increase confidence in the AI vendor's ability to safely deploy AI, let alone to assure their customers that the so-called frontier models are safe to use," he told The Register. "It is akin to hiring a superhero to protect you but being afraid that the superhero may suddenly go rogue and kill you and your family. Nobody needs such a superhero." Likewise, security pro Jake Williams, VP at HunterStrategy and IANS faculty member, said: "I'm not going to mince words: the major AI labs are negligent in protecting the public from their agents. "We need government regulation now or at the very least a private cause of action with guaranteed punitive damages for agents damaging others." By trying to reclaim a marketing trope that served it well, Anthropic has invited scrutiny of its own safety record and accusations that it is chasing attention above all else. Other experts we spoke to shared the concern that both companies are mishandling their agents, with potentially greater consequences as the systems become more capable. The common thread is recklessness, which Anthropic and OpenAI seem oddly eager to advertise. ®

  •  

Charities remain locked out of CAF Bank online accounts

A week after suspending online banking, CAF Bank still has no timetable for restoring access to its 14,000 UK charity customers. The bank updated customers on Thursday about the outage, which has disrupted payments to staff and suppliers. Little had changed. In a message seen by The Register, CAF Bank said it was not yet able to restore the service safely. As it had earlier in the week, the bank said it detected attempted fraud on some accounts and acted quickly to stop it. Its investigation uncovered a previously unknown vulnerability in the connection between its systems and third-party software. CAF Bank said its technical team was working around the clock with suppliers and external experts on a fix. The Register understands that no timetable has been set for restoring online banking. Earlier this week, CAF Bank CEO Alison Taylor apologized for the disruption. "The core bank is not affected. We are acutely aware of the impact this has on our customers and want this to be fixed as soon as possible, but we cannot restore access to the online service until we are assured the issue is safely resolved," she said. Since The Register first reported the story earlier this week, the BBC has spoken to charities struggling to make essential payments, including payroll. Kevan Hodges, chief executive of Down's syndrome charity 21 Together, told the BBC the outage was "appalling." "People are concerned that wages won't get paid because of this, and that's just stressful when they have bills to pay. My team have wasted days trying to get through to [CAF Bank], but all in vain," he said. Bali Rodgers, chief executive of Safer Communities Alliance, told the BBC the grassroots organizations it represents were slowly losing trust in the bank. CAF Bank also came under fire last year after the introduction of a new banking platform left customers unable to log in or make transactions. The bank later apologized but has not disclosed how much it spent on the system. CAF Bank held £1.45 billion ($1.93 billion) in customer deposits at the end of its 2024/25 financial year. ®

  •  

AI Escaped a Sandbox. That is Not What Should Worry You

What OpenAI’s and Anthropic’s testing incidents really teach defenders  In the past two weeks, two of the world’s leading AI labs have disclosed the same unsettling result. During their own safety testing, their most capable models reached real companies’ systems. First OpenAI, whose models broke into Hugging Face. Then Anthropic, whose models reached three more organizations.  Read the disclosures closely. Two facts carry the weight.  First, the safeguards were not defeated. They were switched off by design. OpenAI ran the models with reduced cyber refusals and safety classifiers disabled, to measure raw capability on a cyber benchmark. A model doing […]

The post AI Escaped a Sandbox. That is Not What Should Worry You appeared first on Check Point Blog.

  •  
❌