Deadly macOS Homebrew Fake Websites Putting Users at Risk

You may be working on a side project, setting up a development environment, or trying to install a new library on your Mac. You search for Homebrew install macOS, open a page that looks legitimate, copy the installation command, and paste it into Terminal.

That familiar workflow can become an attack vector.

Security researchers have documented multiple campaigns in which fake Homebrew websites imitate the legitimate project and persuade macOS users to execute attacker-controlled Terminal commands. Some campaigns used malicious Google Ads, while others relied on lookalike domains and manipulated clipboard content.

The danger is that these attacks do not necessarily need a vulnerability in macOS. They rely on user execution. The victim runs the command voluntarily because the website appears trustworthy.

This technique is closely related to ClickFix, a social-engineering method in which attackers convince victims to copy and execute malicious commands themselves. Similar behavior has appeared in other macOS infostealer ClickFix attacks.

Why is Homebrew Being Targeted?

Homebrew is a free, open-source package manager widely used to install software on macOS and Linux.

Its normal installation process involves running a Terminal command. That makes Homebrew particularly attractive for social-engineering attacks because copying a command into Terminal does not immediately look suspicious to many developers.

Attackers can imitate a workflow that users already expect:

1. Search for Homebrew.
2. Open the installation page.
3. Copy a command.
4. Paste it into Terminal.
5. Enter a password if requested.

The malicious version changes only a small part of that familiar process.

Instead of exploiting Homebrew itself, attackers impersonate its website or modify the command that the victim is instructed to execute.

This distinction is important. The documented campaigns do not establish that the official Homebrew project was compromised.

Several Homebrew Malware Campaigns Have Used Similar Tactics

The reports discussed around fake Homebrew websites do not all describe one single campaign. Different researchers documented related techniques at different times, with different domains and malware payloads.

Keeping those campaigns separate makes the attack history much clearer.

Google Ads Redirected Users to a Fake Homebrew Site

In January 2025, researchers documented a malicious Google advertisement targeting people searching for Homebrew.

The sponsored result displayed the legitimate brew.sh address, but clicking the advertisement redirected users to brewe[.]sh, a lookalike domain.

The fake page closely reproduced the legitimate Homebrew installation experience and instructed visitors to execute a Terminal command.

Researchers analyzing that campaign identified Atomic macOS Stealer, also known as AMOS, as the malware delivered through the malicious installer.

This is an example of malvertising, where attackers use legitimate advertising platforms to place malicious destinations in front of people searching for trusted software.

The same basic trust problem has appeared in newer campaigns involving malicious sponsored search results. For example, another Mac-focused campaign used Google Ads to distribute malware through a Claude-themed lure.

Kandji Researchers Found a More Deceptive Clipboard Technique

A separate investigation later published by Kandji, now Iru, documented fake Homebrew websites using a more sophisticated copy-and-paste trap.

Researchers identified several Homebrew-related domains, including homebrewoneline[.]org, that resolved to the same infrastructure and displayed close copies of the legitimate Homebrew website.

The important difference was the installation box.

Instead of allowing visitors to manually highlight and copy the command, the fake page pushed users toward a dedicated Copy button.

That button was part of the attack.

JavaScript on the page could place an additional attacker-controlled command into the clipboard. The command visible on the website was therefore not necessarily everything the user would paste into Terminal.

This is a classic malicious copy-and-paste pattern.

The user thinks:

I copied the Homebrew installer.

The Mac actually receives additional instructions supplied by the attacker.

How the Clipboard Injection Worked

The fake pages were designed to reduce the victim's ability to inspect the command manually.

Researchers found code that interfered with normal text selection and copying inside the installation area. This encouraged users to press the attacker's Copy button instead.

When the button was clicked, the page could:

• Place an attacker-controlled shell command in the clipboard
• Preserve enough legitimate Homebrew installation behavior to reduce suspicion
• Trigger a request to a notify.php endpoint
• Record information associated with the copy interaction

Researchers also observed Russian-language comments inside the page code describing locations where payload or notification functionality could be inserted.

Those comments are evidence found in the analyzed code. They do not, by themselves, establish the identity or nationality of the attackers.

The technique belongs to a broader family of malicious copy-and-paste attacks. Our analysis of fake CAPTCHA malware on Mac explains how the same basic ClickFix concept can be disguised as browser verification rather than a software installation.

