El remitente era auténtico. La citación no

A las 08:03 de esta mañana, lunes 31 de agosto, me ha entrado esto en el buzón:

De: Notificación judicial mail24382@mail24.welinkappe.com

Asunto: Envío de Citación Judicial Nº9546 - Documento Adjunto eaymerich@… - 31/08/2026 06:03

Estimado/a Sr./Sra. eaymerich@…,

Notificación en adjunto 7119

Para abrir el archivo PDF, utilice la siguiente contraseña: 6640

Atentamente, Pablo Álvarez Asistente de Juez Tribunal de Justicia de Madrid

Y un adjunto: eaymerich_XXXXXXXXXX.pdf, 40,7 KB.

No lo he abierto. No lo voy a abrir. Y da igual, porque lo interesante de este correo no está dentro del adjunto: está en el hueco que hay entre lo que el mensaje cuenta y lo que sus cabeceras demuestran.

Adelanto la conclusión, que es lo que me ha hecho escribir esto en vez de darle a borrar y seguir con el café:

Este correo no falsificó su origen. Falsificó su historia.

SPF, DKIM y DMARC dieron pass, los tres. Viajó cifrado por TLS. El filtro antispam de mi proveedor le puso un cero. Técnicamente, su procedencia está correctamente autenticada. Lo falso era que aquello fuese una citación judicial.

Voy a desmontarlo en tres capas: lo que ve una persona, lo que ve un servidor, y lo que ninguno de los dos puede dar por sabido.

Capa 1: lo que ve una persona

La autoridad prestada

«Tribunal de Justicia de Madrid» no existe. El que existe es el Tribunal Superior de Justicia de Madrid, y le falta una palabra. Es la distancia justa: suficiente para sonar a institución, poca para que nadie se pare a mirarlo.

«Asistente de Juez» tampoco existe. Los cuerpos de la Administración de Justicia española son el de Letrados de la Administración de Justicia y los generales de Gestión Procesal y Administrativa, Tramitación Procesal y Administrativa y Auxilio Judicial. «Asistente de juez» no es ninguno de ellos: suena exactamente a lo que probablemente sea, una traducción literal de judge's assistant.

Dos palabras y ya tenemos dos cosas que no encajan, y ninguna requiere saber nada de informática.

Los números que simulan precisión

Citación Nº9546. Adjunto 7119. Contraseña 6640. Tres números de cuatro cifras en cinco líneas.

Parecen datos administrativos y no identifican absolutamente nada. Una comunicación judicial auténtica permite identificar, como mínimo, el órgano y el procedimiento —«Juzgado de Primera Instancia n.º 4 de Madrid, Procedimiento Ordinario 345/2026»—, y esos dos datos sirven para algo: se pueden contrastar por los canales oficiales. «Nº9546» no se puede contrastar contra nada.

Es precisión decorativa: la apariencia de un dato sin el dato.

La personalización que no lo es

«Estimado/a Sr./Sra. eaymerich@…».

Mi dirección de correo aparece tres veces —en el saludo, en el asunto y en el nombre del archivo adjunto— y ni una sola vez aparece mi nombre. No saben cómo me llamo. Han sustituido una variable.

Que un correo lleve tu dirección, tu empresa o incluso tu nombre no demuestra que nadie haya mirado tu caso. La personalización es un printf.

La contraseña que viaja con la cerradura

Esta es la pieza que me hizo mirar las cabeceras. Un adjunto que, según el remitente, hay que abrir con una clave —cuatro dígitos, en negrita— escrita en el mismo correo que el archivo.

Conviene decirlo con precisión, porque es fácil dar aquí un paso de más: yo no sé si ese archivo está cifrado. Sé que el correo dice que hace falta una contraseña. Comprobarlo exigiría mirar el archivo, y el archivo sigue sin tocar.

Pero demos por bueno lo que anuncia. Como medida de seguridad no tendría ningún sentido: cualquiera que lea el mensaje abre el documento. La llave va pegada a la puerta.

Un candado excelente y su llave, guardados en el mismo sitio. Candado español o alemán de finales del siglo XVI o principios del XVII. Fotografía del Metropolitan Museum of Art, CC0, vía Wikimedia Commons; imagen reescalada.

