Evil Google Ads
Robert sent us some nice analysis earlier today about some hostile ads he discovered at Google. As best we can tell they are gone now, but here are his findings.
Searching for some free templates at google may bring you nasty things you wont have:
http://www.google.com/search?hl=en&q=kostenlose+vorlagen&btnG=Google+Search
Have a look at the first advertising link "Kostenlos-Vorlagen.info"
All files there (all the same) are detected as:
AntiVir 7.4.0.39 07.07.2007 TR/Spy.BZub.JD.1After executing, the malware drops a file named:
F-Secure 6.70.13260.0 07.07.2007 W32/Malware
Ikarus T3.1.1.8 07.07.2007 Trojan-Spy.Win32.Goldun.lw
Kaspersky 4.0.2.24 07.07.2007 Trojan-Spy.Win32.BZub.jd
Microsoft 1.2704 07.07.2007 TrojanDropper:Win32/Small.OT
Norman 5.80.02 07.06.2007 W32/Malware
Sophos 4.19.0 07.06.2007 Mal/Binder-C
Webwasher-Gateway 6.0.1 07.07.2007 Trojan.Spy.BZub.JD.1
C:\WINDOWS\System32\ipv6monl.dllIt hooks as a BHO under CLSID:
HKEY_CLASSES_ROOT\CLSID\{36DBC179-A19F-48F2-B16A-6A3E19B42A87}To do so it looks for activated Brwoser extensions:
\InprocServer32
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\MainIt also ensure that the IE could bypass Windows Firewall:
"Enable Browser Extensions" = yes
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SharedAccessThe Keylogger function checks for banking logins end if recognized it logs this information and send it to a server.
\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications
\List "C:\Program Files\Internet Explorer\IEXPLORE.EXE" = C:\Program
Files\Internet Explorer\IEXPLORE.EXE:*:Enabled:Internet Explorer
Thanks, Robert! Great job of analysis.
Marcus H. Sachs
Director, SANS Internet Storm Center
Yahoo Follow-up
On Friday we reported that there were connectivity issues with Yahoo. Initially we thought that it was a problem either at Yahoo or perhaps inside Verizon's networks based on emails we received. Later we determined that it was not Verizon or Yahoo, but more likely an issue at Level3. Yahoo's official response is here.
The first indication we got that the problem was at Level3 was from a post to the NANOG mailing list showing the output of a traceroute to Yahoo. Here are the last few hops, notice the latency at and beyond Level3:
13 * 70 ms 77 ms ge-0-3-0-69.bbr2.sanjose1.level3.net [4.68.18.2]
14 * 78 ms 71 ms so-14-0.hsa4.sanjose1.level3.net [4.68.114.158]
15 487 ms 449 ms 459 ms hanaro.hsa4.level3.net [4.79.60.22]
16 * * * Request timed out.
17 * * * Request timed out.
18 * 586 ms * te-8-1.bas-a2.sp1.yahoo.com [209.131.32.19]
19 * 570 ms * f1.www.vip.sp1.yahoo.com [209.131.36.158]
20 * * 591 ms f1.www.vip.sp1.yahoo.com [209.131.36.158]
Later, one of our readers found that a BGP peer of Level3 was advertising itself as the best path via San Jose for a large number of routes. The advertisement came from AS9318 (Hanaro Telecom) and caused Yahoo and many other sites that were reached via Level3 to be unavailable for a period of about an hour. As an example, that reader did a route lookup for www.merit.edu (host of the NANOG mailing list) to show that it wasn't just Yahoo that was affected. Here is the output provided to the Internet Storm Center:
BGP routing table entry for 198.108.0.0/14
Bestpath Modifiers: deterministic-med
Paths: (2 available, best #1)
Not advertised to any peer
9318 9318 11164 237, (aggregated by 237 lo0x0.2.nl-chi3.mich.net)
AS-path translation: { APNIC-AS-3-BLOCK APNIC-AS-3-BLOCK WILLINET NSFNETTEST14 }
lo-22.hsa4.SanJose1 (metric 161) from lo-22.err1.SanJose1 (lo-22.err1.SanJose1)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
Community: North_America Lclprf_100 Level3_Customer United_States San_Jose
Originator: hsa4.SanJose1
9318 9318 11164 237, (aggregated by 237 lo0x0.2.nl-chi3.mich.net)
AS-path translation: { APNIC-AS-3-BLOCK APNIC-AS-3-BLOCK WILLINET NSFNETTEST14 }
lo-22.hsa4.SanJose1 (metric 161) from lo-22.err2.SanJose1 (lo-22.err2.SanJose1)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate
Community: North_America Lclprf_100 Level3_Customer United_States San_Jose
Originator: hsa4.SanJose1
If the same query is done now, here is what Level3's looking glass service says for www.merit.edu via San Jose:
BGP routing table entry for 198.108.0.0/14
Bestpath Modifiers: deterministic-med
Paths: (2 available, best #2)
Not advertised to any peer
7911 237 237 237 237
AS-path translation: { WCG NSFNETTEST14 NSFNETTEST14 NSFNETTEST14 NSFNETTEST14 }
lo-22.car4.SanJose1 (metric 141) from lo-22.err2.SanJose1 (lo-22.err2.SanJose1)
Origin IGP, metric 0, localpref 100, valid, internal
Community: North_America Lclprf_100 Level3_Customer United_States San_Jose 7911:777 7911:7705
Originator: car4.SanJose1
7911 237 237 237 237
AS-path translation: { WCG NSFNETTEST14 NSFNETTEST14 NSFNETTEST14 NSFNETTEST14 }
lo-22.car4.SanJose1 (metric 141) from lo-22.err1.SanJose1 (lo-22.err1.SanJose1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: North_America Lclprf_100 Level3_Customer United_States San_Jose 7911:777 7911:7705
Originator: car4.SanJose1
Over at Netcraft, you can see the brief outage by observing the red area on the bottom-right side of this status graphic:
So, bottom line - it wasn't Yahoo having the problems. It was a BGP routing issue that affected reachability of many sites that had routes advertised through Level3. Unfortunately this is one of the Internet's "dirty little secrets" - BGP updates are the lifeblood of the Internet but yet there are many ways these route advertisements can fail. There have been many suggestions for improvement (see the soBGP and S-BGP projects) and even the US Department of Homeland Security has tried to get some traction in making improvements to the routing infrastructure. But the Internet remains vulnerable to these types of configuration errors and intentional false routing advertisements.
Marcus H. Sachs
Director, SANS Internet Storm Center
Fun with Darknets
When I write Darknet, I mean "a portion of routed, allocated IP space in which no active services or servers reside" not "a private virtual network where users connect only to people they trust."
Every environment is different, so you need to use the architecture to your advantage when placing your darknet sensors. At one of my clients', they have a unique full-proxied environment where the desktops do not have direct outbound access to the Internet and all non-proxied Internet-bound traffic ends up on their core-routers where it times-out. By placing a sensor in this loop I can capture all of the traffic initiated from internal clients that is trying to get out to the Internet but is not properly proxied. This means that I see a lot of misconfigured traffic, but it also means I see all of the botnets trying to phone home.
In it's initial stages I only had argus and p0f running on the sensor. The drive would fill up within a week because of the huge amount of misconfigured traffic that was landing on the core-routers, traffic that served no purpose but only to die. This type of traffic was caused by typos in syslog configs which sent firewall logs off to never-never land, or BOOTP requests intended for decommissioned servers, things of that nature. After many weeks of working with operations teams we cleared up a lot of the wasted traffic and can now collect full-packet captures via snort for additional analysis.
An external sensor was placed to listen for traffic intended to an internal-only block of IPs. On this sensor we see what scans are targeting our neighborhood of the Internet, and backscatter from attacks that spoofs our IP space (for some reason, I only see the APAC region targeted this way.)
I've found that no single tool provides all of the information that I need. Argus, with its assumptions about flows, doesn't always render backscatter properly and it's difficult to tell when a scan is targeting our network, or if our IP was spoofed to disguise a scan on another network. Other times, full-packet captures are overkill and p0f logs are all I need to see if a particular scan hit us or not. No single tool satisfies our requirements (no surprise there.) I'm still thinking about what I want to use to synthesize all of these data-sources into a more-complete picture.
As a next step, I'm looking into running snort with a very stripped down rule-set (due to the nature of the Darknet, content-based rules are all but useless) to immediately notify our security staff of suspected internal infections (e.g. a SYN sent to establish an IRC connection to a known-malicious host,) and add some visualization via afterglow to see if that adds any capabilities to the analyst.
The Darknet has been very useful in confirming reports sent to the Handlers. It's paid for itself by helping clean up misconfigured systems and aided in locating unmanaged infected systems on our network. Darknets are also much safer and easier to justify to management than Honeypots. So if you're looking for something fun to do at work, give a Darknet a thought.
----------------------------------------------------------------
Kevin Liston (kliston -at- isc.sans.org)
Comments