Domain Mayday EP10: Cómo el Ejército Electrónico Sirio Derribó NYTimes.com a través de un Revendedor Víctima de Phishing

El 27 de agosto de 2013, el Ejército Electrónico Sirio realizó un ataque de phishing a un revendedor de Melbourne IT, reescribió los registros DNS de nytimes.com y los dominios de Twitter, y dejó al New York Times fuera de línea durante horas. Un análisis profundo de cómo el eslabón débil de la cadena de registradores se convirtió en el punto de falla de un periódico — y qué habrían cambiado los bloqueos de registro.

Publicado el 17 de junio de 2026Por Equipo Namefi
  • domains
  • security
  • dns
  • domain-security
Domain Mayday EP10: Cómo el Ejército Electrónico Sirio Derribó NYTimes.com a través de un Revendedor Víctima de Phishing

El nombre de dominio de un periódico es su puerta de entrada. Cuando escribes nytimes.com, estás confiando en una cadena invisible — un registro de dominios, un registrador, y a veces un revendedor por debajo de ese registrador — para que te dirija a la redacción real y a ningún otro lugar. En un día normal nunca piensas en esa cadena. El 27 de agosto de 2013, se rompió, y millones de lectores se acercaron a la puerta de entrada de The New York Times para encontrar que había sido reemplazada por la de otra persona.

Esa otra persona era el Ejército Electrónico Sirio (SEA, por sus siglas en inglés), un colectivo de hackers pro-Assad que pasó 2013 atacando medios de comunicación occidentales. Esta vez no desfiguraron un solo artículo ni irrumpieron en un sistema de gestión de contenido. Fueron un nivel más profundo — hacia los registros DNS que deciden hacia dónde apunta un dominio — y durante unas horas fueron dueños de la dirección de uno de los sitios de noticias más leídos del planeta.

Un dominio es la puerta de entrada, y la puerta de entrada tiene una cerradura que tú no controlas

Cuando una empresa como The New York Times registra un dominio, el registro autorizado de "quién posee esto y hacia dónde apunta" vive en el registro (para .com, ese es Verisign) y se gestiona a través de un registrador. Los grandes registradores también venden a través de revendedores — empresas más pequeñas que revenden servicios de dominio y tienen su propio inicio de sesión en los sistemas del registrador.

Esa estructura por capas es conveniente. También es una cadena de confianza donde el eslabón más débil determina la seguridad de todo el conjunto. Si un atacante puede autenticarse como cualquiera en esa cadena — el titular del dominio, el personal del registrador o el revendedor — los sistemas del registrador, por diseño, lo tratarán como el propietario legítimo. El propio director ejecutivo de Melbourne IT resumió el modo de falla en una frase devastadora: "Entraron por la puerta principal," le dijo a la AP. Si tienes un nombre de usuario y contraseña válidos, el sistema asume que eres el propietario autorizado. Ese es todo el problema en pocas palabras.

27 de agosto de 2013: el día en que nytimes.com apuntó a otro lugar

Arte conceptual colorido y vívido de un enorme letrero de puerta principal de un periódico siendo desatornillado y vuelto a colgar sobre una entrada diferente, con flechas de enrutamiento de color rojo brillante que desvían a una multitud de lectores hacia un callejón oscuro

Al final de una tarde de martes, los lectores dejaron de llegar al Times. El sitio web de The New York Times había "quedado oscuro para algunos usuarios," informó ABC News, y el periódico confirmó que su sitio "no estaba disponible para los lectores el martes por la tarde" tras un ataque a su registrador de dominios. Esto no fue una interrupción breve. Los visitantes "fueron recibidos con pantallas de navegador en blanco durante varias horas el martes," informó el Christian Science Monitor — y para empeorar las cosas, era "la segunda vez en este mes" que el sitio caía.

Lo que había ocurrido en realidad fue un secuestro de DNS a nivel del registrador. Los atacantes intervinieron los registros que traducen nytimes.com en una dirección IP y los reescribieron. Según el relato de Wikipedia sobre el incidente, NYTimes.com "tuvo su DNS redirigido a una página que mostraba el mensaje 'Hacked by SEA'". La puerta de entrada había sido vuelto a colgar sobre una entrada diferente.

