"I'm attaching the data in the attachment" 💌

“Attaching the data in the attachment” 💌

Today we have as our guest a small, but no less interesting and experimental reverse shell for Linux. Although it’s hard to surprise anyone with a reverse shell these days, this sample still managed to catch our attention.

It is notable for the following:

• Its “distribution” includes a kernel module.
• Control is implemented via email.

Let’s examine it in more detail: all files are combined into a single dropper that extracts and launches the main shell components. There are three of them in total:

1️⃣ messenger.py — the transport. This script receives commands from the attacker and sends the results of their execution to the C2 server using IMAP and SMTP.

2️⃣ agent.elf — the main agent. It constantly polls the transport for commands, executes them in the command-line interpreter, and saves the output for subsequent transmission to the C2 server.

3️⃣ maldrv.ko — the LKM rootkit. Used to escalate the agent’s privileges.

int __cdecl main(int argc, const char **argv, const char **envp)
{
  if ( getuid() )
  {
    fwrite("Agent must be run as root\n", 1uLL, 0x1AuLL, stderr);
    return 1;
  }
  else
  {
    extract_file("/root/.agent.elf", agent_elf, 30400uLL);
    extract_file("/lib/modules/5.15.0-67-generic/kernel/drivers/misc/maldrv.ko", maldrv_ko, 446880uLL);
    extract_file("/root/.messenger.py", messenger, 5295uLL);
    inject(shellcode_out, 136uLL);
    call_all_plugins("/root/.agent.elf");
    return 0;
  }
}
Code language: JavaScript (javascript)

All the initialization work is performed by a small shellcode that is injected into a child process. It is this shellcode that loads the rootkit into the kernel via the finit_module call and launches the agent.

🙌 The maldrv.ko module intercepts the execve system call. When a specific argument is passed, it escalates the privileges of the calling process via commit_creds, after which the agent activates the transport for receiving commands and transmitting their results (see screenshot).

📧 The transport messenger.py uses a mailbox specified in the script. To receive commands, it retrieves emails with the subject Command from the inbox folder every 10 seconds, received no earlier than the current date, thus fetching only fresh commands. It looks for the command itself in the part of the email with the MIME type text or plain, writing it to the file /root/.output/.output.txt. After retrieval, the email with the command is deleted from the mailbox.

The results of command execution, which are written as separate files to the /root/.output/ directory, are archived into a ZIP file, which is encrypted with AES in CBC mode. Then this file is sent in “chunks” of 40 KB to a specified mailbox. If the list of mail accounts contains several accounts, the sending of each part of the encrypted archive is distributed among them.

👨‍🎓 It is obvious that our guest is a certain educational project, a proof of concept for such a malicious program. Moreover, the limitations of IMAP and SMTP do not allow for quickly exchanging large volumes of data with the C2 server. However, mail protocols have quite often been used in real malicious campaigns as well — suffice it to recall the active use of SMTP in Agent Tesla in the SteganoAmor campaign.

By what signs can such activity be recognized? It is worth paying attention to the periodicity of communication with the mail server, as well as the volume of data from the host transmitted via the specified protocols.

IoCs:

SHA-256:
40BB351F8B5AC6A02CD2A31D1683CC1ADB4C0C949346F51C2746F023004C5361
E908E1F4B799E1B5F38FCC8E6B1300E3604A101CF367D3431D82EEDDD1A02A05
68B3C2E7EF26C0432D7DEBFEB8CBCEE2F557A52B5662B3B3B49DCE21E0B288A4Code language: YAML (yaml)

#ti #malware #tips #ioc
@ptescalator