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!)