When come to analyzing Linux Hacked Server in live, most properly it's HARD. It's HARD in the sense that we can't do the imaging and perform dead analysis since the server requires no down time. However we can actually track down what is currently running or malfunctioning in our server with ps, netstat and memgrep, some might said you will have to have clean binaries for forensic purpose which is trusted, it's certainly true and you can actually download the static binaries from the Incident Response Live CD - Helix, the site provides the static binaries or you can compile your own trusted binaries if you want.
Memgrep is a tool to search, replace, or dump arbitrary memory from running applications and core files. Potential applications for memgrep include reverse engineering, debugging, and vulnerability assessment.
Below are the steps that I have taken on my demo server. I have found there's a suspicious process called kf.
Memgrep is a tool to search, replace, or dump arbitrary memory from running applications and core files. Potential applications for memgrep include reverse engineering, debugging, and vulnerability assessment.
Below are the steps that I have taken on my demo server. I have found there's a suspicious process called kf.
shell>ps auxww | grep kf
nobody 23437 0.0 0.0 1468 856 ? S Nov17 0:00 ./kf
I choose to use -p options since it will show the pid. This is good when you want to track down what process is currently having listenning port, or maybe initiating connection to internet.
shell>netstat -anp | grep 23437
tcp 0 0 0.0.0.0:3442 0.0.0.0:* LISTEN 23437/kf
unix 2 [ ] STREAM CONNECTED 399392712 23437/kf
Since we do not know what is kf doing, some prefer to use lsof -p 23437, for me I just use memgrep here since memgrep will provide more valuable info. The -L option will list memory segments of a process or core file.
shell>cd /nsm/memgrep/
shell> ./memgrep -p 23437 -L
.bss => 0804a874
.data => 0804a6a0 (96 bytes, 0 Kbytes)
.rodata => 0804959c (226 bytes, 0 Kbytes)
.text => 080489ac (3028 bytes, 2 Kbytes)
stack => bffe60bc
shell> ./memgrep -p 23437 -d -a 0x0804a6a0 -l 96
96 bytes starting at 0804a6a0 (+/- 0) as hexint...
0804a6a0: 00000000 00000000 0804a7d4 00000000 ................
0804a6b0: 00000000 00000000 00000000 00000000 ................
0804a6c0: 30786168 00000072 00000000 00000000 hax0r...........
0804a6d0: 00000000 00000000 00000000 00000000 ................
0804a6e0: 61202d3d 69696170 43616220 3030646b =- apaii baCkd00
0804a6f0: 63282072 30322029 2d203430 00000a3d r (c) 2004 -=...
Do you see the haxor :]
shell> ./memgrep -p 23437 -d -a 0x0804959c -l 226
226 bytes starting at 0804959c (+/- 0) as hexint...
0804959c: 00000003 00020001 73736170 00206477 ........passwd .
080495ac: 6b637546 2166664f 000a2121 73727170 FuckOff!!!..pqrs
080495bc: 77767574 617a7978 65646362 32313000 tuvwxyzabcde.012
080495cc: 36353433 61393837 65646362 642f0066 3456789abcdef./d
080495dc: 702f7665 00786d74 7665642f 7974702f ev/ptmx./dev/pty
080495ec: 65642f00 74742f76 6f730079 74656b63 ./dev/tty.socket
080495fc: 6e696200 696c0064 6e657473 63666e00 .bind.listen.nfc
0804960c: 20736920 72617473 676e6974 002e2e2e is starting....
0804961c: 202c4b4f 20646970 6425203d 6557000a OK, pid = %d..We
0804962c: 6d30636c 30742033 72347020 7a316461 lc0m3 t0 p4rad1z
0804963c: 316b2033 73306464 002f000a 7665642f 3 k1dd0s.././dev
0804964c: 6c756e2f 6873006c 00692d00 454d4f48 /null.sh.-i.HOME
0804965c: 0073253d 276e6143 6f662074 70206b72 =%s.Can't fork p
0804966c: 202c7974 21657962 622f000a 732f6e69 ty, bye!../bin/s
0804967c: 00000068 /sh.
If you know apaii backd00r or it's variant, please do feedback since I can't find any info regarding it in the internet after googling ..... til next time :]
5 comments:
Great work .. nice to know there's someone who knows what he's doing :)
Did you find out who and how?
I have already figured out but yet I can't post it here due to legal issue.
how if they used rootkit?
pretty obvious these day
:)
It depends, however small foot print of rootkit is the hardest to detect. For rootkit detection, you do need to watch your system call since most of the rootkit likely to modify it, or you have to check your kernel loadable module with lsmod. However like I mentionned at first, it depends on which kind of rootkit you encounter :]
Post a Comment