The Times no fue el único objetivo en esa cuenta. TechCrunch, reportando en tiempo real, descubrió que tanto "los servidores de nombres de The New York Times como los de Twitter parecen haber sido registrados a través del registrador Melbourne IT," y que el dominio twimg.com, "que sirve imágenes y avatares de Twitter, también muestra cambios que apuntan a servidores que aparentemente son propiedad del SEA." El sitio principal de Twitter sobrevivió en gran medida intacto, pero su dominio de imágenes y avatares tembló — lo suficiente como para que algunos usuarios vieran brevemente imágenes rotas.

El impacto: horas de oscuridad y una redirección en la que no podías confiar

Para una organización de noticias, el costo de un secuestro no se mide solo en páginas vistas perdidas. Se mide en confianza. Durante la duración de la interrupción, cualquiera que accediera a nytimes.com estaba siendo enrutado por el atacante. El propio director de tecnología del Times, Mark Frons, le dijo al personal que la interrupción "fue el resultado de un ataque malicioso externo del Ejército Electrónico Sirio o de alguien que se esforzaba mucho en parecerlo" — y advirtió a los empleados que tuvieran cuidado con el correo electrónico mientras el dominio estuviera fuera del control del periódico.

Piensa en lo que realmente permite un registro DNS secuestrado. El atacante controla hacia dónde se resuelve el nombre, lo que significa que puede servir una página de desfiguración (como lo hicieron), pero con igual facilidad podría servir un falso inicio de sesión convincente, recolectar credenciales o interceptar tráfico. Una desfiguración es ruidosa y obvia. Un secuestro de DNS silencioso es mucho más peligroso — y la misma vulnerabilidad habilita ambos. El dominio del Huffington Post UK quedó atrapado en el mismo incidente, lo que subraya que esto fue un compromiso de cuenta de registrador, no una broma aislada contra una sola redacción.

Cómo ocurrió: atacar al revendedor con phishing, no al periódico

Arte conceptual colorido y vívido de una llave dorada víctima de phishing deslizándose en una puerta de sala de control iluminada con diales de enrutamiento abstractos, una mano sombría reescribiendo un luminoso libro de registro de flechas de direcciones mientras un falso sobre de correo electrónico se disuelve en la cerradura

Aquí está la parte que vale la pena reflexionar: el SEA nunca tuvo que irrumpir en The New York Times. Nunca tocaron los servidores del periódico ni su CMS. Atacaron la cadena por debajo del registrador.

El punto de entrada fue un correo electrónico de spear-phishing enviado a un revendedor de Melbourne IT con sede en Estados Unidos. Como informó The Next Web, Melbourne IT "confirmó que el SEA utilizó tácticas de phishing para obtener los datos de inicio de sesión" — los empleados del revendedor fueron engañados para que entregaran sus credenciales de correo electrónico, y los atacantes luego extrajeron de esos buzones las credenciales de inicio de sesión del registrador. A partir de ahí fue sencillo: las credenciales "de un revendedor de Melbourne IT (nombre de usuario y contraseña) se utilizaron para acceder a una cuenta de revendedor en los sistemas de Melbourne IT," y una vez dentro, los atacantes "cambiaron los registros DNS de varios nombres de dominio ... incluidos los del Times."

El relato de TechCrunch es igualmente contundente: los "registros DNS de varios nombres de dominio en esa cuenta de revendedor fueron cambiados — incluido nytimes.com."

Esta es la asimetría que hace tan atractivos los ataques a la cadena de registradores. El Times podría haber reforzado al máximo su propia infraestructura y no habría importado, porque la cuenta vulnerable pertenecía a un revendedor externo a varios pasos de la redacción. Un ataque de spear-phishing contra unos pocos empleados de una pequeña empresa fue suficiente para redirigir a un periódico leído por millones.

Respuesta y consecuencias

Una vez que Melbourne IT comprendió lo que había ocurrido, la remediación fue sencilla — y muestra lo reversibles que son estos ataques si controlas el registrador. La empresa restauró la configuración correcta: revirtió los registros DNS alterados y los "bloqueó" para evitar más modificaciones. Cambió la contraseña de la cuenta de revendedor comprometida y revisó los registros para rastrear la intrusión. El Times restableció el servicio a principios del miércoles.

Pero el detalle más instructivo de todo el episodio es por qué el daño se detuvo donde lo hizo. Algunos dominios en esa misma cuenta de revendedor nunca se vieron afectados en absoluto — porque sus propietarios habían activado una protección más sólida. En palabras del propio Melbourne IT, para "nombres de misión crítica recomendamos que los propietarios de nombres de dominio aprovechen las características adicionales de bloqueo de registro disponibles en los registros de nombres de dominio, incluido el de .com — algunos de los nombres de dominio atacados en la cuenta del revendedor tenían estas características de bloqueo activas y, por lo tanto, no se vieron afectados."

