Sophos said a fake coding test ran malware on an employee's Mac whose endpoint agent had been silent since June 11, and that a source-code app grant survived the password reset. Companies can test both gaps this week.
This is Sophos's account, from a blog post listed November 4 and a root cause analysis whose page data says "October 2026".
What happened
According to the analysis, the Sophos Endpoint agent was last seen on June 11 and then stopped reporting.
On September 10-11, browser telemetry recorded the employee's corporate password entered on a public source-code platform's sign-in page. On September 14 the employee cloned a repository presented as a job-interview assignment and opened it as a trusted VS Code workspace. Workspace settings that define the terminal profile ran when a terminal opened 92 seconds after the clone (our count).
The blog says the BeaverTail loader and InvisibleFerret backdoor were running "within two minutes," but the analysis puts the final-stage backdoor in memory about 18 minutes after the clone (our count).
An industry partner, not Sophos, reported the probable compromise on September 15. Sophos then established the device was not reporting, the first recorded finding, 96 days after June 11 by our count. Sophos said the malware ran in memory for about 26 hours; the user's reboot on September 15, about 4.5 hours after the partner's report (our count), ended it. Sophos found no persistence.
Sessions were revoked and the password reset, but the analysis says a third-party OAuth app grant on the account "was not invalidated" by either and "had to be revoked separately." The grant was used for 27 read requests against two internal repositories, which Sophos treated as unauthorized, with the actor undetermined. The timeline says only "afternoon" for the reset and the use, not which came first. Sophos revoked the grant on September 16 and closed the incident on September 24.
The blog lists NICKEL ALLEY among "North Korean groups" and says the technique matches its tradecraft; the analysis says no attribution to a named group is made or implied.
Who is affected
Sophos said its products, services and customers were not affected, and that actions on the device could not be fully recovered. Its follow-on work found a small population of other corporate devices that were compliant in identity and device management yet not reporting to the console.
In our analysis, the exposure is a job-search task on a work laptop, because the lure runs with that employee's access. Neither Sophos page says the employee was job hunting or how the lure arrived.
What to do now
- Security engineering, this week: join identity-provider sign-ins to EDR check-ins; list and alert on devices that sign in but have not reported within a threshold you set.
- IT, within 30 days: make EDR reporting a device-compliance condition. Sophos requires the agent on macOS.
- Identity team, this week: make revoking third-party app grants its own containment-runbook step. Sophos lists this as a post-incident review item. Test it by resetting a password and checking whether a live grant still works.
- Security, within 30 days: have staff run take-home tests in a disposable VM, not on a work laptop.
- Security engineering, within 30 days: check VS Code Workspace Trust for trusted parent folders, which trust their subfolders. On by default, it blocks terminals in Restricted Mode, but this workspace was trusted. VS Code's enterprise policy reference had no workspace-trust entry on November 4, so we could not confirm central enforcement.
What is not known yet
Sophos says the agent failure's cause is still under investigation, so test behavior, not a specific fault. It has not said which app held the grant or how it was obtained.
