socat to Simulate a Website

Published: 2010-06-26
Last Updated: 2010-06-26 18:07:02 UTC
by Guy Bruneau (Version: 1)
2 comment(s)

Last week I published a diary on DNS Sinkhole. If you are looking at tracking the clients that are redirected into your sinkhole address, the method I have been successfully using is with a multipurpose relay tool, called socat (SOcket CAT) .

In order to capture the host information (true website name) the client is attempting to access, I have been using socat to simulate various web server ports (80, 443, 7070, 8080, etc) and you can capture that information with your favorite IDS or using a simple Snort signature. It is much easier then to figure out what site the client was attempting to connect to and figure out if the client is already infected. A direct client outbound connection might indicate the client is attempting to contact a C&C and already compromised while a web site redirect is potentially malicious but blocked by the sinkhole.

Socat as a Web Site Simulator

socat TCP-LISTEN:80,bind=192.168.25.5,fork,reuseaddr,crlf SYSTEM:"echo HTTP/1.0 200; echo Content-Type: text/plain; echo;" &

This first socat example is used to simulate a web server listener on TCP port 80. The same line can be copied several times with different ports using the same address to simulate your web port list.

socat openssl-listen:443,bind=192.168.25.5,fork,reuseaddr,verify=1,cert=/home/certs/sinkhole32.pem PIPE=echo &

This second socat example is used to simulate a SSL server with a certificate and will need to capture the full packet stream and have the SSL certificate private key to be able to read it. This works best with a signed SSL certificate by a known CA which the browser will recognized as signed and valid. If you collect full packets (i.e. for example, using Sguil), you can then use Wireshark to examine the SSL packets and find which site the client was attempting to reach. You can create your own self-signed certificate with OpenSSL but the client will surely give a message that you are attempting to use an untrusted SSL certificate and most likely won't get the host name.

Header Review

Here is an example of a client redirected to the socat web site simulator while attempting to reach 00g00.ca.

-------------------------------------

GET / HTTP/1.1

Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*

Accept-Language: en-CA

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)

Accept-Encoding: gzip, deflate

Host: 00g00.ru

Connection: Keep-Alive

 

The socat binary is included in the DNS Sinkhole ISO and these two example are in the rc.local script. More information is available about socat's other features here.

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org

Keywords: socat
2 comment(s)

Comments

Wait... what? Your DNS sinkhole does not log the client IP and the domain name requested? Why do you need to capture the domain name again from the web request?

Anyway, the same can be accomplished using netcat that is kept up with tcpserver (http://cr.yp.to/ucspi-tcp.html). I run various little tools using tcpserver and netcat, from scan detectors to full-fledged telnet like interfaces. Worth checking out as it's handy for any TCP socket foo.
When a DNS sinkhole is run as BIND a forwarder, it will log the domain name and the IP address of the DNS server, not the client. Otherwise, you would need to go check the logs on the DNS server that made the request on behalf of the client which is most likely a Windows server. By default, Windows doesn't keep DNS logs.

Diary Archives