Silent Persistence: How Chinese APT ‘VerdantBamboo’ Spent 18 Months Inside Microsoft 365 Using Custom Malware

A deep-dive investigation into UNC5221’s dual-intrusion campaign, how it quietly compromised edge devices and an MSP, and the technical mechanics behind the Brickstorm, Plenet, and AgentPSD toolset.

TL;DR

The Threat Actor: Mandiant tracks them as UNC5221. Volexity calls them VerdantBamboo. Other researchers know them as WARP PANDA or UTA0178. This is a Chinese state-sponsored espionage group with a well-documented preference for going in through the edges – firewalls, VPN gateways, storage appliances rather than fighting through the front door.

Dwell Time: The actors went undetected inside a victim’s Microsoft 365 environment and their Managed Services Provider’s network for at least 18 months.

Initial Access and Privilege Escalation: Entry came through an Egnyte Storage Sync appliance. The attackers logged in over SSH using valid credentials belonging to a default service account called egnyteservice. A misconfigured sudoers entry let them escalate straight to root without a password.

Bypassing M365 Conditional Access: With BRICKSTORM deployed on the internal appliance, the attackers stood up a SOCKS proxy and routed their external connections through the victim’s own SSL VPN. To Microsoft’s authentication infrastructure, the logins looked like they were coming from inside the building.

The MSP Angle: The victim’s managed services provider was separately compromised. A FreeBSD-compatible BRICKSTORM variant was running directly on the MSP’s pfSense firewall, likely for the same 18 months, giving the attackers another angle into the target.

The Second Wave: After the victim attempted remediation, the actors came back. Using credentials they’d harvested and held in reserve, they re-enabled the SSL VPN on the external firewall, got back in, and deployed a new backdoor family – PLENET on a Synology NAS, along with a backup reverse shell called AGENTPSD.

Why the Perimeter Is Losing

There’s a long-standing assumption in enterprise security that if you can protect Active Directory and harden your endpoints with a decent EDR suite, you’ve done most of the work. VerdantBamboo – like several other Chinese APT clusters active since 2021 has spent years proving that assumption wrong.

The attack surface that matters now isn’t the workstation. It’s the device rack. Firewalls, VPN concentrators, NAS boxes, storage sync appliances, load balancers – most of these run proprietary Linux or BSD builds, ship without EDR support, get patched infrequently if ever, and get monitored only at the network level, if at all. An actor who gets root on a pfSense firewall or a Synology NAS is sitting in a position that most enterprise monitoring tools will never see.

According to incident response findings published by Volexity on June 4, 2026, VerdantBamboo exploited exactly those blind spots to maintain a continuous foothold inside a high-value target for over a year and a half. What follows is a technical reconstruction of how they did it.

Egnyte Storage Sync and the Sudo Misconfiguration

The Egnyte Storage Sync appliance is a Linux-based virtual machine. Its job is to keep on-premise file storage synchronized with Egnyte’s cloud platform. It’s not glamorous infrastructure. It doesn’t get the same security scrutiny as a VPN gateway or an AD domain controller. That’s part of why it was chosen.

VerdantBamboo’s initial access was straightforward: SSH login using valid credentials for egnyteservice, the default service account the appliance ships with. How those credentials were obtained isn’t fully established. Credential harvesting from the MSP is the most likely explanation, covered in more detail below but once in, the attackers had a shell on a trusted internal device.

From an unprivileged shell, the natural next step is privilege escalation. What Volexity found in the sudoers configuration file is exactly the kind of thing that slips through vendor QA and never gets caught in routine audits. The entry allowed egnyteservice to execute arbitrary commands as root without a password prompt. That’s a NOPASSWD wildcard that shouldn’t exist on a production appliance with any network exposure. Egnyte has since patched it in v13.13, but for the duration of this campaign it was a reliable root escalation on an appliance that many organizations almost certainly still hadn’t touched.

To be specific about the mechanics: Linux privilege escalation via sudoers misconfigurations has been a reliable technique for years. The usual pattern is something like:

egnyteservice ALL=(ALL) NOPASSWD: ALL

or a variant with a wildcard over a specific binary that can be leveraged for shell escape. Either way, the result is a root shell reachable through a non-privileged SSH login using service account credentials. Once you have that, you can write to /usr/sbin/, install a service, modify /etc/rc for persistence, and do basically anything the OS allows. The attackers wrote BRICKSTORM to /usr/sbin/ on the Egnyte appliance. That’s when things got interesting.

BRICKSTORM: A Proxy Inside the Perimeter

