sábado, 6 de marzo de 2010

Descubriendo troyanos 3/3

Ahora toca registrar las conexiones realizadas en Windows desde Windows.

Para ello, iniciamos Windows desde la máquina virtual e instalamos Wireshark. Abrimos Wireshark, elegimos el adaptador de red y comenzamos una captura de paquetes apuntando exactamente la hora y el minuto de inicio de la captura.

Ahora es el momento de abrir IE6 en Windows, navegar por páginas de dudosa reputación y aceptar todo lo que se ponga por delante. Cuanto más tiempo tenga la captura, más posibilidades tendremos de atrapar a algún troyano.

Cuando detengamos la captura de paquetes con Wireshark, exportamos los paquetes capturados mediante el menú File, Export, File..., y guardamos el archivo como export_w32.txt con formato de texto plano (plain text) en el directorio de trabajo.

El siguiente paso es extraer las IPs de las conexiones que se han realizado desde Windows hacia Internet, eliminar redundancias y mostrar más información de la IP (como ya hicimos con Ubuntu con el script conex_report.pl). Para ello, en el directorio de trabajo, ejecutaremos el script conex_report_w32.pl de la siguiente forma:

perl conex_report_w32.pl > windows.txt

Lo anterior genera el fichero windows.txt cuyo contenido será parecido a esto:



Ya tenemos todos los datos que necesitamos. Ahora tenemos que comparar los resultados de windows.txt y de ubuntu.txt para detectar sus diferencias. Para ello, copiamos el contenido de windows.txt, creamos otro windows.txt en el directorio de trabajo de Ubuntu y pegamos en él el contenido del primero.

La comparación de ambos ficheros la realizaremos con el script compara_conex_report.pl que ejecutaremos en el directorio de trabajo de Ubuntu donde también deben figurar los archivos ubuntu.txt y windows.txt

Conclusión y aclaraciones:

Como el procedimiento explicado en el segundo y tercer post depende de ciertos scripts para permitir la automatización de tal, la presentación en PDF del primer post muestra el concepto general, mientras que el procedimiento detallado paso a paso es el siguiente:
  1. En un ordenador conectado a Internet mediante un router con IP 192.168.1.1 instalamos Ubuntu 9.10 (Karmic Koala).
  2. Ubuntu debe tener la interface de red eth0 con la IP 192.168.1.33, máscara 255.255.255.0 y un par de DNS válidas.
  3. En Ubuntu, instalamos el módulo de Perl Net::Whois::IP con CPAN.
  4. En Ubuntu, instalamos VirtualBox.
  5. Creamos una máquina virtual en VirtualBox para Windows XP, configuramos el adaptador de red en modo bridged. Iniciamos la máquina virtual e instalamos en ella Windows XP.
  6. En Windows XP configuramos la IP fija 192.168.2.35, máscara 255.255.255.0 y las mismas DNS que tiene Ubuntu.
  7. En Windows XP instalamos Strawberry Perl y Wireshark (implica la instalación de Winpcap).
  8. En Windows XP, instalamos el módulo de Perl Net::Whois::IP con CPAN.
  9. Ya tenemos todo montado.
  10. En Ubuntu, creamos NAT para la red 192.168.2.0 permitiendo su tráfico de E/S e iniciamos el logeo para el tráfico de dicha red. Para ello, en Ubuntu podemos crear un directorio de trabajo, bajamos a él este script en bash: captura.sh y lo ejecutamos en un terminal.
  11. En Windows XP, iniciamos Wireshark y empezamos a capturar paquetes apuntando la fecha, la hora y el minuto de comienzo de la captura de paquetes.
  12. Iniciamos IE6 en Windows XP y navegamos por webs maliciosas abriendo todo lo que se ponga por delante.
  13. Después de un tiempo prudencial (cuanto más mejor), detenemos la captura de Wireshark, exportamos los resultados a un archivo de texto plano llamado export_w32.txt y lo guardamos en un directorio de trabajo junto con el script conex_report_w32.pl
  14. Iniciamos una shell en Windows (Inicio, Ejecutar, cmd), vamos al directorio de trabajo y ejecutamos: perl conex_report_w32.pl > windows.txt
  15. Abrimos windows.txt, seleccionamos su contenido, lo copiamos y lo pegamos en otro windows.txt nuevo, pero en el directorio de trabajo de Ubuntu.
  16. En el directorio de trabajo de Ubuntu, bajamos los scripts conex_report.pl y compara_conex_report.pl
  17. En el directorio de trabajo de Ubuntu, ejecutamos en un terminal: perl conex_report.pl, le proporcionamos el mes, el día, la hora, el minuto y el segundo de inicio que tenemos apuntados de la captura con Wireshark y después el mes, el día, la hora, el minuto y el segundo de fin de captura. El tiempo de inicio debe ser lo más exacto posible, mientras que el tiempo final mejor que vaya sobrado.
  18. El resultado del script anterior es el fichero ubuntu.txt que contiene las IPs de conexión únicas con la información de whois en el intervalo de tiempo dado.
  19. Por último, en un terminal de Ubuntu y en el directorio de trabajo, ejecutamos: perl compara_conex_report.pl. Las IPs resultantes con su correspondiente información son las de las conexiones que inició Windows, que han sido capturadas por Ubuntu y no han sido capturadas por Wireshark desde Windows, esto es: conexiones realizadas por rootkits troyanizados. En caso de que el resultado no indique ninguna IP, quiere decir que todas las IPs de windows.txt y ubuntu.txt coinciden y todo es correcto: no hay rootkits en Windows.

