Como evitar el cifrado por ransomware de un servidor Windows con las herramientas GRATUITAS del sistema.

Estimados amigos de Inseguros !!!

El ransomware acapara numerosas publicaciones y está siendo una de las amenazas con mayor repercusión y con mayor crecimiento en este último 2015 y se prevé que siga en crecimiento a lo largo de este 2016.

Tomemos como descripción la Wikipedia: Un ransomware (del inglés ransom rescate y ware, software) es un tipo de programa informático malintencionado que restringe el acceso a determinadas partes o archivos del sistema infectado, y pide un rescate a cambio de quitar esta restricción.

Algunos tipos de ransomware cifran los archivos del sistema operativo inutilizando el dispositivo y coaccionando al usuario a pagar el rescate.

Durante el 2015 fue la amenaza con más crecimiento en el ámbito de la ciberseguridad, ya que de manera rápida, proporciona suculentos ingresos a los ciberdelicuentes que explotan dicho vector de ataque.

En el blog de Eset Protegerse hemos hablado en numerosas ocasiones de las distintas variantes que aparecen para los distintos sistemas, desde equipos Android, equipos Windows, los Mac y su “no-virus” etc. Mi compañero Josep Albors se ha hecho un experto en la materia.

Aunque siempre debemos confiar en nuestros sistemas de antivirus para su detección, existe una mínima franja de tiempo desde que aparecen algunas muestras y los sistemas son capaces de detenerlas, para ellos, les ofrecemos una pequeña guía de ayuda.

En el artículo de hoy vamos a implementar una solución basada en FILE SERVER RESOURCE MANAGER (Administrador de recursos del servidor de ficheros). Esta opción está disponible de manera gratuita en Windows Server 2012 y anteriores añadiendo simplemente las características correspondientes, dentro del servidor de ficheros.

El concepto a desplegar es sencillo. Vamos a monitorizar los ficheros dentro de nuestro servidor de ficheros. Vamos a introducir una serie de extensiones maliciosas empleadas por el malware para cifrar. Vamos a poner un “señuelo” en esas carpetas para que en caso de infección, un equipo comenzará el proceso de cifrado, detectar el proceso y pararlo.

Lo primero que debemos hacer es tener una lista de extensiones empleadas por el malware más o menos actualizadas.

Pongamos como punto de partida este listado:

*.*AES256

*.*cry

*.*crypto

*.*darkness

*.frtrss

*.vault

*want your files back.*

confirmation.key

enc_files.txt

last_chance.txt

message.txt

recovery_file.txt

recovery_key.txt

vault.hta

vault.key

vault.txt

*.aaa

*help_your_files*.*

En el FSRM creamos un grupo de archivos que incluya este tipo de extensiones.

El siguiente paso es crear una plantilla de actuación, en la que definiremos el comportamiento deseado ante la detección de un fichero con la extensión mencionada.

Una de las opciones básicas es configurar un mensaje y cuenta de correo para notificar el incidente.

A continuación sería una buena idea escribir un evento en el registro de Windows para reenviar posteriormente a un sistema de correlación SIEM o simplemente para efectos de control.

Como es normal, no solo queremos detectar que hemos sido víctimas de un ataque por ransomware, sino que queremos prevenir o mitigar las temidas consecuencias. Para ello, habilitamos una sesión de comandos al encontrar un cambio en los ficheros.

El comando o comandos que podemos ejecutar mediante este “disparador” o monitor son infinitos. 

Podemos optar por apagar el servidor de ficheros. Podemos optar por bloquear el acceso al usuario de red que ha intentado modificar los ficheros (el malware). Podemos bloquear la dirección IP de entrada al servidor desde el equipo que origina la infección.Particularmente prefiero apagar el servidor. Esto dejará a los usuarios sin servicio, pero es una manera radical de evitar la infección.

Por último, configuramos donde queremos que se aplique el filtro.

Tenemos que ser conscientes de que este servicio de monitorización consume recursos en el sistema, y que en grandes entornos con miles y millones de ficheros podría producir penalizaciones en el rendimiento del servicio.Para ello empleamos un pequeño truco. En los sistemas Windows el guion bajo (¬_) es el primer carácter que aparece en una ordenación, por lo que creamos una carpeta con este nombre y esta será la que sea monitorizada por FSRM.A efectos prácticos en caso de producirse una infección, el proceso de cifrado comienza por la carpeta “señuelo”.

En un entorno real, se produce un lapsus de tiempo entre que el virus comienza a cifrar la carpeta señuelo, ejecuta el comando deseada (apagar) y se apaga el equipo o se ejecuta cualquiera otra opción, por lo que tenemos que contar con 5/10 ficheros cifrados. 

Esto es un pequeño defecto en el concepto, si bien, en un entorno de millones de ficheros, es un mal menor que seguro estamos dispuestos a pagar por evitar el temido cifrado del servidor de ficheros.

Para terminar, podemos ver como se ha producido el correspondiente registro en el visor de eventos. En esta prueba, un simple cambio manual de nombre de fichero.

Como suelo intentar en el blog, me gusta ponerme en la perspectiva real del administrador o usuario que realiza los procedimientos.

Hasta aquí, este artículo sería una copia más de los muchos que hay en la red sobre FSRM para detener amenazas del tipo ransomware. Ahora vamos a lo interesante.

El propio maestro MVP  Juan Garrido  dio una charla este año en Rooted . Cuando salgan los videos realizaré el enlace para ampliar la información.

Seguro que se te han planteado varias dudas.

1.- Como actualizo la lista de extensiones conforme aparecen las nuevas versiones?En todos mis fileservers?

2.- Como realizo esta gestión de manera centralizada en todos mis fileservers?

3.- Como soluciono el problema de las carpetas de usuario?*

Para este último punto vamos a poner un ejemplo. Tenemos un file server \\\ip\empleados\"usuario_del_dominio" y cada usuario tiene una unidad de red conectada a su carpeta. Donde colocamos la carpeta "señuelo" ?

Vamos a ver como podemos ayudar. Lo primero que tenemos es una lista mía personal que mantengo con las extensiones que voy documentando. La puedes descargar desde aquí: Lista de extensiones ransomware

He subido a mi repositorio de Github un pequeño script, muy cutre, pero altamente funcional. Si alguien quiere modificar algo o ayudarme/ayudarnos, está invitado, yo no tengo mucha idea.

Os pego el Script:

## Autor: Jmolina Kinomakino

## blog http://kinomakino.blogspot.com.es/

## @kinomakino

## Con este script podemos definir una seria de extensiones usadas por ransomware y usarlas en un servidor FSRM sobre Windows 

## para apagar el servidor y enviar un e-mail.

## Ejecuta el script con el parámetro de la carpeta que quieres monitorizar. por ejemplo : Script.ps1 c:\datos\

## El script primero borra los grupos y plantillas, no se comprueba que existen, por lo que la primera vez que se ejecuta puede

## dar algún problema. Ejecútalo varias veces y desaparecen los mensajes de error.

## De esta manera se puede programar una tarea para que se actualización.

## Si quieres incorporar extensiones propias, ten en cuenta que con la actualización las perders. Te animo a que me las envies 

## a kinomakino@hotmail.com para añadirlas al repo. param (

[string]$filePath

) ## Datos de correo

Set-FsrmSetting -SmtpServer "SMTP.SMTPSERVER.COM" -AdminEmailAddress "direccion_email" -FromEmailAddress "direccion_email" ## descarga de las extensiones

