After the attacker clicks on the Add button, they are taken back to the main screen.

The attacker can then adjust the THREADS number if desired to further increase the strength of the attack. When they are ready to lauch the attack, they click on the "FIRE TEH LAZER!" button. With the default settings shown above, the HTTP requests look like this:

What makes HOIC different from LOIC?

Looking at this attack data, you may be asking yourself "How is HOIC different from LOIC?" First of all, LOIC had both TCP and UDP DDoS attacks in addition to HTTP attacks were as HOIC is strictly an HTTP DoS tool. The real difference, or enhancement, that HOIC has over LOIC is its use of what it calls "Booster Scripts."

Booster Scripts

This is taken directly from the HOIC DOCUMENTATION FOR HACKERS text file:

OK!

So BASICALLY

HOIC is pretty uselessUNLESS it is used incombination with "BOOSTERS", AKA "SCRIPTS"/BOOST PACKS / BOOM BOOM POWERThese boosters come in the form of .HOIC scripts.

hoic scripts are very simple and follow VB6 mixed with vb.net syntax although slightly alteredhere are the functions and globals that relate the HOIC:

booster -> This is a global variable that contains the contents of the current script (string)Headers -> This is a global variable that is an array of strings, and will be used to form headers in requests sent to the target URL. To add a header, simply do something like this:Headers.Append("User-Agent: penis") or Headers.Append("User-Agent: penis x" + CStr(powerFactor)

lbIndex -> Index into list box (cant really be used outside of the program, useless to developers)PostBuffer -> String buffer containig post paramets, ie PostBuffer = "lol=2&lolxd=5"powerFactor -> Integer from 0-2, 0 being low, 1 being medium , 2 being hightotalbytessent -> a count of the number of bytes sent to the target already (presistent across each attack)URL -> url to attackUsePost -> boolean, true = uses post, otherwise itll use get

Let's take a look at a booster script called GenericBoost.hoic:

Dim useragents() as StringDim referers() as Stringdim randheaders() as string

// EDIT THE FOLLOWING STRINGS TO MAKE YOUR OWN BOOST UNIQUE AND THEREFORE MORE EVASIVE!

As you can see, the booster scripts set groups of various request header data including User-Agent, Referer and Cache-Control/If-Modified-Since data and will randomize the various combinations during attacks. After specifying the GenericBoost.hoic script and re-launching the attack, you can see that these request items are no longer static and instead randomly rotate between these data pieces:

In addition to the GenericBoost.hoic file, there are two other scripts that target specific web sites. One script is specifically targeting a government web site in retaliation for prosecuting someone for using LOIC is previous attacks. The hoic file includes random URLs on the target website to hit:

By randomizing these request characteristics, it makes things more challenging for defenders to create defensive rules to identify the individual attack payloads. While it does make detection more difficult, it is still possible.

HOIC Detection

While the HOIC requests try to evade detection through randomization techniques, there are still some request attributes which can be used for identification of attack traffic. Most of these tell-tale signs are based on abnormalities vs. real web web browsers.

Generic DoS Detection

Before we discuss some of the unique identifiers of HOIC traffic, we wanted to make sure to highlight the generic detection of automated DoS detection through traffic velocity violations. The OWASP ModSecurity Core Rule Set (CRS) has a denial of service detection rule set that can identify DoS attacks. The ModSecurity admin only needs to activate the file and then edit the following directives in the modsecurity_crs_10_config.conf file:

## -=[ DoS Protection ]=-## If you are using the DoS Protection rule set, then uncomment the following# lines and set the following variables:# - Burst Time Slice Interval: time interval window to monitor for bursts# - Request Threshold: request # threshold to trigger a burst# - Block Period: temporary block timeout#SecAction "phase:1,id:'981215',t:none,nolog,pass, \setvar:'tx.dos_burst_time_slice=60', \setvar:'tx.dos_counter_threshold=100', \setvar:'tx.dos_block_timeout=600'"

When a HOIC attack is run against the ModSecurity site, the following alerts will be generated:

These rules will initiate the drop action on all traffic from the attacker source and will provide periodic alerting with traffic stat counts). Besides alerting on traffic velocity violations, there are a numbe of other HOIC-specific attributes that may prove useful in the short-term to uniquely identify the attack tool in use.

HTTP Version and Host Header

All of the requests specify "HTTP/1.0" however they also include the "Host:" request header, which wasn't introduced until HTTP/1.1. The Host header's main purpose was to help conserve IP address space by allowing name-based virtual hosting. Without a Host header, each web site would have to have a unique IP address.

With this detection mechanism in mind, we can use the following ModSecurity rule to generically catch any HTTP/1.0 client that submits a Host header:

HTTP Request Header Ordering

While the request header names and payloads, in and of themselves, are valid, the order in which they are defined in the request do not match what normal web browsers would send. Two good references for Browser Fingerpringing/Header Ordering are the Browser Recon Project and p0f3 (passive OS fingerprinting).

Browser Recon Project

The Browser Recon Project has a Header Order DB with info on a large number of HTTP clients. The only limitation with this dataset is that it is quite old. The last update was in June 2008.

p0f3

Michal Zalewski recently updated his Passive OS Finferprinting (p0s) tool to v3 which includes application layer fingerprinting capabilities. This includes analysis of HTTP clients by means of header ordering analysis. Here is a section of the p0f.fp file for HTTP Client Fingerprints for Microsoft's Internet Explorer and for Google's Chrome browsers:

By examining the valid header ordering shown here in p0f3, we can identify that the HOIC header ordering is abnormal. The easiest charcteristing to notice is that, in HOIC, the Host header is always listed last in the header order while this is not the case in any legitimate browsers.

The following ModSecurity rule will inspect the current header odering of the client request and then alert if the Host header is listed last:

This rule uses ModSecurity's macro expansion capability to create a custom variable which captures the order of the request header names. Here is an example from the debug log showing how this rule processing works:

Leading Space Character Anomalies

Another interesting characteristic of HOIC traffic is that many of the Request Header payloads have leading double-spaces in them. Look at this pcap capture in wireshark:

In this screenshot, we are highlighting the Keep-Alive field. Notice that after the Header Name and semi-colon, that there is actually two space characters (20 20) before the 115 payload text in the hex window. There are actually a number of headers that exhibit this behavior in this request. After analyzing the varsious .hoic files included in the download, we determined that this can be reliably flagged on the User-Agent field as it is included with almost all requests.

We attempted to create a ModSecurity rule to detect this issue, however Apache is executing some pre-processing on the header values before passing this data off to ModSecurity and these leading space characters are not visible to ModSecurity.

If you are running Snort IDS, you can use the following rule (Thanks to SpiderLabs' Rodrigo Montoro) to detect this same traffic on the network prior to reaching the web server: