DDoS site attack through social engineering

Started by john45, Sep 02, 2022, 04:43 AM

Previous topic - Next topic

john45Topic starter

The attacker replaces the source ip with the address of your server and triggers automatic abuses. As a result, the client is banned from the hosting for malicious activity that was not there.
The insidiousness lies in the fact that no attack is performed on the victim's server itself. Instead, the attacker provokes the operation of third-party intrusion detection systems, forcing them to generate completely real complaints (in the common people "abuses") against your server.

From the hosting provider's point of view, it looks like you are engaged in malicious activity, although in fact that is not true. It turned out that many large hosting providers are not ready to deeply understand the causes of the problem and would rather just ban you for breaking the rules.

I kept several personal projects on VPS servers from a well-known host. Once I received a letter from him, in which the hosting provider sends me a complaint received on his abuse@ mailbox, and insistently asks me to stop malicious activity, otherwise I will be blocked.
The attached log shows a list of TCP connections to port 80 (HTTP) in the SYN RECEIVED state. That is, there is a SYN flood from my server to someone's web server.

My first thought is that I was hаcked and there is a SYN flood coming from my server. Linux has restrictions on managing sockets with normal user rights and sending only SYN packets (without establishing a full TCP connection) can only be done with root privileges. Which means it's completely hаcked.

In a panic, I run to the server to look for a malicious process. I check top, ss, lsof and see nothing suspicious. Primary conclusion: "horror, they probably uploaded such a cool rootkit that hides the virus at the kernel level from all system utilities!". In the process of research, it turns out that the load on the server has not changed in any way, according to the graphs in the hosting provider's panel, the traffic on the interface remains the same.
Before that, I ran tcpdump with filters showing outgoing traffic, and did not see anything suspicious. Desperate, I decide to look at all the traffic to the server. In the flow of legitimate traffic, I find rare RST packets from strange servers.

It looks something like this, where my-server-ip-xx-xхx is the address of my server:

IP > my-server-ip-xx-xхx.8389: Flags [R]
IP > my-server-ip-xx-xхx.8389: Flags [R]
IP > my-server-ip-xx-xхx.8389: Flags [R]
IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xхx.8389: Flags [R]
IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xхx.8389: Flags [R]
IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xхx.8389: Flags [R]

It was obvious that that was an anomaly, since there was no other exchange with these servers, and why they send a connection close packet was not clear to me.
At that point, experienced admins would immediately understand everything, but we will analyze everything on our fingers

How it works

Incoming RST packets are responses to attempts to establish a TCP connection on a closed port. At the same time, there is no outgoing traffic from my server towards the servers that send RST. This means that the attacker replaces the outgoing address with mine and generates traffic similar to a DDoS attack. But since the only thing an attacker can do is send an outgoing packet, all responses from servers go to my server.

Only responses to fake requests reach the victim's server

    Typically, such attacks are used for DNS amplification, when the attacker sends a small request on behalf of the victim, and the victim receives a large response that he did not request. This is a classic channel exhaustion attack mechanism.

In my case, the attacker did not set out to exhaust the channel of the victim server. His activity was completely invisible on the channel's consumption charts. Its main purpose was to provoke automatic notification systems about network attacks, which would send a letter with a complaint to the abuse address specified in the whois of my provider's subnet. Intrusive Prevent/Detect System such as Snort and Suricata can do this.

As a result, the hosting provider receives an absolutely real letter from legitimate companies, which contains a complaint about my malicious activity, and even the logs in them are real. At the same time, the attacker does not need a large channel, since he knows in advance the addresses of the servers on which IDS / IPS systems are installed and the minimum number of packets required for an automatic complaint to work.

The only difficulty for an attacker is to find a server that allows spoofing of outgoing IP addresses in packets. All normal hosting providers block such packets. There are only two types of hosting that allows customers to change the outgoing IP: either very illiterately configured, or specially created for cybercrime.

Checking the possibility of IP address spoofing

I advise you to check your hosting provider for the possibility of changing the outgoing IP. that will require two servers, one for receiving traffic, the other for sending.
On the side of the receiving server, let's start logging incoming traffic. As a filter, we specify a rare port on which there should be no traffic during normal times:

tcpdump -i any port 9912

On the server being checked, we will generate a packet with the outgoing IP address changed to, directed to port 9912. To do this, we use the cool nping utility from the nmap developers. It allows you to generate any non-standard packets at the L2 and L3 levels.

nping --tcp -p 9912 -S receiver-server.com

receiver-server.com - address of the listening server running tcpdump - spoofed outgoing address
9912 - remote port

If on the side of receiver-server.com you see a packet coming on behalf of, then your provider allows you to change the outgoing IP address. This is an occasion to inform him about problems in setting up network equipment. Often that problem affects home Internet providers.

Stupid tech support

Having figured out the reasons for the complaints, I detailed everything to the hoster:

    I finally understand what happened.

    They spoof my IP address and DDoS random hosts using my address as source address. So victims generate automatic abuse reports to my hosting providers.

    You can see on abuse log that connections are only in SYN_RECV state (no full TCP-connection established) because they can send only one packet using spoofed IP and can't finish TCP-handshake.
    I can prove that . There are many TCP RST incoming packets coming right now to my server from hosts whom I never sent any packets.

    You can check it right now by running:

    tcpdump -i eth0 "tcp[tcpflags] & (tcp-rst) != 0"

    You will see that many RST packets came from hosts to which I've never sent any data.
    This proves that the attacker is spoofing my IP address to compromise me and generate abuses.

Then it seemed to me that any qualified technical support engineer would understand the situation and the issue would be closed. But instead they demanded that I check the server with an antivirus or completely reinstall the OS. While we corresponded with technical support, the abuses continued to arrive and a day later I was banned.

It was wildly insulting that I was actually framed. This situation shows how vulnerable people are, who, instead of understanding, mindlessly follow scripts. Since then, I often cite that case as an instance when a dispute comes over the choice of hosting for important projects.
So, many hosts simply cannot afford to devote much time to non-standard cases of small clients and it is easier to ban you than to understand your problems.


The problem that is raised in the topic is that hosting providers are essentially being misled. No fake packets reach the target server itself. It's just about letters.
I am not discussing who is to blame for the possibility of IP spoofing, but only outraged this fake complaints can get you banned, and that these fake complaints are so easy to provoke.

Formally, this is the problem of who you have an agreement with. So. if you get disconnected because they think your activity is sabotage, and it turns out that they relied on the wrong conclusions of their automation tools, then they actually fall into compensation payments due to a violation of the service agreement.


I came across a similar meanness: the guys launched the project and even before the announcement, competitors found out about it and launched a spam mailing list mentioning the domain and substituting it in from.
As a result, even before the start of the project, all mailers marked it as spam. The name had to be changed.

It was necessary to configure SPF, DKIM and DMARC records in DNS immediately after domain name registration.
Competitors, most likely, have nothing to do with anything at all — just someone's spam bot found a domain suitable from his point of view and took it into circulation.