BRICKSTORM is not a typical remote access trojan. It doesn’t exfiltrate files directly or try to beacon home with a payload. Instead, it’s built around a core capability that makes it particularly dangerous in environments that rely on IP-based access controls: it creates a SOCKS or HTTP proxy on the device it’s installed on.

The early versions were written in Go. The newer ones, at least some of them, are in Rust. Both implement the same core functions:

• Acts as a lightweight web server, listening on a configurable local port
• Handles file and directory operations
• Runs arbitrary interactive shell commands
• Establishes SOCKS4/5 and HTTP proxy channels
• Communicates with its C2 infrastructure over WebSockets, with some variants using DNS-over-HTTPS (DoH) to obscure C2 lookups from standard DNS monitoring

The WebSocket-based C2 is worth dwelling on. Traditional RATs phone home over TCP with custom protocols or basic HTTP. WebSockets are increasingly used in legitimate enterprise applications such as collaboration tools, dashboards, streaming APIs. So, WebSocket traffic from an internal device doesn’t automatically stand out. If the C2 domain doesn’t show up on a threat intel feed and the traffic is mixed in with normal app activity, it can sit there for a very long time.

The DoH variant is more aggressive. By wrapping C2 hostname lookups inside HTTPS requests to legitimate DoH resolvers (Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, and so on), the actors make it much harder to detect C2 communications through DNS monitoring alone. Network defenders who rely on DNS logs to catch suspicious outbound connections lose that visibility entirely when the malware never issues a plaintext DNS query.

How BRICKSTORM Killed Conditional Access

Microsoft 365 Conditional Access policies are a legitimately useful security control. They let organizations say things like: “only allow M365 logins from corporate IP addresses” or “require MFA from any IP we don’t recognize.” For most threat actors, these policies add meaningful friction. For an actor with a SOCKS proxy on an internal device, they’re basically irrelevant.

Here’s exactly what VerdantBamboo did:

The attacker’s workstation, sitting somewhere outside the victim’s network, connected to the organization’s web-based SSL VPN. That VPN session gave them access to internal network resources. From that session, they directed their browser or a tool like ProxyChains to route all traffic through BRICKSTORM’s SOCKS listener on the Egnyte appliance. When they then navigated to Microsoft 365, Entra ID (formerly Azure AD) saw a connection originating from the internal IP of the Egnyte Storage Sync server. That IP was trusted. The Conditional Access policy didn’t trigger MFA. The login succeeded. The session was flagged as compliant.

This is a fundamental problem with location-based access controls. An IP address tells you where a connection appears to come from. If an attacker controls a device inside the trusted IP range, they get the same trust level as a legitimate employee. The policy assumes your internal network is clean. Once it isn’t, the policy works against you.

What makes this particularly hard to catch is the traffic volume. The Egnyte appliance legitimately generates network traffic like it’s syncing files. Some outbound WebSocket connections from a storage device are not going to jump out in aggregate log analysis. Behavioral analytics might catch it eventually if they’re tuned to look for M365 authentication events coming from non-workstation IPs, but that’s a specific detection rule that most organizations aren’t running.

BRICKSTORM’s C2 Infrastructure and Operational Security

The C2 domains associated with BRICKSTORM read like someone cycling through plausible-but-slightly-off enterprise names: systemsvcs.com, natsupport.net, performanceviewtools.com, winfoacacorp.com. None of them are wildly obvious. msazure.azdatastore.workers.dev is particularly noteworthy. It’s hosted on Cloudflare Workers, which gives it a Cloudflare IP range. Blocking it on reputation alone is difficult without blocking legitimate Cloudflare Worker endpoints, which breaks a lot of things.

When Volexity and Google’s threat intelligence researchers published their findings in September 2025, the operators responded within days. Between September 18 and 23, every server fingerprinted as a BRICKSTORM C2 node dropped off port 443. The infrastructure went dark rather than risk exposure. That kind of rapid operational response – reading public threat intel and rotating infrastructure within a week is characteristic of a well-resourced, professionally run operation with dedicated infrastructure management.

The MSP Breach: Supply Chain Access Done Quietly

Investigating the primary victim’s network, Volexity researchers noticed unusual traffic patterns pointing outward toward infrastructure controlled by the MSP. What they found when they looked closer was a separate and independently significant compromise.

The MSP’s pfSense firewall had a FreeBSD variant of BRICKSTORM running on it. pfSense is open-source and runs on FreeBSD, so a standard Linux BRICKSTORM binary won’t work as the attackers had compiled a platform-specific version. That’s not difficult for a well-resourced team, but it does indicate deliberate targeting rather than opportunistic infection. Someone made the decision to develop and deploy a BSD-compatible implant on this specific firewall.

