Conflicker detector?

Carter Bullard carter at qosient.com
Mon Mar 30 16:02:17 EDT 2009


Gentle people,
There is a lot of conficker news about, and the link below is  
interesting
as it has a few more behavioral descriptions.  Much of the tags
are searchable in argus data, so this week I may put together a
perl script, along the same lines as radark.pl, to report on potential
conficker activity, using the info in this link:

http://www.confickerworkinggroup.org/wiki/pmwiki.php?n=SP.ServiceProviders

as a guide (for starters).  One of the interesting things, is the list  
of "malicious
conficker" sites.  I'll also add a test for DNS requests for these  
host names,
from local machines, as that may also add some interesting fuel to the  
fire.

Because there is a DNS component to the attack profile, I think we can  
use
the radump() features to give us a heads up on who is doing conficker  
related
DNS lookups.  That should be very useful?

If anyone has any thoughts, please start hollering ;o)


Carter

On Mar 30, 2009, at 3:16 PM, Carter Bullard wrote:

> Gentle people,
> Anyone interested in doing a Conflicker detection program?
>
> I don't have any argus records of a successful Conflicker session.
> I only have Conflicker scan attempts.  No one I know seems to be
> having Conflicker problems, so I haven't seen any good data yet.
>
> If you are capturing user data in your argus data records, you
> may find this interesting.
>
> So, just looking for external to internal TCP -> port 445 will give  
> you
> some Conflicker scan activity if you have any, and the list of src  
> IP addresses
> involved in those types of scans can be used to seed searches in  
> your argus
> archives to see if any of those addresses have done anything
> interesting with your network.
>
> From what I know, Conflicker, once it has done its thing, uses HTTP
> over a peer-to-peer "callback" channel to check for things, and we can
> test for that really easily.
>
> With the list of IP addresses that used port 445, we can look for  
> any flow
> that has HTTP protocol key words on a session not using a traditional
> HTTP port.
>
> So, by hand you can do something like this, with the data from an
> argus looking at your border interfaces:
>   ../bin/racluster -L0 -m saddr -s saddr -R /Volumes/Data/argus/ 
> prim*/207*/2009/03 - tcp and port 445
>
> This will print out the IP addresses of port 445 scanners.  You can  
> refine that with a filter to say give
> you only addresses that are outside of your network.  For the month  
> of March,
> here is the output from QoSient world headquarters:
>            41.209.130.202
>            41.209.130.205
>              58.222.22.41
>             69.57.239.251
>              74.11.29.171
>             85.109.156.27
>            85.189.237.214
>                86.8.99.27
>            94.241.252.150
>             123.169.76.30
>            189.26.118.117
>            207.40.251.189
>           207.160.119.252
>            207.164.177.50
>            207.182.133.26
>            207.188.73.161
>           207.188.248.132
>           207.199.245.133
>            207.212.177.34
>            207.212.177.36
>             207.213.99.57
>           207.218.175.231
>           207.224.112.169
>              207.225.1.47
>           207.225.186.157
>            207.237.36.130
>            207.237.37.194
>            207.237.37.198
>            207.237.152.49
>            207.237.152.98
>           207.237.152.243
>             207.248.38.10
>            210.193.47.160
>              216.12.74.84
>
> So "../bin/racluster ...... port 445 > /tmp/ips.using.port.445"
>
> OK, so put that in a file, and use it as config for rafilteraddr()  
> to grab all the argus
> records from/to  those addresses, and check to see if you see any  
> HTTP like
> protocol keywords on a non "port 80" tcp connection.
>
> Remember, all ra* programs in argus-clients-3.0.x can 'grep' for  
> patterns
> in the user data buffers.  Just use the "-e 'regex'" option.
>
>   rafilteraddr -f /tmp/ips.using.port.445 -R /path/to/your/archive/ 
> 2009/03 -e "GET | PUT" - port not  \(80 or 8008 or 8080\)
>
> The "GET | PUT" is the regular expression "'GET' or 'PUT'" so be  
> sure and use the (bar)
> character.   OK, if you get any hits that look suspicious (like the  
> contents are all encrypted, or
> it just doesn't look right), then what would be cool is to capture  
> all the argus records to and
> from the local IP address over the time period where the Conflicker  
> activity was seen
> to see if you can figure out what is going on.
>
> Or, you can just go through your entire archive looking for this:
>
>   ra -R /path/to/your/archive/2009/03 -e "GET | PUT" - port not \(80  
> or 8008 or 8080\)
>
> But you'll get some false positives.
>
> When I do that, I found a single HTTP session using port 10080, and  
> that was it.
>
> That TCP connection was interspersed with other port 80 HTTP  
> connections to the
> same server, and you could see that it was preceeded by a loading of a
> "jquery_pack.jsr" file, so it was some java script grabbing off of a  
> weird port.  The
> commands were all "GET"'s and they were just images (a few gifs,  
> pngs, jpgs),
> so not interesting.
>
> I validated that they were pretty boring by doing a radump() of the  
> domain requests
> over the same period, looking for the IP addresses in the output, so  
> I could see
> that I had actually done something that made sense.  Let's say that  
> the IP address
> was x.y.z.w, then I would type:
>
>   radump -R /path/to/your/archive/2009/03/12/ -s +suser:128 +duser: 
> 129 - port domain | fgrep x.y.z.w
>
> And got the DNS session that actually returned the IP address of  
> interest.  So everything
> was pretty boring on that 10080 port HTTP session.
>
> Anyone have any interest in thinking about this kind of stuff?
>
> Carter
>

Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York  10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090330/70fce56f/attachment.html>


More information about the argus mailing list