What Happens After the Malicious Command Is Pasted?

Executing the command gives the attack its first opportunity to run code on the Mac.

Depending on the campaign, the shell command can contact attacker-controlled infrastructure, retrieve another script or binary, and execute additional malware.

One important feature of the Kandji investigation was that malicious activity could be mixed into what appeared to be a normal Homebrew installation workflow.

This makes the attack harder for a casual user to recognize. Homebrew may appear to install while additional code executes separately.

Researchers observed encoded commands and remote payload retrieval associated with the malicious infrastructure.

Base64 encoding was also used in parts of the attack chain. Base64 itself is not malicious and is widely used by legitimate software. In malware campaigns, however, attackers can use encoding to make commands less immediately readable.

Odyssey Stealer Was Linked to the Infrastructure

Research connected parts of the fake Homebrew ecosystem with Odyssey Stealer, a macOS information-stealing malware family.

Odyssey is designed to collect valuable information from infected Macs. Depending on the version and campaign, targeted information can include browser data, credentials, cookies, files, system information, and cryptocurrency-related data.

This creates particular risk for developers.

A development Mac may contain much more than personal browsing information. Depending on the user's configuration, it could contain access to repositories, development platforms, cloud services, saved sessions, API credentials, or other sensitive resources.

That is one reason fake developer tools are attractive to attackers.

Cuckoo Stealer Appeared in Another Fake Homebrew Campaign

Cuckoo Stealer has also been distributed through malicious Homebrew-themed infrastructure, but it should not be treated as the same incident as every AMOS or Odyssey report.

In a 2026 investigation, Hunt.io documented typosquatted Homebrew domains that delivered a malicious installer through a ClickFix-style workflow.

The initial script harvested credentials and then deployed Cuckoo Stealer as a second-stage payload.

Researchers reported that the malware could target information including:

• macOS Keychain data
• Browser credentials
• Session information
• Apple Notes
• VPN configuration data
• Cryptocurrency wallet information

This shows why describing every fake Homebrew incident as one campaign would be misleading. The lure remains similar, but the infrastructure, timeframe, and malware can change.

What Was the "Trouble Brewing" Research?

Oliver Simonnet of CultureAI published an analysis titled "Trouble Brewing: Dissecting a Fake Homebrew Update That Stole User Data" in March 2025.

That research examined how a Homebrew-themed Google Ads attack could exploit user trust and demonstrated the technical behavior behind the malicious installation process.

It is useful evidence of the broader attack technique, but it should not be combined with later Kandji or Hunt.io findings as though every researcher were investigating the exact same infrastructure.

Instead, the reports collectively demonstrate a recurring pattern:

trusted developer tool + convincing imitation + user-executed Terminal command = an effective macOS malware delivery method.

Why This Attack Works

Fake Homebrew attacks succeed because they imitate behavior that is normal for the intended victim.

Developers regularly:

• Search documentation
• Copy shell commands
• Install packages from Terminal
• Use curl in legitimate workflows
• Enter administrator credentials during software setup

None of these actions is automatically dangerous.

The attacker wins by placing a malicious instruction inside a workflow that normally feels safe.

This is why visual appearance alone is weak evidence that an installation page is legitimate.

A professionally designed page, familiar logo, HTTPS connection, convincing command, or sponsored search placement does not prove that the underlying installation instructions are safe.

Similar tactics continue to appear against Mac users. A recent AmnesiaStealer campaign used a fake GitHub-style page and Terminal instructions, demonstrating that attackers are applying the same trust-abuse model beyond Homebrew.

The central security lesson is simple: the command you execute matters more than how trustworthy the page looks.

Screenshot of the real Homebrew install page.(source: the-sequence)

Screenshot of a spoofed Homebrew install page(source: the-sequence)

screenshot showing the malicious command injected into the page(source: the-sequence)

Why This Trick Works

Fake Homebrew attacks are effective because they rely more on social engineering than on exploiting a vulnerability in macOS.

The attacker tries to make several ordinary behaviors work in their favor:

• Trusting a website because it closely resembles an official page
• Looking at branding instead of carefully checking the domain
• Copying a Terminal command without reading it
• Assuming a sponsored search result has already been verified
• Treating a familiar installation process as automatically safe

This approach is similar to phishing and ClickFix attacks. Instead of breaking through a technical security control directly, the attacker persuades the victim to perform the dangerous action.