Persistence was achieved by modifying /etc/rc, the BSD initialization script that runs at boot. This is a reliable persistence mechanism on BSD-based systems because it doesn’t depend on systemd or any of the service management layers that EDR tools might monitor. The modification ensures BRICKSTORM runs with each reboot, quietly, before most logging infrastructure is fully active.

Forensic timestamps placed the MSP compromise at approximately the same time as the primary victim’s breach – at least 18 months before discovery. This strongly suggests the MSP was the initial entry point, not a secondary target. The working theory, which Volexity states with medium confidence, is that the actors gained a foothold at the MSP, used that position to harvest administrative credentials for client environments, and then leveraged those credentials to access the primary victim’s Egnyte appliance directly over SSH.

From the attacker’s perspective, this is elegant. An MSP by definition has administrative access to client infrastructure. If you compromise the MSP’s firewall and can see all the traffic flowing through it including credentials, VPN configurations, administrative sessions. You gain visibility into every client the MSP serves. You don’t have to attack each client separately. You harvest from the one access point.

For organizations using MSPs, this is one of the harder risks to mitigate. You need the MSP to have administrative access to your systems. You can’t operate otherwise. But you have almost no visibility into the security posture of the MSP’s own infrastructure. When an attacker compromises the MSP’s firewall and reads administrative traffic, your Conditional Access policies and endpoint controls provide zero protection because the initial access came through a channel you explicitly trusted.

The Post-Remediation Second Intrusion

Advanced persistent threat groups don’t give up cleanly. When a victim starts pulling cables and imaging drives, a well-prepared APT has already thought about this and left themselves options.

When the victim attempted remediation from isolating compromised systems, rotating credentials to blocking suspicious IPs, VerdantBamboo came back in through a different door. Using admin credentials they’d harvested during the initial intrusion and kept off their primary C2 infrastructure, the actors connected externally to the victim’s firewall. They re-enabled the SSL VPN service, reconfigured it for remote access, and walked back in.

This is one of the more important lessons from this campaign. Credential rotation at remediation time has to be comprehensive. Every service account, every administrative credential, every VPN profile that existed before the breach has to be treated as compromised. If any one of those is missed, the actor can use it to re-establish access. In this case, the actors had apparently retained credentials that survived the partial remediation.

Once back inside, they moved to a Synology NAS, which is a device the victim’s response team likely treated as lower priority than the Egnyte appliance they’d already cleaned. NAS devices are a common blind spot for exactly the same reasons as storage sync appliances: they’re not workstations, they don’t run EDR, they have web administration consoles that get enabled and forgotten. The actors used the Synology web admin UI to enable SSH, then used SSH to deploy PLENET.

PLENET (Grimbolt): What Comes After BRICKSTORM

PLENET, which Google tracks internally as Grimbolt, is best understood as VerdantBamboo’s next-generation implant. Where BRICKSTORM is written in Go or Rust and focused heavily on proxying, PLENET is a .NET application compiled with Native Ahead-of-Time (AOT) compilation, with a broader feature set oriented around interactive access and file management.

Native AOT compilation is worth explaining because it has meaningful security implications. Normally, .NET applications rely on the Common Language Runtime (CLR): the binary contains intermediate language (IL) that gets JIT-compiled to native machine code at runtime. Tools like ILSpy, dnSpy, and dotPeek can largely reverse the IL back to something resembling C# source code, because IL preserves a lot of the original structure.

Native AOT changes this. The compiler converts everything to native machine code at build time. The CLR doesn’t run at all. The result is a binary that looks much more like a compiled C or C++ program than a typical .NET application. Standard .NET decompilation tools don’t work. Reverse engineers have to fall back on traditional binary analysis with tools like Ghidra or IDA Pro, which is slower and harder. For an implant that needs to stay hidden, this is a deliberate choice that meaningfully raises the reverse engineering cost.

PLENET’s architecture mirrors BRICKSTORM’s communication approach: WebSockets for the C2 channel, a multiplexing library to run multiple concurrent streams over a single TCP connection. That means you can have an interactive shell session and a file download happening simultaneously through the same connection, with the connection looking like a single persistent WebSocket from the outside. Blocking it without blocking all WebSocket traffic is difficult.

Feature-wise, PLENET covers:

• Interactive shell execution (full PTY-style remote shell)
• File system operations: create, delete, upload, download, directory listing
• Ability to dynamically switch which C2 server it’s connecting to, without restarting or redeploying

