VerdantBamboo Ports BRICKSTORM to BSD, Goes Hunting for Linux Appliances

Another week, another reminder that your network edge appliances are running operating systems your SOC has no telemetry on.

A China-nexus espionage cluster has been spotted deploying a BSD-flavored variant of the BRICKSTORM backdoor, alongside two previously undocumented Linux implants tracked as PLENET (also called GRIMBOLT) and AGENTPSD. The activity has been pinned on a group called VerdantBamboo, which overlaps with what Microsoft has been calling Clay Typhoon.

BRICKSTORM is not new. It surfaced in incident response work tied to long-dwell intrusions at managed service providers and edge appliance vendors, where attackers sat for months on devices that don't run any reasonable agent. What's new is the porting effort. A BSD build is a deliberate choice. It tells you the operators know exactly what runs the firewalls, load balancers, and storage controllers they want to live on — because a lot of those ship FreeBSD or a vendor fork underneath the marketing skin.

In practice, this is the same playbook we've watched China-nexus actors run for three years now. Find the appliance. Find the auth bypass or n-day. Drop a quiet implant on a platform nobody monitors. Pivot from there into the Linux fleet using stolen creds or hopping through management planes.

PLENET and AGENTPSD round out the Linux side of the kit. Volexity's writeup is the primary source for the IOCs and behavioral details if you want to start hunting; I'd point you at Volexity's research portal rather than wait for a CVE that may never come, because a lot of this tradecraft rides on stolen credentials and known-vuln appliances rather than fresh zero-days.

The failure mode here is predictable. You bought a VPN concentrator or a backup appliance. The vendor told you it was hardened. You don't have root, you don't have an agent, you don't have logs leaving the box. Six months later somebody's reading your engineering Slack archive.

One thing the post-mortem will say: nobody was looking at the appliance.

Detection guidance is the boring stuff that works. Pull netflow at the appliance boundary and look for long-lived outbound TLS to infrastructure that isn't the vendor's update servers. Diff appliance firmware hashes against vendor-published values. If your vendor won't give you a shell or an integrity API, treat that as a procurement red flag at renewal time.

Operational takeaway: if you can't get telemetry off a box, assume an adversary already has telemetry on it.