lunes, 15 de febrero de 2010

Descubriendo troyanos 2/3

El post anterior trata sobre registrar las conexiones que inicia un Windows hacia Internet. Tal operación se realiza con un Linux y una máquina virtual donde "enjaular" a Windows.

Una vez registradas las conexiones en /var/log/kern.log, hay que extraer las IPs remotas y averiguar más información sobre ellas. Como el número de conexiones a una misma IP puede ser muy elevado, conviene eliminar redundancias, obtener la lista de IPs únicas visitadas en un rango de tiempo que indicaremos y obtener más información mediante el servicio whois.

Para ello, he preparado un script en perl conex_report.pl, que hace todo el trabajo y nos saca esa lista junto con alguna información relevante de whois y lo deja en el archivo ubuntu.txt.

Un ejemplo de la ejecución del script:



Y su correspondiente informe de conexiones únicas del archivo ubuntu.txt



En la tercera entrega, veremos cómo hacer lo mismo pero con las conexiones registradas dentro de Windows.

sábado, 13 de febrero de 2010

Descubriendo troyanos 1/3

La mayoría de las veces, es infructuosa la búsqueda de troyanos en un Windows debido a los siguientes factores:
  • Se ocultan con Rootkits
  • Se propagan rápidamente vía web
  • Existe muchísima variedad y cada vez más
  • Muchos son 0-day que antes de ser descubiertos puede pasar mucho tiempo
Esto quiere decir que un Windows infectado por un rootkit que oculte a un troyano es garantía de pertenecer, con suerte, a una botnet y en el peor de los casos, tus datos personales incluyendo contraseñas y números de tarjeta de crédito (si has realizado compras por Internet) estarán en una base de datos lista para ser vendida.

La solución que propongo es enjaular un Windows en una máquina virtual, exponer a Windows como cebo para los troyanos (navegando con IE sin cuidado) y monitorizar las conexiones de red dentro de Windows y fuera de él (mediante el S.O. anfitrión) durante días.

Comparando ambos resultados, las conexiones remotas que estén registradas fuera de Windows y que no estén registradas dentro de Windows son, seguramente conexiones realizadas por rootkits troyanizados.

En esta presentación en PDF muestro cómo realizarlo con el siguiente software:
  • Ubuntu Linux 9.10
  • Virtual Box 3.0.8 para Linux
  • Windows, preferiblemente un XP pelado
  • Internet Explorer 6
  • WinPcap y WireShark


jueves, 10 de diciembre de 2009

Recopilación de herramientas


adsetuserpass: cambia contraseñas de usuarios del Directorio Activo con un script de PowerShell.

control-drivers: identifica a los drivers actuales de Windows y los compara con futuras versiones o drivers nuevos para comprobar cambios sospechosos.

dirsize: informa sobre los tamaños de todas las subcarpetas de una carpeta.

ejecutable.pl: script en perl para detectar archivos ejecutables sospechosos.

error-sys-events: realiza un informe con los sucesos de error de varios servidores Windows.

infosis: realiza un informe html recopilando hardware/software de un host Windows.

limpia-medios-extraibles: detecta y elimina (con confirmación) archivos sospechosos que pudieran estar en algún medio extraible como un pendrive.

regsys-net: realiza informes html del hardware/software de todos los hosts Windows de una red.

regsys: realiza un informe recopilando hardware/software de un host Windows.

userperm-net: informa sobre los permisos que tiene un usuario/grupo en todas las carpetas compartidas de un Directorio Activo.


miércoles, 18 de noviembre de 2009

Informes de Windows masivos

Disponer de informes hardware/software de los ordenadores de una red administrada ahorra mucho tiempo al solucionar problemas.

Una muestra de los datos que se pueden incluir en estos informes puedes verla en el post de Informe del Sistema.

Para automatizar la elaboración de estos informes, las utilidades regsys e infosis extraen estos datos mediante WMI y el Registro de Windows en el mismo ordenador donde se ejecuta la utilidad y pasa los resultados a HTML.

Estas utilidades son muy prácticas al finalizar la instalación/configuración de un sistema Win32 nuevo, pero en el caso de necesitar los informes de decenas o cientos de ordenadores, por ejemplo, de un Directorio Activo, realizar los informes uno a uno es ineficiente.