In the Homebrew campaigns, that action is particularly effective because developers already expect to copy commands from documentation and execute them in Terminal.

The result is an important security lesson: a familiar workflow is not proof that the command behind it is trustworthy.

What the Malware Can Actually Steal

Fake Homebrew campaigns have been associated with multiple macOS information stealers, including Atomic macOS Stealer (AMOS), Odyssey Stealer, and Cuckoo Stealer.

Their exact capabilities vary by malware family and version, but researchers have documented attempts to collect data such as:

• Browser passwords and stored credentials
• Authentication cookies and session data
• macOS Keychain information
• Cryptocurrency wallet data
• Browser-extension information
• Files from selected directories
• System and device information
• Application and configuration data

This becomes especially serious on a developer workstation.

A compromised development Mac may provide access to much more than personal information. Depending on what is stored on the device, attackers could potentially obtain developer credentials, active browser sessions, cloud access, repository credentials, API keys, or other secrets.

The wider risk is similar to what happens when API keys are exposed: compromising one credential can sometimes provide access to additional services and systems.

That does not mean every fake Homebrew infection automatically leads to a larger corporate breach. The impact depends on what information is present on the infected Mac and what privileges the stolen credentials provide.

These Are Recurring Campaigns, Not One Identical Attack

It is important not to combine every fake Homebrew report into a single operation.

Researchers have documented several separate campaigns using similar techniques:

• A January 2025 malvertising campaign redirected users from a deceptive Google advertisement to brewe[.]sh and delivered AMOS.
• Later spoofed Homebrew pages used JavaScript-based clipboard manipulation and were associated with Odyssey Stealer infrastructure.
• A February 2026 investigation identified additional Homebrew typosquatting sites delivering credential-stealing code followed by Cuckoo Stealer.

These similarities show that the Homebrew installation workflow remains an attractive lure.

They do not prove that every campaign was operated by the same attacker or that the malware families were part of one continuous operation.

How to Stay Safe From Fake Homebrew Websites

Verify the Installation Source

The official Homebrew website is:

brew.sh

Homebrew also maintains its official source code and installation resources through the Homebrew organization on GitHub.

Do not trust a site simply because it contains words such as:

• homebrew
• brew
• mac
• install
• official

Look at the complete domain before executing anything it provides.

Domains discovered in malicious campaigns have included subtle variations and entirely different domains designed to resemble Homebrew.

Inspect the Command Before Running It

A Terminal command should never be treated like a normal download button.

Read the command and look at:

• The domain being contacted
• Any curl or wget request
• Files being downloaded
• Pipes into bash, sh, or another interpreter
• Encoded or heavily obfuscated content
• Commands executed in the background
• Requests for administrator credentials

You do not need to understand every character in a shell script to recognize that a command downloading executable content from an unfamiliar domain deserves further investigation.

Be Suspicious of the Copy Button

A command displayed on a webpage may not always be identical to the text placed into your clipboard.

That was one of the most important techniques documented in the spoofed Homebrew campaign.

If a page prevents you from manually selecting an installation command and insists that you use its Copy button, treat that behavior as suspicious.

After copying a sensitive command, consider pasting it into a plain-text editor first and comparing it with the command provided by the official project.

Do not execute it until you understand where it came from.

Do Not Assume a Search Advertisement Is Safe

Google Ads were used in a documented Homebrew malware campaign.

A sponsored position therefore should not be interpreted as evidence that the destination has been security-verified.

Advertising platforms have security controls, but malicious advertisements can still appear before they are detected and removed.

An ad blocker may reduce exposure to some malvertising, but it should be treated as an additional layer rather than a complete defense. Users can still encounter malicious domains through search results, messages, social media, compromised websites, or other channels.

Protect Developer Endpoints

Endpoint security becomes particularly important on machines used for development because they may contain access to source code, production services, cloud platforms, and internal resources.

Security controls can help identify behaviors such as:

• Unexpected script execution
• Suspicious child processes
• Downloads from known malicious infrastructure
• Credential-access behavior
• Unusual persistence mechanisms
• Connections to known command-and-control infrastructure

Hoplon Infosec's Endpoint Security is designed to help organizations strengthen endpoint protection against malware and other endpoint-based threats.

Security software should still be treated as one part of the defense. It does not eliminate the need to verify commands and software sources.

