Justin C alerted me in our Slack channel that GreyNoise, a commercial system similar to DShield, noted a large increase in the number of sources scanning. We do have these “Spikes” from time to time and had one for the last two days. Artifacts are usually not lasting that long, and we also did not have a notable change in the number of submitters. So I took a quick look at the data, and here is what I found:
Looking at the top /8 Networks also shows an interesting anomaly (each table cell contains the /8 followed by the number of sources from that /8):
|Jan 2nd||Jan 3rd||Jan 4th|
|103/8 (6666)||103/8 (181969)||103/8 (308602)|
|36/8 (5620)||167/8 (24761)||187/8 (5633)|
|187/8 (5601)||177/8 (5857)||177/8 (5262)|
|177/8 (5365)||187/8 (5847)||14/8 (4903)|
|14/8 (4908)||36/8 (5783)||189/8 (4864)|
|189/8 (4796)||14/8 (5539)||190/8 (4703)|
|113/8 (4731)||189/8 (5382)||36/8 (4501)|
|190/8 (4237)||190/8 (4846)||113/8 (4323)|
|200/8 (3875)||113/8 (4805)||185/8 (4113)|
|185/8 (3618)||117/8 (4057)||5/8 (3872)|
Scans from 103/8 pretty much explain the increase in sources we had over the last few days. There was also a notable increase for 167/8 on the 3rd, but it was nowhere as significant as the increase for 103/8. Now we can “zoom” in on the reports from 103/8 and look at how they compare to the rest of our reports. I ran this data across all three days:
|22 (182,710)||445 (140,056)|
|23 (170,000)||23 (117,595)|
|80 (35,102)||80 (73,071)|
|7547 (29,649)||8080 (69,167)|
|443 (23492)||22 (33,520)|
The big anomaly is port 22 and 23 here. It looks like the 103/8 network prefers to scan these two ports. Of course, these are popular ports in general.
Now, if they are scanning port 22 and 23, then we should see them in our cowrie honeypots if they are trying to log in.
Let’s look at the number of source IPs from Cowrie logs:
|All Sources||103/8 Sources|
So no increase in login attempts and 103/8 is unremarkable. Having no logins from 103/8 could indicate that the purpose of these scans is to either find open ports or the scans are spoofed. To investigate further, I plotted the 2nd Byte of the IP address for all 103/8 sources
The distribution is pretty “random” with a dip from about 150-190. The unassigned /16 in this netblock (in addition to smaller blocks) 103.128/16, still had 1,174 sources contributing to these scans. All of these scans are from January 3rd and 4th. Our sensors detected nothing from 103.128/16 on January 2nd. So this is a pretty good hint that the scans are spoofed.
What is special about 103/8? This netblock was the last /8 assigned to APNIC from IANA. It was assigned to APNIC on Feb 2011, and assignments from 103/8 have been made to ISPs all over Asia.
Why would someone run a large spoofed scan like this? Not clear. It could be an experiment, a bug, or an attempt to hide the actual scan. I will look into this in more detail tomorrow. This may be a new “Mirai” style botnet that tries to do something a bit different, but . of course, we won’t get the respective malware from 103/8 if these scans are spoofed. Usually, “decoy scans” that include spoofed packets, in addition to real packets tend to be a waste of time for these simple internet-wide scans. If anything, they increase the noise and make it more likely that the scan is discovered. The scanning system is usually better off using these resources for actual scans. One of the “breakthroughs” of MIrai was its scanning speed after all. It may be notable that the scans started on 01/03, and the spoofed IPs are ‘103’. But not sure if this means anything.
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.