$extensiones = (Invoke-WebRequest "https://raw.githubusercontent.com/kinomakino/ransomware_file_extensions/master/extensions.csv”).Content

$grupo_ext = @()

foreach($line in $extensiones.Split("`r`n”)){ if ($line -ne "”) {$grupo_ext += $line} }

## exista o no, borramos el grupo de extensiones

Remove-FsrmFileGroup -Name "Extensiones" -Confirm:$false

## creamos el grupo de extensiones

New-FsrmFileGroup -Name "Extensiones" –IncludePattern $grupo_ext

## configuramos las acciones

$Notification = New-FsrmAction -Type Email -MailTo "direccion_email" -Subject "Cuidado, alguien quiere joderte" -Body "El usuario [Source Io Owner] ha intentado guardar [Source File Path] en [File Screen Path] en el servidor [Server]. Este archivo se encuentra en el grupo de archivos [Violated File Group], que no está permitido en el servidor." -RunLimitInterval 120 

$Notification2 = New-FsrmAction -Type Command -Command "c:\Windows\System32\shutdown.exe" -CommandParameters "-s -f -t 00" -SecurityLevel LocalService -KillTimeOut 0

## exista o no, borramos la plantilla

Remove-FsrmFileScreenTemplate -Name "Anti-Ransomware" -Confirm:$false 

## creamos la plantilla

New-FsrmFileScreenTemplate -Name "Anti-Ransomware" -Active:$true –IncludeGroup "Extensiones" -Notification $Notification,$Notification2 

## exista o no, quitamos la configuracion de la ruta a monitorizar

Remove-FsrmFileScreen $filePath -Confirm:$false

## activamos la monitorización de la ruta pasada como parámetro.

New-FsrmFileScreen -Path $filePath -Active:$true -Description "Monitorizar ransomware" –IncludeGroup "Extensiones" –Template "Anti-Ransomware" 

Creo que está suficientemente claro lo que hace. Si lo añadimos a una tarea programada y lo ejecutamos en cada servidor, indicando la carpeta a monitorizar, tenemos la configuración hecha. (Para leerlo bien entra a Github a mi repositorio)

Existe la posibilidad de exportar un xml con la configuración, pero entiendo que en cada servidor tenemos una estructura distinta de carpetas.

La 3ª duda que comentaba arriba era referida a grandes servidores de ficheros. Monitorizar la raíz de un fileserver, imagina \\ip\datos\  de 1 Tb puede que resienta el rendimiento.

Un caso muy común es tener una carpeta por usuario, mapeada a una unidad de red. 

Podríamos crear un señuelo directorio/carpeta en cada carpeta, y habilitar la monitorización de esa carpeta de usuario. Este trabajo, en un entorno de 2000 usuarios, sería algo tedioso.

Se me ha ocurrido una chapuza, un script bat que recorre el directorio que se le indique, y en cada subdirectorio que encuentra crea un directorio _honeypot\ y un fichero txt. Además, ejecuta una versión modificada del script de configuración de FSRM para que incluya la carpeta creada al sistema FSRM.

Para ello lo único que tienes que hacer es una copia del script powershell original, y quitarle la linea que borra el path: Remove-FsrmFileScreen $filePath -Confirm:$false

El siguiente paso es crear el fichero bat que ejecute el powershell:

FOR /d %%A IN (c:\cosas\*) DO  (mkdir "%%A\_no_borrar" & type NUL > %%A\_no_borrar\no_borrar.txt & Powershell.exe -executionpolicy remotesigned 

-File  C:\fsrm-2.ps1 %%A\_no_borrar\)

c:\cosas sería tu raíz de carpetas compartidas para usuarios.

c:\fsrm-2.ps1 sería el script modificado.

Espero que te haya gustado el artículo de hoy.

Si tienes alguna duda concreta sobre este procedimiento a los scripts, no dudes en preguntar.

Como siempre te recordamos no pagar nunca y te animamos a contactar con nosotros para solventar cualquier duda al respecto.

Recuerda que la defensa ante el ransomware es la tendencia marcada por los cibercriminales para este año y me temo que para los siguientes. Nada de "romperte" el ordenador, si pueden sacar pasta por ello.

No olvides tener un antivirus legal y actualizado.
No olvides tener copias de seguridad.

Existen otras soluciones con software libre interesante y que llevan cierto tiempo funcionando, y por lo que me consta, bastante bien. En este caso hemos hablado de la gracia de usar una herramienta NATIVA de servidores Windows, pero si tu opción es usar una herramienta externa, y compatible con Windows de escritorio, sin duda puedes usar Anti-RAnsom del señor Yago Jesús. Una herramienta con varias actualizaciones ya y que sin duda te hará feliz. Por cierto, no te pierdas el resto de herramientas. Gracias señor !!!

Gracias por leerme ¡!!