Our Incident Response team recently investigated a sophisticated attack that shows how little it can take to turn an ordinary working day into a serious security incident. Cyberattacks are becoming increasingly sophisticated. Not necessarily because attackers are using breakthrough technologies, but because they can convincingly imitate routine workplace situations and strike when the victim suspects nothing.
It was the morning of an otherwise ordinary working day. An employee at the affected company joined an online business meeting without the slightest reason to believe that an attacker was sitting on the other side. The call appeared to be legitimate communication with a business client via Microsoft Teams. Then the audio stopped working.
The person on the other side offered a solution. The employee only needed to open Terminal and run a command that was supposed to update a component required for the Teams call. All they had to do was copy the command into macOS Terminal, press Enter and wait for the technical problem to be resolved. At 8:03:08 a.m., the employee ran the command. From that moment on, no further action was required.
One command in Terminal started a quick chain of events
The command connected to a domain impersonating Microsoft Teams infrastructure, downloaded additional code and passed it directly to the system shell. Thirteen seconds later, the first piece of malware appeared on the disk. Its name was designed to resemble a legitimate Apple system file. It changed its permissions, applied an ad hoc code signature and launched in the background.
A second malicious application was then downloaded to the computer, this time disguised as an iCloud synchronisation component. At 8:03:33 a.m., it captured the user’s password and saved it in a hidden file. Two seconds later, the script sent the password to infrastructure controlled by the attacker. At that exact moment, the XDR platform detected the attack. One second later, it automatically stopped the malicious activity, and another second later, it isolated the device from the network. Only 27 seconds passed between the command being executed and the password being stolen. The entire attack was stopped within 29 seconds.
For our client and our SOC, however, the incident was far from over. In fact, the real investigation was only beginning. We needed to establish what the malware could have accessed during those few seconds and which other accounts, tokens or systems had to be treated as potentially compromised.
What was the impact on the company?
The forensic investigation confirmed that the user’s password had been successfully exfiltrated. It found no evidence that the contents of the macOS Keychain had been stolen, that the browser or its extensions had been compromised, or that the attacker had gained interactive access to the device. This was good news, but it was not enough to simply change the password, switch the computer back on and continue working.
Before it was stopped, the malware attempted to access paths associated with SSH keys. It checked which processes were running on the device and prepared a persistence mechanism designed to launch it with administrator privileges whenever the system started. It continuously deleted temporary files and passed parts of its code directly into the shell through chained commands. This helped the attacker obscure their tracks and made it more difficult for our analysts to reconstruct the attack.
For the company, the incident therefore meant taking the device out of service, terminating active sessions, replacing passwords, tokens and other secrets accessible to the user, and conducting a threat hunt across the entire environment. The hunt ultimately found no evidence of the same indicators or attack techniques on any other devices.
Could the social engineering attack have been prevented?
Instead of exploiting a software vulnerability, the attackers exploited trust, time pressure and the employee’s natural desire to complete the business meeting. The first line of defence should therefore be a simple rule worth repeating: no legitimate business partner should ask you to run a command in Terminal during a call. A technical problem is better resolved by arranging a new meeting through a verified corporate channel.
Employee training alone, however, should never be considered sufficient. The consequences could also have been reduced by removing unnecessary local administrator privileges, restricting unauthorised applications, implementing application allowlisting, and applying DNS and HTTP filtering. In this case, the final layer of defence—the XDR platform—pulled the emergency brake by detecting the attack and automatically isolating the device.
Dubai IP address concealed the North Korean APT group BlueNoroff
At first glance, the trail led to the United Arab Emirates. One of the IP addresses used in the attack was geolocated to Dubai. A deeper analysis of the attack techniques, the structure of the lure and the links between the infrastructure led us to assess with a high degree of confidence that BlueNoroff was behind the operation. BlueNoroff is a North Korean state-sponsored group within the Lazarus ecosystem, also tracked as Sapphire Sleet.
BlueNoroff is strongly financially motivated. The group has a long history of targeting fintech companies, investors, developers and technology executives. Its interest extends far beyond the computer itself. The real prize is the access its user may have to digital wallets, development environments, corporate systems and sensitive accounts.
The incident fits the pattern of the GhostCall campaign documented by Kaspersky and its more recent Microsoft Teams-based variation, sometimes referred to as ProspectCall. The attacker poses as a potential client, investor or business partner, establishes trust and moves the conversation to an online meeting. Then comes the audio problem, the fake update and the command that the victim is asked to run in Terminal.
A Mac is not secure simply because it is a Mac
There is a popular but overly simplistic belief that attackers largely leave macOS devices alone. Nothing could be further from the truth. The attacker did not need anything exotic in this case. The tools were already available in the operating system: curl, zsh, AppleScript, codesign and nohup. Each of them is legitimate on its own. They only became suspicious when viewed as a specific sequence of actions, executed from a particular location and within the wider context of the incident.
The case underlines why effective defence must combine several layers. XDR monitors behaviour on the device. Network logs show which domains and IP addresses the device communicated with. By comparing this information with current threat intelligence, the SOC can identify connections to suspicious infrastructure and add relevant indicators to its detection rules. Phishing-resistant MFA and hardware-protected keys reduce the value of a stolen password. A SOC must be able to assemble weak signals into a coherent story before the attacker gets the chance to finish it.
Incident response after password theft: what should a company do?
The biggest mistake after an incident like this is rushing to return to normal operations. The compromised device must be isolated immediately, but before wiping it, the company should consider creating a complete forensic image of the disk. If that is not possible, the device should be securely sealed and preserved for further analysis. Only after the evidence has been secured should the device be fully reinstalled in an offline environment.
At the same time, the compromised passwords must be changed, active sessions terminated, and all corporate and personal credentials, tokens, secrets and keys that may have been stored on the device replaced. Searching other devices for the same indicators of compromise and attack techniques will determine whether this was an isolated event or merely the first affected device to be discovered.
The lesson in this case is not to run anything under pressure that you do not understand simply because the person on the other side appears trustworthy. The attack took 27 seconds. Establishing with confidence what remained untouched required hours of work.
If a similar situation occurs in your company, the Incident Response and DFIR team at Binary Confidence can isolate the affected device, preserve evidence, reconstruct the attack, determine its true impact and clean the environment before it is safely returned to operation. We help companies detect and stop attacks, understand what triggered them and, most importantly, identify what the attackers left behind.
This activity is supported by the European Cybersecurity Competence Centre (ECCC) as part of the project under grant code 101145856, and by the Ministry of Investments, Regional Development and Informatization as part of the state programme of the Recovery and Resilience Plan of the Slovak Republic under project grant code 17I04-04-V02-00001.
