Category: Malware Analysis

We spend most of our time on the outside of an infostealer campaign: the delivery pages, the C2 infrastructure, the loader that stages the payload. This post looks at the inside instead. Once a stealer is running on a host, it has to do a small number of things that it cannot avoid doing, because those actions are the whole point of the malware. That makes them the most durable detection surface we have. The panel names change every quarter. The behaviour on the endpoint barely moves.

The things every infostealer has to do

Strip away the branding and the invariants are the same across StealC, Lumma, Vidar, and the rest of the current field. A stealer has to locate credential stores, decrypt them, collect a few other high-value files, bundle the result, and send it out. Each of those steps leaves a signal that is hard to hide precisely because it is load-bearing.

Signal 1: a non-browser process reading the browser’s credential files

Browsers keep saved passwords, cookies, and autofill in known SQLite files: Login Data, Cookies, Web Data. A stealer opens them directly. The tell is not that the files are read, the browser reads them constantly. The tell is who reads them. When a process that is not the browser opens Login Data under a Chrome or Edge profile directory, that is close to a definition of the attack. MITRE catalogs this as Credentials from Web Browsers (T1555.003) and the cookie theft that rides along with it as Steal Web Session Cookie (T1539).

Signal 2: decryption, and the response to app-bound encryption

The saved secrets are encrypted. Historically a stealer just called DPAPI to unprotect them, which meant touching the user’s master key. Since Chrome added app-bound encryption in 2024, the loot can no longer be decrypted by any process running as the user; it has to be decrypted by the browser itself. The stealers adapted by getting their code to run inside or on behalf of the browser process, through injection or COM abuse. That adaptation is itself a signal: an unexpected module loaded into the browser, or a short-lived child of it doing credential work, is now part of the pattern rather than an anomaly to explain away.

Signal 3: the walk through the rest of the credential landscape

After the browser, a stealer sweeps a predictable list: cryptocurrency wallet directories, FTP and SSH client configs, email client stores, and the local databases of password managers. To an endpoint sensor this looks like one process opening a scattered set of sensitive files across unrelated applications in a short window, which is Unsecured Credentials: Credentials In Files (T1552.001). Normal software does not read your wallet, your SSH key, and your Thunderbird profile in the same two seconds.

Signal 4: staging and archiving

The collected material gets written to a working directory, usually under the user’s temp or app-data path, and compressed into a single archive for transport. That is Local Data Staging (T1074.001) followed by Archive Collected Data (T1560). A burst of reads across sensitive locations, immediately followed by an archive appearing in temp, is a tight, high-confidence sequence.

Signal 5: the exfiltration burst

Finally the archive leaves, in one short outbound transfer to a first-seen domain or a messaging API. It is Exfiltration Over C2 (T1041) or, increasingly, over a legitimate web service. Taken alone the network event is easy to miss inside TLS. Taken as the last link of the chain above, it is the confirmation.

Where this visibility has to live

The problem with every signal here is that it is on the endpoint, not the wire. The credential reads, the injection, the staging, the archive, none of it is legible from network logs, and the exfil is a single burst against normal-looking TLS. Catching it means process, file, and registry telemetry from the host, correlated in near real time, with someone actually reading the correlations at the hour the infection happens rather than the following Monday. That last requirement is where most organisations come up short, because a 24-hour endpoint watch is a staffing problem before it is a tooling problem. It is why teams that cannot run that watch in-house route these detections to a managed detection and response provider that already runs the endpoint side around the clock. The IOCs we publish through ThreatFox and the family notes on Malpedia feed the infrastructure side of the same detection; the behaviours above feed the host side.

Closing

We will keep tracking the infrastructure, because it is where attribution and early warning live. But if you are defending endpoints, build your detections on the invariants rather than the indicators. The domain in this week’s campaign will be dead by next week. A non-browser process reading Login Data, decrypting it, archiving the result, and shipping it out will still be an infostealer next year.

