Fake recruitment installed persistent malware on macOS

On 29 July 2026, Polish cybersecurity site Sekurak published a first-person account of a real macOS incident. The attack began with a LinkedIn recruitment conversation tailored to the victim’s professional profile. After building trust, the contact directed the candidate to a domain impersonating Cisco Webex, where a downloaded DMG instructed the user to drag an item into Terminal.

That detail matters. The malware did not have to “magically break” every macOS security control. The user was persuaded to execute a shell command, moving execution away from the normal LaunchServices path and the expected Gatekeeper checks. The attack then established persistence in ~/Library/LaunchAgents, obtained a second-stage location from a DNS TXT record, and executed JavaScript for Automation through osascript -l JavaScript.

What the 29 July source confirms

Wojciech Wilk’s incident account published by Sekurak documents the event from the infected user’s perspective. Confirmed elements include:

• a recruitment approach tailored to genuine professional experience;
• the domain cisco[.]us-webexmeet[.]com, made to resemble Webex;
• a DMG with a “Drag into Terminal” instruction;
• user-level persistence under ~/Library/LaunchAgents;
• retrieval of a next-stage address from a DNS TXT record;
• execution of the second stage as JXA through osascript;
• exposure of SSH keys, Git and cloud tokens, browser sessions and local projects;
• host isolation, removal of persistence, session revocation and a complete device erase.

The source does not publicly identify a specific threat group, so it does not support a confident attribution. Similarity to known “Contagious Interview” operations may be an analytical hypothesis, but it should not be presented as fact without matching indicators and independent sample analysis.

Why a carefully prepared recruitment approach works

The message did not look like random spam. The attacker referred to a real profile and created a process that resembled expected recruitment steps. A candidate expects an interview link, technical exercise or conferencing application. Each can become a plausible reason to download a file.

Malicious recruitment does not need a five-minute payment ultimatum. It can proceed slowly, ask sensible questions, use industry language and request an unusual action only after trust has formed. This is an important lesson for employee cybersecurity training: simulations should include HR, GitHub, messaging and developer-tool contexts, not only invoice emails.

“Drag into Terminal” changes the trust model

An application downloaded from the internet normally receives a quarantine attribute. LaunchServices and Gatekeeper can then assess signatures, notarization and reputation. When instructions convince a user to paste a command or drag an object into a shell, however, the system sees an action performed through Terminal—an application the user already trusts.

This does not mean every DMG can automatically bypass Gatekeeper. The attack exploits the distinction between opening an application and deliberately executing text or a script in a shell. Human judgment becomes the barrier, so fake installation screens often explain the unusual step as a permission problem, a connection repair or a requirement imposed by corporate security.

The defensive rule is straightforward: a legitimate conferencing tool should not require dragging an item into Terminal, running curl | sh, disabling Gatekeeper or pasting an administrator password. If a recruiter requests any of those actions, stop and verify the process through a separate channel.

LaunchAgent persistence does not require root

~/Library/LaunchAgents belongs to the user. A plist there can start a program at login without administrator privileges. The absence of a password prompt therefore does not mean that compromise failed. User-level malware can still read accessible files, reuse authenticated sessions and communicate with services to which the user is already signed in.

Useful monitoring points include:

• new or modified files under ~/Library/LaunchAgents;
• launchctl bootstrap, load or kickstart invoked by an unusual parent;
• child processes involving Terminal, osascript, sh, bash or zsh;
• unsigned artifacts launched from Downloads or a mounted DMG;
• a browser connection to a brand-like domain followed by script execution;
• plists pointing to hidden user directories or randomly named programs.

Those signals do not individually prove infection. Administrators and legitimate applications use LaunchAgents too. Effective detection combines creation time, process parentage, binary reputation, network activity and user context.

DNS TXT becomes a flexible configuration channel

A TXT record stores text retrievable over DNS. Legitimate uses include SPF, DKIM, domain verification and service configuration. An attacker can instead place an encoded URL or next-stage parameter in the record. The implant no longer needs a fixed download location, and the operator can redirect it without releasing a new sample.

Blocking one record does not solve the class of problem. Organizations should log DNS queries, detect unusual TXT lookups from workstations and correlate them with the originating process. A user’s Mac should not normally make repeated TXT requests to a newly registered domain unrelated to corporate mail or services.

Indicators also need context. A domain from one incident can expire or be sinkholed. Historical blocking is useful, but behaviour-oriented detection outlives a single IOC list.

