|
| 1 | +# Sandfly File Decloak - Decloak data hidden by a Linux stealth rootkit |
| 2 | + |
| 3 | +This utility helps investigate a host for signs of an active Linux stealth rootkit that may |
| 4 | +be hiding data in critical files. It does this by reading in a file using standard file I/O |
| 5 | +operations and then doing the same using memory mapped I/O to see if the number of bytes |
| 6 | +read are identical. |
| 7 | + |
| 8 | +Any differences detected will generate an alert. Plus, you will see the hidden data |
| 9 | +decloaked to instantly see if it is suspicious or not. This utility will work against many |
| 10 | +common Loadable Kernel Module (LKM) stealth rootkits that use data hiding techniques. |
| 11 | + |
| 12 | +## Linux Loadable Kernel Module Stealth Rootkit File Hiding Tactics |
| 13 | + |
| 14 | +Loadable Kernel Module rootkits on Linux use a variety of tactics to hide. One method is to |
| 15 | +hide processes which can be decloaked using our utility sandlfy-processdecloak |
| 16 | +(<https://github.com/sandflysecurity/sandfly-processdecloak>). The other is to hide data |
| 17 | +inside critical start-up scripts so it can maintain persistence between reboots but not be |
| 18 | +seen by investigators when running. |
| 19 | + |
| 20 | +For instance the files below are commonly targeted to hide data as they are used to insert |
| 21 | +kernel modules upon system boot. Or, these files can be used to insert malicious libraries |
| 22 | +to intercept system calls in libc, etc. to alter data to callers: |
| 23 | + |
| 24 | +```text |
| 25 | +/etc/modules |
| 26 | +/etc/ld.so.conf |
| 27 | +``` |
| 28 | + |
| 29 | +Also directories for module loading on boot such as: |
| 30 | + |
| 31 | +```text |
| 32 | +/etc/modules-load.d |
| 33 | +/etc/init.d |
| 34 | +/etc/rc*.d |
| 35 | +/etc/systemd |
| 36 | +``` |
| 37 | + |
| 38 | +Many more files can also be used for this purpose and often are hidden under /etc as part |
| 39 | +of system init scripts. |
| 40 | + |
| 41 | +## Stealth Rootkit Hiding Method |
| 42 | + |
| 43 | +Most LKM rootkits generally accomplish data hiding by hooking common system calls for file |
| 44 | +read operations. They will use a special set of tags to mark data to hide. Between the tags |
| 45 | +the malicious data will be inserted. When the rootkit sees the start tag it simply does not |
| 46 | +show any data present until the end tag is read. By doing this the rootkit can effectively |
| 47 | +hide from discovery using common command line tools and even editors on Linux. |
| 48 | + |
| 49 | +For instance, a modified file may have tags inserted like this: |
| 50 | + |
| 51 | +```bash |
| 52 | +# malicious content below |
| 53 | +#<lkm_tag> |
| 54 | +malicious_module |
| 55 | +#</lkm_tag> |
| 56 | +``` |
| 57 | + |
| 58 | +Anything between the *<lkm_tag>* and *</lkm_tag>* will be masked (along with the tags |
| 59 | +themselves) when you use tools like cat, echo, vi and so on. It simply won't be shown. |
| 60 | + |
| 61 | +## Detecting LKM rootkits |
| 62 | + |
| 63 | +It is one thing to convince the kernel to hide data, but something else entirely to get |
| 64 | +the file system to agree with it. In fact we know the data is there on the file system |
| 65 | +and we just need to bypass the hooked calls to see if we can get it to reveal itself. We'll |
| 66 | +accomplish this using memory mapped (mmap) file I/O instead of standard file I/O. LKM |
| 67 | +rootkits generally do not intercept mmap file I/O which is a significantly harder and |
| 68 | +riskier thing to do. |
| 69 | + |
| 70 | +We will read the file using standard system calls, then we read the file using mmap system |
| 71 | +calls in a simple Python script. We then compare the two results. If the results show the |
| 72 | +same number of bytes the system is likely clean. However if the two results do not match |
| 73 | +then data is being hidden and we will use the mmap I/O to show the data difference and |
| 74 | +decloak the data it saw that was different. |
| 75 | + |
| 76 | +## Usage |
| 77 | + |
| 78 | +Simply execute the python script on the system in question and the answer will come forth. |
| 79 | + |
| 80 | +```bash |
| 81 | +python3 ./sandfly-file-decloak.py -f <file_to_investigate> |
| 82 | +``` |
| 83 | + |
| 84 | +Below we find a system with cloaked data under /etc/modules. |
| 85 | + |
| 86 | +```text |
| 87 | +root@sandflysecurity:/root # python3 ./sandfly-file-decloak.py -f /etc/modules |
| 88 | +
|
| 89 | +Sandfly File Decloaking Utility - Version 1.0 |
| 90 | +Copyright (c) 2018-2022 Sandfly Security |
| 91 | +Agentless Security for Linux - https://www.sandflysecurity.com |
| 92 | +
|
| 93 | +
|
| 94 | +************************************** |
| 95 | +File contents with standard I/O |
| 96 | +************************************** |
| 97 | +
|
| 98 | +
|
| 99 | +# /etc/modules: kernel modules to load at boot time. |
| 100 | +# |
| 101 | +# This file contains the names of kernel modules that should be loaded |
| 102 | +# at boot time, one per line. Lines beginning with "#" are ignored. |
| 103 | +
|
| 104 | +# malicious content below |
| 105 | +
|
| 106 | +
|
| 107 | +
|
| 108 | +************************************** |
| 109 | +File contents with memory mapped I/O |
| 110 | +************************************** |
| 111 | +
|
| 112 | +
|
| 113 | +# /etc/modules: kernel modules to load at boot time. |
| 114 | +# |
| 115 | +# This file contains the names of kernel modules that should be loaded |
| 116 | +# at boot time, one per line. Lines beginning with "#" are ignored. |
| 117 | +
|
| 118 | +# malicious content below |
| 119 | +#<reptile> |
| 120 | +malicious_module |
| 121 | +#</reptile> |
| 122 | +
|
| 123 | +
|
| 124 | +
|
| 125 | +Standard IO file size bytes: 222 |
| 126 | +MMAP IO file size bytes: 260 |
| 127 | +
|
| 128 | +******************************************************************************************** |
| 129 | +ALERT: File sizes do not match. File has cloaked data. Check contents above for hidden data. |
| 130 | +******************************************************************************************** |
| 131 | +``` |
| 132 | + |
| 133 | +## Automating with Agentless Linux Endpoint Detection and Response (EDR) |
| 134 | + |
| 135 | +This tool can be built into an automated script to check hosts for signs of compromise. |
| 136 | +However, a much easier way is to use Sandfly to do it agentlessly for all your Linux systems |
| 137 | +continuously. |
| 138 | + |
| 139 | +We have modules to detect and decloak stealth rootkit activity instantly across all your |
| 140 | +Linux systems. Even better, we can do it without the risk of loading any agents on your |
| 141 | +endpoints. |
| 142 | + |
| 143 | +You can find out more information and get a free license to use on your Linux systems below: |
| 144 | + |
| 145 | +<https://www.sandflysecurity.com> |
| 146 | + |
| 147 | +## More Linux Forensics |
| 148 | + |
| 149 | +If you liked this utility, please check out our blog where we go into many other Linux |
| 150 | +forensic techniques using command line tools and procedures at our website: |
| 151 | + |
| 152 | +<https://www.sandflysecurity.com> |
0 commit comments