SANS ISC: Google DNS Server IP Address Spoofed for SNMP reflective Attacks

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

I started seeing these at 2014-09-14 21:35 UTC. I see one probe about every 20 minutes in numerical order to a class C, starting with .1. I don't have any packet captures, though, just firewall logs.

Update: These scans against my network stopped at 2014-09-16 09:06 UTC. The scan made it to .113 and then just quit.

JimC

We started seeing these at 16:36 (CDT) yesterday. Pattern is same as JimC: one hit on a single IP every 20 minutes, working thru our class C in sequence. no packet-caps.

It appears someone is trying to brick devices, not conduct a reflection attack. We are also seeing our entire IP range hit. For each class C range the IP address being targeted increments by 1 every 20 minutes. They are attempting to set ipDefaultTTL to 1 and ipForwarding to 2 (not forwarding), using a community string of "private".

Yes I also noticed this activity from 8.8.8.8 against our perimeter over the weekend. Our IPS blocked all attempts as we don't allow ingress SNMP. I was wondering what was going on with Google's DNS @ 8.8.8.8 so this post has been informative for me. Thanks.

Hi

We see this traffic too.

Best, Daniel

A /16 here. Judging from our logs, the attacker is incrementing the third octet of the address before the fourth. Attacks are coming in approximately one every 4 seconds which is approximately 17 minutes before the fourth octet is incremented.

Attacks appear to have started @ 2014-09-14T21:28:07+00:00

Confirm, but got only flows. Unfortunately this farming will produce results... (dst ips omitted)

Date first seen Duration Proto IP Addr Flows(%) Packets(%) Bytes(%) pps bps bpp
2014-09-15 08:07:36.387 13324.545 any 8.8.8.8 3986(100.0) 3986(100.0) 346782(100.0) 0 208 87

Duration Proto Src IP Addr:Port Dst Port Packets Bytes Flows
08:16:46.046 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:16:46.027 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:16:50.443 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:16:54.926 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:16:59.337 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:16:59.386 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:03.818 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:08.233 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:12.718 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:17.158 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:12.520 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:17.135 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:21.614 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:35.628 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:40.039 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:43.954 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:40.090 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:50.396 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:48.924 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1
08:17:53.296 0.000 UDP 8.8.8.8:47074 -> 161 1 87 1

Just noticed something in the flows, it scanned our network but instead of scannig a full /24 host by host it scans a /32 in blocks of /24 in the same minute, check (a way of avoiding some auto measures...)

Dst IP Addr:Port
xx.yy.0.32:161
xx.yy.0.32:161
xx.yy.1.32:161
xx.yy.2.32:161
xx.yy.3.32:161
xx.yy.3.32:161
xx.yy.4.32:161
xx.yy.5.32:161
xx.yy.6.32:161
xx.yy.7.32:161
xx.yy.6.32:161
xx.yy.7.32:161
xx.yy.8.32:161
xx.yy.9.32:161
xx.yy.10.32:161
xx.yy.11.32:161
xx.yy.12.32:161
xx.yy.13.32:161
xx.yy.12.32:161
xx.yy.14.32:161
xx.yy.15.32:161

Only saw one request in the past week from 8.8.8.8 to port 161. Approx 10:00AM AEST today. Not seeing the repeat requests like the others though.

Quoting Pavel:Just noticed something in the flows, it scanned our network but instead of scannig a full /24 host by host it scans a /32 in blocks of /24 in the same minute, check (a way of avoiding some auto measures...)

Dst IP Addr:Port
xx.yy.0.32:161
xx.yy.0.32:161
xx.yy.1.32:161
xx.yy.2.32:161
xx.yy.3.32:161
xx.yy.3.32:161
xx.yy.4.32:161
xx.yy.5.32:161
xx.yy.6.32:161
xx.yy.7.32:161
xx.yy.6.32:161
xx.yy.7.32:161
xx.yy.8.32:161
xx.yy.9.32:161
xx.yy.10.32:161
xx.yy.11.32:161
xx.yy.12.32:161
xx.yy.13.32:161
xx.yy.12.32:161
xx.yy.14.32:161
xx.yy.15.32:161

exactly the same at ours.

At the moment we don't see such traffic on our boxes.

Since one hour I see the same request as from 8.8.8.8 from other IP addresses on multiple devices around the world.
All are from source port 40000

Example 1: 66.240.236.119
Example 2: 204.42.253.130
Example 3: 71.6.135.131
Example 4: 71.6.165.200

Best, Daniel

Now it comes from "184.105.139.67 - shadowserver.org"

These were active today to 10:37.
80.168.248.89.in-addr.arpa domain name pointer b10s03.ecatel.net.
67.139.105.184.in-addr.arpa is an alias for 67.64-26.139.105.184.in-addr.arpa.
67.64-26.139.105.184.in-addr.arpa domain name pointer scan-01.shadowserver.org.
109.227.3.31.in-addr.arpa domain name pointer h31-3-227-109.host.redstation.co.uk.

Rgds
Jan

It does look like this actor has started spoofing various source IPs now. We have always has many probes to SNMP so I wonder how long this particular attack has been going on.

Just had 8.8.8.8 show up in our firewall logs today. Hasn't been reported for a while:

*Port Scan* detected from 8.8.8.8 (US/United States/google-public-dns-a.google.com). 21 hits in the last 161 seconds

It was followed immediately by another port scan by 134.174.21.190 (US/United States/chb-external1.tch.harvard.edu). 21 hits in the last 161 seconds