Protect Developer Credentials

Development machines should not contain more reusable secrets than necessary.

Where possible:

• Avoid storing long-lived secrets in plain text
• Revoke credentials that are no longer needed
• Rotate credentials after suspected compromise
• Use separate credentials for development and production
• Apply least-privilege access
• Protect important accounts with strong authentication

Organizations should also understand the broader risks created by credential theft because an infostealer infection may remain valuable to attackers even after the original malware is removed.

Train Development Teams

Developers are attractive targets precisely because command-line installation is routine for them.

Security awareness training should therefore cover more than traditional email phishing.

Teams should understand:

• Fake package-manager websites
• Typosquatted domains
• Malicious search advertisements
• ClickFix-style instructions
• Clipboard manipulation
• Fake GitHub repositories
• Malicious shell commands
• Credential-stealing malware

A developer who recognizes the technique before running the command can stop the attack before endpoint controls are needed.

Use Indicators of Compromise Carefully

Security researchers frequently publish indicators of compromise, or IoCs, associated with these campaigns.

These may include:

• Malicious domains
• IP addresses
• Download URLs
• File hashes
• Suspicious commands
• Payload filenames
• Command-and-control infrastructure

Organizations can use these indicators during threat hunting and incident investigation.

However, an IoC list should not be treated as permanent protection. Attackers can register new domains, rotate servers, change payloads, and modify scripts.

This is why behavioral detection and investigation remain important alongside domain and hash blocking.

Emerging Risks and Future Trends

Clone Domains Are Easy to Replace

Blocking known malicious domains is useful, but attackers can register additional lookalike domains.

Security teams therefore need controls that can recognize suspicious behavior even when the domain has never previously appeared on a blacklist.

Payloads Can Change

A fake Homebrew site is only the delivery mechanism.

The malware behind it can be replaced.

One campaign may distribute AMOS, another may deploy Odyssey, and another may deliver Cuckoo or a future malware family.

Defenders should focus on the attack technique as well as a specific malware name.

Other Developer Tools Can Be Impersonated

There is nothing about this technique that limits it to Homebrew.

Any popular tool with a familiar command-line installation process could potentially be impersonated.

Package managers, development frameworks, command-line utilities, AI tools, cloud utilities, and software repositories can all become attractive social-engineering lures.

Software supply-chain attacks already demonstrate why developers must validate where packages and installation instructions originate. Organizations can strengthen this area through a broader software supply chain security strategy.

macOS Is Not Immune to Malware

macOS includes multiple security mechanisms, but no operating system is immune to malicious software or social engineering.

In these Homebrew cases, the attacker does not necessarily need to defeat macOS security through a new vulnerability.

Instead, the attacker attempts to convince an authorized user to execute the malicious command.

That fundamentally changes the security challenge.

Important Advice for Homebrew Users

If you are about to install Homebrew or another command-line tool, remember these principles:

• Verify the domain. Use brew.sh or Homebrew's official project resources.
• Read before executing. Check what a Terminal command downloads and runs.
• Inspect copied commands. Do not assume clipboard contents match visible webpage text.
• Treat sponsored results cautiously. Paid placement is not a security guarantee.
• Protect credentials. Developer Macs may contain access to valuable systems.
• Use endpoint protection. Detection can provide another layer when malicious code executes.
• Keep the team informed. Developers should recognize fake installer and ClickFix techniques.
• Follow current threat intelligence. Domains and malware infrastructure can change quickly.

Final Takeaway

The most important part of the fake Homebrew attack is not a sophisticated macOS exploit.

It is the attacker's ability to make a malicious action look routine.

A convincing website shows a familiar installation command. The user copies it. Terminal executes it. From the user's perspective, everything initially resembles a normal developer workflow.

That is exactly why verification matters.

Before running any command copied from the web, check where it came from, what it downloads, and what it will execute.

With fake Homebrew sites, those few seconds of verification can be the difference between installing a package manager and installing an information stealer.

Hoplon Infosec’s Endpoint Security can protect macOS users from threats like Homebrew spoofed websites. By detecting suspicious scripts, clipboard injections, and unusual activity in real time, they help prevent attacks before damage occurs.

Follow us on X (Twitter) and LinkedIn for more cybersecurity news and updates. Stay connected on YouTube, Facebook, and Instagram as well.