Falsificar correo, omitir SPF | ¿Cómo simular un ataque de correo electrónico falso y evitar la verificación del remitente SPF? | 2#2 |.com
En el artículo actual, demostraremos cómo simular un ataque de correo electrónico falso, que evitará la implementación de verificación de remitente SPF existente.
La serie de artículos actual incluye dos artículos.
El artículo anterior es: ¿Cómo puede un elemento hostil ejecutar un ataque de correo electrónico falso y evitar la implementación SPF existente? | introducción | 1#2
Descargo de responsabilidad
Para evitar cualquier duda, el propósito de esta demostración no debe aplicarse , de cualquier forma o modo para explotar y atacar a organizaciones.
El único propósito de este artículo es brindarle una forma de verificar la configuración de seguridad del correo de su infraestructura de correo existente, de modo que pueda conocer las vulnerabilidades existentes en su infraestructura de correo y encontrar las soluciones necesarias para mitigar y bloquear la vulnerabilidad. “agujeros” que pueden y probablemente serán explotados por una variedad de elementos hostiles.
| THIS CODE AND ANY ASSOCIATED INFORMATION ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK OF – USE, INABILITY TO – USE, OR RESULTS FROM THE – USE OF THIS CODE REMAINS WITH THE – USER. |
Cómo simular un ataque de correo electrónico falso y evitar la verificación del remitente SPF | Paso a paso
Implementar los arreglos necesarios requeridos.
Para poder alcanzar los dos objetivos principales:
- Triunfe en un ataque simulado de correo electrónico falso
- Omitir con éxito la verificación de verificación del remitente de SPF
Hemos hecho estos preparativos preliminares:
- Compre un nombre de dominio ficticio: el propósito del nombre de dominio ficticio es servir como señuelo para el proceso de verificación del remitente SPF que implementará el servidor de correo que representa al destinatario de destino.
- Configure el registro SPF requerido en el servidor DNS que aloja el nombre de dominio ficticio.
- Agregue la información requerida, es decir, la dirección IP del servidor de correo que utiliza para realizar ataques de suplantación de identidad o phishing.
En la siguiente captura de pantalla, podemos ver un ejemplo del SPF (un registro TXT) que se creó para el “nombre de dominio ficticio” -thankyouforsharing.org
La dirección IP que aparece es la dirección IP del servidor de correo que utiliza el elemento hostil para enviar el correo electrónico falso al destinatario de destino.
Nuestros personajes falsos del escenario de simulación de ataque por correo electrónico
Para poder demostrar la forma en que ese elemento hostil puede usarse para implementar un ataque de correo electrónico falso + eludiendo la verificación de verificación del remitente SPF, usemos el siguiente escenario:
Un elemento hostil planea atacar (ejecutar un ataque de Spoofing\Spear Phishing) a la empresa denominada - o365pilot.com
- El destinatario al que el elemento hostil busca atacar es Bob, el director general de la empresa que utiliza la
dirección de correo electrónico bob@o365pilot.com - La identidad falsa que utilizará el elemento hostil es la identidad de Suzan, la directora financiera de la empresa que utiliza la dirección de correo electrónico suzan@o365pilot.com
- El elemento hostil sabe que la infraestructura de correo de o365pilot.com implementa una verificación de remitente SPF para cada correo entrante.
- Para poder eludir la verificación del remitente del SPF, el elemento hostil utiliza un nombre de dominio ficticio llamado - thankyouforsharing.org
El elemento hostil utilizará un mensaje de correo electrónico que incluye dos direcciones de correo electrónico del remitente:
- evil@thankyouforsharing.org
- suzan@o365pilot.com
Uso de una sesión SMTP Telnet para ejecutar el ataque de correo electrónico falso
En la siguiente sección, revisaremos cómo ejecutar una simulación de un ataque de correo electrónico falso en el que utilizamos una sesión de telnet SMTP para ejecutar el ataque.
El cliente telnet que utilizamos
Técnicamente, podemos usar el cliente telnet integrado de Windows, pero este cliente telnet es un poco limitado y no tan convencional.
Personalmente, me gustaría trabajar con una aplicación telnet dedicada. Hay una variedad de clientes telnet gratuitos. En nuestro escenario específico, utilizo un cliente telnet muy agradable llamado - conemu
Las dos partes de la sesión de telnet SMTP
Para mí es importante enfatizar las "dos partes" de la sesión de telnet SMTP:
- La primera parte (A), es la parte en la que demandamos los comandos SMTP que están relacionados con
el Sobre de correo parte. - La primera parte (B), es la parte en la que demandamos los comandos SMTP que están relacionados con
el encabezado del correo .
El conjunto de dos identidades que utilizamos en la sesión de telnet SMTP.
Para poder eludir la verificación del remitente del SPF, usaremos un conjunto de dos identidades:
- Identidad de la dirección de correo electrónico ficticia: evil@thankyouforsharing.org (la dirección de correo electrónico que pertenece al sobre de correo).
- La dirección de correo electrónico falsificada:bob@o365pilot.com (la dirección de correo electrónico que pertenece al encabezado del correo).
En la siguiente captura de pantalla podemos ver la “sesión telnet SMTP completa” que simula el ataque de correo electrónico falso:
- El propósito de la primera parte es “ocupar” el servidor de correo de destino con información “no útil” que nos ayudará a presentarnos como una organización legítima.
- El propósito de la segunda parte es enviar el correo electrónico falso que incluye información sobre el remitente falsificado.
En la siguiente sección proporcionaremos una descripción “paso a paso” de los comandos telnet SMTP que utilizamos:
0. Dirigirse al servidor de correo de destino
Uso de una sesión de telnet SMTP para comunicar el servidor de correo de destino
Para poder abordar el “servidor de correo de destino”, es decir, el servidor de correo que representa el dominio que queremos atacar (En nuestro ejemplo, el servidor de correo que representa el dominio o365pilot.com), necesitamos saber el nombre de host o la dirección IP del servidor de correo de destino (el nombre de host que aparece en el registro MX para el nombre de dominio en particular).
Los comandos telnet que utilizamos para iniciar una sesión SMTP con otro servidor de correo son:
Telnet <Mail server Hostname \ IP address> 25
1. Inicialice la sesión SMTP
El primer comando que usamos es el comando HELO que usamos para inicializar la sesión con el servidor de correo remoto.
Técnicamente hablando, no tenemos que proporcionar ninguna información adicional además del comando HELO , pero en nuestro escenario, nuestro objetivo principal es presentarnos como un servidor de correo legítimo que representa el nombre de dominio - thankyouforsharing.org
Por este motivo, especificaremos el nombre de dominio después del comando helo.
La sintaxis del comando que utilizamos es
helo thankyouforsharing.org2. Proporcione la identidad del remitente
En esta parte, proporcionamos la identidad del remitente (la dirección de correo electrónico del remitente) mediante el
comando: FORMULARIO DE CORREO
Nota: Observe que la identidad del remitente está relacionada con el "dominio ficticio" que utilizamos. Esta no es la identidad del remitente que queremos proporcionar al usuario final, sino simplemente una identidad temporal que engañará al servidor de correo de destino que realiza la prueba de verificación SPF.
La sintaxis del comando que utilizamos es
mail from: evil@thankyouforsharing.org3. Proporcione la identidad del destinatario.
En esta parte, proporcionamos la identidad del destinatario (la dirección de correo electrónico del remitente) mediante el comando: RCPT TO:
En nuestro escenario, queremos enviar un correo electrónico falso al destinatario de destino, Bob.
La sintaxis del comando que utilizamos es
rcpt to: bob@o365pilot.com
En esta etapa hemos “terminado” la fase de Sobre de correo.
Técnicamente hablando, para poder enviar el correo electrónico al destinatario de destino, no necesitamos proporcionar "información de identidad" adicional.
El propósito de esta fase es proporcionar la información requerida para “construir” la parte Encabezado de correo. El significado es: las identidades del remitente y del destinatario + la información que aparecerá en el mensaje de correo electrónico que se envió al destinatario de destino.
Solo un recordatorio rápido: en la fase del encabezado del correo, usamos el comando FROM para especificar la identidad del remitente y el comando TO especificando la identidad del destinatario de destino.
4. Inicializando la sección del encabezado del correo
Para poder “señalar” al servidor de correo de destino que queremos iniciar la fase de encabezado de correo, usamos el comando -
data5. Proporcionar la identidad falsificada del remitente
En este paso, proporcionamos la "identidad aparente" del director financiero de la empresa: Suzan.
Para que la identidad falsa parezca una identidad confiable a los ojos del destinatario de destino, proporcionaremos dos partes separadas de “La identidad de Susan” -
Suzan Nombre para mostrar + Dirección de correo electrónico de Suzan
- El nombre para mostrar del remitente falsificado es la cadena que aparece entre las comillas.
- La dirección de correo electrónico falsificada del remitente es la dirección de correo electrónico entre corchetes angulares.
La sintaxis del comando que utilizamos es:
from: "Suzan the CFO" <Suzan@o365pilot.com>6. Proporcionar la identidad del destinatario de destino
Técnicamente hablando, no es obligatorio proporcionar la dirección de correo electrónico del destinatario de destino. La razón por la que proporcionamos la dirección de correo electrónico es que cuando utilizamos una sesión de telnet, si el campo TO está vacío, la información sobre el destinatario se muestra como - “Destinatarios no divulgados“
La sintaxis del comando que utilizamos es:
to: bob@o365pilot.comEn esta fase definiremos el asunto del mensaje de correo electrónico + el contenido del correo.
7. Proporcionar el asunto del mensaje de correo electrónico
Para poder definir el contenido del mensaje de correo electrónico que incluirá asunto + el texto que queremos enviar, utilizamos el comando asunto: + el texto requerido.
En nuestro escenario específico, usaremos el comando de asunto + el siguiente texto
subject: Hello Bob, an important message,8. Agregue un espacio entre el asunto en el cuerpo del correo.
Para poder agregar el texto de correo requerido que aparecerá en el mensaje de correo electrónico, debemos agregar un espacio entre el comando del asunto y el texto que agregaremos.
Utilice la tecla ENTER para crear el espacio requerido.
9. Proporcionar el texto del mensaje de correo electrónico.
En nuestro escenario específico, agregaremos la siguiente cadena de texto
Please transfer to the following bank account - 4589865, the amount of million dollars ASAP!10. “Finalizar” la sesión SMTP con el servidor de correo
Para poder “finalizar” la sesión SMTP utilizamos el carácter de punto.
Utilice un punto .
El resultado de nuestro ataque de correo electrónico falso
En la siguiente captura de pantalla, podemos ver el correo electrónico falso que se envió a nuestro
destinatario de destino: Bob. Observe que el mensaje de correo electrónico parece un mensaje de correo electrónico legítimo.
Sólo "insinuar" el hecho de que el mensaje de correo electrónico en particular no es un "mensaje de correo electrónico estándar" (correo electrónico falso en nuestro escenario) es la forma que utiliza el cliente Outlook para mostrar la información sobre la identidad del remitente.
Cuando miramos en profundidad la “parte superior” del mensaje de correo electrónico, podemos notar que la información sobre el remitente incluye el mensaje de correo electrónico del remitente< /lapso>.
Este comportamiento no se considera un “comportamiento normal” de un destinatario legítimo.
En la siguiente captura de pantalla, podemos ver un ejemplo de un correo electrónico enviado por el "usuario real". Cuando el correo electrónico es un mensaje de correo electrónico legítimo, el cliente de correo como Outlook u OWA mostrará solo el nombre para mostrar del remitente.
Si se pregunta cómo Outlook "se dio cuenta" de que el mensaje de correo electrónico fue enviado por un "destinatario estándar de la organización", la respuesta es que cuando usamos la sesión de telnet, proporcionamos la dirección de correo electrónico falsificada, pero no lo hicimos. No proporcione ninguna credencial de usuario.
Por este motivo, el destinatario se identifica como Anónimo (la información se guarda en un campo de correo llamado - X-MS-Exchange-Organization-AuthAs ).
Cuando Outlook u OWA reconocen un escenario en el que el remitente se considera Anónimo, la información sobre el remitente incluirá la dirección de correo electrónico del remitente de origen.
Analizar la información del correo electrónico falso mediante el uso de un analizador de correo electrónico
En la siguiente sección, revisaremos la forma que podemos utilizar para analizar la información que se guardó en el encabezado del correo electrónico falso que se envió a Bob.
El proceso en el que examinamos las “evidencias” que se guardan en el encabezado del Mail podría considerarse como un proceso de ingeniería inversa de un proceso forense en el que utilizamos las evidencias existentes para sacar conclusiones sobre hechos ocurridos en el pasado.
La información que se guarda en el encabezado del correo incluye muchos detalles importantes y "consejos" que podemos utilizar para comprender mejor los eventos que ocurrieron durante el procesamiento de la simulación de ataque de correo electrónico Spoof
.
Técnicamente, podemos analizar la información en el encabezado del mensaje de correo electrónico usando un editor de texto simple como el Bloc de notas, pero la opción preferida es usar un analizador de correo.
En nuestro ejemplo específico, utilizaremos la herramienta web de Microsoft ExRCA (analizador de conectividad remota de Exchange) para analizar la información que se guardó en el encabezado del correo.
¿Cómo "extraer" la información del encabezado del correo electrónico?
Obtienen la información que está "almacenada" en el mensaje de correo electrónico (el correo electrónico falso que se envió al destinatario Bob), debemos elegir el mensaje de correo electrónico específico, elegir el Archivo menú
y luego la opción - Propiedades.
- Selecciona la información que aparece en el - encabezado de Internet
- Copia la información (podemos utilizar la combinación de teclas COPIAR + C).
Accederemos al sitio web de ExRCA (Analizador de conectividad remota de Exchange) utilizando la siguiente dirección URL: https://testconnectivity.microsoft.com/
- Seleccione la pestaña - Analizador de mensajes
- En el cuadro de texto vacío pegamos la información copiada en el paso anterior (podemos usar la combinación de teclas COPIAR + V ).
- Haga clic en el botón Analizar encabezados
En la parte superior de la pantalla podemos ver la información sobre la identidad del remitente y del destinatario.
En la sección de resumen (A), observe que la información sobre estas "identidades" es la información que hemos proporcionado en la segunda fase de la sesión de telnet, que describimos como la "fase del encabezado del correo".
Como se mencionó, el servidor de correo elimina el Sobre de correo que incluye información sobre la identidad del remitente almacenada en el FORMULARIO DE CORREO.
En nuestro escenario específico, la dirección de correo electrónico que utilizamos en el campo FORMULARIO DE CORREO era - evil@thankyouforsharing.org.
La información sobre esta dirección de correo electrónico que se eliminó en el encabezado del correo incluirá información sobre la dirección de correo electrónico del remitente que aparece en TO campo de correo.
La “información del remitente” que aparece es la información que ve el destinatario de destino (Bob). En otras palabras, desde la perspectiva de Bob, la dirección de correo electrónico fue enviada por Suzan, la directora financiera de la empresa.
En la sección del encabezado recibido (B), podemos ver información sobre el servidor de correo que estuvo involucrado en el flujo de correo.
La información sobre cada uno de los servidores de correo incluye la dirección IP del servidor de correo y en caso de que el servidor de correo proporcione su "nombre" (el término "nombre" podría traducirse como nombre de host, el nombre de dominio del FQDN).
En nuestro escenario específico, el servidor de correo que utilizamos para simular el ataque de correo electrónico falso proporciona su nombre: thankyouforsharing.org
La información sobre el nombre de host del servidor de correo la proporcionamos nosotros en la sesión de telnet SMTP, al inicio de la sesión cuando usamos HELO comando.
Nivel de confianza de phishing
El valor de PCL (Nivel de confianza de phishing) es - 0.
El significado es que el mensaje de correo electrónico no se reconoce como phishing o correo electrónico falso.
Resultados de autenticación
En la sección denominada - Authentication-Results, podemos ver la siguiente información:
spf=pass (la IP del remitente es 212.25.80.239) smtp.mailfrom=thankyouforsharing.org
El significado de esta información es que, desde el punto de vista del servidor de correo de destino que realiza la prueba de verificación del remitente SPF, la verificación se completa con éxito (spf=pass).
Sólo para recordarles, uno de nuestros objetivos principales en esta “simulación de ataques de correo electrónico falsos” fue demostrar que podemos eludir la implementación de protección SPF existente.
El servidor de correo (el servidor de correo que aloja al destinatario al que queremos atacar) nos “informa”, que comprueba la dirección de correo electrónico que aparece en el MAIL FORM campo que en nuestro escenario era - evil@thankyouforsharing.org
(smtp.mailfrom=graciasporcompartir.org)
Tenga en cuenta que cuando se utiliza la verificación del remitente SPF, la verificación se refiere al "nombre de dominio" y no a la "dirección de correo electrónico completa".
Recibido-SPF
En el apartado denominado - Received-SPF, podemos ver una información adicional:
Podemos ver que el servidor de correo de destino (el servidor de correo que aloja a Bob) nos informa que el servidor de correo que representa el nombre de dominio thankyouforsharing.org, considere que es un servidor de correo legítimo: thankyouforsharing.org designa 212.25.80.239 como remitente permitido.
Pass (protection.outlook.com: el dominio deThankyouforsharing.org designa 212.25.80.239 como remitente permitido) Receiver=protection.outlook.com; IP del cliente=212.25.80.239; helo=graciasporcompartir.org;
Como ya hemos aprendido, el servidor de correo de destino elimina el sobre de correo después de finalizar el procedimiento requerido para aceptar el mensaje de correo electrónico. .
Entonces, en teoría, no hay información sobre el remitente mencionado en el sobre de correo (el campo MAIL FROM).
Esta suposición es correcta, salvo una excepción: el campo RETURN-PATH.
La definición estándar SMTP de que la responsabilidad del servidor de correo de destino es “buscar” la dirección de correo electrónico que aparece en el FORMULARIO DE CORREO y copia esta dirección de correo electrónico en el campo RETURN-PATH.
El servidor de correo de destino “borra” la información que aparece en el Sobre de correo, pero hay una cosa que el servidor de correo de destino hace antes de elimina el sobre de correo: copie la información que aparece en el campo FORMULARIO DE CORREO a un campo de correo adicional llamado - RUTA-RETORNO.
El propósito de este campo de correo es contener la dirección de correo electrónico que se utilizará en caso de que el
mensaje de correo electrónico no pueda enviarse al destinatario de destino.
En caso de que el servidor de correo de destino necesite notificar al “remitente de origen” sobre algún problema, el mensaje NDR se enviará a esta dirección de correo electrónico (la dirección de correo electrónico que se registró como RUTA-RETORNO).
En nuestro escenario, la dirección de correo electrónico (la “dirección de correo electrónico ficticia”) que aparece en el sobre del correo era evil@thankyouforsharing.org<
El servidor de correo de destino copió esta dirección de correo electrónico y el resultado es que este mensaje de correo electrónico rellena el campo RETURN-PATH .
En otras palabras, la única “evidencia” que tenemos del “truco” implementado por el elemento hostil es la información almacenada en RETURN-PATH campo.
X-MS-Exchange-Organization-AuthAs: autenticación versus remitente no autenticado
El último detalle que me gustaría revisar es la parte en la que clasificamos al remitente de origen como “destinatario conocido” o remitente anónimo.
En nuestro escenario, el elemento hostil falsifica la identidad de un usuario legítimo de la organización presentándose como suzan@o365pilot.com
A pesar de que logramos "evitar" el mecanismo de verificación del remitente SPF y logramos enviar el mensaje de correo electrónico al buzón del destinatario de destino, el remitente no proporcionó las credenciales de usuario.
Por este motivo, el remitente fue clasificado como Anónimo.
Esta información sobre esta “observación”, puede ayudarnos a identificar y detectar mensajes de correo electrónico que logran eludir nuestro “muro SPF”.