Lo que sí conseguiría es otra cosa. Un PDF cifrado no se puede leer sin la clave, y eso incluye a quien intente analizarlo por el camino: un filtro que quiera mirar dentro tiene que sacar la contraseña del texto del mensaje y probarla. Algunos productos lo hacen; otros no; y depende de la configuración de cada uno.

Voy con cuidado también aquí: no puedo afirmar que impida el análisis. Sí puedo afirmar que lo dificultaría. Y ese es el efecto técnico relevante de anunciar una contraseña de cuatro cifras en el mismo correo que el archivo al que supuestamente protege. No cierra nada. Solo tapa.

Lo que falta

Lo escandaloso de este correo no es lo que dice. Es lo que evita decir.

Todo lo que aparece es incomprobable y todo lo que sería comprobable falta. Sea deliberado o no, el resultado favorece al engaño: un dato verificable es también un dato que puede delatarlo.

Y hay un detalle de calendario que da gracia. El artículo 183 de la Ley Orgánica del Poder Judicial dice que serán inhábiles los días del mes de agosto «para todas las actuaciones judiciales, excepto las que se declaren urgentes por las leyes procesales». Recibir una citación el 31 de agosto no es imposible —hay excepciones, y la instrucción penal es una de ellas—, pero es raro. No lo pongo como prueba de nada; lo pongo porque es el tipo de cosa que un correo bien hecho habría evitado.

La urgencia que no hay que pedir

No dice «tienes 24 horas». No amenaza. No hace falta: la palabra judicial ya trabaja sola. Ese es, técnicamente, el trabajo más fino de todo el mensaje. La prisa no la mete el remitente, la pone quien lo lee.

Capa 2: lo que ve el servidor

Aquí es donde este correo se pone verdaderamente interesante, y donde deja de parecerse a los cientos de ejemplos que salen cuando uno busca «cómo detectar un phishing».

SPF, DKIM y DMARC dijeron que sí

Authentication-Results: mx.mail.ovh.net;
    dkim=pass (2048-bit rsa key sha256) header.d=mail24.welinkappe.com ...
    dmarc=pass ... (p=quarantine,sp=quarantine) header.from=mail24.welinkappe.com;
    spf=pass smtp.mailfrom=mail24382@mail24.welinkappe.com ...
    x-tls=pass smtp.version=TLSv1.3

Los tres, en verde. Y no por casualidad: el dominio que envía tiene su registro SPF autorizando la IP concreta desde la que salió, tiene su clave DKIM publicada y firma con ella, y tiene incluso una política DMARC de cuarentena. Está montado como se monta un dominio de envío serio.

Lo que esas tres comprobaciones acreditan, simplificando mucho, es esto:

• SPF: la IP 213.156.148.134 estaba autorizada para enviar en nombre de mail24.welinkappe.com.
• DKIM: las partes firmadas del mensaje llegaron sin alteraciones incompatibles con la firma de ese dominio.
• DMARC: el dominio del remitente que se ve en pantalla es el mismo que ha firmado.

Fíjate en lo que no aparece por ninguna parte: nadie ha demostrado que welinkappe.com sea un tribunal. Ni falta que hacía, porque el atacante no lo intentó. No trató de suplantar un dominio de Justicia —eso habría fallado, y precisamente para eso existe DMARC—. Puso «Notificación judicial» como nombre visible, dejó la dirección real detrás y confió en que nadie la mirara.

La suplantación no la hizo el protocolo. La hizo mi cabeza.

SPF, DKIM y DMARC autentican dominios. No autentican relatos, ni cargos, ni facturas, ni citaciones.

El sello acredita quién cerró el documento. Sobre si es verdad lo que el documento dice, no opina. Confirmación del emperador Carlos VI de la hacienda libre de Orlová, 11 de septiembre de 1732, con sello de los Habsburgo en cera roja dentro de su caja de madera y cordón de seda amarilla. Imagen en dominio público, del Archivo Provincial de Opava, vía Wikimedia Commons; imagen reescalada.

Merece la pena insistir porque el consejo se ha degradado por el camino. «Comprueba que el correo esté autenticado» se ha ido convirtiendo en «si pasa SPF y DKIM, es legítimo», y eso es sencillamente falso. La autenticación responde a ¿viene de verdad del dominio que dice?. No responde a ¿es verdad lo que cuenta?.

Cero puntos de spam

X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-Ovh-Spam-Status: OK
X-Ovh-Message-Type: OK

Un cero limpio. Se pueden intuir factores que ayudaron: venía de un servidor autorizado, con firma válida, cifrado en tránsito, con poquísimo texto, sin un solo enlace y con un adjunto declarado como PDF.

Pero aquí toca frenar otra vez, porque es la trampa fácil de este apartado: la cabecera demuestra el resultado —cero—, no el razonamiento que llevó hasta él. Los filtros modernos también valoran lenguaje, estructura, contexto y reputación, y yo no sé qué miró el de OVH ni con qué reglas activadas.

Lo que sí se puede decir es que el fraude de este correo está sobre todo en el significado, que es una capa bastante más difícil de valorar automáticamente que un remite o un enlace.

Para la máquina, cero. Para una persona que se pare diez segundos, sospechoso por los cuatro costados.

Llegar a la bandeja de entrada no es un certificado de nada. Es la ausencia de un motivo para pararlo.

El recorrido, que se lee de abajo arriba

Las cabeceras Received se apilan: cada servidor añade la suya arriba del todo, así que la última que se escribe es la primera que se ve. Para saber de dónde salió un correo hay que empezar por abajo.

Y abajo del todo, la única línea que importa:

Received: from mail24.welinkappe.com (mail24.welinkappe.com [213.156.148.134])
	by in89.mail.ovh.net (Postfix) with ESMTPS ...

Todo lo demás —cinco líneas más— es el trayecto interno por la infraestructura de mi proveedor y por el servidor de correo de la empresa hasta llegar al buzón. Ruido de fontanería.

Ni una sola línea menciona nada judicial, nada de la Administración, ningún dominio .gob.es. Todo el aparato administrativo del mensaje existe únicamente en el asunto y en el cuerpo.

El sello del cartero

X-Mailer: Newsletter Dispatcher 3.0

Una citación judicial enviada con algo que se presenta como despachador de boletines.

Y ya está, porque esta cabecera la escribe quien envía y puede poner lo que le apetezca: no demuestra nada, ni siquiera que el envío fuera masivo. Me quedo solo con el contraste, que no necesita interpretación, y con un detalle del remite —mail24382@—, que parece más un número de plantilla que una persona. Tampoco eso es una prueba. Es una impresión, y como tal la dejo.

userid 0

Received: by mail24.welinkappe.com (Postfix, from userid 0)

Esta me gusta especialmente. Dice que el mensaje no llegó al servidor por una sesión SMTP normal desde fuera, sino que se inyectó localmente en Postfix, y que el proceso que lo hizo corría como el usuario 0: root en cualquier Unix.

Y aquí es donde toca frenar en seco, porque es tentador seguir tirando del hilo. Ese dato no dice si el servidor es del atacante, si es un servidor legítimo comprometido, o si hay ahí una aplicación corriendo con muchos más privilegios de los que necesita. Dice solo que quien metió el mensaje estaba dentro de la máquina y con permisos para todo. Lo demás requiere investigar el servidor y el dominio, y yo no he hecho ni una cosa ni la otra.

«application/pdf» lo dice quien envía

Content-Type: application/pdf
Content-Disposition: attachment; filename="eaymerich_XXXXXXXXXX.pdf"

Tanto el tipo declarado como el nombre del archivo los elige el remitente. Son una etiqueta, no un análisis. Puede ser un PDF cifrado, puede ser un PDF sin cifrar, puede ser otro formato disfrazado. Para comprobar su formato habría que inspeccionarlo; para estudiar su contenido y su posible comportamiento, analizarlo en un entorno aislado y preparado para eso. No he hecho ninguna de las dos cosas, y por eso este post no te va a decir qué contenía ni siquiera si la contraseña servía para algo.

Lo que sí he mirado, porque es gratis: el cuerpo del correo viaja en base64, que no es cifrado ni ocultación —es la forma normal de meter acentos en un mensaje—. Al decodificarlo aparece, letra por letra, exactamente el mismo texto que se ve en pantalla. Ningún truco escondido en la parte HTML, ningún enlace invisible. Si había algo más, estaba en el adjunto.

Capa 3: lo que no puedo decir

Este es el apartado que casi nunca se escribe, y es el que separa un análisis de un titular. Estas son las tres columnas, y conviene no cambiarlas de sitio:

Lo que sé de este correo cabe entero en la primera columna. Lo de la segunda es probable y razonable, y sigue sin estar comprobado. Y la tercera es donde se cae la gente con más ganas que datos.

Lo que sí está documentado es la familia. INCIBE lleva años publicando avisos de campañas que se hacen pasar por citaciones judiciales y por notificaciones de la Policía Nacional para repartir troyanos. Que este correo pertenezca a ese género es una hipótesis con muy buen respaldo. Sigue siendo una hipótesis, y por eso el adjunto está donde está: sin abrir.

Actualización: hora y media después, el segundo

Estaba terminando de escribir esto cuando ha entrado otro.

De: Notificación judicial mail4297@mail4.welinkappe.com

Asunto: Envío de Citación Judicial Nº9758 - Documento Adjunto info@… - 31/08/2026 07:29

Estimado/a Sr./Sra. info@…,

Notificación en adjunto 7718

Para abrir el archivo PDF, utilice la siguiente contraseña: 4379

Atentamente, Pablo Álvarez Asistente de Juez Tribunal de Justicia de Madrid

El mismo Pablo Álvarez, el mismo cargo que no existe, el mismo tribunal que tampoco. A otro buzón del mismo dominio, una hora y veintiséis minutos más tarde.

Y lo que cambia es exactamente lo que tenía pinta de ser una variable:

Lo que no cambia es todo lo demás: la firma, el cargo, el tribunal, la estructura de cada frase y el formato del asunto, coma a coma.

Esto mueve una fila de la tabla

Y por eso lo añado aquí abajo en vez de reescribir el artículo como si lo hubiera sabido desde el principio.

«Que es una campaña automatizada» estaba en la columna de lo que solo se sugiere, apoyada en indicios blandos: una cabecera X-Mailer que cualquiera puede escribir y un remite numerado. Con un segundo mensaje delante, esa fila cambia de sitio. Dos correos con el mismo texto, la misma firma inventada y tres números distintos en los mismos tres huecos demuestran que hay una plantilla con variables y más de un destinatario. Ya no es una impresión.

Lo que sigue sin demostrarse es el tamaño: «automatizada», sí; «masiva» continúa siendo una suposición razonable, porque dos no son muchos.

Hay además un dato que antes no tenía: el subdominio de envío también rota. mail24 en el primero, mail4 en el segundo.

Y ahora sí, sus cabeceras

Cuando escribí el párrafo de arriba todavía no las tenía. Ya sí, y traen dos cosas que el primer correo, él solo, no podía enseñar.

La primera: la infraestructura está bastante mejor montada que el texto del correo.

dkim=pass (2048-bit rsa key sha256) header.d=mail4.welinkappe.com ... header.s=mail4;
dmarc=pass ... (p=quarantine,sp=quarantine) header.from=mail4.welinkappe.com;
spf=pass smtp.mailfrom=mail4297@mail4.welinkappe.com;

Otra vez los tres en verde, pero mira el detalle: el selector DKIM es mail4, no mail24.

Eso solo dice que usan selectores distintos, así que he ido a comprobar el DNS: los registros mail24._domainkey.mail24.welinkappe.com y mail4._domainkey.mail4.welinkappe.com existen los dos y publican claves públicas RSA distintas. No es el mismo par de claves reutilizado con dos nombres. Cada subdominio de envío tiene la suya, más su propio SPF autorizando su propia dirección.

Aquí no vemos un servidor improvisado: vemos al menos dos hosts de envío, cada uno con su nombre, su IP, su selector, su clave y su autorización, todo dado de alta en el DNS como Dios manda.

Las dos direcciones son vecinas: mismo bloque 213.156.148.0/24. Eso demuestra que ambos correos salen del mismo rango; sugiere —no demuestra— una sola infraestructura detrás, y sigue sin decir si esa infraestructura es de quien manda el correo o de alguien a quien se la han tomado prestada.

La segunda es mi favorita, porque es la parte del correo que no escribió nadie.

Los dos Message-ID, uno debajo del otro:

<178815620838.3556.1366798039708559261@mail24.welinkappe.com>
<178816139482.3556.4414019789168187807@mail4.welinkappe.com>

Ese formato de tres números separados por puntos no es decorativo: coincide exactamente con el que produce email.utils.make_msgid(), de la biblioteca estándar de Python. Coincide, que no es lo mismo que estar firmado por ella: cualquier programa puede reproducir ese formato o implementar algo equivalente. Pero los tres campos se leen, y eso sí es comprobable:

• El primero es la hora, en centésimas de segundo. 178815620838 ÷ 100 son las 06:03:28 del 31 de agosto, clavadas al Date: del mensaje, y la firma DKIM se estampó dos segundos más tarde. En el segundo correo, igual: 07:29:54.
• El segundo es el identificador del proceso que generó el mensaje. Es 3556 en los dos.
• El tercero es un número aleatorio de 64 bits, que es lo único de ahí que es realmente aleatorio.

El mismo PID en dos hosts de envío distintos no prueba nada por sí solo —los identificadores de proceso se reciclan sin parar—, pero encaja con un despliegue común del mismo programa sobre sistemas configurados de forma parecida. Ojo con estirarlo más de ahí: dos nombres de host y dos IP no demuestran dos máquinas. Podrían ser contenedores, máquinas virtuales o interfaces distintas de lo mismo, y las cabeceras no distinguen entre esos casos.

Y aquí hay una ironía que merece señalarse. Todo el mensaje está construido para no dejar nada comprobable: el número de citación no lleva a ningún sitio, el cargo no existe y el tribunal tampoco. Pero la cabecera que el propio programa se pone a sí mismo, sin que nadie la redacte, canta la hora exacta, un identificador de proceso y una huella muy reconocible de la biblioteca que probablemente lo generó. Lo más verificable de todo el correo es justo lo que no escribió ninguna persona.

Un último detalle, que está en los dos y que antes no conté. Junto al cero de spam viene esta línea:

X-Ovh-Spam-Reason: vr: OK; dkim: disabled; spf: disabled

El componente que escribe esa cabecera declara SPF y DKIM como disabled, mientras que otra etapa distinta sí los comprobó y dejó sus pass en el Authentication-Results. No sé cómo se combinan las dos cosas para llegar al cero —esa fórmula no está en ninguna cabecera—, pero sí sé una consecuencia: el cero no se puede explicar diciendo simplemente «es que SPF y DKIM habían pasado». Son etapas separadas, y lo que vemos son sus resultados, no su aritmética.

Y confirma lo otro

Que a mí no me ha elegido nadie. Las dos direcciones son de mi dominio y una de ellas, info@, está publicada en la web. No hay caso, no hay expediente y no hay nadie leyendo nada: hay una lista. Es lo mismo que contaba aquel post sobre la falsa sensación de seguridad — nadie te elige, te encuentra un bucle—, solo que esta vez lo he visto ocurrir dos veces en la misma mañana.

La regla que sí sirve

Aquí es donde este tipo de artículos suele terminar en una lista de diez señales, y donde creo que hacen más daño que bien.

Porque ninguna de las señales que he ido enumerando es un requisito. Un correo mejor hecho no tiene erratas, usa el nombre real del Tribunal Superior de Justicia de Madrid, cita un procedimiento con el formato correcto, firma con un cargo que existe y no manda contraseñas de cuatro dígitos. Y ese correo pasaría SPF, DKIM y DMARC exactamente igual de bien que este, porque autenticar no tiene nada que ver con decir la verdad.

Si la defensa es «reconocer al malo», la defensa caduca en cuanto el malo mejora la redacción.

No decidas si el correo parece auténtico. Decide si puedes comprobar lo que afirma por un canal que no dependa del propio correo.

En este caso concreto: no abrir el adjunto, no escribir a la dirección que viene en el correo, no llamar al teléfono que viene en el correo, no pulsar el enlace que viene en el correo. Si de verdad existiera una citación, se comprueba entrando por cuenta propia en la sede judicial electrónica, llamando al juzgado con un número sacado de una fuente oficial o preguntando a tu abogado. Fíjate en que ninguna de esas tres cosas usa un solo dato del mensaje.

Y una observación que ahorra disgustos: este mensaje no se parece a una vía formal de comunicación judicial. Un adjunto anunciado como protegido, enviado a un buzón cualquiera, sin órgano ni procedimiento verificables y sin ningún camino de comprobación que no pase por el propio correo. Los cauces oficiales existen y se pueden mirar por cuenta propia: LexNET, la plataforma de comunicaciones entre órganos judiciales y profesionales, y la sede judicial electrónica. Ninguno de los dos es un archivo que te llega por correo.

