Malware Analysis - AMOS from SEO-poisoned website

Executive Summary

On 29 August 2025, Cortex XDR flagged a suspicious program downloaded by one of our employees from a malicious advertising site mimicking GitHub. Upon further analysis, the downloaded program was discovered to be a variant of Atomic macOS Stealer (AMOS) disguising itself as a fake GitHub Desktop downloader. More about AMOS can be read from my previous blog.

Malware attachment (password is infected)

Technical Analysis

Tracking Google Ads

From what we know, the malware was originally distributed via SEO poisoning. Checking the metadata of the advertised website, the advertiser named Paid for by SOS Burn-out accompagnement, was identified to be based in Belgium and was verified by Google.

SOS Burn-out accompagnement is a small Belgian mental-health nonprofit that offers support and counseling for burnout. Google’s Ad Centre shows its verified advertiser identity and country tied to the ad you saw. Nothing about this organization suggests any link to software distribution, developer tooling, or GitHub products - its public footprint is healthcare-adjacent, not tech. That mismatch is the signal. Seeing their verified name on a “GitHub Desktop” download ad points to either a hijacked Google Ads account or cloaking

Here we can see more similar ads from the advertiser that is all related to Github Desktop. Earliest advertisement was on 10 August 2025, while the most recent was on 28 August 2025.

Mounting the DMG file on a macOS virtual machine, an on-screen prompt will be shown to instruct the user to execute a Mach-O binary by right clicking and opening it directly. This was a common tactic used to override Apple’s integrated security feature (GateKeeper) and execute unsigned applications.

Payload Analysis

When mounting the DMG file on a macOS virtual machine, we see the familiar AMOS stealer background along with the same prompt used to bypass GateKeeper. The malware supports both x86 and ARM architectures, enabling it to compromise any macOS user.

Using both otools and strings on the malicious binary, the encrypted payload could not be identified. This suggested that the binary might be more evasive and complex than other AMOS we have identified so far…

With static analysis revealing no results, dynamic analysis was necessary to uncover the payload. Before debugging with lldb, I had to identify the binary structure and key addresses. With IDA, the entry point was identified to be at 0x100006530. The several calls to system() was also noted since AMOS was known to frequently use them to execute its payload.

Recent AMOS stealers have also implemented strong anti-VM techniques to evade analysis in sandbox environments (to make people like me miserable), typically by querying system information to detect virtualization signatures like QEMU, VMWare, KVM, etc. Hence, several breakpoints was placed to catch key functions potentially used for anti-VM in the binary.

These breakpoints target:

• ptrace: For debugger detection.
• system: For the anti-VM osascript call.
• 0x100001220: For a sysctl check (system information query).
• pthread_create: For threaded checks (e.g., parallel anti-debugging logic).
• sysctl: For additional VM detection.

Resuming the execution, the first breakpoint hit was at system(). The main thread was confirmed, and the command string passed to system() was inspected. The %rdi register reveal the anti-VM osascript command.

To bypass this check, the string at $rdi was patched directly in memory using LLDB’s memory write command. The original script was overwritten with the simple command exit 0, effectively neutralizing the anti-VM logic and forcing it to always succeed.

Following this bypass, execution reached a breakpoint on pthread_create. The malware attempted to spawn additional worker threads, likely to parallelize execution or distribute payload tasks. Since thread creation itself was not inherently malicious, execution was allowed to continue. Subsequent system() calls were intercepted, and their command arguments were extracted directly from process memory instead of being executed on the host.

The extracted payload revealed the presence of malicious backdoor code consistent with recent AMOS stealer variants.

Indicators of Compromise

Addendum

On September 5, 2025, security researchers at Artic Wolf identified the same malicious repository that was hosting the malware. Readers interested in the Windows malware can check out their page for a detailed breakdown.