That last capability – hot-swapping C2 servers is particularly useful for operational security. If a C2 domain gets flagged and starts getting blocked, the operator can redirect the implant to a clean domain without touching the victim’s system again. The implant just updates its target and continues running.

PLENET was observed communicating with four IP addresses: 107.175.235.196, 170.187.181.243, 104.253.1.46, and 149.248.11.71. These are separate from the BRICKSTORM infrastructure, which suggests the two toolsets run on independent C2 tracks. If one gets burned, the other keeps working.

AGENTPSD: The Backup No One Used

AGENTPSD is, by design, the least interesting piece of this toolkit. It’s a Python-based reverse shell compiled to a standalone executable using PyInstaller. No WebSockets, no multiplexing, no fancy evasion. It opens a TCP connection to a hardcoded C2 address, hands over a shell, and waits.

What makes it worth analyzing is the deployment strategy it represents. AGENTPSD was installed on both the Egnyte appliance and a retired Linux-based GroupWise email archive server, two systems that BRICKSTORM was also running on. But AGENTPSD was never actively used. The actors never issued commands through it. They didn’t need to, because BRICKSTORM was working fine.

The point of AGENTPSD was redundancy. If the victim’s response team found and removed BRICKSTORM, AGENTPSD would still be sitting there on a server that might not have been included in the remediation sweep. The C2 infrastructure for AGENTPSD was completely separate from BRICKSTORM’s different domains, different IPs. A defender who identified and blocked BRICKSTORM’s C2 traffic would have no immediate visibility into AGENTPSD’s callback.

Running a redundant implant on independent C2 infrastructure, installed on a lower-profile system that’s less likely to be scrutinized first during incident response. The GroupWise email archive server is a good example: an old, semi-retired system that might still have network connectivity but isn’t getting the same remediation attention as the primary Egnyte appliance. Installing a backup implant there is the kind of thing that would have kept the actors in the network even after a thorough-seeming cleanup of the obvious targets.

Full Technical Comparison of the Malware Arsenal

SLAYSTYLE: The Web Shell in the Arsenal

Worth noting separately, since it often gets less attention than the two main backdoors: SLAYSTYLE is a web shell targeting Apache Tomcat servers, implemented as a Java Servlet Filter. Rather than being an uploaded PHP file or a dropped binary, a Servlet Filter is a Java class registered directly in the Tomcat application context. It intercepts HTTP requests before they reach the application layer, making it stealthy in a specific way: there’s no suspicious file to find in the web root. You have to look at the deployed application’s web.xml or the Tomcat configuration itself to find it.

SLAYSTYLE’s primary function appears to be credential harvesting and passive backdoor access. The two SHA-256 hashes associated with it (f06457d2be... and 92fb4ad6de...) are flagged in the IOC list but haven’t been analyzed as publicly as BRICKSTORM or PLENET. Its presence in the VerdantBamboo toolkit alongside those two tools suggests the group uses it on targets that run Java-based enterprise applications on Tomcat, as a complement to their edge-device implants.

Indicators of Compromise (IOCs)

Malicious File Hashes (SHA-256)

Network Indicators (C2 Domains & IP Addresses)

Detection: What to Actually Look For

Given that BRICKSTORM lives on devices that don’t run EDR, purely host-based detection isn’t going to catch it. Detection has to happen at the network layer and through authentication log analysis.

Authentication anomalies in M365 sign-in logs. Look for successful sign-ins to M365 where the source IP is an internal appliance rather than a workstation or known proxy. Specifically, filter Entra ID sign-in logs for source IPs belonging to your storage sync appliances, NAS devices, or firewall management interfaces. A successful M365 authentication from an Egnyte sync server’s IP is not something that should happen under normal operating conditions.

WebSocket connections from non-workstation internal IPs. If you have network visibility (via a NGFW, NDR sensor, or flow analysis), look for persistent outbound WebSocket connections originating from storage devices or firewall management IPs. Legitimate storage sync appliances don’t need to maintain long-lived WebSocket sessions to external hosts.

DNS-over-HTTPS from appliances. Standard storage and NAS devices have no reason to issue DoH queries to Cloudflare or Google’s DoH endpoints. If you can see encrypted DNS resolution coming from these devices, that’s worth investigating.

Modifications to /etc/rc on BSD-based appliances. If you have any mechanism to audit filesystem changes on your pfSense or other BSD-based network equipment, unexpected modifications to /etc/rc are a reliable persistence indicator for this specific group.

Sudoers misconfigurations. Run sudo -l as each service account on Linux appliances in your environment. Any entry with NOPASSWD: ALL or a wildcard over a command that can be used for shell escape (vi, less, awk, python, etc.) is a privilege escalation risk regardless of whether you’ve been targeted.

