I'm thinking of adding transcripts to the podcasts threads.
Maybe someone could help with it, or at least give feedback.
Tell me what you think of transcripts?
This is an example for this podcast episode.
Bear in mind that this is my rough show notes.
--( Transcript )--
Quote:Unix Forensic
Your Unix box has been p0wn3d, what do you do?
I'm gonna explain if you've been p0wn3d or not, if you've been hacked
You need to figure out if something really happened without showing the
attacker that you've noticed to not alarm him and maybe cause more harm.
Or destroying evidence, wiping out your disk, without taking down your machine.
Talk to users, know what are the weird stuffs happening.
APT
Using good binaries
Minimizing disturbance to the system
Collecting data, information gathering, what kind of data, from where? Too much not enough?
Automating with scripting? (netcat)
Next step if there is a breach
How to keep him out, kick him
Recover and stand on your feet again.
You wanna take notes about what's happening and what happened.
Otherwise you'll get lost in the amount of information.
You need to make sense of the situation, every case is different.
Your machine is customized, has different services that run on it.
Different OS, different binaries, different architecture, etc..
So then depending on those services you need to know what's weird.
Why is there a suspicion in the first place.
You need to talk with the persons that noticed it.
If it's yourself then fine, if it's others go interview them.
There's someone that knows the situation better.
Who's the expert that knows what's running on that machine.
The context, everything has a context.
Best case scenario it might even be a false alarm and there's no need to dig
the issue.
In all cases, it's gonna make you win a lot of time.
Instead of having to learn about the system by yourself.
What are they suspecting?
Why do you think an incident happened?
What is there to know about this system?
After getting enough information you can touch the machine.
First thing you wanna do is rung good binaries you don't wanna run possibly
trojan binaries.
For that you can use a USB response drive.
Contains known good binaries
At a minimum /bin, /sbin, /lib for the same architecture, and again that's why we
ask about the OS and architecture (64 bit, 32 bit, ELF, Freebsd, etc..)
You can have some extra tools good binaries that could help /usr/sbin /usr/bin /usr/lib
Those can help.
it should have a filesystem supported by the OS, ext2, ext3 or ext4, for example
You could also go for a bootable Unix or any OS that you can access the host.
That is if you can afford to restart the system
Live CD or live USB are good options.
Actually it's a way better idea, you don't want that system to stay online with
an attacker on it.
And maybe you have a real time fight with him, and he kicks you out and erase
everything on the machine.
But sometimes you can't afford to remove a live system, a production system.
Slitaz, or anything small is a good option.
Busybox is also an interesting one.
You want to avoid at all cost running binaries from the possibly infected
system. You never know what could've happened to them.
We take our precautions.
We can even mount the filesystem in a read-only mode to avoid loosing evidence.
That would minimize changes and disturbances to the system, minimize footprints too.
You don't want to write on that important system and mess things up.
That basically comes down to changing the environment variables to point to
the binaries and libaries on your USB.
the $PATH and $LD_LIBRARY_PATH
You don't want to be running their version of the shell either, you want to run
your own binary, your own shell and only them!
Nota bene: Run all script with the shell mentioned before it, your own shell.
Never run them with the shebang, you cannot know what the behavior will be,
it's gonna point to the possibly infected one.
We talked about minizing, one approach is to not write anything on the system.
Or you write the things on your USB or you send them over the network for later
analysis.
For sending over the network you can go for complex solutions or you can simply
use a netcat listening.
You create log files, get some info of the machine and send the log file
through netcat.
What you wanna do is Open a netcat listener on the machine you wanna analyse
the logs on and create a client on the infected machine.
#Listen on a port and output what it gets to a file
#-k to keep the connection alive
nc -l 5556 > $1/$(basename $filename)
#To send the file
nc $RHOST $RFTPORT < $1
When you are done you clean everything, stop the listener.
What do collect.
What data do you want to collect and why.
First thing you wanna get is the date.
There can be a clock skew on the subject system.
What keeps them accurate is the time server, NTP
Maybe the timezone is different if you wanna compare.
date
Then you collect the kernel version for the operating system.
So that you can list the known vulnerabilities for that OS.
uname -a
Other things you wanna collect.
What network connections are happening and the interfaces.
What is it like.
Are there new devices connected, someone plugged a USB,
New network connections happening to unkown
servers from unknown binaries.
Any suspicious addresses, strange localhost connections or weird ports.
Any program running on the wrong port?
ifconfig -a
netstat -anp
Even more things to collect.
What files are opened at the moment,
But you know, files on Unix are everything, it's gonna be a long list but it's
worth it.
lsof -V
What processes are running, are there things that are running as root and that
shouldn't, GID or ID 0
Or there are no account logged in and things are running...and they shouldn't be
running.
Or accounts logged in that shouldn't be login in.
ps -ef
Routing information, What router are you connected to
Are there new gateways, new interfaces.
netstat -rn
route
If the outputs differ then you've been hacked.
We talked about USB, if it's a server maybe someone has connected a rogue usb.
Check if it's mounted using df and mount
df
mount
Is the filesystem filling up in a tempfs, that might be an indicator that
something weird is happening.
Overuse the the fs or any resources, for that matter.
Udev rules, there could be something plugged... automatic scripts
Maybe the attacker has loaded a new kernel module, new device, new driver,
or modules that changed
lsmod
Now some of the most important part.
Check the users.
Who's logged in now, are there system accounts that shouldn't even be able to
login
w #like who but gives you the last command a user has runned
Who has been logging in the last days or has failed logging in.
last
lastb # Someone has cracked your account, 2k failure and then a success
Well, let's check if there is anything changed to their groups and shells.
login information.
Any newly created login, users
Any account with ID 0, they have root permission!
New account called "nobody" with user ID 0
Did someone add a shell to something that shouldn't even be able to login
cat /etc/passwd
cat /etc/shadow
Check the logs, might not be that relevant, they might have been altered.
Last commands run, in the HISTFILE, have you ran commands with the password in
it... It's stored in the HISTFILE and the attacker has seen them.
You should change all that.
You shouldn't even use passwords in the first place, you should use key based
authentication
Are there new ssh keys in the authorized_keys file?
Live analysis, which are advanced:
Linux Memory Extractor (LiME) which is used for dumping RAM
Make an image from a physical hard drive that has been removed from a subject system
You've been hacked so what do you do?
Do you take the machine offline. Probably yes.
You need to review what has been infected.
Repair the system.
Using all the data gathered through the analysis you can narrow down what needs
to be taken care of so that the attack doesn't repeat itself.
But sometimes that's not enough and you cannot know from where you've been
hacked, what was the leak, the door to your system.
In this case you need to review the softwares you are running on the machined
because that's probably related to that.
It's an exploit.
So keep in mind you have to run the latest versions of the softwares.
Keep patching.
Don't run too many things on a single box.
That's about it folks.
|
