Purpose

LOIC is a network stress testing tool for simulating and testing peaks on various services.
It is meant only for testing how your servers cope with many requests and under heavy load and how your server does respond to several (D)DOS ((Distributed) Denial Of Service - Attacks).
Nevertheless it is assumed, that you own the servers you are testing!

DISCLAIMER:

USE ON YOUR OWN RISK. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER OR CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES

THIS TOOL IS RELEASED WITH NO WARRANTY AT ALL.

Attacks

The Target

Unless you know exactly what you are doing, you should use the "URL" field with the DNS of the server.
In 99.99% you do NOT want to target the IP!
Whatever you do - hit "Lock ON" BEFORE you start.

Attack Options

• HTTP
• UDP
• TCP
• ReCoil
• SlowLOIC

Choose an attack method from the pulldown and see which fields get enabled.
You can change the speed slider on the right during the attack.
If you use ReCoil or slowLOIC you can change the amount of threads during the attack as well.

HTTP

HTTP Attack

The HTTP-Attack can be used as a bandwidth reaper or for massdemanding (dynamic) content.

Options

In the "subsite" you can specify the page to request.
If "Append random chars" is checked, 6 random characters are added at the end of the subsite. (usefull with dynamic pages and get-parameters)
If "Wait for reply" is checked, the complete document will be downloaded.
If it is unchecked, the page is only requested but not (completely) read. However the server starts to send the document until your receivebuffer is full. This option is especially intereseting for noncached dynamic pages where the processing time is more valuable than the used bandwidth.
In the "Timeout" field you set the read timeout in seconds. This is only important if "Wait for reply" is checked.
Remarks

"Failed" counts the unsuccessful connection attempts to the target. If "Wait for reply" is checked, "Failed" is also increased, if the target took longer than the time specified in "Timeout" to deliver the page.

UDP

UDP Attack

The UDP method is a packet flooder.

Options

In the "message" you can set some payload to send to the targeted service.
If you need the newline chars, you can use \r and \n to construct the desired command / message.
If "Append random chars" is checked, 6 random characters are added at the end of the message.

"Wait for reply" waits until the packet is completely send. (you may want to check this on slower connections!)
Remarks

"Failed" counts the unsuccessful connection attempts to the target.
In most cases 10 threads is more than enough and should use all available upload-bandwidth, however with the speed-slider you can adjust this.

TCP

TCP Attack

The TCP method is a packet flooder. It is NOT a SYN-Flooder!!

Options

In the "message" you can set some payload to send to the targeted service.
If you need the newline chars, you can use \r and \n to construct the desired command / message.
If "Append random chars" is checked, 6 random characters are added at the end of the message.

"Wait for reply" waits until the packet is completely send. (you may want to check this on slower connections!)
Remarks

"Failed" counts the unsuccessful connection attempts to the target.
In most cases 10 threads is more than enough and should use all available upload-bandwidth, however with the speed-slider you can adjust this.

SlowLOIC Attack

SlowLoris (originally by RSnake) keeps the connections alive as long as possible by sending partial headers but nether completing the request.

Options

In the "subsite" you can specify the page to request.
If "Append random chars" is checked, 6 random characters are added at the end of the subsite. (usefull with dynamic pages and get-parameters)
The "Timeout" field is for the wait time in seconds between sending a new part of the header. This must be less than the read timeout on the target side.
The amount of worker "threads" can be changed during the attack at any time. This value should be initially lower than the maximum allowed half-open connections.
Check "use gZip" to check for CEV-2009-1891.
Check "use GET" to use the GET-command instead of POST. (mods like http-ready mitigate GET-attacks)
In the "Sockets / Thread" field you can define the number of connections per thread. (this number should not be insanely high - if you go over 100 it might be better to increase the amount of threads!)
the speed-slider sets just the delay between the creation of sockets.
Remarks

The "requested" value shows the amount of currently connected sockets.
If no thread is in the "Connecting" state you should increase the number of threads - if all your threads or most of them are connecting you should lower the amount of threads.
"Failed" counts the connections which were reset by the server.
If "failed" goes up too fast you are doing it WRONG!
Tip

If you target a system which is not vulnerable to this attack you can always go for port-starving!
Just use up all max possible 64K connections and you are done! (running 16 clients with 5.000 connections each should do the trick!)

ReCoil Attack

The ReCoil attack focuses on keeping the connections alive as long as possible, but it is not the same as SlowLoris. It is more like a "reverse" DOS-attack.

A fully legimit request is made but the download-speed is slowed down to nearly 0 by reading just enough from the network to keep the socket alive.
The attack itself produces NO errors - there are just a bunch of HTTP 200 in the access logs. If the server runs out of available ressources and goes down, there might be an system error entry.
Especially all servers, that are vulnerable to SlowLoris, are vulnerable to this attack. ReCoil however is not as "easy" mitigated as SlowLoris. Think of it as a bunch of mobile devices requesting a page just before driving through a tunnel.
Prerequisite

Due to the nature of the attack the requested site has to be at least 24kb (better larger).
The exact minimum filesize depends on the network buffer space of the attacking system. For most 10/100 connections around 24KB should work, while on gigabit connections filesizes beyond 64KB are needed.
NOTE: Your LOCAL link speed is the essential key not your internet speed! (meaning if you have a 1MBit internet connection and you are have a 1 gigabit link to your modem / router, you are pretty much screwed! --> target pdfs or big stuff like that!)

Options

In the "subsite" you can specify the page to request. (keep the size in mind and do a bit scouting!)
If "Append random chars" is checked, 6 random characters are added at the end of the subsite. (usefull with dynamic pages and get-parameters)
If "Wait for reply" is checked, ReCoil follows Header redirects and discards early documents, which are smaller than 16KB. (Only apply this if needed)
The "Timeout" field is for the wait time in seconds between reading from each socket. This must be less than the write timeout on the target side.
The amount of worker "threads" can be changed during the attack at any time. This value should be initially lower than the maximum allowed half-open connections.
To consume even more memory you can additionaly check the "use gZip" - but remember the resulting document has to be of reasonable size!
In the "Sockets / Thread" field you can define the number of connections per thread. (this number should not be insanely high - if you go over 100 it might be better to increase the amount of threads!)
the speed-slider sets just the delay between the creation of sockets.
Remarks

The "requested" value shows the amount of currently connected sockets.
If no thread is in the "Connecting" state you should increase the number of threads - if all your threads or most of them are connecting you should lower the amount of threads.
"Failed" counts the connections which were reset by the server. If "Wait for reply" is checked it also counts the unsuccessful attempts which are early discarded.
If "failed" goes up too fast you are doing it WRONG!
Tip

If you target a system which is not vulnerable to this attack you can always go for port-starving!
Just use up all max possible 64K connections and you are done! (running 16 clients with 5.000 connections each should do the trick!)