A BO Team supply chain attack appears to have been stopped before it reached its goal, but the intrusion behind it ran for months. Kaspersky ICS CERT published its incident response report on 5 November 2026. It describes how the group took over a software developer’s network, including the build and code-signing systems. The company asked for help in June 2025, and Kaspersky waited almost a year to publish so the company could fix its gaps.
This deep-dive follows the intrusion in order, then turns each step into a detection and a fix. We name no victim, and neither does Kaspersky. Every fact below comes from Kaspersky’s report unless we say it is our own reading.
- Exposed SSH on a Linux terminal serverService account that still accepted a passwordTechnique T1078 (MITRE ATT&CK, opens in a new tab)
- Network and web reconnaissanceMetasploit scans, Burp Suite through an SSH proxyTechnique T1046 (MITRE ATT&CK, opens in a new tab)
- Hypervisor takeoverLikely Log4Shell on VMware vCenter 7.0.3, then rootTechnique T1210 (MITRE ATT&CK, opens in a new tab)
- Backdoors on hypervisors and VMsHourly cron jobs with forged timestampsTechnique T1053.003 (MITRE ATT&CK, opens in a new tab)
- Domain takeoverLSASS dump, ntds.dit copy, shared admin passwordsTechnique T1003 (MITRE ATT&CK, opens in a new tab)
- Linux fleet through AnsibleStolen key reached VPN, backup and SIEM serversTechnique T1552.004 (MITRE ATT&CK, opens in a new tab)
- Build and signing server targetedInjection attempts blocked by antimalwareTechnique T1195.002 (MITRE ATT&CK, opens in a new tab)
Kaspersky does not give ATT&CK identifiers in this report, so the codes in the diagram are our mapping. Use them as a starting point for your own detection tagging.
Who Is BO Team, According to Kaspersky?
Kaspersky calls the group Black Owl, or BO Team, and treats it as an APT group. It says the group usually steals confidential data and cripples a victim’s IT by deploying ransomware. The group posts results on a Telegram channel, a habit Kaspersky says makes it look like a hacktivist crew.
This case differed. Kaspersky saw no data destruction and no boasting. The attackers instead built convenient command channels and planted backdoors to restore access if they lost it.
Kaspersky attributes the attack to BO Team with a high degree of confidence. Its reasons include credential-theft commands that match earlier BO Team attacks, Russian-language phishing, a long and patient dwell time, and a victim profile that fits the group. That is Kaspersky’s assessment, and we have not verified it independently.
How Did the BO Team Supply Chain Attack Begin?
The first event Kaspersky can tie to the incident is a login to a Linux terminal server over SSH from the internet. The attackers used a service account that still allowed username and password logins. Over the next days they scanned internal ranges for SMB, Kerberos, SSH, Telnet, FTP, WinRM, LDAP and web services.
Kaspersky says column names in the event log suggest Metasploit for port scanning. Traces of Burp Suite show that the attackers pointed their own machine at the terminal server through an SSH proxy. Blocked web requests landed in a log, which the attackers later deleted, but Kaspersky recovered part of it.
The recovered requests show their interests: vCenter documentation, MikroTik and QNAP documentation, a vulnerability database and a dependency analysis platform. Kaspersky later uses that last item as a clue to the supply chain goal.
How Did They Reach the Hypervisors and the Build Systems?
The attackers first tried to log in to the vCenter web interface and failed. Soon after, processes with encoded commands appeared on the hypervisors, creating a remote shell with root rights, with no matching user session in the vCenter logs. The system ran vCenter 7.0.3 with a vulnerable log4j library loaded.
Kaspersky concludes that CVE-2021-44228, known as Log4Shell, was likely exploited, and it confirmed on a test bench that the same build was vulnerable. For background on the flaw, see our Log4Shell vulnerability page. As root, the attackers read the server’s private SSH key and moved to the hypervisor itself.
They then planted backdoors that ran every hour from the cron.hourly directory, one disguised as a PostgreSQL component. Kaspersky says the files carried a forged modification date from 2021, a technique called timestomping. A second cluster got the same treatment, and a variant on the virtual machines ran a reverse SSH tool in memory.
Kaspersky explains that the backdoors stayed dormant while the attackers’ command domain pointed to a loopback address. Changing one DNS record woke them. The domains came from a free dynamic DNS service that creates names with a single curl request.
From the hypervisors the attackers read virtual machine contents. They compromised the GitLab server, which gave them some source code repositories and the server’s private key. That key opened the Ansible orchestration server, and its key opened a large part of the Linux estate.
How Did They Take the Windows Domain?
On a Windows terminal server the attackers found domain account credentials in service scripts that any user could read. Those accounts lacked rights on the domain controller. A few days later, however, they logged in with an administrator account that Kaspersky says probably came from virtual machine memory.
That account was not in Domain Admins. It sat in the local administrators group with RDP access, most likely left over from setup. This is the kind of forgotten permission an access-rights audit finds.
The credential theft shows how BO Team avoids malware. A Nanodump attempt on the domain controller was blocked, so the group deleted the logs and paused. It came back with a built-in method: a rundll32 call into comsvcs.dll that writes an LSASS memory dump. Kaspersky says its products detect this, but the domain controller ran an outdated security product with no behavioural analysis.
The attackers copied the NTDS database with ntdsutil and dumped the registry to decrypt it, and moved the data with the built-in scp.exe. With the krbtgt key they could forge Kerberos tickets, a Golden Ticket attack. Kaspersky says administrators reused passwords across the forest’s domains, so cracking one more password opened the root domain.
Our OS credential dumping technique page covers the family of methods used here. Defenders should treat any LSASS or NTDS access on a domain controller as an incident until proven otherwise.
What Did the Attackers Want From the Software Vendor?
Kaspersky found traces on a server used to sign builds of the company’s commercial software. The security product blocked remote WMI execution, a scheduled task and code written to memory there. Elsewhere in the network the attackers had already taken the GitLab server and visited dependency analysis documentation.
Kaspersky offers two readings. Attackers could inject code into a build just before signing, or steal the signing certificate to sign malware. It believes BO Team may have wanted to inject code into the vendor’s product and reach its customers, mostly industrial firms in Eastern Europe. That is its inference from circumstantial evidence, and the report describes no compromise of its customers.
The same pattern is why compromise of the software supply chain is so costly. A signed update carries the vendor’s trust to every customer, as the SolarWinds Orion compromise showed.
What Happened After the Company Cut Them Off?
After the response began, the network was isolated, then partly reconnected. A few days later staff received emails posing as technical support with the subject “Account disconnected from the mail server”. The link led to a generated page that copied the company’s own website and asked for a password.
The mail passed SPF and was not flagged because it carried a valid DKIM signature from the company’s own key. Kaspersky says the attackers most likely stole that private key from the mail server. The phishing was detected in time, so no credentials leaked.
Kaspersky kept the removed Linux backdoors running on test benches. A few days later the attackers switched the command domains on, and the benches received their scripts, which included a Global Socket remote shell. Kaspersky says the attackers made mistakes in their scripts, such as a missing protocol prefix, and fixed them soon after.
Why Did It Go Unnoticed for Months?
Kaspersky also lists missing updates, weak network segmentation and plaintext authentication data. Most items are basic hygiene rather than clever exploitation. Kaspersky says the group’s own mistakes let it learn a great deal about the group’s tactics.
How Can a Software Vendor Detect This Chain?
The tooling here is mostly built in, so detection has to follow behaviour. The list below follows the chain in order, and the signals are our reading of Kaspersky’s findings.
- Perimeter. Alert on external SSH logins to service accounts and disable password logins for those accounts. Service accounts should never log in interactively.
- Hypervisors. Watch for shells spawned by the vCenter web components, new files in cron.hourly, and recent files with old modification dates. Treat a login with no vCenter user session as suspect.
- Linux hosts. Look for unset HISTFILE, quick who and w checks, memory-only executables, and a changed NX login helper that writes credentials to shared memory.
- Windows domain. Alert on rundll32 calling comsvcs.dll, ntdsutil copies, registry dumps and scp.exe on a domain controller. Check old accounts in local administrators groups.
- Network. Review VPN logins that repeat hundreds of times from a few provider addresses with automatic reconnects, and DNS records that flip between loopback and a public address.
- Mail. Flag DKIM-signed mail sent from servers that are not yours. That pattern means the signing key may have been stolen.
- Build chain. Alert on any remote execution, scheduled task or unexpected process on signing and build servers.
What Should Software Vendors Fix First?
The steps below follow Kaspersky’s recommendations. Item 6 is our own addition for any vendor that signs software.
- Update the virtualization stack and network firmware, and patch internet-facing services first.
- Remove stored passwords from scripts, LDAP fields and files, and move them to a password manager or vault.
- Enforce two-factor authentication for VPN, RDP and every system holding confidential data, including domain controllers.
- Use unique administrator passwords per domain and a separate admin workstation, and audit local administrator groups.
- Keep backups on a server outside the domain, with a dedicated account for deletion rights.
- Isolate build and code-signing servers on their own segment, keep signing keys in dedicated hardware, and review recent signed builds for unexpected changes.
- Keep at least 30 days of OS and firewall logs, and staff a security function that watches antivirus detections.
Kaspersky publishes file hashes, domains, addresses and file paths in the report itself. Load those values from the original source into your tooling, and prioritise the behaviours above because infrastructure like this changes quickly.