Tres momentos, y no uno

Se mezclan constantemente, y la diferencia entre ellos no es el susto: es qué hay que hacer.

Antes de abrirlo. Aquí el riesgo es mínimo. Se mira la dirección completa del remitente —la dirección, no el nombre visible—, se comprueba si lo que afirma se puede verificar por otro camino, y se borra o se reporta. Sin drama y sin épica. Si es un equipo de empresa, se avisa igualmente: un correo así casi nunca llega a una sola persona.

Ya lo he abierto. Que hayas descargado un archivo no significa automáticamente que el equipo esté comprometido; depende de qué era, con qué se abrió y qué hizo el sistema después. Lo que toca es no seguir: no meter la contraseña, no habilitar contenido, no ejecutar nada, no instalar nada. Y contarlo, con detalle y sin vergüenza, a quien lleve los sistemas. La vergüenza es lo que convierte un incidente pequeño en uno grande.

He ejecutado algo, he habilitado macros o he metido credenciales. Aquí se acaba la conversación tranquila. Se desconecta el equipo de la red, se cambian desde otro equipo las contraseñas afectadas, se revisan las reglas de reenvío del buzón —el primer movimiento después de robar un correo es crear una regla que copie los mensajes a otro sitio— y se abre un incidente en condiciones. Si no hay a quién llamar, INCIBE tiene el 017, gratuito y confidencial, y un formulario de reporte de fraude.

Mezclar los tres hace daño en las dos direcciones: hay quien formatea el portátil por haber abierto un PDF, y hay quien sigue trabajando tan tranquilo después de haber tecleado su contraseña en una web clonada.

Y cómo se manda a quien lo va a mirar

Un detalle pequeño que casi nadie hace, y que es la diferencia entre poder analizar un correo y no poder.

Si se lo mandas a tu técnico, mándalo como adjunto. No reenviado del modo normal, y muchísimo menos como captura de pantalla.

Un reenvío corriente reescribe las cabeceras, y las cabeceras son justamente el material. Una captura las tira todas. Todo lo que he contado en la segunda mitad de este post —el SPF, el DKIM, la ruta, el userid 0, el X-Mailer— no existiría si lo único que tuviera delante fuese la imagen que vi en pantalla. En Thunderbird y en Outlook hay un «reenviar como adjunto»; en Gmail, «mostrar original» y descargar el mensaje.

Es exactamente la misma idea que la captura recortada de la que escribí hace unos días: lo que se recorta nunca es el ruido.

El remitente era auténtico

Volvamos al principio. Este correo pasó las comprobaciones que se ven en sus cabeceras. Salió del servidor que decía, firmado con la clave de ese servidor, desde una IP autorizada por ese dominio, cifrado en tránsito y con cero puntos de spam. Todas las respuestas técnicas sobre su procedencia son correctas.

Lo que era mentira es la historia que contaba.

Y ahí está, creo, la razón por la que esto sigue funcionando después de treinta años de filtros: hemos automatizado extraordinariamente bien la pregunta «¿de dónde viene esto?» y seguimos teniendo muchas más dificultades para automatizar «¿es verdad?». La segunda la sigue contestando una persona, normalmente a las ocho de la mañana de un lunes y con el café a medias.

A mí me ha llevado seis minutos y el correo se ha ido a la papelera. Pero lo he abierto por dentro antes de borrarlo, y por eso ahora sé algo que a las 08:03 no sabía: que un mensaje puede estar impecablemente autenticado y estar contando una mentira de principio a fin. Que la sensación de seguridad no es una medida de seguridad también vale para los pass en verde de una cabecera.

Verificar el remitente sigue siendo buena idea. Solo que verifica al remitente.

He recortado dos datos en las reproducciones de este artículo: mis direcciones de correo, que aparecen como eaymerich@… e info@…, y el identificador hexadecimal del nombre del adjunto, que aparece como XXXXXXXXXX. El dominio y la IP de origen se publican tal cual porque son un hecho comprobable del recorrido del mensaje; no sé, y este post no afirma, si pertenecen a quien envió el correo o a un tercero comprometido. El adjunto no se ha abierto ni analizado: por eso el artículo dice en todo momento que el archivo se anuncia protegido con contraseña, y en ningún momento que lo esté.