Hack Like a Pro: Digital Forensics for the Aspiring Hacker, Part 4 (Evading Detection While DoSing)

Welcome back, my hackers novitiates!

As you read my various hacking tutorials, you're probably asking yourself, "What are the chances that this hack will be detected and that I'll land behind bars, disappointing my dear mother who already thinks I'm a loser?"

In this tutorial, I will try to answer that question by running an attack against a vulnerable system, but with an Network Intrusion Detection System in place monitoring for malicious traffic, i.e. you.

We'll be using Snort, the ubiquitous NIDS, to identify the attack and the attacker. Snort, having been purchased by the networking giant Cisco in 2013, is likely to continue its position as the world's most-widely used detection system. Using it here, we should get a good idea of how a security engineer at the victim company will view our remote exploits/hacks.

If you're unfamiliar with Snort, take a look at my previous guides on evading an NIDS using Snort and reading and writing Snort rules before continuing.

Step 1: Open Up Snort

Snort is built into BackTrack, so there's no need to download and install. We simply need to start the Snort daemon (Services, then Snort) and then run Snort. We can start Snort with its configuration file by typing:

• bt > snort -vde -c /etc/snort/snort.conf

When we do so, Snort will begin sniffing traffic off the wire and analyzing it for signatures of malicious traffic.

The Importance of Using a DoS Attack

The first attack we want to view through the eyes of the security engineer at Victim Inc., is the ever popular denial of service (or DoS) attack. The beauty of DoS attacks is that they are simple and relatively easy to perform. In addition, because you do not need a TCP connection and return traffic, you can spoof your IP address without any downside.

Although the attacker will not gain any info or credit card numbers by performing a DoS attack, they can certainly do significant financial harm to the victim, especially to e-commerce sites. For instance, last year Amazon generated $70B in sales from their website. That works out to $192 million per day, or $8M every hour, and $133,181 for every MINUTE. To put it another way, a DoS attack against Amazon that is successful for JUST 10 minutes, would cost them $1.3 million!

There are numerous tools on the market that can be used for DoS. In this case, we will use one of my favorite tools, hping3—a versatile tool that I refer to as a "packet crafting tool" because it enables us to basically create just about any type of packet we can imagine. If you aren't familiar with hping, check out my tutorial on conducting active recon on your target with hping3.

Step 2: Use a SYN Flood Attack & Spoof Your IP Address

Among the simplest DoS attacks is the SYN flood attack, which sends millions of TCP packets at the target with the SYN flag set, in essence, asking the system to establish a TCP connection. It never creates a TCP connection, so the server never logs the IP address (all successful connections are logged). It uses up all the bandwidth on the network as well as all the connection queue, so that new connections cannot be established.

As for the target and the security engineer there, they will see the flood of SYN packets coming and trace the attack to the IP address on the packets, i.e. YOURS. To avoid this, hping enables us to spoof our IP address so that the flood appears to be coming from another IP. In this case, let's use Microsoft's IP address, so the attack appears to be coming from our friends at Microsoft.

We can start a SYN flood with hping by typing:

• bt > hping3 -S -a 65.55.58.201 192.168.1.101 -p 80 --flood

• -S is the packet flag type (SYN)
• -a = spoof the following address
• 65.55.58.201 is the spoofed IP address (Microsoft's)
• -p 80 = the port to send the packets to
• --flood = send the packets as fast as you can

Hping in --flood mode won't show any returned packets, as it will just be way too many to display on the screen. In addition, since we spoofed Microsoft's IP address, any responses are going there.

Step 3: Check the Alerts

If you still have the Snort terminal open, you're seeing thousands of packets going by. Let's stop Snort with Control C. When we do that, we'll see that Snort will display some statistics for us. If we scroll up a bit, we can see the number of alerts that were generated. I ran hping3 for just a few seconds and it generated 91 alerts on Snort.

Now, let's open our Snort alerts file. This is the file that Snort generates to alert the security engineer of any malicious activity. We can use any text editor, but here I am simply going to use the tail command in Linux to see the end of the file. When you have large log or alert files, tail is perfect tool as it will only show the "tail" of the file (the most recent additions).

To see the last 50 lines of the Snort alerts, I can type:

• tail -50 /var/log/snort/alert

When we do, we will see several alerts that were triggered by our attack.

Notice in the fourth line from the bottom that the alert references the appropriate Microsoft TechNet Security Bulletin, which in this case is MS01-059.

Step 4: Reference Microsoft's Security Bulletins

We can now go to Microsoft's Technet Bulletins to see what Mr. Gates has to say about this attack. For more info on what the Technet Bulletins are, check out my guide on finding the latest exploits and vulnerabilities directly from Microsoft.

Below is a copy of the page for MS01-059.

Note the highlighted area. It reads:

"An attacker could specify a third-party server as the host for the device description in the NOTIFY directive. If enough machines responded to the directive, it could have the effect of flooding the third-party server with bogus requests, in a distributed denial of service attack. As with the first scenario, an attacker could either send the directives to the victim directly, or to a broadcast or multicast domain."

Snort has classified our attack as a DoS attack. Although it appears to Snort that it might be a DDoS, it did a pretty good job of detecting our attack and notifying the security admin. Now when the admin attempts to trace the attack, it will take him directly to Microsoft.

You're Safe from Detection!

So, for now, you will avoid an extended stay in the concrete 8 by 8 foot room and save your dear mother from heartbreak, but she still kinda thinks you're a loser, albeit, a lovable one.

Keep coming back, my hacker novitiates, for more Null Byte adventures, and make sure to keep tabs on my section on Digital Forensics for the Aspiring Hacker to stay up to date on recent forensics tutorials.