- Rapid7 tracked Linux implants, including a new BPFDoor variant and six AVERAT builds, that copy the software and traffic of the telecom and appliance environments they target.
- Because the malicious activity resembles a device's normal job, such as sending mail on port 25, 'is this traffic normal?' stops being a reliable test.
- Ask teams whether edge appliances are monitored for processes running from deleted files and whether outbound mail behaviour is baselined.
Most security monitoring asks one question: does this look normal? Rapid7 has described malware built so that the answer is yes. These samples show attackers copying the victim's own job description.
What Rapid7 found
Rapid7's researchers studied a group of Linux malware samples aimed at telecom environments. One is a new variant of BPFDoor, a backdoor that waits for a secret signal. Another is a backdoor built on Rekoobe code that targeted South Korea. The group also holds an installer, called a dropper, and six versions of an implant Rapid7 names AVERAT. AVERAT was used against appliances in Taiwan.
Rapid7 calls the shared trait "regionalized disguise". Each sample knows which vendor's software runs on its target. It then mimics that software.
In South Korea, the BPFDoor variants copy the process-ID file of SpamSniper, an anti-spam product used mainly there. A process-ID file is a small marker a program leaves to show it is running.
The installer is a separate piece. It builds its decryption key from the word ShareTech, the name of the target vendor. It also places its files in the appliance's own add-on folder. Rapid7 does not state in which country the installer was found. AVERAT, by contrast, was deployed against Taiwanese appliances.
The disguise is the device's job
AVERAT calls out on port 25, which mail servers use to talk to each other. It opens with a normal mail greeting. It then asks to encrypt the session and starts its own private channel.
On a mail security gateway, sending mail out to many servers is the core job. Rapid7 says flow records cannot tell this traffic from real work.
The implant reports in every 600 to 699 seconds. It tells the operator the machine's name, the account it runs under and the operating system version. It also lists the network interfaces and the users logged in.
How the chain works
The installer has no network code. It runs only after an attacker already has access. It saves a small script on the appliance's storage drive and launches it.
The script copies two programs into the /sbin folder. It names them ntpdate and udevds, which sound like routine system tools. It starts both and deletes each file ten seconds later.
Both programs keep running. Linux lists their file location as "(deleted)". A responder has no file to scan, isolate or send to an analyst. Searching /sbin turns up nothing.
One of the two programs is the installer itself, now acting as a watchdog. It rewrites the script if the script goes missing.
Rapid7 found no code that survives a reboot. It judges that the appliance's own package startup very likely relaunches the files.
Rapid7 also names a limit that helps defenders. The storage drive must allow both writing and running programs. If the drive blocks execution, the script fails.
Waiting instead of knocking
BPFDoor works differently. It attaches a filter to a raw network socket and watches passing traffic for a trigger. Rapid7 says passive implants like this avoid conventional port scans.
One Rekoobe-based build looks for packets with port 25 as both source and destination. A firewall rule that allows mail relay would pass such a packet to the raw socket before stateful inspection. Rapid7 concludes the authors knew which traffic this kind of host would let through unseen.
Rapid7 also reconstructed the source code of a BPFDoor controller. Earlier variants used fixed byte patterns, and vendors wrote network signatures to catch them. The controller now hides the trigger inside ordinary-looking HTTPS POST requests. Rapid7 says this may evade conventional deep packet inspection.
What this means for the people on call
Picture the responder told that an appliance is suspect. They search /sbin and find nothing. They check mail traffic and see a gateway doing its job. Every normal check passes, because the malware was designed around those checks.
This shows that a baseline of normal rests on a weak assumption. It assumes attackers do not know what normal looks like. These samples show operators who studied one vendor's products closely.
Rapid7 says telecom and network-edge operators are most affected. It adds that some embedded hardware is in scope too. Examples are CCTV cameras and DVR recorders, which can be wired in close to the core of a network.
This is one vendor's analysis of a set of samples. It does not say how many organisations are affected.
Questions to put to your team
First, can we see running processes whose program file has been deleted on edge appliances? Second, do we have a baseline for outbound mail on gateways, including regular check-ins to unfamiliar hosts? Third, do appliance storage drives block execution where the vendor allows it? Fourth, can the vendor tell us if files in the add-on package folder have changed?
If the answer to any of these is that nobody looks, the appliance is a place where the attacker's disguise and your assumptions agree.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Rapid7.