Para automatizar esta tarea realicé regsys-net que hace lo siguiente:
  1. Ejecutas regsys-net con permisos de administrador de dominio en un ordenador que pertenezca al dominio (supongamos que este ordenador tiene la ip 192.168.1.56)

  2. regsys-net busca ordenadores para conectar con WMI desde la ip 192.168.1.1 hasta la 192.168.1.254 (busca en toda la subred en la que se encuentra)

  3. Si en su búsqueda, regsys-net encuentra un ordenador con el WMI disponible, conecta con él, le extrae la información mediante WMI y el Registro de Windows, y la pone en un archivo HTML, nombra al archivo HTML con el nombre DNS del ordenador correspondiente y lo guarda en la misma carpeta donde se encuentra regsys-net
Este proceso suele suele tardar entre una y tres horas. En el caso de necesitar informes de más ordenadores ubicados en otras subredes, bastará con repetir el proceso en algún ordenador de la subred correspondiente.

Observación: es necesario que los ordenadores con Windows Vista tengan iniciado el servicio Registro Remoto, así, regsys-net puede extraer la información del software instalado mediante el registro de Windows.

jueves, 12 de noviembre de 2009

Localiza evidencias de Rootkits

Los rootkits son procesos que tienen la capacidad de ocultarse al usuario mediante varias técnicas. Una de ellas es mediante la inyección de código malicioso desde un proceso maligno a un proceso víctima.

Una de las funciones que utiliza el malware para realizar esta inyección es CreateRemoteThread, por tanto, conocer qué archivos ejecutables tienes en tu Windows que utilicen esta función puede sacar a la luz archivos sospechosos.

Mediante la herramienta Filealyzer podrás ver dentro de un archivo ejecutable, entre otras cosas interesantes, la tabla de importación donde aparecerá una lista de funciones que utiliza el archivo ejecutable en cuestión. Pero ¿cómo saber si un archivo ejecutable utiliza la función CreateRemoteThread para fines lícitos o no? Una forma rápida es buscar dentro de los archivos ejecutables de un Windows recién instalado e identificar los que utilizan la función CreateRemoteThread.

Hacer esto con Filealyzer es muy tedioso, así que para automatizar este proceso puedes utilizar la herramienta Strings de Sysinternals, ubicarla en una carpeta del Path (por ejemplo en c:\windows\system32), ir a esa misma ubicación en la línea de comandos y poner:

strings * | findstr CreateRemoteThread > report.txt

De esta forma,
Strings buscará CreateRemoteThread en todas las cadenas de texto de todos los archivos de c:\windows\system32 y pondrá el resultado en el archivo report.txt.

Observando el report.txt en un Windows XP SP3 recién instalado con las Windows Update al día, los archivos ubicados en c:\windows\system32 que utilizan la función CreateRemoteThread son:

csrsrv.dll
dbgeng.dll
kernel32.dll
safrslv.dll
usrcoina.dll
vdmdbg.dll
winlogon.exe
winsrv.dll

Todos ellos son archivos ejecutables de Windows que se suponen lícitos, pues al sistema, se supone que no le ha dado tiempo de infectarse con malware. Por tanto, si generas un report.txt de la manera mencionada en tu Windows XP SP3 y observas que además de los archivos listados hay alguno más, mosquéate, porque los que no aparezcan en esta lista utilizan la función CreateRemoteThread y no es de Windows.

jueves, 22 de octubre de 2009

Errores de sistema en varios servidores Windows

Comprobar los sucesos de error de sistema que se producen en un servidor Windows forma parte imprescindible en la administración de sistemas en estas plataformas. Para ello tienes el Visor de Sucesos y el procedimiento: eventvwr.msc, Sistema, Filtrar por Tipo y seleccionar sólo el tipo Error. Luego queda ver lo que ha sucedido y comprobar si todo va como tiene que ir.

Esto está bien si lo haces con un servidor, pero si lo tienes que hacer con más de tres, el procedimiento es más ineficiente: desde el Visor de Sucesos tienes que ir conectando con cada uno de los distintos servidores y repetir el procedimiento anterior (menos el primer paso que es la ejecución del visor de sucesos).

Quiero que la extracción de los sucesos de error de sistema de varios servidores se realice en un sólo paso, y después consultarlo tranquilamente, y para ello he realizado la herramienta error-sys-events.exe que funciona así:
  1. Creo una carpeta y pongo en ella la herramienta error-sys-events.exe
  2. Creo en esa misma carpeta un archivo de texto llamado servers.txt y pongo un nombre de servidor por cada línea (también valen ip's)
  3. Ejecuto con los privilegios adecuados (administrador local o de dominio) la herramienta error-sys-events.exe, y a esperar
  4. Al terminar tendré un archivo llamado syslogerror-nombre_servidor.txt en esa misma carpeta con los resultados del servidor correspondiente
Después sólo queda ir mirando los distintos informes y ver qué pasa realmente con los servidores.