In short: Whether it is a DDoS or a hack shows in the traces. A DDoS generates a very large number of requests and makes the website slow or unreachable but changes nothing. An exploit often needs only a few requests and leaves new files, accounts, processes or connections. The right classification decides whether you have to fend off load or contain an incident.
The difference in plain words
A DDoS attack (distributed denial of service) is like a crowd blocking the entrance to a shop. Nobody gets in, but nothing is stolen inside. The aim is to overload your website or server so that real customers can no longer get through.
An exploit, by contrast, is a break-in through an open door. The attacker uses a weakness, for example in PHP, in the CMS or in an extension, to execute code on your server. This can happen quietly, without the website becoming slower. The consequences range from spam pages through data theft to the takeover of the server.
For management the difference is decisive: a DDoS is an availability problem that ends with the attack. A successful exploit is a security incident that stays until it has been found, cleaned up and documented.
DDoS or hack: the signs compared
The following table helps with the first classification. It does not replace an analysis but shows where to look first.
| Characteristic | More likely DDoS | More likely exploit or break-in |
|---|---|---|
| Availability | slow or down | often normal |
| Requests in the log | very many, often uniform | few, targeted requests |
| Files | unchanged | new or modified PHP files |
| Accounts | unchanged | new admins, changed passwords |
| Processes | web server and PHP under full load | unknown processes, mining, spam sending |
| Network | a lot of incoming traffic | unusual outgoing connections |
| After the end | everything as before | traces remain |
Beware of overlaps: mass scanning for a vulnerability can look like a small DDoS. That is exactly what was to be expected around PHP2Shell, when attackers were searching for vulnerable servers. High load can therefore also mean that someone is trying to break in right now.
First checks on the server
The following commands change nothing on the system and give a quick overview. If you suspect a break-in, secure the logs before making larger interventions.
# Load and uptime
uptime
# Connections summarised and the most frequent peers
ss -s
ss -tn state established | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
# Most frequent client addresses in the access log (adjust path)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# PHP files modified in the last 7 days
find /var/www -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Processes with the highest CPU load
ps aux --sort=-%cpu | head -15
In the connection overview, the fourth column shows the peer. Many connections from few addresses, or a rise to a multiple of the normal value, point to overload. New PHP files in upload or cache directories, processes under the web server user with foreign names, or outgoing connections to unknown destinations point more towards a break-in. A detailed list is at Signs of compromise after PHP2Shell.
Why high load can also be a diversion
It happens that attackers create an overload while at the same time breaking in in a targeted way. The team is then busy with availability, and the actual traces get lost in the log noise. Therefore: even if a DDoS is obvious, check files, accounts and outgoing connections after it ends.
In the case of PHP2Shell, there is the further point that, according to php.net and the security firms, there are no published, confirmed indicators of compromise. Detection relies on behavioural analysis. A server that was unpatched during the scanning period from mid-October should therefore be checked regardless of the load observed.
Another variant is extortion emails threatening a DDoS attack unless payment is made. Keep such messages, do not pay without consulting specialists, and consider a report to the Central Contact Point for Cybercrime. In parallel, inform your hosting provider so that protective measures can be prepared. How to analyse the logs for this is in the guide Analysing web server logs after an attack.
What to do in the first hours
If you suspect a DDoS:
- Inform the hosting provider or data centre; they often have filters in front of the server.
- Activate or tighten an upstream protection service or a WAF with virtual patching.
- Set rate limits in the web server and protect expensive pages such as search or shopping cart in particular.
- Keep logs so that the attack can be traced later.
If you suspect a break-in:
- Delete nothing and do not rebuild the server before logs and affected files are secured.
- Update PHP to a fixed version and restart all workers, if that has not yet happened.
- If the update is not immediately possible, take the website offline temporarily, as the BSI recommends.
- Renew credentials from a clean device, not from the possibly affected server.
- Have it checked whether personal data could be affected; reporting deadlines may then be running.
In both cases, a short, factual note for the hosting provider and service providers helps: since when the problem has existed, which websites are affected, what you have observed and what has already been changed. Also record who made which decision. This timeline saves time in the analysis and is valuable later for insurance, data protection and internal follow-up. If it is unclear whether there is an attack at all, treat the situation as an incident as a precaution until the opposite is shown.
How does PHP SOS help?
- We classify the situation remotely based on load, logs, files and connections and tell you what you are probably dealing with.
- In case of overload, we set filters, rate limits and upstream protection rules until the attack subsides.
- If a break-in is suspected, we take over structured incident response: secure, contain, find the cause, clean up.
- At the end, we document what happened and which measures were implemented, until the incident is closed.
Frequently asked questions
Can a DDoS attack steal data?
A pure DDoS attack targets availability, not data. It does not change files and does not read databases. It can, however, occur at the same time as a break-in attempt, so it is still worth looking at files and accounts.
How do I recognise that my website has been hacked?
Typical signs are new or modified PHP files, unknown admin accounts, redirects to foreign sites, unexpected outgoing connections and processes that do not match your application. A single sign is not proof; several together are a serious signal.
Does a CDN or WAF help against both types of attack?
Against volume-based attacks, an upstream service usually helps well. Against exploits, rules work only if they recognise the pattern. With PHP2Shell, Cloudflare itself points out that rules based on request data alone are not sufficient.
Do I have to report a DDoS attack?
That depends on the individual case and on your industry. Without access to personal data, the GDPR reporting duty generally does not apply, but sector-specific obligations may exist. Clarify this with your data protection officer or a lawyer.