JXA enables memory-oriented execution

JavaScript for Automation is a macOS mechanism for controlling applications and invoking system interfaces from JavaScript. osascript -l JavaScript runs that code without compiling a conventional application. In this incident, the second stage was reportedly executed in memory, reducing obvious files left on disk.

“Fileless” does not mean “invisible.” Evidence can still include:

• the osascript process and command line;
• process ancestry from Terminal or a LaunchAgent;
• DNS queries and outbound connections;
• access to keychains, browser directories and developer files;
• execution events and persistence changes.

An EDR should treat osascript as a dual-use tool. Blocking it globally may break automation, but a newly downloaded installer launching long or encoded JXA is a high-value signal.

Why tokens are more urgent than passwords

Changing the main password is a natural reaction to compromise. It is necessary but insufficient. A browser session, OAuth token, SSH key or CLI token can remain valid without the password and may bypass MFA. Response therefore needs to follow actual access paths.

A prioritized sequence is:

1. isolate the host from networks;
2. preserve volatile data and copies of relevant artifacts;
3. revoke SSO, email, GitHub/GitLab and cloud sessions;
4. withdraw SSH keys and personal access tokens;
5. rotate secrets found in repositories, .env files, CLI configuration and shell history;
6. review actions performed with those identities;
7. rebuild or fully erase the device from a trusted source.

Rotation should occur from a clean device. Performing it on the infected Mac may give the attacker the replacement credentials. A structured incident-response plan helps separate containment, scope analysis and recovery.

What IT and SOC teams should do

Start by hunting for the described artifacts across managed endpoints: the domain, DMG name, LaunchAgent, osascript execution and TXT queries. Then expand to equivalent behaviour because names are easy to change. Review developer and cloud logins after the possible infection time, focusing on new addresses, devices and geographies.

Review the developer-device policy too. Production keys should not remain permanently available on a laptop. Tokens need short lifetimes and minimum scope, while privileged actions should require fresh, phishing-resistant authentication. Source-control and cloud platforms should alert on a new key, security-setting changes and bulk data downloads.

Run the scenario as a tabletop exercise: HR receives the report, the user admits executing the command, SOC isolates the host, IAM revokes sessions and development teams rotate dependent secrets. Without rehearsal, the greatest delay often comes from discovering who can revoke a token and which projects were reachable.

Source versus BreachRoad conclusions

Facts about the specific recruitment flow, domain, DMG, LaunchAgent, DNS TXT record, JXA and response come from Sekurak’s first-person publication on 29 July 2026. We do not attribute the operation to a named group because the source does not provide sufficient confirmation.

The detection hypotheses, rotation order, EDR recommendations and organizational exercise are BreachRoad conclusions. If a company uses Macs for software development or cloud administration, this incident is a ready-made training and review scenario. The largest risk is not the laptop alone, but every trusted system in which its user already had an authenticated session.

Detection that survives a domain change

An incident IOC is a starting point, but an operator can replace the domain, disk-image name and LaunchAgent quickly. Behavioural analytics should connect events that may be legitimate in isolation:

• a browser downloads a DMG shortly after a messaging or recruitment-site visit;
• the instructions lead the user to Terminal instead of a signed application;
• osascript launches JavaScript for Automation from an unusual parent;
• a new file appears under ~/Library/LaunchAgents;
• the host queries a TXT record and soon retrieves another stage;
• a process reads cloud configuration, SSH keys, repositories and browser profiles.

Correlation inside a short time window is a stronger signal than any one event. The SOC can express the sequence as a detection hypothesis, validate it with a controlled simulation and maintain it through a Sigma and SIEM detection-engineering process.

Recruitment should never require commands, Gatekeeper bypass or an unknown meeting client. Publish legitimate recruiting domains and tools, and give candidates a clear impersonation-reporting route. A social contact—even a genuine but compromised profile—must not automatically become a trusted software source.

If a command was executed, use an incident-response plan whose scope includes Git, cloud, password manager, email and active sessions, not only the Mac. The Breachroad Academy helps employees understand those trust relationships without reproducing malware.

Useful readiness metrics include time from user report to host isolation, SSO-session revocation, domain blocking and secret inventory. Also measure the percentage of Macs reporting osascript activity, EDR visibility into user directories and IAM’s ability to revoke tokens at scale. Those outcomes say more about resilience than the mere presence of an endpoint product.