Analysis of a Low-Detection Linux Implant with Hands-On Intrusion Capabilities
UPDATE: After reviewing related infra found by @500mk500 and a related sample by @malwrhunterteam, I found quite a few similarities with the Adaptix Agent using the adaptix_gopher protocol.
In early July 2026, MalwareHunterTeam shared an interesting ELF named gregbfdah.png with minimal detection in VirusTotal. The ELF was uploaded to VirusTotal on 2026-06-16 and it still has very low detection. The file was delivered from the following AWS domain: https://zapier-logos.s3.amazonaws[.]com/gregbfdah.png. That URL was first submitted to VirusTotal from India on 2026-06-11.
The file in question is a statically-linked x86-64 Linux ELF backdoor/C2 implant written in C++, possibly still in development. When executed, the backdoor:
Implements a classic double fork for daemonization.
Redirects its standard streams to /dev/null.
Changes directories to /tmp.
Checks if it was executed with the -nodel argument. If it was, it executes the main backdoor logic. If not, it self-deletes.
The implant uses the MessagePack binary serialization format for its configuration and C2 communication. The main function of the malware starts by retrieving, decrypting, and parsing its configuration.
The following attributes are parsed from the configuration:
type
banner_size
conn_timeout
conn_count
sleep_delay
jitter
addresses
The configuration is embedded in the .data section and is encrypted with AES-128 in GCM mode. The blob with the encrypted configuration has the following structure:
The first 16 bytes are the key.
The next 12 bytes are the nonce.
Bytes 28 until the tag is the encrypted configuration.
The last 16 bytes are the tag.
The following script can be used to decrypt and parse the configuration once the embedded blob has been extracted:
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import msgpack
with open("extracted_blob.bin", "rb") as f:
raw = f.read()
blob = raw[:150]
key = blob[:16]
nonce = blob[16:28]
encrypted_config = blob[28:-16]
tag = blob[-16:]
print(f"Key: {key.hex()}")
print(f"Nonce: {nonce.hex()}")
print(f"CT: {encrypted_config.hex()}")
print(f"Tag: {tag.hex()}")
aesgcm = AESGCM(key)
plaintext = aesgcm.decrypt(nonce, encrypted_config + tag, None)
print(f"\n[+] Decrypted {len(plaintext)} bytes")
print(f"Raw hex: {plaintext.hex()}")
config = msgpack.unpackb(plaintext, raw=False)
print("\n[+] C2 Config:")
for k, v in config.items():
print(f" {k}: {v}")
Decrypted and parsed configuration for this backdoor:
Next, the agent generates a per-host ID (a “fingerprint”) using SHA1. The fingerprint is comprised of the following elements:
The nginx string. This does not change.
The machine id from /etc/machine-id. If that fails, it tries with /proc/sys/kernel/random/boot_id.
The username (via the $USER and $LOGNAME environment variables).
The MAC address, enumerating interfaces under /sys/class/net, searching for the first non-loopback interface.
The reverse static string. This does not change.
Only the first 4 bytes of the SHA1 digest are extracted as the agent ID, with _byteswap_ulong applied for endian conversion.
Next, the ‘agent’ generates a new random AES-128 session key and retrieves the key from the configuration (for further use).
After generating the session key, the agent starts profiling the infected host. The following items are retrieved:
The process name that the agent is running as by checking /proc/self/exe. If it cannot be retrieved, it falls back to agent.
The PID (process ID).
The username by first getting the user ID and looking it up in /etc/passwd. Fallbacks include the $USER environment variable, the $LOGNAME environment variable, or unknown if everything else fails.
The hostname by retrieving the nodename via the uname syscall.
The IP address is retrieved by creating a UDP socket (using 8.8.8.8 as a dummy address), calling connect to trigger a routing table lookup, and retrieving the local IP address via getsockname. It falls back to 127.0.0.1.
Validates if it is running as root by comparing the uid to 0.
The OS type is always set to “linux”.
OS information by parsing /etc/os-release and parsing NAME=, VERSION=, and VERSION_ID=. This check falls back to running uname, or "Linux" if everything else fails.
Process name retrieval and fallback to agent:
Username retrieval:
Hostname retrieval:
IP retrieval:
OS type and OS information:
After profiling the system, the agent builds a beacon to register to the C2. The beacon includes a combination of configuration settings and system profiling information. The registration beacon is serialized using the MessagePack format. The registration MessagePack has an outer map and an inner map.
The inner map contains: the process name, the pid, the user, the hostname, the ip address, whether or not the implant is running as root, the os, the os version, the encryption key (the previously generated session key), the sleep delay, and the jitter. In addition to these values, which were observed before in the system profiling and configuration, additional values are sent:
acp
oem
rootkit_scheme
All three are set to 0, and not modified. While I did not see a clear explanation for these fields in the implant, a hypothesis is that there may be versions of the agent that support Windows. acp could potentially refer to the GetACP function (to obtain the current ANSI Code Page), and oem could refer to GetOEMCP, associated with the OEM code page. However, this is just a hypothesis. I could not correlate these settings with anything within this specific implant.
Inner map:
The outer map contains the ID, previously generated via the SHA1 hash, the type, from the configuration, and the data, which is the inner map data.
The registration beacon with the inner and outer maps is encrypted with the AES-128 key from the implant configuration (previously decrypted). This has to be known by the C2 to decrypt the registration information. This initial beacon includes the random session key.
After sending the registration beacon, the agent enters a loop to receive encrypted instructions from the C2. The commands received from the C2 are decrypted with the session key and deserialized with MessagePack unpacking. A type and an object are parsed from the response. The object is subsequently processed by a command dispatcher function.
The object received from the C2 is subsequently deserialized and code, id, and data are parsed. The code determines which command code is executed by the agent, the id can be used to correlate commands and responses, and the data is additional data that a specific command may need, like a command line.
The agent supports the following commands:
|
Command |
Description |
Comment |
|---|---|---|
|
0x1 |
Gets current working directory |
Uses getcwd syscall |
|
0x2 |
Changes working directory |
Uses chdir syscall |
|
0x3 |
Executes program with arguments |
Unpacks ‘program’ and ‘arguments’ |
|
0x4 |
Stops/exits |
|
|
0x5 |
File exfiltration |
Allows for exfiltration of larger files. Chunked uploads |
|
0x6 |
Writes files to disk |
It can unzip delivered files |
|
0x7/0x1B |
Reads small files |
Synchronous read of small files (<=1MB) |
|
0x8 |
File copy |
|
|
0x9 |
File move/rename |
|
|
0xA |
Creates a directory |
Uses mkdir syscall |
|
0xB |
Deletes a file |
Uses rm -rf |
|
0xC |
Directory Listing |
Equivalent to ls -la |
|
0xD |
Process listing |
Equivalent to ps aux |
|
0xE |
Kills a process by PID |
Uses kill system call |
|
0xF |
ZIP compression |
Does zip -r destination source |
|
0x10 |
Screenshot |
Returns “screenshot not supported” |
|
0x11 |
Program Execution with a PTY |
Could be used for interactive shell |
|
0x12 |
Lists running jobs |
Lists tasks run asynchronously |
|
0x13 |
Cancels a job by ID |
Uses the shutdown system call |
|
0x15 |
Updates sleep and jitter |
|
|
0x16 |
Timestomping |
Takes access time and modify time, uses utimensat syscall |
|
0x17 |
Changes file permissions |
Uses chmod syscall |
|
0x18 |
Moves or renames a file |
Takes old_path and new_path values |
|
0x19 |
Creates a file |
Creates a file with O_CREAT and O_WRONLY flags |
|
0x1A |
File write |
Writes or overwrites a file |
|
0x1F |
Reverse Port forward/Pivot Tunnel |
Accepts an address, protocol, and channel ID |
|
0x20 |
Reverse Port forward/Pivot Tunnel Close |
Closes the tunnel with a channel ID |
|
0x23 |
Interactive program with PTY |
Spawns program with full PTY |
|
0x24 |
Kills interactive program with PTY |
Uses shutdown syscall on socket and takes term_id |
|
0x25 |
Sends Data Through Pivot |
Bidirectional data relay into an existing 0x1F pivot tunnel |
|
0x26 |
Connects to malware relay (a peer) |
Potentially used to connect to 0x2D tunnel |
|
0x27 |
Kills the connection to a peer |
Likely related to peer connection from 0x26 |
|
0x29/0x2A |
Returns “no agetty” |
This looks like a feature that is not implemented yet |
|
0x2D |
Opens a listener |
Binds to all interfaces. Accepts connections from any reachable host |
|
0x2E |
Closes a listener |
Likely related to listeners opened via 0x2D |
|
0x2F |
Root directory enumeration |
Minimal command that likely returns “/” |
|
default |
Returns “unknown” |
|
Overall, this looks like a low prevalence Linux implant with the capabilities that could be expected in malware used in a hands-on / targeted intrusion on a network. The capability to establish reverse tunnels, use the malware for pivoting, the implementation of port forwarding, and the multiple file extraction options suggest that this could potentially be used in a targeted intrusion.
I attempted to find similar samples, but did not find any. As always, if you recognize this as something previously reported or that you have seen yourself, feel free to reach out and share what you can.
Delivery URL: https://zapier-logos.s3.amazonaws[.]com/gregbfdah.png
ELF: f264f04f597a2bdda372a27ae701c18d4036175b1eb8722db5f8531615b38788
C2: iot.981666[.]xyz:8080