[Guest Diary] Distracting the Analyst for Fun and Profit

Published: 2025-09-23. Last Updated: 2025-09-23 12:55:18 UTC
by Jesse La Grew (Version: 1)
0 comment(s)

[This is a Guest Diary by Taylor House, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].]

Distributed denial of service (DDoS) attacks are a type of cyber-attack where the threat actor attempts to disrupt a service by flooding the target with a ton of requests to overload system resources and prevent legitimate traffic from reaching it. From March 31st until April 20th of this year, my honeypot went under a constant barrage of TCP SYN packets over port 443. This post seeks to go over this attack and share observations proving how looks can be deceiving.

In total, this attack sent 2389339 packets from 6039 hosts. The attack came over a series of three waves, with no relation other than the destination port and the flag that was set. A sample was taken from the first of these waves, and each packet was found to have these properties:

  • A total length of 60 bytes.
  • Targeted port 443 using the TCP protocol.
  • Had the SYN flag and no other flags set.
  • Had a window size of 32768.
  • Had a maximum segment size of 1460 bytes.
  • A trailer in the Ethernet header containing 2 bytes of padding.


Figure 1. Wireshark output displaying a sample of packets from wave 1.

 

The First Wave

The first wave occurred from March 31st until April 4th, sending 647069 packets from 743 hosts. The top 10 hosts from this wave were:

Host Number of Packets
103.15.246.198 1030
103.15.247.87 1028
103.15.247.17 1028
103.15.247.111 1028
103.15.245.80 1028
103.15.245.249 1028
103.15.245.239 1028
103.15.245.169 1028
103.15.245.0 1028
103.15.247.93 1027
Total 10281

Figure 2. Top 10 hosts from wave 1 by number of packets sent.

An overwhelming majority of the hosts (86%) were within the IP address range 103.15.245.0-103.15.247.99. Of those hosts, 36 of them had domain name entries. All these hosts are assigned to Summit Communications, an ISP located in Bangladesh. Of those 36 hosts, Shodan intelligence [2] shows multiple possible vulnerabilities due to outdated software such as:

  • dropband[.]summitiig[.]net is running a web server on Apache version 2.4.18 and may be vulnerable to critical vulnerabilities such as buffer overflow attacks and remote code execution attacks that enable attackers to exert direct control over the system through the web server. [3,4]
  • mrtg[.]summitiig[.]net is running an even older version of Apache, version 2.2.15, and may be vulnerable to vulnerabilities such as buffer overflow and reading process memory. [5,6] 

Crafted Packets?

It is possible that this could be the result of a botnet. However, with only a minority of hosts having domain names or clearly exposed services, another possible explanation is the connections were spoofed. The consistent size and attributes of the packets, including window size and maximum segment size, is a sign this might be happening because of packet crafting using a tool like Scapy. Packet crafting is a process for sending fake packets to a target with custom fields. Suppose I craft a packet to send to my loopback address using the following commands. Padding can be any value, since there are two random bytes that can be found at the end of each packet:

packet = IP(src=RandIP(), dst='127.0.0.0')/TCP(sport=RandShort(), dport=443, window=32768, options=[('MSS',1460)])/Padding('\x00\x00')
send(packet, iface=?lo?) #Repeat many times?

What we find on the other side is the following:


Figure 3. Screenshot of the crafted packets captured in Wireshark.

Shockingly similar to the observed activity! This proves that packet crafting may have a role to play in this attack.

The Second Wave

The second wave occurred from April 7th until April 14th, sending 885209 packets from 1054 hosts. The top 10 hosts from this wave were:

Host Number of 
86.105.145.100 8375
86.105.144.104 8373
86.105.145.254 8372
86.105.145.205 8371
86.105.145.135 8371
86.105.145.37 8370
86.105.145.16 8370
86.105.144.83 8370
86.105.144.167 8370
86.105.144.132 8370
Total 83712

Figure 4. Top 10 hosts from wave 2 by number of packets sent.

This wave had both more hosts and each host sent more packets, demonstrating a slight increase in the rate of packets sent. The majority of hosts (60%) were from the IP range 85.194.196.1-85.194.198.99. All these hosts are assigned to ScopeSky, an ISP located in Iraq. CloudFlare reports a spike in Layer 7 attacks sourcing from ScopeSky’s autonomous systems number for the period of this attack, suggesting that many attacks involving the application layer, like web application firewall bypasses and DdoS attacks are coming from this autonomous systems number over the period relative to previous periods [7].

 


Figure 5. Application layer attack volume change relative to the previous period from AS50597: ScopeSky [7].

 

Is this a new botnet?

The chance these are the legitimate sources is low. Given that it makes up a third of the address space assigned to ScopeSky, this would be a major incident for the company and would make the news. This proves that threat actors can spoof their traffic to make it look like it is coming from another source, but an 1800% increase is very unrealistic for it to appear like a legitimate threat.

The Third Wave

The third wave occurred from April 16th until April 20th, sending 857061 packets from 4242 hosts. The top 10 hosts from this wave were:

Host Number of Packets
176.241.82.245 262
176.241.89.194 261
176.241.82.87 261
176.241.87.173 259
176.241.85.61 257
176.241.85.40 256
176.241.84.153 256
176.241.88.35 254
176.241.82.90 254
176.241.91.89 253
Total 2573

Figure 6. Top 10 hosts from wave 3 by number of packets sent.


An overwhelming majority of hosts (96%) came from the ip range 176.241.80.0-176.241.95.99. These ranges are covered by two autonomous systems numbers: AS57588, managed by Hayat for Internet & communication LLC, another ISP in Iraq, and AS57000 LinkiWay DMCC, an Emirati ISP [8,9]. This wave had a lot more hosts, but the number of packets per host were a lot fewer, which may increase the rate of packets being sent, but impacts the overall volume. GreyNoise reports 44 known malicious hosts from this wave [10]. The hosts have been observed doing a variety of suspicious actions such as Telnet/SSH brute forcing attempts, web crawling, default password guessing, and the deployment of various worms such as variants of WannaCry and TrickBot. Looking at Shodan data relevant to the identified ASNs [11,12], There are about 150 systems that have SSH exposed externally, a very poor security practice. The known malicious systems may have been brute forced by the threat actor to gain more systems under their control. Combined with spoofing, this may explain why the total host count is so high relative to the other waves.

Is this really a DDoS?

While the honeypot received a total of 2389339 packets, this is likely not enough to interrupt a modern service. For DDoS attacks, they are usually represented by the number of packets (or requests when speaking in terms of HTTP) per second. CloudFlare reported that they mitigated a DDoS attack operating at over 71 million requests per second [13]. In this attack, the packet volume was not nearly that high, and the sample we collected from the first wave only achieved 12.1 packets per second.



Figure 7. Average packets per second from the packet capture.

 

Even if the rate picked up significantly in the third wave since the number of hosts were higher, it would not ever reach a high enough speed to have a good chance at taking down a service. So, what was the point of this attack if it was not to shut down services? While SYN flags can be used to scan a network for open ports (listening ports would respond with a SYN-ACK), this was a spike relative to my usual traffic, it is unlikely that so many hosts decided to scan the honeypot at the same time.

 


Figure 8. Number of packets received by the honeypot from April 14th to July 14th.

 

There are also tools like nmap that can perform SYN scans with the -sS option, but the packets do not have the same properties as our sample data:


Figure 9. Wireshark capture of a nmap SYN scan. Note the window size and length.

 

In summary, if this was a DDoS, it is very unlikely to be effective on any modern system. A scan using TCP SYN flags is also very unlikely, leaving few explanations for this attack.

Lessons Learned

We can draw a few conclusions from analyzing each wave of this attack. First, packet crafting may have been in use to mask the attacker’s real IP address, Secondly, a legitimate SYN flood attack seems very unlikely here, since the packet volume and rate were both far too low. Finally, traffic came from unlikely sources without making the news or showing up on threat intelligence aside from a very small minority of traffic, strongly indicating that the traffic is not legitimate.

Another possibility is that all of this traffic was a smokescreen for another attack. An analyst can waste a lot of time looking at network logs that seem related while the real attack may be taking place using another method that seems unrelated. The demonstration of Scapy shows that it is quite easy to spoof network traffic and send it to a target host to create very noisy network logs. You could even create a list of IP addresses like the hosts found in the waves to create the light correlations described in my findings. In short, this makes an excellent distraction. As for what the plan for attack was, the honeypot did not log any attacks of significance, other than what is typical of the daily traffic. On April 1st, there were some hosts that were also logged in the first wave attempting to access the following URLs from the web honeypot:

  • /
  • /.git/config
  • /.git/index
  • /.env

To wrap up, the packet volume was not enough for this attack to be considered an effective DDoS attack, it also does not seem to be an access attack on web services, but the small SYN flood made an excellent distraction if the threat actor wished to perform a more complex attack. Understanding what volume a SYN flood becomes a threat is important to avoid getting caught in a distraction as an analyst. 
 

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://hunter.how/list?searchValue=domain%3D%22summitiig.net%22
[3] https://nvd.nist.gov/vuln/detail/CVE-2021-44790
[4] https://nvd.nist.gov/vuln/detail/CVE-2019-0211
[5] https://nvd.nist.gov/vuln/detail/CVE-2011-3607
[6] https://nvd.nist.gov/vuln/detail/CVE-2017-9798
[7] https://radar.cloudflare.com/security/application-layer/as50597?dateRange=24w
[8] https://ipinfo.io/AS57588
[9] https://ipinfo.io/AS57000
[10] https://viz.greynoise.io/analysis/5f16d7a0-5fd5-4491-a618-b52c1ee16266
[11] https://hunter.how/list?searchValue=%20as.number%3D%3D%2257588%22
[12] https://hunter.how/list?searchValue=as.number%253D%253D%2257000%22
[13] https://blog.cloudflare.com/cloudflare-mitigates-record-breaking-71-million-request-per-second-ddos-attack/

---
Taylor House
Apprentice Handler, Internet Storm Center

0 comment(s)

Comments


Diary Archives