# ¿DDoS o ataque de hackers? Cómo clasificar bien los ataques

> ¿DDoS o ataque de hackers? Indicios típicos comparados, primeros comandos de revisión para el servidor y qué hacer de forma concreta en las primeras horas.

Fuente: https://phpsos.de/es/ratgeber/ddos-oder-exploit/  
Actualizado: 25/10/2026  
Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6

**En resumen:** si es un DDoS o un ataque de hackers se ve por los rastros. Un DDoS genera muchísimas peticiones y vuelve el sitio web lento o inaccesible, pero no modifica nada. Un exploit suele necesitar pocas peticiones y deja archivos, cuentas, procesos o conexiones nuevos. La clasificación correcta decide si debe repeler carga o contener un incidente.

## La diferencia en palabras sencillas

Un **ataque DDoS** (Distributed Denial of Service) es como una multitud que bloquea la entrada de un comercio. Nadie entra, pero en la tienda no se roba nada. El objetivo es sobrecargar su sitio web o su servidor para que los clientes reales ya no puedan pasar.

Un **exploit**, en cambio, es una intrusión por una puerta abierta. El atacante aprovecha una vulnerabilidad, por ejemplo en PHP, en el CMS o en una extensión, para ejecutar código en su servidor. Eso puede ocurrir en silencio, sin que el sitio web se vuelva más lento. Las consecuencias van desde páginas de spam hasta el robo de datos y la toma del servidor.

Para la dirección, la diferencia es decisiva: un DDoS es un problema de disponibilidad que termina con el ataque. Un exploit exitoso es un incidente de seguridad que permanece hasta que se encuentra, se limpia y se documenta.

## DDoS o ataque de hackers: los indicios comparados

La tabla siguiente ayuda en la primera clasificación. No sustituye a un análisis, pero muestra dónde conviene mirar primero.

| Característica | Más bien DDoS | Más bien exploit o intrusión |
|---|---|---|
| Disponibilidad | lento o caído | a menudo normal |
| Peticiones en el registro | muchísimas, a menudo uniformes | pocas, dirigidas |
| Archivos | sin cambios | archivos PHP nuevos o modificados |
| Cuentas | sin cambios | nuevos administradores, contraseñas cambiadas |
| Procesos | servidor web y PHP a plena carga | procesos desconocidos, minería, envío de spam |
| Red | mucho tráfico entrante | conexiones salientes inusuales |
| Tras el final | todo como antes | los rastros permanecen |

Atención a los solapamientos: el escaneo masivo en busca de una vulnerabilidad puede parecer un pequeño DDoS. Eso era justo lo que cabía esperar en torno a PHP2Shell, cuando los atacantes buscaban servidores vulnerables. Una carga alta puede significar, por tanto, también que alguien está intentando entrar en ese momento.

## Primeras comprobaciones en el servidor

Los comandos siguientes no modifican nada en el sistema y dan una visión rápida. Si sospecha una intrusión, conserve los registros antes de realizar intervenciones mayores.

```bash
# Carga y tiempo de actividad
uptime

# Resumen de conexiones y las contrapartes más frecuentes
ss -s
ss -tn state established | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

# Direcciones de cliente más frecuentes en el registro de acceso (adapte la ruta)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Archivos PHP modificados en los últimos 7 días
find /var/www -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

# Procesos con mayor carga de CPU
ps aux --sort=-%cpu | head -15
```

