Introducing HULK (Http Unbearable Load King).1-twitter-dos-data
In my line of work, I get to see tons of different nifty hacking tools, and traffic generation tools that are meant to either break and steal information off a system, or exhaust its resource pool, rendering the service dead and putting the system under a denial of service.
For a while now, I have been playing with some of the more exotic tools, finding that their main problem is always the same… they create repeatable patterns. too easy to predict the next request that is coming, and therefor mitigate. Some, although elegant, lack the horsepower to really put a system on its knees.
For research purposes, I decided to take some of the lessons I’ve learned over time and practice what I preach.
Enforcing Python’s engines, I wrote a script that generates some nicely crafted unique Http requests, one after the other, generating a fair load on a webserver, eventually exhausting it of resources. this can be optimized much much further, but as a proof of concept and generic guidance it does its job.
As a guideline, the main concept of HULK, is to generate Unique requests for each and every request generated, thus avoiding/bypassing caching engines and effecting directly on the server’s load itself.
I have published it to Packet Storm, as we do.
Obfuscation of Source Client – this is done by using a list of known User Agents, and for every request that is constructed, the User Agent is a random value out of the known list
Reference Forgery – the referer that points at the request is obfuscated and points into either the host itself or some major prelisted websites.
Stickiness – using some standard Http command to try and ask the server to maintain open connections by using Keep-Alive with variable time window
no-cache – this is a given, but by asking the HTTP server for no-cache , a server that is not behind a dedicated caching service will present a unique page.
Unique Transformation of URL – to eliminate caching and other optimization tools, I crafted custom parameter names and values and they are randomized and attached to each request, rendering it to be Unique, causing the server to process the response on each event.
Basically my test web server with 4gb of Ram running Microsoft IIS7 was brought to its knees under less than a minute, running all requests from a single host.
In the pictures below you can see the tool in action, where it first ( #1 ) executed against a URL, and then the tool starts generating a load of unique requests and sending over the target server ( host of the URL ), and second ( #2 ) we can see that the server at some point starts failing to respond since it has exhausted its resource pool.