Últimamente he andado mirando temas de volcado de procesos para posteriormente analizarlos, o bien con herramientas dedicadas para cada proceso o sencillamente interactuando con el comando string y un poco de grep.
Lo último que probé fue volcar el proceso outlook.exe (versión 2003):
procdump -ma outlook.exe outlook.dmp
ProcDump v7.1 - Writes process dump files
Copyright (C) 2009-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
With contributions from Andrew Richards
[17:18:34] Dump 1 initiated: D:\Pruebas\Microsoft\technet\Sysinternals\Procesos y subprocesos\outlook.dmp
[17:19:40] Dump 1 complete: 528 MB written in 66.3 seconds
[17:19:41] Waiting for dump to complete...
[17:19:41] Dump count reached.
Una vez volcado el proceso outlook.exe, dije "pues ahora a jugar un poco con strings"...
Antes de nada, como el protocolo utilizado para el correo en este caso es IMAP, quise informarme un poco de comandos del mismo a través de la RFC.
https://tools.ietf.org/html/rfc3501#page-25
Y me resultó curioso el comando NOOP:
6.1. Client Commands - Any State
The following commands are valid in any state: CAPABILITY, NOOP, and LOGOUT.
6.1.2. NOOP Command
Arguments: none
Responses: no specific responses for this command (but see below)
Result: OK - noop completed
BAD - command unknown or arguments invalid
The NOOP command always succeeds. It does nothing.
Since any command can return a status update as untagged data, the
NOOP command can be used as a periodic poll for new messages or
message status updates during a period of inactivity (this is the
preferred method to do this). The NOOP command can also be used
to reset any inactivity autologout timer on the server.
Example: C: a002 NOOP
S: a002 OK NOOP completed
. . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 3 RECENT
S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed
Me quedé con esta parte “The NOOP command can also be used to reset any inactivity autologout time on the server”.
Entonces dije: "pues será que en cada llamada de este comando el cliente de Outlook manda la contraseña al servidor para mantener viva la conexión"... y efectivamente así era.
Como los comandos IMAP realizan saltos de línea ni me molesté en la ejecución de strings con el típico grep.
cat outlook.dmp | strings | grep NOOP
Con lo que tuve que volcarlo a un fichero de texto para posteriormente su edición.
cat outlook.dmp | strings > outlook.txt
Bueno, pues lo siguiente sería editar el archivo txt y realizar búsquedas con el texto 'NOOP completed'.
Y, efectivamente, dos líneas más arriba de dicho texto estaba la contraseña de mi cuenta de Hotmail.
Me pareció raro que no encontrara las contraseñas del resto de cuentas con lo que cambié la búsqueda por 'OOP completed' y obtuve el resto de contraseñas.
Todo esto anterior está muy bien y parece bastante nativo e indetectable por los antivirus (tendría que verificar que el procdump no se detecta como amenaza pero entiendo que al ser de las sysinternals/Mark Russinovich no tendría por qué) por eso presté especial atención.
Pero si que es verdad que realizando una búsqueda por Internet no me sorprendió que dentro de mis resultados encontrara una tool de securityxploded :-) llamada OutlookPasswordDump.
Así que no dudé en bajarla y ejecutarla y el resultado fue bastante bueno:
El tema con esta utilidad es que dudo mucho que pase desapercibida por los antivirus.
Pues ante la duda… a virus total:
Y me quedé bastante sorprendido de que tan sólo es detectado en 4/57 AVs!
Así que quizás sea mejor usar directamente procdump de Outlook.exe en máquinas remotas.
psexec \\remote procdump
O quizás un poco de powershell.
Ahí va la idea, a ver que más posibilidades se os ocurren...
Lo último que probé fue volcar el proceso outlook.exe (versión 2003):
procdump -ma outlook.exe outlook.dmp
ProcDump v7.1 - Writes process dump files
Copyright (C) 2009-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
With contributions from Andrew Richards
[17:18:34] Dump 1 initiated: D:\Pruebas\Microsoft\technet\Sysinternals\Procesos y subprocesos\outlook.dmp
[17:19:40] Dump 1 complete: 528 MB written in 66.3 seconds
[17:19:41] Waiting for dump to complete...
[17:19:41] Dump count reached.
Una vez volcado el proceso outlook.exe, dije "pues ahora a jugar un poco con strings"...
Antes de nada, como el protocolo utilizado para el correo en este caso es IMAP, quise informarme un poco de comandos del mismo a través de la RFC.
https://tools.ietf.org/html/rfc3501#page-25
Y me resultó curioso el comando NOOP:
6.1. Client Commands - Any State
The following commands are valid in any state: CAPABILITY, NOOP, and LOGOUT.
6.1.2. NOOP Command
Arguments: none
Responses: no specific responses for this command (but see below)
Result: OK - noop completed
BAD - command unknown or arguments invalid
The NOOP command always succeeds. It does nothing.
Since any command can return a status update as untagged data, the
NOOP command can be used as a periodic poll for new messages or
message status updates during a period of inactivity (this is the
preferred method to do this). The NOOP command can also be used
to reset any inactivity autologout timer on the server.
Example: C: a002 NOOP
S: a002 OK NOOP completed
. . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 3 RECENT
S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed
Me quedé con esta parte “The NOOP command can also be used to reset any inactivity autologout time on the server”.
Entonces dije: "pues será que en cada llamada de este comando el cliente de Outlook manda la contraseña al servidor para mantener viva la conexión"... y efectivamente así era.
Como los comandos IMAP realizan saltos de línea ni me molesté en la ejecución de strings con el típico grep.
cat outlook.dmp | strings | grep NOOP
cat outlook.dmp | strings > outlook.txt
Bueno, pues lo siguiente sería editar el archivo txt y realizar búsquedas con el texto 'NOOP completed'.
Y, efectivamente, dos líneas más arriba de dicho texto estaba la contraseña de mi cuenta de Hotmail.
Me pareció raro que no encontrara las contraseñas del resto de cuentas con lo que cambié la búsqueda por 'OOP completed' y obtuve el resto de contraseñas.
Todo esto anterior está muy bien y parece bastante nativo e indetectable por los antivirus (tendría que verificar que el procdump no se detecta como amenaza pero entiendo que al ser de las sysinternals/Mark Russinovich no tendría por qué) por eso presté especial atención.
Pero si que es verdad que realizando una búsqueda por Internet no me sorprendió que dentro de mis resultados encontrara una tool de securityxploded :-) llamada OutlookPasswordDump.
Así que no dudé en bajarla y ejecutarla y el resultado fue bastante bueno:
El tema con esta utilidad es que dudo mucho que pase desapercibida por los antivirus.
Pues ante la duda… a virus total:
Y me quedé bastante sorprendido de que tan sólo es detectado en 4/57 AVs!
Así que quizás sea mejor usar directamente procdump de Outlook.exe en máquinas remotas.
psexec \\remote procdump
O quizás un poco de powershell.
Ahí va la idea, a ver que más posibilidades se os ocurren...
Contribución gracias a Iñaki Martín
Y si usás la herramienta de Nirsoft (MailPassView)? O se asume que el usuario no almacenó su credencial?
ResponderEliminarBuenas, a ver si trato de explicarlo mejor.
ResponderEliminarPartiendo de una base en la que el usuario ha marcado el check de "Recordar contraseña", a partir de esa acción la contraseña se ha guardado en el registro local de windows en su lugar correspondiente claro está según el programa y versión del que estemos hablando (Por ejemplo internet explorer las guarda en el Protected Storage System Provider, ¿os suena? y las nuevas versiones de outlook en el Windows Messaging Subsystem)
Debido a que estas contraseñas están guardadas en registro local exísten varias herramientas para su extracción (en el caso de outlook tenemos OutlookPasswordDump y OutlookPasswordDecryptor de securityxploded o MailPassView de nirsoft la cuál has comentado en tu comentario).
Dicho esto lo que he intentado reflejar en este post es un poco diferente a lo anterior ya que no se trata de extraerlas del registro sino que a través de un volcado del proceso outlook.exe podremos extraer esa contraseña que estaba almacenada al ser recordada por el usuario y que se ha cargado en la memoria cuando en outlook hemos presionado al botón de enviar y recibir correo(F9).
La prueba la realicé ayer sobre un outlook 2003 SP3 con una cuenta IMAP y activada la conexión a través de SSL (puerto 993), estaréis diciendo un poco vieja la versión de mi outlook... pero lo interesante de todo esto ha venido hoy cuando he realizado la misma prueba en un outlook 2013 con una cuenta exchange de Office365 (IMAPS) y el resultado ha sido que ahora la contraseña se guarda en Base64.
Espero con esto haber aclarado tus dudas.
Buenas.
ResponderEliminarAntes de nada gracias por la entrada, la verdad que no lo conocía y me ha venido muy bien el "apunte".
Supongo que ya lo sabréis, pero acabo de probarlo en office 2016 con una cuenta de exchange y también funciona.
En lugar de usar las búsquedas "NOOP completed" o "OOP completed" basta con buscar "Authorization: Basic" y ahí está la contraseña.
Saludos y gracias.
Buenas Akil3s,
ResponderEliminarMe alegro que te haya gustado la entrada, yo lo probé hasta la versión 2013 de Office con lo que te agradezco que nos confirmes que en 2016 también funciona.
En mi comentario indique que en versiones superiores se guardaba la autenticación en Base64 para ver si alguién más lo realizaba :)
Saludos y gracias a tí
¡¡¡ Muy buena entrada !!!! Muchas gracias por tu tiempo y dedicación Ignacio aprendemos mucho de ti y de tus post.
ResponderEliminarUn saludo.