Namefi

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.

Fenwei BianFenwei BianAutoríaVictor ZhouVictor ZhouEdiciónIria MaquieiraIria MaquieiraTraducción17 jun 2026aprox. 11 min de lectura
  • domains
  • security
  • dns
  • domain-security
Compartir en X

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

Colaboradores

Fenwei Bian
Fenwei BianAutoría
Desarrolladora de software y escritora • Namefi

Fenwei Bian es una desarrolladora de software treintañera que pasa sus horas de trabajo entre pull requests y los fines de semana con las manos en la tierra o el serrín. Años de trabajo en proyectos de código abierto en GitHub le enseñaron que los nombres son interfaces: uno bueno es claro, sincero sobre lo que hace y considerado con quien tenga que usarlo después.

Se dedica a la jardinería porque recompensa la paciencia y castiga las ilusiones, y trabaja la madera porque una unión encaja o no encaja. Ambos hábitos se reflejan en su forma de escribir sobre nombres: mide dos veces, comprueba la fuente y no lijas una aspereza esperando que nadie la note.

Para Namefi escribe sobre cómo se mueven realmente los mercados de dominios, las contrapartidas prácticas de tokenizar y revender nombres y cómo elegir un dominio que dentro de veinte años aún te alegre tener.

Victor Zhou
Victor ZhouEdición
Fundador y editor de estándares • Namefi

Victor Zhou es un emprendedor tecnológico y editor de estándares centrado en la identidad digital y la confianza. Fundó Namefi, edita propuestas de mejora de Ethereum y anteriormente dirigió trabajos de arquitectura de contratos inteligentes en Google Labs.

Su trabajo se sitúa en la intersección de los nombres, la propiedad y los sistemas que las personas utilizan para establecer su identidad en internet. Esa perspectiva hace que le interese especialmente cómo los nombres transitan entre el significado personal, el reconocimiento público y la infraestructura digital.

Para Namefi, Victor edita y escribe sobre los dominios como una forma perdurable de identidad digital: cómo los nombres se convierten en activos onchain que se pueden poseer, cómo la tokenización cambia la custodia y la confianza y qué puede aprender el mundo de los nombres de los sistemas que las personas utilizan para establecer su identidad en internet.

Iria Maquieira
Iria MaquieiraTraducción
Traductora de localización al español • Namefi

Iria Maquieira es una traductora treintañera de A Coruña, Galicia. Empezó atendiendo consultas de soporte en el centro de llamadas de una empresa de telecomunicaciones, creó como proyecto paralelo un blog en el que puntuaba los nombres de startups españolas y, poco a poco, convirtió su trabajo independiente de localización entre el inglés y el español en una ocupación a tiempo completo.

Traduce a la vez para lectores de España y América Latina, lo que la hace alérgica a los regionalismos que excluyen discretamente a la mitad del público y muy cuidadosa con las tildes y la ñ cuando aparecen en un nombre de dominio. El surf en las aguas frías de la costa atlántica y los largos domingos de pulpo y albariño la mantienen realista con los plazos.

Para Namefi localiza al español artículos sobre dominios y nombres, teniendo en cuenta .es, .mx y .ar y eligiendo términos que suenen naturales desde Madrid hasta Ciudad de México.

Guías relacionadas

Comenta esta publicación

Ver la discusión en Namefi Discuss