[Emerging-Sigs] Proposed Signature for Trojan.Gatak

Christopher Granger chrisgrangerx at gmail.com
Fri Dec 14 08:34:29 HAST 2012


This information is still relevant (
https://community.mcafee.com/message/249627):

It appears to be what Symantec and others dub Trojan.Gatak
(link<https://sa-live.com/l?v=0&ui=0&p=000c00000000000000000000400000000000&spid=mcafee-forums&url=-+7878782f747a6e626f7566642f64706e/security_response%2Fwriteup.jsp%3Fdocid%3D2012-012813-0854-99%26tabid%3D2%26API1%3D100%26API2%3D4485850>),
however only limited information on this appears to have made its way
online.  First instance, the variant that we saw uses tcp/443 for C&C.  The
infected files are googletalk.exe, Skype.exe, and AdVantage.exe all located
in %UserProfile%\Application Data\%Foldername%.  Startup registry keys
similar to those in the Symantec article were created for each.  C&C IPs
are 178.162.182.60, 82.80.231.51, and one additional that I don't have
documented.  All C&C traffic is clear text over tcp/443.  All C&C servers
appear to be compromised web servers."

Hopefully this helps!

Thanks,
-Chris

On Fri, Dec 14, 2012 at 1:24 PM, Will Metcalf <william.metcalf at gmail.com>wrote:

> Not seeing any of this either... :(  If you have pcaps and/or ip's you
> can share would be helpful.
>
> Regards,
>
> Will
>
> On Fri, Dec 14, 2012 at 12:22 PM, Martin Holste <mcholste at gmail.com>
> wrote:
> > I'm not seeing any URI's containing either galfstream or golfstream.
> > Normally when there's a popular check-in out there, we're big enough
> that we
> > get a hit or two, but none so far.  Can you share an IP list either
> publicly
> > or privately so I can validate we are really not getting hits?
> >
> >
> >
> > On Fri, Dec 14, 2012 at 12:15 PM, Christopher Granger
> > <chrisgrangerx at gmail.com> wrote:
> >>
> >> 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!
> >>>
> >>>
> >>
> >
> >
> > _______________________________________________
> > 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/29ad861a/attachment.html>


More information about the Emerging-sigs mailing list