Hoja de respuestas Módulo CIBERINTELIGENCIA Nombre y apellidos Noelia Simón Durán Fecha entrega 08/03/2022 Para la resolución del ejercicio se pide responder a las siguientes preguntas utilizando esta plantilla. Se deben tener en cuenta los siguientes puntos: • • • Responder a las preguntas en el orden establecido. Limitarse a contestar a las preguntas planteadas mediante una respuesta directa que posteriormente tendrá que ser argumentada y desarrollada en detalle a partir de la información facilitada para el análisis (fichero que se puede descargar desde un enlace que hay en la página donde están estas preguntas). Como orientación, el ejercicio debe tener una extensión de entre 10 y 15 páginas. Pregunta 1 (0,5 puntos): En el caso 1, indicar el tipo de ataque realizado. Respuesta: El tipo de ataque realizado es un spear phishing. En primer lugar, se trata de un phishing porque se está realizando una suplantación para obtener información sensible. En este caso se suplanta la web de Microsoft Outlook, como se puede ver en la Figura 1. Fichero index.code1.html abierto en el navegador. Figura 1. Fichero index.code1.html abierto en el navegador El objetivo de este caso de phishing es obtener los campos de usuario (username), contraseña (password) e IP (función getenv(“REMOTE_ADDR”)) de los trabajadores de Ficticy SL. Esto se refleja en el fichero post.php, que define el método POST que utilizará la página para enviar los datos, como se puede observar en la siguiente figura. Además, se observa que tras la introducción de estos valores en el formulario se creará un mail con destino ($recipient) ejercicio_modulo1@ciberinteligencia.es, asunto ($subject) “Accounts nPost” y en el cuerpo del mensaje se incluirán los datos del usuario. Por último, se redirigirá al usuario a la web oficial de Hotmail, como se puede ver en el campo header. Figura 2. Código fichero post.php Además, es un ejemplo concreto de spear phishing puesto que la distribución del phishing no es masiva, si no que está dirigida a una compañía concreta, en este caso Ficticy SL, por lo que ha habido un mínimo de análisis o estudio hacia las víctimas, con el objetivo de obtener información sensible de la compañía. Pregunta 2 (0,5 puntos): En el caso 1, ¿qué correo es el origen del ataque? Respuesta: El correo origen del ataque es el enviado desde la cuenta: m.walker.franch@ficticy.de, con asunto: “FW: Validate Email Account” y cuerpo: “This is to notify all employees that we are validating active accounts. Please, confirm that your account is still in use by clicking the validation link below: Validate Email Account. Cheers,” Es el origen porque en él se incluye el link del phishing. Pregunta 3 (1 punto): En el caso 1, ¿dónde se envían los datos comprometidos? Respuesta: Como se ha comentado en la Pregunta 1, los datos comprometidos se envían por correo electrónico a la dirección ejercicio_modulo1@ciberinteligencia.es, como se puede ver en el fichero post.php en la variable $recipient. Figura 3. Destino de envío de los datos comprometidos Pregunta 4 (1 punto): En el caso 1, ¿por qué el correo de las 10.00 a. m. se manda desde la cuenta “m.walker.franch@ficticy.de”? ¿Desde dónde es posible que haya sido el ataque? Respuesta: La cuenta m.walker.franch@ficticy.de recibió un correo electrónico de verify@microfoft.com, que parece tratarse de una cuenta que realiza phishing suplantando a Microsoft, puesto que tiene como asunto: “FW: Validate Email Account”. Por lo tanto, todo apunta a que el usuario dueño de la cuenta m.walker.franch@ficticy.de calló en el ataque de phishing, se obtuvieron sus datos y se reenvió el correo desde su cuenta. Esto puede verse en el fichero de logs logsmail_mwalkerfranch-20171120000000_20171123170000. Se señala en azul el primer correo mencionado y en amarillo los correos reenviados. Figura 4. Logs mail m.walker.franch@ficticy.de Los correos se reenvían a partir de las 09:51 del 23/11/2017. Mirando los logs de acceso a la cuenta de m.walker.franch@ficticy.de (logs-access_mwalkerfranch20171120000000_2017112319000000), se puede ver que todas las conexiones se realizan desde el mismo rango de IPs: 172.16.10.XX, excepto el acceso del 23/11/2017 a las 09:45, que se realiza desde la IP 77.72.83.26 (en azul en la Figura 5), que además coincide en franja horaria con el reenvío de correos. Por lo tanto el ataque se realiza desde esta última IP, con ubicación en Reino Unido. Figura 5. Logs de acceso m.walker.franch@ficticy.de Pregunta 5 (1 punto): En el caso 1, ¿qué otras cuentas han podido ser comprometidas? Respuesta: Como se puede ver en la Figura 4. Logs mail m.walker.franch@ficticy.de), las cuentas de correo que han podido ser comprometidas son a las que se ha reenviado el correo (en la imagen en naranja). Estas cuentas son: m.will.smith@ficticy.us, l.stephan.martin@ficticy.co.uk, l.martin.fierre@ficticy.es, j.rodriguez.maceda@ficticy.es y s.mick.resce@ficticy.nl. Pregunta 6 (0,5 puntos): En el caso 2, indicar el tipo de ataque realizado. Respuesta: El ataque realizado es un ataque de tipo CEO Fraud, donde se estudia a la víctima para presionarla a realizar un pago de manera urgente, haciéndose pasar por un cargo importante de su empresa o un contacto importante relacionado con la empresa. En este caso, el atacante se hace pasar por proveedor de TI y solicita a la víctima un cambio del número de cuenta bancaria para realizar los pagos, metiendo prisa con motivo de una auditoría, como se verá en detalle en la pregunta 7. Tras la explicación de la pregunta 7, se puede ver que el atacante probablemente haya realizado un análisis de la víctima, en este caso Juan Philips Todobene, mediante sus redes sociales, por ejemplo, observando así que es el Responsable de pagos y transferencias. Además se puede ver en los logs de MTA departamento de transferencias que el atacante realiza varios intentos de envío del correo fraudulento hasta dar con la cuenta de correo correcta de Juan (se marca en amarillo en la Figura 6 el correo origen del ataque). Figura 6. Logs de MTA del departamento transferencias Pregunta 7 (0,5 puntos): En el caso 2, ¿qué correo es el origen del ataque? Respuesta: El origen del ataque es el correo recibido por j.philips.todobene@ficticy.es (en adelante Juan), con asunto “New account”, remitente transfer@mailer.com (en adelante atacante) e ID 27665, como se puede ver en la Figura 6. Logs de . Esto es porque, al descomprimir el ZIP tomando como contraseña el ID anteriormente mencionado, se obtienen los correos codificados, se decodifican en Base64. Finalmente, se obtiene que el atacante se hace pasar por un proveedor de TI y solicita a Juan un cambio del número de cuenta bancaria para realizar los pagos. Juan dice que necesita un documento certificado para justificar el cambio pero el atacante mete prisa con la excusa de una auditoría, por lo que Juan hace la modificación del número de la cuenta de pago bajo presión. Se incluye a continuación la decodificación de los correos de más reciente a más antiguo como justificación. From: "Transfer account" <transfer@mailer.com> Sent: Thu, 23 Nov 2017 14:54:21 To: "Philips Todobene, Juan" <j.philips.todobene@ficticy.es> Sent: Thu, 23 Nov 2017 14:54:21 Subject: New account Perfect!! thanks! I'll send you the documento ASAP From: "Philips Todobene, Juan" <j.philips.todobene@ficticy.es> Sent: Thu, 23 Nov 2017 10:56:12 To: "Transfer account" <transfer@mailer.com> Subject: RE: New account Ok, the change is done From: "Transfer account" <transfer@mailer.com> Sent: Thu, 23 Nov 2017 10:45:43 To: "Philips Todobene, Juan" <j.philips.todobene@ficticy.es> Subject: RE: New account Hello Juan, I will send you the document within the next days, but it is critical to make the change immediately due to auditory requests. Thanks in advance, Regards From: "Philips Todobene, Juan" <j.philips.todobene@ficticy.es> Sent: Thu, 23 Nov 2017 09:30:54 To: "Transfer account" <transfer@mailer.com> Subject: RE: New account Hello, I need a guarantee for the change, could you please provide me a certificated document? Regards, From: "Transfer account" <transfer@mailer.com> Sent: Wed, 22 Nov 2017 18:00:35 To: j.philips.todobene@ficticy.es Subject: New account Hello Juan, I write you on behalf of your IT provider. Please, note the change of the bank-account where you have to make the payment. INTEXER67 1026 7842 0814 5674 1236 8905 Please, the next payment must be made to that account. Regards, IT Team Pregunta 8 (1 punto): En el caso 2, ¿qué método ha utilizado el atacante para obtener los datos de los empleados del Departamento de Transferencias? Respuesta: El método que ha utilizado el atacante es la Ingeniería Social. Esto se puede llevar a cabo de diversas formas como buscar información en Google o mirar sus perfiles en distintas redes sociales, en este caso para Juan Facebook, Linkedin e Infojobs, entre otras técnicas. La meta de esta búsqueda se centra en recopilar toda la información de la posible víctima que sirva de ayuda al atacante, como puede ser: cargo dentro de la empresa, funciones, correo electrónico o empresas con las que trabaja, entre otros datos. De esta manera el atacante obtiene que Juan es el Responsable de pagos y transferencias dentro de Ficticy, fijando así el objetivo del ataque. Pregunta 9 (1 punto): En el caso 2, ¿cómo ha sido la consecución temporal de los hechos? Respuesta: En primer lugar, el atacante realiza Ingeniería Social para averiguar quién es el Responsable de pagos y transferencias y fija su objetivo en Juan. Después, envía correos electrónicos con direcciones de destino en distintos formatos (Figura 6. Logs de MTA del departamento transferencias) hasta dar con la cuenta correcta de Juan. Tras esto, presiona a Juan para que cambie la cuenta de pago con el pretexto de una auditoría para meterle prisa. Finalmente, Juan realiza el cambio bajo presión. Se resumen los hechos en la siguiente tabla: Fecha 22/11/2017 23/11/2017 23/11/2017 23/11/2017 23/11/2017 Hora Origen Destino Hecho/Mensaje 18:00:35 Atacante Juan Solicitud cambio de número de cuenta 9:30:54 Juan Atacante Solicitud de documentación para realizar el cambio 10:45:43 Atacante Juan Presión con auditoría 10:56:12 Juan Atacante Cambio de número de cuenta realizado 14:54:21 Atacante Juan Envío del documento en los próximos días Tabla 1. Consecución temporal de los hechos Pregunta 10 (0,5 puntos): En el caso 3, indicar el tipo de ataque realizado. Respuesta: El tipo de ataque realizado es a través de malware, un software malicioso que se crea para acciones ilegítimas. En este caso, al mostrar el siguiente mensaje: “# C:\WINDOWS\mssecsvc.exe # Ransom-WannaCry!7339A0EFC768 # trojan # deleted # 1 # VIRUS_DETECTED_REMOVED # VIRUSCAN8800 # VirusScan Enterprise #” y además ver que todos los archivos cifrados tienen la extensión “.wncry”, se puede deducir que es un ransomware, concretamente el conocido WannaCry. Figura 7. Mensaje WannaCry El ransomware es un tipo de malware que cifra archivos de la víctima, como se puede ver en el mensaje de la Figura 7. Los ficheros o directorios a fichar se definen en la configuración del ransomware pero nunca se cifran archivos de funcionamiento esencial. Esta operación se realiza para obtener un beneficio económico por el rescate de estos archivos. Normalmente, el atacante tras recibir el pago facilita a la víctima la clave privada de cifrado para recuperar los archivos originales. Un ejemplo de fichero cifrado es el que se incluye en este caso, test.txt.wncry, se incluye su captura de pantalla. Figura 8. text.txt.wncry Pregunta 11 (0,5 puntos): En el caso 3, indicar la vulnerabilidad explotada en los sistemas. Respuesta: La vulnerabilidad que explota el ransomware WannaCry es generalmente la exposición del puerto de SMB (Server Message Block) 445 a Internet. SMB es un protocolo que permite a los distintos sistemas Windows permanecer conectados a la misma red para compartir archivos. Para lanzar un ataque WannaCry se puede usar el el kit de explotación EternalBlue + DoublePulsar. El objetivo es instalar el malware en los equipos vulnerables y que se propague, mediante SMB, a través de la red en la que se encuentra dicho equipo. Este ataque fue muy conocido hace unos años y Microsoft lanzó un parche de actualización para solventar esta vulnerabilidad en sus equipos. Como se puede ver en la captura de pantalla de la Figura 9. Configuración del Firewall, para el puerto 445, se permite todo el tráfico (VPN = any traffic, ACTION = accept), lo que quiere decir que el puerto 445 está expuesto a cualquier tipo de tráfico y es una vulnerabilidad del sistema o servicio. Por lo tanto, una vez el malware infecte un sistema, se podrá propagar por toda la red infectando los demás equipos que también tengan esta vulnerabilidad. Figura 9. Configuración del Firewall Pregunta 12 (1 punto): En el caso 3, ¿cómo se ha propagado el malware a través de la red interna? Respuesta: Para ver como se ha propagado el malware a través de la red interna, se puede comprobar el fichero de logs del Firewall. En este fichero se puede ver en detalle el tráfico de una dirección de origen a otra de destino dentro de la red de Ficticy, todo este tráfico se realiza a través del puerto 445, que, con motivo de la regla del Firewall, siempre es aceptado. Se ha realizado un tratamiento del fichero para resumir este tráfico y analizar la propagación del malware a través de la red interna, se incluye una captura a continuación. Figura 10. Logs del Firewall El tratamiento consiste en haber eliminado las filas intermedias para una misma dirección de origen, dejando únicamente la dirección de destino inicial y final, ya que se ha observado que el envío del tráfico se hace en direcciones IP consecutivas e incrementales. El procedimiento es infectar una máquina y que esta se encargue de infectar a otras, así sucesivamente. Por lo tanto, la propagación del malware ha sido la siguiente, se utilizan los mismos colores que en la Figura 8 para diferenciar las direcciones de origen: • En primer lugar, se infecta la máquina con dirección IP 172.31.133.68. • Desde la dirección 172.31.133.68 se intenta infectar a los equipos con direcciones comprendidas entre la 172.32.133.69 y la 172.31.133.83. • Se infecta al equipo con dirección IP 172.32.133.69. • Desde la dirección 172.31.133.69 se intenta infectar a los equipos con direcciones comprendidas entre la 172.32.133.70 y la 172.31.133.78. • Se infecta al equipo con dirección IP 172.32.133.78. Esto puede haberse realizado desde cualquiera de las dos direcciones IP de origen mencionadas anteriormente (172.31.133.68 y 172.31.133.69), ya que ambas dirigen el ataque hacia direcciones IPs coincidentes (de la 172.32.133.75 a la 172.32.133.78). • Desde la dirección 172.31.133.78 se intenta infectar a los equipos con direcciones comprendidas entre la 172.32.133.12 y la 172.31.133.32. • Se infecta al equipo con dirección IP 172.32.133.25. • Desde la dirección 172.31.133.25 se intenta infectar a los equipos con direcciones comprendidas entre la 172.32.133.28 y la 172.31.133.136 (solapando algunas direcciones IPs de intentos anteriores). • Se infecta al equipo con dirección IP 172.31.133.101. • Por último, desde la dirección 172.31.133.101 se intenta infectar a los equipos con direcciones comprendidas entre la 172.32.133.135 y la 172.31.133.159. Cabe destacar que es posible que haya otros equipos de la red infectados, en los casos anteriores se indica únicamente la propagación mostrada en los logs del Firewall. Pregunta 13 (1 punto): En el caso 3, indicar de 3 a 5 medidas imprescindibles que podrían haber evitado el ataque. Respuesta: La primera medida y la más importante es mantener los equipos actualizados en su última versión del software. Así, los equipos poseerían el parche de seguridad lanzado por Microsoft y no tendrían la vulnerabilidad anteriormente comentada. Otra medida importante y que se suele seguir en todas las redes o sistemas que otorguen privilegios a distintos usuarios o equipos, es otorgar los mínimos privilegios posibles. Así, se podría haber frenado la propagación del malware entre los sistemas de la red. En tercer lugar, configurar el Firewall de red para no permitir el tráfico no deseado, ya sea bloqueando el tráfico mediante SMB cerrando el puerto TCP 445 si no se va a utilizar, restringiendo este tráfico solo a ciertos equipos, entre otros casos. De esta manera, como en el caso anterior, se frenaría la propagación del malware entre los sistemas de la red. Como cuarta medida, más que una manera de evitar el ataque se trata una tarea de prevención de daños, se podría realizar copias de seguridad de forma periódica para no perder los archivos en casos de ataques como el que se trata. Así, en el caso de que un ransomware cifre los archivos, se tendría una copia de seguridad de los mismos y no se perdería información. Aun así, esta medida no evita que los archivos o información sensible de los sistemas sean robados, por ejemplo. Por último, como medida de prevención se podría formar a los empleados sobre ciberseguridad en la empresa. Por ejemplo, si los empleados saben reconocer qué es un phishing, qué sitios web son maliciosos, qué archivos que van a abrir o descargar son maliciosos, entre otras cosas, podrían evitar este tipo de ataques y muchos otros.