Un bloqueo de registro coloca el dominio en un estado (puedes verlo en WHOIS como indicadores como serverUpdateProhibited) donde el registro rechazará los cambios a menos que se siga un proceso más estricto y fuera de banda. Como señalaron los observadores de la industria de dominios en su momento, los registros de Twitter llevaban exactamente ese tipo de estado de bloqueo de Verisign. Una contraseña de revendedor obtenida mediante phishing no es suficiente para superar un bloqueo de registro — y esa única opción de configuración es la línea entre "caído durante horas" y "nunca afectado".

Lo que esto enseña sobre las cadenas de registradores y revendedores, y los bloqueos de registro

El secuestro del 27 de agosto es un caso de estudio casi perfecto porque cada eslabón de la cadena de fallas es visible.

  1. Tu dominio es tan seguro como la cuenta más débil que puede modificarlo. Eso incluye al personal de tu registrador y a cualquier revendedor por debajo de ellos — ninguno de los cuales controlas directamente. El Times no hizo nada mal en sus propios servidores; el compromiso estaba a varios pasos de distancia.
  2. El phishing supera a los cortafuegos. No se utilizó ningún exploit exótico. Un correo electrónico falso enviado a un puñado de empleados de un revendedor produjo credenciales que los sistemas del registrador trataron como completamente autorizadas. "Entraron por la puerta principal."
  3. El bloqueo de registro es el control que realmente importó. Los dominios con características adicionales de bloqueo de registro "no se vieron afectados." Para cualquier dominio de misión crítica, el bloqueo de registro (junto con el bloqueo del registrador y la autenticación de dos factores en la cuenta del registrador) no es un refuerzo opcional — es la línea base.
  4. Los cambios de DNS son poderosos y rápidos. Una sola reescritura de los registros de servidores de nombres o A redirige toda una marca de forma instantánea. El radio de impacto de una cuenta comprometida es cada dominio que puede tocar.
  5. Monitorea tus propios registros. El monitoreo de WHOIS y DNS habría detectado el cambio no autorizado en cuestión de minutos. Cuanto antes notes un cambio inesperado en el servidor de nombres, menor será la interrupción.

El ángulo de Namefi

Ilustración colorida de la propiedad de dominio verificable y resistente a manipulaciones — una tarjeta de dominio asegurada por un escudo verde, un token verde de Namefi y continuidad DNS

El secuestro del SEA fue, en su núcleo, un problema de autoridad. El sistema del registrador no podía distinguir entre el propietario real y alguien que tenía una contraseña obtenida mediante phishing, por lo que hizo lo que fue diseñado para hacer y aceptó el cambio. Cada defensa que funcionó — los bloqueos de registro, la confirmación fuera de banda, el monitoreo cuidadoso — es en realidad una forma de elevar el listón para demostrar que una solicitud de cambio realmente proviene del propietario.

Namefi parte exactamente de esa premisa: la propiedad y el control del dominio deben ser verificables y resistentes a manipulaciones, no una sola contraseña reutilizable flotando en la bandeja de entrada de un revendedor. Al representar la propiedad del dominio como un activo verificable criptográficamente en la cadena que permanece compatible con DNS, Namefi convierte "quién tiene permitido cambiar este dominio" en una pregunta con una respuesta sólida y auditable, en lugar de una confianza implícita en quien inició sesión. Los cambios de control se convierten en acciones explícitas y firmadas vinculadas al propietario — más cercanas a un bloqueo de registro cuya llave tú tienes que a una puerta principal cuya cerradura cualquiera con la contraseña correcta puede abrir.

El dominio de un periódico es su puerta de entrada. La lección del 27 de agosto de 2013 es que el cerrojo más fuerte posible no sirve de nada si un desconocido a varios edificios de distancia puede ser engañado para que entregue una copia de la llave. La solución es hacer que la propiedad en sí sea demostrable — para que "entró por la puerta principal" deje de ser algo que un desconocido pueda decir jamás.

Fuentes y lectura adicional

Sobre quienes escriben

Equipo Namefi
Equipo Namefi • Namefi

Namefi es un equipo de desarrolladores y diseñadores apasionados por crear herramientas que simplifican la gestión de nombres de dominio para todos.

Guías relacionadas