Tarzok wrote: Wed Sep 09, 2026 4:58 pm
Hey,
So, in the other, now closed thread, 'DDoS Round 12,' it came up that the IP to authenticate might be compromised.
This link was posted:
https://www.abuseipdb.com/check/185.165.170.59?page=1
I got no clue about stuff like that, can someone with some knowledge explain what this means ?
Is it still safe to connect ?
I asked AI (i know i know) and it said, among other things:
"A private game server should never autonomously scan third-party servers on the internet or launch brute-force attacks. If this happens, a third party has obtained root access or deployed malicious code on the machine."
Can someone shed some light on this?
This does not automatically mean the server is malicious or scanning people. If you look at the history on abuseipdb the 185.165.170.59 suddenly (starting 07.09 11:20 following to 09.09 ) got 92 reports from 51 different sources. Mostly reported for TCP port scanning / probing activity with some logs specificaly stating SYN Scanning, ACK Scan like traffic or RST behavior. Keep in mind that things reported to abuseipdb service are
not verified (there are some automatic filters on the reports but still). So if we see that OctoWoW server was reported for PortScan or Hacking etc. it doesnt mean it was performing the actual attack but its action/behavior was classified as such by some system/firewall - just like when you try to load DLL to game client and your firewall goes crazy when in fact its safe.
TCP/IP Packet has strictly defined structure. For us here most important fields will be:
SPT (Source Port), DPT (Destination Port), SRC (Source Address), DST (Destination Address), TTL (Time-to-live)
Simply put TCP Connection is established by 3 way handshake:
Client to Server - SYN (ask Server for connection)
Server to Client - SYN/ACK (acknowledge and ask Client to accept)
Client to Server - ACK (acknowledge Server connection)
Properly terminated TCP connection follows 4 way handshake:
Client to Server - FIN
Server to Client - ACK
Server to Client - FIN
Client to Server - ACK
Sudden connection break sends RST (TCP Reset)
Now looking back at absueipdb report we see TCP port scanning / probing by:
SYN Scan - Attempt to establish connection on random ports. Used to scan open/closed ports and check if firewall filters on that port.
ACK Scan - Used to scan firewall rules or if its filtered at all. If random ACK without SYN will receive instant RST it opens other paths to analyze.
RST Behavior - abnormal number of RST responses
=================================================
So having that knowledge we can analyze logs from abuseipdb and what we can see is:
1. Source Address - is indeed 185.165.170.59
2. Destination Address - is absolutely random
3. Source Port - this is interesting because port 8091 (N'zoth) keeps repeating however very often the source port is just random like 45881, 18612, 38735, 12370, 42949 and many more. Which is very sus.
4. Destination Port - this is also sus cause mostly destination ports are random however 8091 port keeps repetaing. Coincidence? I dont think so.
5. TTL - this number is the limiter of how many 'jumps' betwen server one packet can perform until its dropped. Most of the time one system has one unified TTL number i.e defaults are 64 (linux based), 128 (windows based), 255 (routers etc.). However this number can be changed system wise but not after the packet was sent (unless it was dropped and recreated or forged). On the abuseipdb we can see 3 different TTL range which is some trace to think of.
Finally what we can conclude out of this?
One possible explanation is that traffic was spoofed, scan like ACK/SYN traffic which means the attacker forge Source Address 185.165.170.59 and send such packets to X random machines around the world. The machine which receive such packet sees it as it was sent from 185.165.170.59:SourcePort so it replies exactly there.
Which results with DDoS on Server (with SPT 8091) and FlokiNet infrastructure (with random ports)
You can see here
Fortinet Article that you just provide target port and botnet use templating for forging packets. I can only assume that due to templating its likely that source 8091 port can appear also in destination port, when you look at the logs whenever source port was different than 8091 then 8091 appeared as destination port which explains point 3 and 4. Packets are also forged with different TTL.
Bonus:
If you go to
https://horizon.netscout.com/ during huge DDoS waves you can very often see the attack performed on Iceland. For example i made screenshot of one report which had
Code: Select all
Start: 2026-09-08 23:33:45 GMT
Attack type:
TCP RST / TCP SYN/ACK Amplification
Destination ports:
80
249
496
1764
2119
2982
3372
3500
3724
4096
Sources:
BR, CN, DE, DK, FI + 18 other countries
We can see 3724 port which is login port. It doesn't mean it was exactly targeted at Octo server cause we dont have the IP however the timing checks out with servers being down and with abuseipdb logs. The attack type reported by netscout is different than what was mostly reported on abuseipdb. It checksout with what Kestrel reported that attackers started adapting to mitigation changes and shape of attacks also changed. The reflection attack reported by netscout TCP SYN/ACK Amplification would could fit significant amount of reports on abueipdb. We could feel that cause before that we could login and more or less often just get DC but somehoiw play. Past few days servers were completely down.
Sorry for long post but i had no idea how to explain it in a shorter way. I hope it somehow makes it more understandable and brings you some peace
Just for the record - i can't say with 100% certainty that it is exactly what happend since i don't have the actual logs but only logs from absueipdb/netscout/forum info and my own observations. I can say that there is too many pieces pointing at spoofed traffic for me to believe that OctoWoW suddenly out of nowhere started scanning not only users but also random servers around the world while dealing with continuus DDoS waves. This doesn't checks out
Cheers