- Phishing con Gophish – Parte 1: instalación, configuración y acceso al laboratorio
- Phishing con Gophish – Parte 2: preparativos y configuraciones adicionales
- Phishing con Gophish – Parte 3: envío de campañas
En la entrada anterior hemos instalado, configurado y accedido al laboratorio desde el cual vamos a lanzar las campañas de phishing simuladas/controladas.
Llegados a este punto tenemos que pararnos a pensar y ponernos en la piel de un atacante real. ¿Qué se necesita para lanzar una campaña de phishing?
Seleccionar la víctima
Lo primero que se me viene a la cabeza es seleccionar la víctima. En casos reales suelen ser un conjunto de destinatarios sin ningún tipo de criterio y normalmente obtenidos de leaks publicados en foros de venta de información de la darkweb. No obstante, también existen ataque dirigidos y muy estudiados a organizaciones. Los atacantes suelen seleccionar un dominio a atacar y realizan enumeración sobre este (OSINT) obteniendo principalmente cuentas de correo electrónico, información de servicios web (como portales de inicio de sesión) y servicios de otra índole que luego suplantaran.
En nuestro caso, vamos a escoger una organización que nos haya dado su previo consentimiento para realizar este tipo de ejercicios simulados con el objetivo de concienciar a sus empleados o cuentas personales que tengamos bajo nuestro control absoluto. Yo voy a escoger solo un destinatario:
Podríamos hacerle también una sorpresita a @albertoj pero vamos a ser buenos 😆
Obtener un dominio para la campaña
La elección del dominio es vital para garantizar el éxito de la campaña. El dominio servirá para:
- Engañar a las víctimas
- Generar confianza sobre la red y no ser marcado como SPAM. Ahora desarrollamos esto en profundidad.
- PD: si vas a realizar un simulacro de phishing controlado sobre una organización no debes de preocuparte por la confianza de la red. Puedes generar excepciones sobre la pasarela destinataria de correos así como en las diferentes herramientas de seguridad (siempre que la organización te permita hacerlo)
Engañar a las víctimas con técnicas de suplantación de dominios
Existen gran cantidad de técnicas de suplantación de dominios. Os adjunto un listado con las más relevantes:
- Typesquatting (Typo Squatting):
- Esta técnica implica registrar dominios con errores tipográficos (por ejemplo, «gogle.com» en lugar de «google.com»).
- Cybersquatting:
- Registro de dominios que son similares o contienen nombres de marcas conocidas con la intención de confundir a los usuarios o extorsionar a la empresa dueña de la marca.
- Combosquatting:
- Registro de dominios que combinan una palabra clave legítima con otra palabra o término adicional para parecer legítimos (por ejemplo, «secure-google.com» o «login-microsoft.com»).
- Subdomain Attacks:
- Creación de subdominios convincentes bajo un dominio legítimo o similar (por ejemplo, «secure.google.com.fakewebsite.com» donde «fakewebsite.com» es el dominio real).
- Domain Shadowing:
- Compromiso de cuentas de registro de dominios para crear subdominios maliciosos en un dominio legítimo comprometido, permitiendo a los atacantes alojar páginas de phishing sin levantar sospechas inmediatas.
- URL Shortening Phishing:
- Utilización de servicios de acortamiento de URL para ocultar el verdadero destino del enlace, redirigiendo a las víctimas a dominios maliciosos sin que puedan verificar previamente la URL completa.
- Punycode Exploits:
- Se trata de aprovechar Punycode, una representación de caracteres Unicode en ASCII, para registrar dominios que parecen legítimos pero redirigen a sitios maliciosos (por ejemplo, «xn--pple-43d.com» que puede parecer «apple.com»). Se suele hacer uso de caracteres similares o idénticos en apariencia de diferentes alfabetos para crear dominios engañosos. Por ejemplo, utilizar caracteres cirílicos que parecen caracteres latinos. Algunos navegadores pueden no mostrar el dominio en formato Punycode y esto lo hace aún más peligroso.
- Domain Hijacking:
- Obtención ilegal del control sobre un dominio legítimo a través de técnicas de ingeniería social, hacking o aprovechando vulnerabilidades en los registros de dominios.
- TLD (Top-Level Domain) Manipulation:
- Utilización de dominios de nivel superior menos comunes o específicos de ciertos países para crear dominios engañosos (por ejemplo, «example.co» en lugar de «example.com» o «example.ru» en lugar de «example.com»).
- Sound-alike Domains:
- Registro de dominios que suenan similares a los dominios legítimos cuando se pronuncian (por ejemplo, «bankofamericae.com» podría sonar como «bankofamerica.com»).
- Look-alike Domains:
- Creación de dominios que visualmente se parecen a los dominios legítimos mediante el uso de caracteres especiales o de aspecto similar (por ejemplo, «paypa1.com» en lugar de «paypal.com»).
- Transposición
- Se trata de intercambiar dos letras del dominio. Por ejemplo: «paypla.com»
- Singularización/Pluralización
- Agregar o eliminar una -s al final del dominio en caso de que este la tenga. Por ejemplo: «elpaiss.com»
- TLD duplicado sin punto
- Agregar el TLD al final del dominio sin punto. Por ejemplo: «paypalcom.com»
Existen algunas herramientas como dnstwist que realizan algunas de las anteriores técnicas de manera automática.
Generar confianza sobre la red y no ser marcado como SPAM
Hay que tener en cuenta a la hora de obtener un dominio la antigüedad de este. Cuanto más antiguo sea un dominio más probable es que se considere como confiable. Además de esto, también afecta que no este marcado como SPAM en listados especializados como Spamhouse. Existen herramientas como MXToolBox que comprueban automáticamente si la IP o dominio origen desde el cual enviarás la campaña de phishing esta marcado como SPAM.
Con lo que tienes dos opciones:
- Comprar un dominio existente con buena reputación y que sea acorde a tu elección. Es importante que sepas que el dominio ha tenido que caducar o revisar que este apunto de caducar.
- Comprar un dominio nuevo y esperar aprox como mínimo varias semanas.
Además de todo lo anterior, hay que configurar correctamente la zona de DNS del dominio adquirido para incluir política rDNS, SPF, DMARC y DKIM. Esto lo veremos a continuación más en profundidad. Disponer de este tipo de políticas favorecerá con creces la entrega de la campaña de phishing.
Configurar zona DNS del dominio
Para configurar la zona DNS del dominio deberéis dirigiros al panel de administración de este. Normalmente se suele acceder a este panel a través de la entidad que os haya vendido el dominio. En mi caso, no voy a comprar un dominio para redactar el artículo (si, soy un poco rácano 🤣). Vamos a hacer uso del subdominio «gophish.dfirpills.com».
Configurar registro A
Un registro A (Address Record) es uno de los tipos de registros DNS más fundamentales y comunes. Su función principal es mapear un nombre de dominio a una IP.
Es importante que el dominio este apuntando en la zona DNS a tu instancia en AWS. He indicado que el subdominio «gophish.dfirpills.com» apunte a mi instancia.
Configurar registro rDNS
El registro rDNS, también conocido como registro PTR (Pointer Record), se utiliza para mapear una dirección IP a un nombre de dominio, lo contrario de lo que hace un registro A en el DNS.
Me temo que en este paso os voy a tener que dejar solos. Quiero hacer mención a este registro ya que es importante configurarlo para ganar puntos de confianza. No obstante, este registro debe ser configurado sobre el propio hosting o proveedor de la IP. En este caso es Amazon AWS. Para configurar un registro rDNS en AWS hay que registrar una IP elástica (posibles costes no incluidos en plan gratuito) y posteriormente enviar una solicitud para asociar el registro PTR a la IP elástica.
Configurar registro SPF
Un registro SPF es un tipo de registro DNS que especifica qué servidores de correo están autorizados para enviar correos en nombre de tu dominio.
Para ello, vamos a dirigirnos a la herramienta SPF Wizard (nos ayudará con la creación). Especificamos los siguientes campos:
Se generará el registro TXT a incluir en la zona DNS.
Lo que estamos indicando con este registro es:
v=spf1
: Indica la versión del SPF que se está utilizando, que en este caso es la versión 1.mx
: Indica que los servidores de correo enumerados en los registros MX del dominio están autorizados para enviar correos en nombre del dominio.a
: Permite que los servidores con registros A (dirección IPv4) del dominio puedan enviar correos.ip4:[IP instancia]
: Especifica una dirección IPv4 específica (ip instancia) que está autorizada para enviar correos en nombre del dominio.-all
: Indica una política de negación estricta. Esto significa que cualquier servidor no especificado explícitamente en las reglas anteriores (MX, A, o la dirección IP especificada) no está autorizado para enviar correos. Los correos enviados desde servidores no autorizados serán rechazados.
Configurar registro DKIM
DKIM es un método de autenticación de correo que permite al dominio remitente firmar digitalmente los correos electrónicos. La firma digital permite al servidor receptor verificar que el correo no ha sido alterado y que proviene de un servidor autorizado por el propietario del dominio.
Para configurarlo hay que acceder al contenedor de postfix y obtener una shell interactiva:
sudo docker exec -it postfix /bin/bash
#actualizar paquetes
apt update
Hay que configurar el servicio Open DKIM. Borramos todo el contenido del fichero y agregamos lo siguiente:
nano /etc/opendkim.conf
AutoRestart Yes
AutoRestartRate 10/1h
Syslog yes
SyslogSuccess Yes
LogWhy Yes
Canonicalization relaxed/simple
InternalHosts 0.0.0.0/0, ::/0
Mode sv
KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
PidFile /var/run/opendkim/opendkim.pid
SignatureAlgorithm rsa-sha256
Socket inet:12301@localhost
UMask 002
UserID opendkim:opendkim
Una vez guardado el fichero:
mkdir /etc/opendkim
cd /etc/opendkim/
mkdir keys
cd keys
#Crear carpeta con nombre de vuestro dominio
mkdir gophish.dfirpills.com
cd gophish.dfirpills.com
#Generar claves dkim
opendkim-genkey -s mail -d gophish.dfirpills.com
chown opendkim:opendkim /etc/opendkim/keys -R
chmod 600 /etc/opendkim/keys/*
#Creamos el fichero
nano /etc/opendkim/KeyTable
#Incluimos lo siguiente y guardamos (recordad usar vuestro dominio)
mail._domainkey.gophish.dfirpills.com gophish.dfirpills.com:mail:/etc/opendkim/keys/gophish.dfirpills.com/mail.private
#Creamos otro fichero
nano /etc/opendkim/SigningTable
#Incluimos y guardamos
*@gophish.dfirpills.com mail._domainkey.gophish.dfirpills.com
#Para finalizar, iniciamos el servicio
service opendkim start
Ya tenemos creadas la clave pública y privada. Ahora podremos incluir el contenido de la clave pública «mail.txt» en el registro TXT de la zona DNS:
Cuidado con las comillas, sanear un poco la salida y obtener el contenido TXT. En mi caso:
v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0qUsfeBQ2mQByz+thq+OH312lflO8UlKqszRuB1BG/OLHNBMygY1qa7mTb4vJP5yWmElGynuwrLGJ3uyI1fVDpzcMVKvpGXB3WUABeBSFth49Ai2VhAAJOMgRXJY0JTo+QXqy9+kwqvxr2QDoqTFmILziePGhM2UMRUwjbfsm1k1wM+buyNRpygD+akhnXzrGqJtRNw3DegBzwAe0Vk8QIWEeOBqU6KMB+xtMf0t2gPZa5cxA02LjVEfPOcoiCxaow+87aFz7r8jgcBC4e0KATGyBwEre2UFusZxGOfaH8R2CPBuTU9D9OZeFPJGdXHM8vh4k4M16w76TWb/IPLl4wIDAQAB
Por último, hay que configurar opendkim como milter (mail filter) en Postfix. No obstante, esto lo haremos más adelante.
Configurar registro DMARC
DMARC es un protocolo de autenticación de correo electrónico que utiliza SPF y DKIM para verificar la autenticidad del correo electrónico. Proporciona una forma para que los administradores de dominios publiquen políticas sobre cómo los receptores deben tratar los correos electrónicos fallidos en las verificaciones de SPF y DKIM.
Hay que agregar el siguiente registro TXT sobre la zona DNS del dominio:
#Nombre
_dmarc.gophish.dfirpills.com
#TXT
v=DMARC1; p=none
Configuración POSTFIX
Lo primero que tenemos que hacer es establecer un mailname para el servidor:
nano /etc/mailname
#Indicar nombre de dominio y guardar
gophish.dfirpills.com
Una vez realizado, hay que editar el fichero main.cf. Este fichero recoge principalmente la configuración del servidor Postfix.
nano /etc/postfix/main.cf
Borramos todo su contenido e incluimos lo siguiente:
Aviso a navegantes, a partir de aquí, hay configuraciones que pueden diferir dependiendo del tipo de pruebas o envíos a realizar. Es decir, en mi caso voy a configurar una regla de transporte que va a indicar expresamente contra el puerto y servidor que debe contactar Postfix para enviar el correo al dominio del destinatario (recordemos que es adrianh@dfirpills.com). No obstante, por defecto, Postfix contacta contra el puerto 25 del servidor del dominio destino. Esto quiere decir que si el servidor destino no acepta conexiones contra este puerto deberéis configurar lo necesario en cuanto a regla de transporte y configuración TLS/SSL de Postfix. En mi caso, he configurado lo anterior para contactar contra un servidor por SSL.
- smtp_tls_security_level = encrypt
- smtp_tls_wrappermode = yes
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
myorigin = /etc/mailname
maillog_file = /var/log/mail.log
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no
# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=may
smtp_tls_note_starttls_offer = yes
smtp_tls_CApath=/etc/ssl/certs
#smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_wrappermode = yes
#smtp_tls_security_level = may
smtp_tls_security_level = encrypt
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
myhostname = gophish.dfirpills.com
mydomain = gophish.dfirpills.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = $myhostname, gophish.dfirpills.com, localhost.com, localhost
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 172.17.0.0/16
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
#Regla de transporte SMTP
transport_maps = hash:/etc/postfix/transport
#Configurar mailter opendkim
milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:localhost:12301
non_smtpd_milters = inet:localhost:12301
Al final de la configuración podéis ver como se configura OpenDKIM como mailter para Postfix. ¡Importante!: cambiar el nombre de dominio sobre la configuración de Postfix.
La regla de transporte se configuraría:
nano /etc/postfix/transport
#Incluir dominio destino y configuracion del servidor destino. Por ejemplo: outlook.com smtp:[mail.ejemplo.com]:465
dfirpills.com smtp:[hostname destino]:puerto
#Tras guardarlo, ejecutamos
postmap /etc/postfix/transport
Para cualquier fallo que encontréis a la hora de realizar envíos, consultar siempre los logs del servidor con:
tail -f /var/log/mail.log
Para finalizar, iniciamos el servicio Postfix:
service postfix start
Configuración certificados Gophish
Por último, tenemos que configurar el certificado del dominio para que las víctimas no sospechen mas de la cuenta con el típico candadito rojo del navegador. Vamos a convertirlo en candadito verde o pagina «segura» 😊
Como somos dueños del dominio tenemos que generar los certificados con ayuda de la autoridad certificadora Let’s Encrypt.
mkdir installcert
cd installcert
mkdir certs
nano certinstall.sh
Incluimos lo siguiente:
DOMAIN="gophish.dfirpills.com"
wget https://dl.eff.org/certbot-auto
chmod +x certbot-auto
sudo apt install snapd
sudo snap install core
sudo snap refresh core
sudo apt-get remove certbot
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
certbot certonly --standalone -d "$DOMAIN"
mkdir ./certs
cp "/etc/letsencrypt/live/$DOMAIN/privkey.pem" ./certs/key.pem
cp "/etc/letsencrypt/live/$DOMAIN/fullchain.pem" ./certs/key.crt
Damos permisos de ejecución al fichero y lo ejecutamos:
chmod +x certinstall.sh
./certinstall.sh
Ya tenemos el certificado y la clave privada sobre el directorio /certs con los nombres «key.crt» y «key.pem»
Okeeeey, bien.
Ahora copiamos los ficheros al contenedor de gophish:
sudo docker cp key.crt gophish:/opt/gophish
sudo docker cp key.pem gophish:/opt/gophish
Accedemos como root al contenedor:
sudo docker exec -u 0 -it gophish /bin/bash
cd /opt/gophish
#cambiamos el nombre al fichero key.crt
mv key.crt\342\200\213 key.crt
chown app:app key.pem
chown app:app key.crt
Actualizamos paquetes e instalamos nano:
apt update
apt install nano
nano config.json
Modificamos el fichero config.json de gophish:
{
"admin_server": {
"listen_url": "0.0.0.0:3333",
"use_tls": true,
"cert_path": "gophish_admin.crt",
"key_path": "gophish_admin.key",
"trusted_origins": []
},
"phish_server": {
"listen_url": "0.0.0.0:443",
"use_tls": true,
"cert_path": "/opt/gophish/key.crt",
"key_path": "/opt/gophish/key.pem"
},
"db_name": "sqlite3",
"db_path": "gophish.db",
"migrations_prefix": "db/db_",
"contact_address": "",
"logging": {
"filename": "",
"level": ""
}
}
Para finalizar, aplicar un reset al contenedor de gophish. Recuerda salir de la consola del contenedor anterior.
sudo docker container restart gophish
¡Finiquitao! Ya tenemos lo necesario para comenzar con la configuración de la campaña que es lo que veremos en la siguiente entrada.
¡Byte! 🫡