En el resumen de conexiones, la cuarta columna muestra la contraparte. Muchas conexiones desde pocas direcciones o un aumento a un múltiplo del valor normal apuntan a sobrecarga. Los archivos PHP nuevos en directorios de subidas o de caché, los procesos del usuario del servidor web con nombres ajenos o las conexiones salientes a destinos desconocidos apuntan más bien a una intrusión. Encontrará una lista detallada en [Indicios de compromiso tras PHP2Shell](https://phpsos.de/es/php2shell/bin-ich-gehackt-anzeichen/).

## Por qué una carga alta también puede ser una maniobra de distracción

Ocurre que los atacantes provocan una sobrecarga mientras irrumpen de forma dirigida. El equipo está entonces ocupado con la disponibilidad, y los rastros reales se pierden en el ruido de los registros. Por eso rige: aunque un DDoS sea evidente, revise tras su fin los archivos, las cuentas y las conexiones salientes.

En el caso de PHP2Shell se añade que, según php.net y las empresas de seguridad, no hay Indicators of Compromise confirmados y publicados. La detección se basa en el análisis de comportamiento. Un servidor que estuviera sin parchear durante el periodo de escaneo desde mediados de octubre debería revisarse, por tanto, con independencia de la carga observada.

Otra variante son los correos de extorsión que amenazan con un ataque DDoS si no se paga. Conserve esos mensajes, no pague sin consultar con especialistas y considere una [denuncia ante la Zentrale Ansprechstelle Cybercrime (ZAC, punto de contacto central alemán contra el cibercrimen)](https://phpsos.de/es/compliance/anzeige-polizei-zac/). Informe en paralelo a su proveedor de hosting, para que puedan prepararse medidas de protección. Cómo analizar los registros para ello se explica en la guía [Analizar los registros del servidor web tras un ataque](https://phpsos.de/es/ratgeber/logfiles-auswerten/).

## Qué hacer en las primeras horas

**Ante la sospecha de DDoS:**

- Informar al proveedor de hosting o al centro de datos; allí suele haber filtros antes del servidor.
- Activar o reforzar un servicio de protección antepuesto o un [WAF con parcheo virtual](https://phpsos.de/es/leistungen/waf-virtuelles-patching/).
- Establecer límites de tasa en el servidor web y proteger de forma especial las páginas costosas, como la búsqueda o el carrito.
- Conservar los registros, para que el ataque pueda reconstruirse más adelante.

**Ante la sospecha de una intrusión:**

- No borrar nada ni reinstalar el servidor antes de haber conservado los registros y los archivos afectados.
- Actualizar PHP a una versión corregida y reiniciar todos los workers, si aún no se ha hecho.
- Si la actualización no es posible de inmediato, desconectar temporalmente el sitio web de la red, como recomienda el BSI (Oficina Federal alemana para la Seguridad de la Información).
- Renovar las credenciales desde un equipo limpio, no desde el servidor posiblemente afectado.
- Hacer comprobar si podrían estar afectados datos personales; entonces pueden estar corriendo plazos de notificación.

En ambos casos ayuda una nota breve y objetiva para el proveedor de hosting y los prestadores de servicios: desde cuándo existe el problema, qué sitios web están afectados, qué ha observado y qué se ha cambiado ya. Anote además quién tomó cada decisión. Esta línea temporal ahorra tiempo en el análisis y es valiosa más adelante para el seguro, la protección de datos y la revisión interna. Si no está claro si existe siquiera un ataque, trate la situación como incidente por precaución hasta que se demuestre lo contrario.

## ¿Cómo ayuda PHP SOS en concreto?

- Clasificamos la situación en remoto a partir de la carga, los registros, los archivos y las conexiones, y le decimos con qué probablemente está tratando.
- En caso de sobrecarga, aplicamos filtros, límites de tasa y reglas de protección antepuestas hasta que el ataque remita.
- Ante la sospecha de intrusión, asumimos la [respuesta a incidentes](https://phpsos.de/es/leistungen/incident-response/) estructurada: conservar, contener, encontrar la causa, limpiar.
- Al final documentamos lo ocurrido y las medidas aplicadas, hasta que el incidente quede cerrado.


## Preguntas frecuentes

**¿Puede un ataque DDoS robar datos?**  
Un ataque DDoS puro apunta a la disponibilidad, no a los datos. No modifica archivos ni lee bases de datos. Pero puede producirse a la vez que un intento de intrusión, por eso merece la pena echar igualmente un vistazo a los archivos y las cuentas.

**¿Cómo reconozco que mi sitio web ha sido hackeado?**  
Los indicios típicos son archivos PHP nuevos o modificados, cuentas de administrador desconocidas, redirecciones a sitios ajenos, conexiones salientes inesperadas y procesos que no encajan con su aplicación. Un solo indicio no es una prueba; varios juntos son una señal seria.

**¿Ayuda un CDN o un WAF contra los dos tipos de ataque?**  
Contra los ataques basados en volumen, un servicio antepuesto suele ayudar bien. Contra los exploits, las reglas solo funcionan si reconocen el patrón. En el caso de PHP2Shell, la propia Cloudflare advierte de que las reglas basadas únicamente en los datos de la petición no bastan.

**¿Tengo que notificar un ataque DDoS?**  
Depende del caso concreto y de su sector. Sin acceso a datos personales, la obligación de notificación del RGPD por lo general no se aplica, pero pueden existir obligaciones específicas del sector. Acláralo con su delegado de protección de datos o con un abogado.

## Fuentes

- [BSI: situación y recomendaciones](https://www.bsi.bund.de/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)
- [php.net: avisos de seguridad](https://www.php.net/)