VerdantBamboo pivoting to Linux: Analyzing the BRICKSTORM BSD variant
Just reviewed the Volexity report regarding VerdantBamboo (overlaps with Microsoft's Clay Typhoon). They've been observed deploying a BSD port of BRICKSTORM on Linux appliances, alongside PLENET (GRIMBOLT) and AGENTPSD.
It’s fascinating they are targeting Linux appliances specifically. These devices often run stripped-down kernels where EDR deployment is a nightmare. The adaptation of a BSD variant suggests the threat actors are reusing core code, likely to speed up deployment cycles.
Technical focus: PLENET usually serves as the initial loader, while AGENTPSD provides the reverse shell capabilities. We should be hunting for anomalous process names and persistence in crontab or systemd override files.
For those running edge servers, try this to find processes that might lack standard package headers:
# List processes with deleted executable files (common with fileless malware or packed binaries)
sudo lsof +L1 | grep -v "\(deleted\)"
# Check for suspicious recent cron jobs
find /etc/cron* -mtime -7 -ls
The shift implies they are prioritizing infrastructure stability over stealth in some cases. Is anyone else noticing an uptick in cross-platform targeting in their environments, or is this specific to the sectors VerdantBamboo is hitting?
From the SOC side, appliances are notoriously blind. We usually don't have agents on the routers/load balancers they target. We're pivoting to network-based anomaly detection. If you have Zeek, keep an eye out for long-duration connections with low throughput—typical beaconing behavior for PLENET.
# Quick grep for suspicious long connections in Zeek logs (conn.log)
zcat conn.log | awk '$9 > 300 && $10 < 1024' {print $1, $2, $3}'
The porting of BSD code to Linux is definitely a trend with this group. They rely heavily on cron and rc.local for persistence because they know people forget to check those legacy paths on modern containers. During engagements, I often find AGENTPSD variants establishing reverse shells via openssl.
Don't just look at running processes; check the openssl binary version and recent exec logs.
# Check for openssl usage in shell history (assuming logs exist)
grep -r "openssl.*-connect" /home/*/.bash_history
Great points on the blind spots. Since installing agents is a no-go, I suggest monitoring configuration drift. Comparing recent config backups against the live running-config often reveals their persistence mechanisms faster than log reviews. If you have shell access, scanning for recently modified binaries is a solid quick win:
find / -type f -perm /111 -mtime -1 -ls
It’s basic, but effective for spotting new tools dropped via the BSD port.
Since these appliances are often edge devices, I recommend strictly locking down outbound traffic. We whitelist known dependencies and trigger alerts for any unexpected protocols. You can spot anomalies quickly by grepping your firewall logs for outbound connections from specific zones:
grep "outbound_interface=eth0" /var/log/messages | grep -v "ESTABLISHED"
If you see non-standard ports initiating sessions, it’s a solid indicator of C2 beaconing trying to phone home.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access