Most articles about ransomware on the Mac start by either dismissing it (“Macs don’t get ransomware”) or inflating it (“attacks are exploding”). Neither is honest. The documented record is short, specific and worth reading closely, because it tells you exactly what each layer of a defence is for. This article goes through that record, then through the layers, and is explicit about which one a firewall covers and which ones it does not.
What has actually happened on macOS
KeRanger, March 2016. Palo Alto Networks’ Unit 42 reported on 6 March 2016 that a compromised installer of the Transmission BitTorrent client, downloaded from the project’s own website, carried the first fully functional ransomware for OS X. It was signed with a valid developer certificate, which let it pass Gatekeeper. Its behaviour is the part worth remembering: according to Unit 42, it waited three days, then connected to its command-and-control servers over the Tor network, and only after that began encrypting files. Apple revoked the certificate and updated XProtect within days.
ThiefQuest, also called EvilQuest, June 2020. Patrick Wardle’s Objective-See published its first analysis on 29 June 2020, describing a sample that spread through trojanised installers of pirated software and persisted through launch agents and daemons. ThreatDown (then Malwarebytes) reported the next day that the pirated installers included Little Snitch and Mixed In Key. Encryption was almost a sideshow: the sample also carried a keylogger and opened a reverse shell to a command-and-control server, which is why researchers renamed it. It was a data thief wearing a ransomware costume.
LockBit, April 2023. BleepingComputer reported on 16 April 2023 that encryptors built for macOS had been found for LockBit, one of the largest ransomware-as-a-service operations at the time. Researchers who examined the builds concluded they were most likely test versions, with references to incompatible systems and missing pieces of macOS-specific functionality, and not ready for real attacks. The story matters less for what the build did than for what it signalled: a large criminal operation had decided the Mac was worth an engineering budget.
Three cases in seven years is not an epidemic. But each one entered through a route that still exists today: a trusted download that was quietly swapped, pirated software, and an industrialised criminal supply chain. A layered defence is built around those routes, not around a headline number.
Layer one: keep untrusted code from running
Apple’s own platform security documentation describes macOS protection against hostile software as three stages: prevent it from launching (the App Store, Gatekeeper and notarisation), block it from running (the same tools plus XProtect), and remediate it after it has executed (XProtect again). This is the layer that stopped KeRanger within days once Apple had revoked the certificate. It is also the layer that pirated software exists to defeat: every ThiefQuest victim had deliberately bypassed Gatekeeper to install a cracked application. The single most effective ransomware control on a Mac is therefore not a product. It is a policy: nothing cracked, nothing from a torrent, and no “right-click, Open” to force past a Gatekeeper warning unless you know exactly why the warning appeared.
Layer two: watch the network, because ransomware talks
Encryption is the last step, not the first. MITRE ATT&CK lists it as Data Encrypted for Impact (T1486), an Impact-stage technique, and the stages before it involve the network. A sample fetches a key or instructions from a command-and-control server; it may exfiltrate files before encrypting them so that a ransom can also threaten publication, which ATT&CK catalogues as Exfiltration Over C2 Channel (T1041); ThiefQuest even ran a reverse shell. KeRanger sat quietly for three days and then made its first outbound connection over Tor. That first connection is what a per-app firewall is positioned to see.
This is where FireAI fits, and the fit is narrow but real. FireAI does not detect encryption. It does not watch files change, it does not analyse processes or memory, and it cannot decrypt anything. What it does is treat every outbound connection as a decision. A binary that has never connected before triggers a permission prompt, with the on-device model’s reason shown alongside; the same model can block or flag a connection from an unknown app to a suspicious destination on its own. The threat-intelligence feeds FireAI applies locally include the Tor exit node list, abuse.ch, Spamhaus, FireHOL and phishing lists, so a first connection to known criminal infrastructure is blocked by rule rather than by judgement. And if you suspect something is running, the kill switch cuts internet access while keeping the local network, which breaks the command-and-control link without pulling the plug on a machine you may need for forensics.
Be clear about the failure modes. A sample that encrypts without ever connecting, using a key embedded in its own code, is invisible to a firewall. A sample that uses an already-approved application, a browser for instance, to reach its server blends into allowed traffic. A firewall reduces the chances that the attack is quiet and complete; it does not make encryption impossible.
Layer three: backups that the attacker cannot reach
Whether an encryption event is a bad afternoon or a business-ending week is decided entirely by this layer. CISA’s #StopRansomware Guide puts it first among its preparation steps: maintain offline, encrypted backups of critical data and test them regularly, and consider immutable storage that protects stored data without needing a separate environment. The word that does the work is offline. A Time Machine drive that is permanently plugged in is a mounted volume, and a mounted volume is a target; a cloud sync folder is not a backup at all if it faithfully syncs the encrypted versions of your files over the originals.
On a Mac the practical version is straightforward. Apple’s guide to Time Machine covers setting up automatic backups to an external drive or a supported network volume. Rotate two drives and keep one disconnected, or at least eject the drive between backups. Keep a second copy somewhere that versions files rather than mirroring them, so that yesterday’s clean version survives today’s overwrite. Then test a restore of a real file, from the disconnected drive, so you know the process works before you need it under pressure. FireAI has no role in this layer, and it is worth saying so: no firewall backs anything up.
Layer four: limit what one Mac can reach
Ransomware in businesses does most of its damage on shared storage, and a Mac with a mounted share can encrypt everything it can write to. Give people write access only to the shares they actually use, and give service accounts their own credentials so that one compromised login does not open the whole file server. On the Mac itself, FireAI’s per-app rules let you decide which applications may reach your NAS, your cloud storage hosts or your office network at all: an unknown binary that tries to reach the file server on port 445 has to get past a rule it was never granted. The stricter security modes, Paranoid and Under attack, go further and refuse network access to unsigned apps entirely.
If it happens anyway
- Disconnect the Mac from the network first. FireAI’s kill switch does this while keeping the local network available; unplugging does it more thoroughly.
- Do not pay before you have checked your backups. CISA’s guide walks through isolation, triage and reporting before any decision about a ransom.
- Preserve the machine. Wiping it destroys the evidence that tells you how the sample got in and what it sent out.
- Report it. In the United States that is CISA or the FBI; in France, Cybermalveillance.gouv.fr and a complaint to the police; elsewhere, your national CERT.
- Restore from the offline copy onto a clean install, not onto the compromised system.
What “complete defence” honestly means
No single tool is a ransomware defence, and any vendor who says otherwise is selling one layer as four. Gatekeeper and your own download discipline keep most hostile code from running. A per-app firewall makes the code that does run ask before it talks, and blocks the destinations that are already known to be criminal. Offline backups make encryption survivable. Least privilege on shares keeps one bad Mac from becoming an incident for the whole office. The layers overlap on purpose, because each one has a hole the others cover. That is what a defence that holds looks like: not impenetrable, but built so that no single failure is fatal.
How FireAI and HisnLabs fit in
The two best-documented Mac ransomware families, KeRanger and ThiefQuest, both talked to a server before or during encryption — and watching for that conversation, from a binary that has never connected before, is the one part of the defence a per-app firewall like FireAI can honestly claim.
FireAI is HisnLabs’ own product: an on-device AI firewall for Mac. It shows every connection your apps make, in plain language, and lets you decide what leaves your Mac — its AI runs locally, so your traffic is never sent to us or anyone else. HisnLabs’ security research team is the group that keeps that decision-making accurate: cataloguing which domains are ordinary telemetry versus a real product, tracking the country and network behind a connection, and training the on-device model (its Autopilot feature) on real traffic patterns, all without any of it leaving your Mac.
You can read the technical decisions behind it, or try FireAI for 17 days, at FireAI, by HisnLabs.