[Emerging-Sigs] Proposed Signature for Trojan.Gatak

Christopher Granger chrisgrangerx at gmail.com
Fri Dec 14 08:15:12 HAST 2012


I thought I'd share a few additional details, FWTW. The majority of traffic
being eval'd by this regex is standard web traffic over 80/TCP, and A LOT
of it has been eval'd from many different orgs at this point ... I'm sure
the regex could be tightened up, and I expected to have to do some
maintenance along these lines, but somewhat surprisingly, that hasn't been
necessary -- we've had a zero FP rate w/ the slightly less strict regex &
no port conditions. However, using the $HTTP_PORTS var instead of 443
should provide internal infection -> internal proxy:80/TCP (et al.)
visibility, for sensors w/ open $HOME_NET vars. It probably goes w/o saying
that having alerts at this layer of the traffics' egress usually makes for
more readily actionable alerts, that contain actual infected host IPs vs.
their NAT'd addresses

On Wed, Dec 12, 2012 at 11:20 PM, Christopher Granger <
chrisgrangerx at gmail.com> wrote:

> Hi Will,
>
> No worries at all, thanks! It's the same regex as in the rule, but without
> a ^ line break match :)
>
>
> On Wed, Dec 12, 2012 at 10:35 PM, Will Metcalf <
> wmetcalf at emergingthreatspro.com> wrote:
>
>> Will dig into this tomorrow from our end.   Sorry about the delay. Can
>> you share the regex your using?
>>
>> Regards,
>>
>> Will
>>
>> On Dec 12, 2012, at 4:54 PM, Christopher Granger <chrisgrangerx at gmail.com>
>> wrote:
>>
>> We have been using less specifically targeted regex monitoring of proxy
>> logs to great effect since I first emailed about this -- no FPs and a
>> surprising number of infections detected.
>>
>> On Sun, Dec 9, 2012 at 10:39 PM, Christopher Granger <
>> chrisgrangerx at gmail.com> wrote:
>>
>>> Hi Martin,
>>>
>>> The write-up addresses an older version which may or may not still be
>>> active - it's one of a small number of public references I could find. The
>>> requests were captured on NIDS SSL/TLS anomaly alerts on traffic to known
>>> controllers. I have only seen the two strings included in the rule &
>>> non-public reports corroborate just the two, but I'm not against expanding
>>> coverage if FPs aren't an issue.
>>>
>>> I think some of the IPs in the reference may still be active, but I
>>> haven't confirmed this. I'll send any additional info I'm able to.
>>>
>>> Thanks,
>>> -Chris
>>>
>>>
>>> On Sun, Dec 9, 2012 at 9:48 PM, Martin Holste <mcholste at gmail.com>wrote:
>>>
>>>> Where did you get those example requests from?  They don't match the
>>>> writeup from Symantec.  Also, I would assume that "gulfstream" would be in
>>>> there at some point, so if you're sure about that style of request, then I
>>>> would swap [oa] with . in the pcre.
>>>>
>>>>
>>>>
>>>> On Sun, Dec 9, 2012 at 8:33 PM, Joel Esler <jesler at sourcefire.com>wrote:
>>>>
>>>>> That won't work unless you have 443 in http_inspects config.
>>>>>
>>>>> Just FYI.
>>>>>
>>>>> --
>>>>> *Joel Esler*
>>>>> Senior Research Engineer, VRT
>>>>> OpenSource Community Manager
>>>>> Sourcefire
>>>>>
>>>>> On Dec 9, 2012, at 8:57 PM, Christopher Granger <
>>>>> chrisgrangerx at gmail.com> wrote:
>>>>>
>>>>> Hi ET,
>>>>>
>>>>> Trojan.Gatak is a Trojan that allows backdoor access. Some versions
>>>>> are able to spread via shared resources.
>>>>>
>>>>> The Trojan uses 443/TCP for C&C but sessions are not SSL/TLS
>>>>> encrypted.
>>>>>
>>>>> Example requests:
>>>>> /galfstream&tmmkmmgat=08PV2nvuCDUN77pF03rJN9E5B**fvjZmKGCmEnpe
>>>>> /galfstream&xcrvekhyx=ZJRWYZFTYdty0IFmK_nSHiT0JDY4AGgj
>>>>> /golfstream&qnpvh=wwld8vWuk34v7HPnmR6q1_EquRg19qHFesHlAhj0LXlBW8m72dnz
>>>>>
>>>>>
>>>>> Proposed rule:
>>>>> alert tcp $HOME_NET any -> $EXTERNAL_NET 443 (msg:"ET TROJAN Gatak
>>>>> POST Request to C&C"; flow:established,to_server; content:"POST"; nocase;
>>>>> http_method; content:"lfstream&"; nocase; http_uri; depth:12;
>>>>> pcre:"/\/g[oa]lfstream&/UAi"; reference:
>>>>> http://www.symantec.com/security_response/writeup.jsp?docid=2012-012813-0854-99;
>>>>> classtype:trojan-activity; sid:XXXXXXX; rev:1;)
>>>>>
>>>>> Regards,
>>>>> -Chris
>>>>> _______________________________________________
>>>>> Emerging-sigs mailing list
>>>>> Emerging-sigs at lists.emergingthreats.net
>>>>> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>>>>
>>>>> Support Emerging Threats! Subscribe to Emerging Threats Pro
>>>>> http://www.emergingthreatspro.com
>>>>> The ONLY place to get complete premium rulesets for Snort 2.4.0
>>>>> through Current!
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Emerging-sigs mailing list
>>>>> Emerging-sigs at lists.emergingthreats.net
>>>>> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>>>>
>>>>> Support Emerging Threats! Subscribe to Emerging Threats Pro
>>>>> http://www.emergingthreatspro.com
>>>>> The ONLY place to get complete premium rulesets for Snort 2.4.0
>>>>> through Current!
>>>>>
>>>>
>>>>
>>>
>> _______________________________________________
>> Emerging-sigs mailing list
>> Emerging-sigs at lists.emergingthreats.net
>> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>
>> Support Emerging Threats! Subscribe to Emerging Threats Pro
>> http://www.emergingthreatspro.com
>> The ONLY place to get complete premium rulesets for Snort 2.4.0 through
>> Current!
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.emergingthreats.net/pipermail/emerging-sigs/attachments/20121214/b2255c6d/attachment-0001.html>


More information about the Emerging-sigs mailing list