If your Mac has been acting strangely – sluggish performance, unexpected pop-ups, browser redirects, or unfamiliar processes consuming CPU – you may be dealing with a malware infection. While macOS has a reputation for being more secure than Windows, it is not immune to threats. Knowing how to check for malware on Mac is an essential skill for anyone who takes their digital security seriously.

This guide walks through a systematic approach to detecting and removing malware on macOS, from built-in tools to specialized scanning utilities and terminal-based investigation techniques.

Recognizing the Signs of Mac Malware

Before diving into how to check for malware on Mac, it helps to understand what suspicious behavior looks like. Common indicators include:

• Noticeably slower system performance without an obvious cause
• Browser homepage or search engine changed without your consent
• Unexpected pop-up advertisements, even when no browser is open
• Applications crashing frequently or failing to launch
• Unusually high CPU or network activity when the system should be idle
• New browser extensions or toolbar items you did not install
• Ransom messages or screen lock warnings demanding payment

Any combination of these symptoms warrants a thorough investigation. The absence of obvious symptoms does not guarantee a clean system either – some malware operates silently, exfiltrating data or mining cryptocurrency in the background.

Using Activity Monitor to Identify Suspicious Processes

The first step when you suspect malware is to open Activity Monitor (Applications > Utilities > Activity Monitor). This built-in tool shows all running processes and their resource consumption.

Click the CPU tab and sort by CPU usage (descending). Look for processes consuming abnormally high CPU that you do not recognize. Common legitimate high-CPU processes include kernel_task, WindowServer, and mds_stores. Anything unfamiliar – especially processes with random-looking names or processes consuming 80-100% CPU persistently – deserves investigation.

Select a suspicious process and click the Info button (the “i” icon) to see its full path. Legitimate macOS processes typically reside in /System, /usr, or /Applications. A process running from /tmp, /var/folders, or a hidden directory in your home folder is a red flag.

The Network tab is equally valuable. Sort by Sent Bytes or Received Bytes to identify processes making unusual network connections. Malware that phones home to a command-and-control server will show persistent outbound network activity.

Checking Login Items and Launch Agents

Malware frequently establishes persistence by adding itself to Login Items or installing Launch Agents and Launch Daemons. These mechanisms ensure the malware restarts after a reboot.

To check Login Items, go to System Preferences > Users & Groups > Login Items. Review the list and remove anything you do not recognize. On macOS Ventura and later, this has moved to System Settings > General > Login Items.

Launch Agents and Daemons require a deeper look. Open Terminal and list the contents of these directories:

ls -la ~/Library/LaunchAgents/
ls -la /Library/LaunchAgents/
ls -la /Library/LaunchDaemons/
ls -la /System/Library/LaunchDaemons/

Legitimate Launch Agents typically have identifiable developer names in their filenames (com.apple.*, com.google.*, etc.). Files with random strings, misspelled company names, or names that do not match any software you installed should be examined. Open the .plist file with a text editor to see what executable it launches and research that path.

macOS Built-in Protection: XProtect and MRT

Apple includes several built-in security mechanisms that work silently in the background. Understanding these helps you know what is already being checked when you want to check for malware on Mac.

XProtect is Apple’s signature-based malware scanner. It checks downloaded files against a database of known malware signatures. XProtect updates automatically through system updates, and its definitions are stored in /Library/Apple/System/Library/CoreServices/XProtect.bundle. While XProtect catches known threats, it cannot detect zero-day malware or threats that have not yet been added to its signature database.

MRT (Malware Removal Tool) runs periodically to scan for and remove known malware that may have already been installed. Like XProtect, it relies on known signatures. On newer macOS versions, this has been replaced by XProtect Remediator, which runs more frequent background scans.

Gatekeeper verifies that applications are signed by identified developers and have not been tampered with. It does not scan for malware directly, but it reduces the risk of running unsigned or modified applications.

These built-in tools provide a baseline level of protection, but they are not comprehensive. They rely on known signatures and cannot detect novel or targeted threats.

Recommended Scanning Tools for Mac Malware Detection

For a thorough check, dedicated malware scanners provide deeper analysis than the built-in macOS protections.

Malwarebytes for Mac is our top recommendation for most users learning how to check for malware on Mac. The free version performs on-demand scans and removes detected threats. It is particularly effective against adware, potentially unwanted programs (PUPs), and browser hijackers – the most common categories of Mac malware. The scan is fast and the interface is straightforward.

ClamXAV is a macOS frontend for the open-source ClamAV engine. It provides real-time scanning and scheduled scans with regularly updated virus definitions. ClamXAV is a solid choice for users who prefer an open-source scanning engine and want continuous monitoring rather than on-demand scans only.

KnockKnock from Objective-See is a free tool that enumerates all persistently installed software on your Mac – Launch Agents, kernel extensions, browser plugins, login items, and more. It does not remove anything, but it provides a comprehensive view of what is running on your system and flags items that are unsigned or from unknown developers.

BlockBlock, also from Objective-See, monitors for persistence mechanisms in real time. It alerts you whenever something attempts to install a persistent component, allowing you to block it before it takes hold.

Terminal Commands for Investigating Suspicious Activity

For more advanced investigation, the Terminal provides powerful tools to check for malware on Mac at a deeper level.

List all open network connections to identify processes communicating with external servers:

lsof -i -P | grep ESTABLISHED

Check for recently modified files in common malware staging directories:

find /tmp -type f -mtime -7 -ls 2>/dev/null
find ~/Library/Application\ Support -type f -mtime -7 -name "*.app" -ls 2>/dev/null

Check for suspicious cron jobs:

crontab -l
ls -la /var/at/jobs/

Examine DNS configuration for signs of DNS hijacking:

scutil --dns | head -30
cat /etc/hosts

If the /etc/hosts file contains entries redirecting legitimate domains to unfamiliar IP addresses, this is a strong indicator of compromise.

What to Do If You Find Malware

If your investigation confirms a malware infection, take these steps in order:

1. Disconnect from the network to prevent further data exfiltration or command-and-control communication
2. Document what you found – process names, file paths, network connections – before removing anything
3. Run a full scan with Malwarebytes or ClamXAV and quarantine detected threats
4. Manually remove any persistence mechanisms (Launch Agents, Login Items) associated with the malware
5. Change passwords for any accounts accessed from the infected system, starting with email and financial accounts
6. Monitor your accounts for suspicious activity in the following weeks
7. Consider a clean macOS reinstall if the infection was severe or if you cannot verify complete removal

Knowing how to check for malware on Mac is not a one-time activity. Establishing a regular scanning schedule – monthly at minimum – combined with safe browsing habits and prompt software updates provides the strongest defense against the growing landscape of macOS threats.

Raccoon Stealer returned in mid-2023 after a period of inactivity following the arrest of one of its operators. Version 3 represents a significant rewrite of the malware, but several core behaviors remain unchanged, making tracking and detection feasible for organizations that had existing signatures.

What Changed

Communication Protocol: v3 switched from HTTP-based C2 communication to a custom binary protocol over TCP. The protocol uses a simple handshake followed by encrypted data exchange. This change makes network-level detection more difficult but also makes the traffic more conspicuous on networks that monitor for unusual TCP connections.

Credential Extraction: The browser credential extraction module was completely rewritten. v3 supports Chromium-based browsers using the new App-Bound Encryption introduced in Chrome 127, which v2 could not bypass. It also added support for extracting passwords from the macOS Keychain.

Anti-Analysis: v3 includes more aggressive anti-sandbox checks, including timing-based detection that measures instruction execution speed to identify virtual environments. Our analysis sandbox required modifications to bypass these checks.

What Stayed the Same

Configuration Format: Despite the protocol changes, the configuration blob format is largely unchanged. This means existing tools for extracting C2 addresses from Raccoon configs still work with minor modifications.

File Collection: The file grabber module uses the same directory traversal and extension matching logic. The default target extensions (wallet files, documents, images) are identical to v2.

Exfiltration: Stolen data is still packaged into a ZIP archive before exfiltration. The archive structure is the same, making it possible to identify Raccoon exfiltration in network traffic by the archive signature pattern.