Re-enabled VPN services after remediation. If you’re in active incident response, monitor your firewall’s management interface for changes to VPN service state. Actors who retain admin credentials will try to re-enable access pathways. An SSL VPN service that gets turned back on when no authorized admin issued that change is a very strong signal.

Defensive Recommendations: What Actually Works Here

The standard advice of patch everything, enable MFA isn’t wrong, but it’s incomplete for this threat model. Here’s what actually addresses the specific techniques VerdantBamboo used.

Patch Egnyte Storage Sync immediately. Version 13.13 addresses the sudoers misconfiguration. If you’re running earlier versions, you’re exposed to a known, weaponized privilege escalation path that’s been used in production attacks.

Audit sudoers on every Linux appliance you operate. This isn’t glamorous work, but it matters. Any service account with NOPASSWD access to a shell, an interpreter, or a file editor is a potential root escalation from anyone who can authenticate as that account. Run sudo -l across your fleet of Linux-based appliances and review every result.

Move M365 Conditional Access away from IP-based trust. IP-based trust doesn’t hold once an attacker has a SOCKS proxy on an internal device. Switch to device-based compliance checks (Intune/JAMF managed device requirements) and hardware-bound MFA like FIDO2 security keys. A SOCKS proxy on a storage appliance can’t satisfy a device health check for a specific enrolled workstation, and it can’t simulate possession of a hardware security key.

Segment appliances from your core network. Storage sync devices and NAS boxes don’t need to route traffic to your AD controllers, and they don’t need arbitrary outbound access to the internet. Firewall rules that restrict appliance egress to only what those devices legitimately require such as specific cloud storage endpoints, nothing else. This would have significantly limited BRICKSTORM’s usefulness as a proxy. The whole attack depended on the Egnyte appliance being able to both reach M365 and communicate outbound with the C2 infrastructure.

Treat your MSP’s perimeter as part of your attack surface. This is uncomfortable, but accurate. The organizations that got burned here didn’t do anything wrong from a technical controls standpoint on their own perimeter. Their MSP’s firewall was compromised, and that gave the attackers a path in that bypassed everything the victim had built. Your MSP’s security posture is effectively your security posture. Push for audit rights, require log forwarding from MSP-managed devices, and include MSP-managed infrastructure in your incident response planning.

Have a tested, documented remediation checklist. One of the reasons the second intrusion succeeded is that the remediation wasn’t complete – credentials that existed during the breach weren’t all rotated. Before you close an incident, walk through every credential, every service account, every VPN profile, every administrative API key that was active during the breach window and assume all of them are burned. The extra credential rotation work is much less costly than another 18 months of undetected access.

Frequently Asked Questions

Who is UNC5221 / VerdantBamboo?

UNC5221 (also known as VerdantBamboo, WARP PANDA, and UTA0178) is a Chinese state-sponsored espionage group that’s been active since at least 2022. They’re specifically associated with targeting edge infrastructure – firewalls, VPN gateways, and storage devices, often exploiting zero-days or n-days in those systems before patches are widely deployed. Mandiant and Volexity track them separately but have concluded they refer to the same underlying group.

How exactly did they get past Microsoft 365 Conditional Access?

Conditional Access policies that trust connections from known corporate IPs assume the internal network is clean. By deploying a SOCKS proxy inside the trusted IP range – specifically on the Egnyte appliance and routing their external connections through the victim’s own SSL VPN, the attackers made their M365 logins appear to originate from a trusted internal device. Entra ID had no way to distinguish that from a legitimate employee’s session.

What are PLENET and AGENTPSD, specifically?

PLENET is a .NET Native AOT backdoor. The AOT compilation makes it harder to decompile than normal .NET apps. It communicates over WebSockets, supports multiple concurrent sessions through a single connection, and can switch C2 servers on the fly. AGENTPSD is a much simpler Python reverse shell, packaged as a standalone binary with PyInstaller. It was installed as a fallback in case BRICKSTORM got removed, but the attackers never needed to use it because BRICKSTORM stayed operational throughout.

What should I check first if I think I might be affected?

Start with your M365 sign-in logs in Entra ID. Look for successful authentications from IP addresses belonging to infrastructure devices such as NAS boxes, storage appliances, firewall management IPs rather than workstations or known proxies. Then audit sudoers configurations on Linux appliances in your environment. Cross-reference the IOCs above against your DNS, proxy, and firewall logs going back at least 18 months if your retention allows it. Upgrade Egnyte Storage Sync to v13.13 or later if you haven’t already.

This post first appeared at - The CyberSec Guru