Análisis de malware

proceso de santificación

julio 1, por Ninja de seguridad

En este artículo, aprenderemos qué es el proceso de santificación, cómo se realiza y cómo podemos detectarlo mientras realizamos el análisis de la memoria.

proceso de santificación

Es una técnica mediante la cual el malware reemplazará un proceso legítimo por un proceso duplicado pero con código malicioso. El proceso ayuda al malware a ocultarse entre otros procesos legítimos. El nuevo proceso malicioso se parece tanto al proceso legítimo original que incluso el nombre de la imagen, la ruta y las líneas de comando permanecen sin cambios. A continuación se detallan los pasos que generalmente se siguen para el proceso de santificación:

¡Conviértete en un ingeniero inverso certificado!

Obtenga capacitación práctica en vivo sobre análisis de malware desde cualquier lugar y conviértase en un analista certificado de ingeniería inversa. Comienza a aprender

• Primero, el proceso de destino se crea en un estado suspendido usando CreateProcess con la opción CREATE_SUSPENDED. Una vez creado el proceso, su espacio de memoria se puede modificar con el identificador proporcionado. Se hará referencia a este identificador en todas las llamadas a funciones posteriores. Tenga en cuenta que en este punto el proceso malicioso se carga pero aún no se ejecuta porque se creó en un estado suspendido.
• El siguiente paso es encontrar el bloque de entorno de proceso (sección PEB) para este proceso malicioso, que se puede realizar utilizando la función auxiliar ReadRemotePEB. Una vez adquirido esto, se lee la dirección base de la imagen para localizar los encabezados NT.
• El siguiente paso es vaciar el código legítimo de la memoria en el proceso alojado. Para esto se utiliza NtUnmapViewOfSection. Debido a que es una función del kernel, el malware generalmente resuelve la función en tiempo de ejecución usando GetProcAddress.
• El siguiente paso es asignar un nuevo bloque de memoria para alojar el código malicioso. El malware generalmente crea el bloque completo PAGE_EXECUE_READWRITE para simplificar; de lo contrario, también se pueden establecer permisos para cada sección.
• Dado que se ha asignado espacio para una nueva imagen, WriteProcessMemory se utiliza para escribir el nuevo código de imagen en lugar del código de imagen original. En la estructura de encabezado opcional, la dirección base se cambiará a la de la nueva imagen de memoria. Sin embargo, si la base de la imagen nueva no coincide con la base de la imagen original, entonces será necesario cambiar la base de la imagen base de la nueva imagen.
• La función SetThreadContext se utiliza para establecer el contexto de este proceso.
• El último paso es simplemente reanudar el proceso usando ResumeThread.

Detección de santificación de procesos mediante volatilidad

Usando el complemento de volatilidad mal encontrado

Como se mencionó anteriormente, si el autor del malware olvidó reparar la protección RWX en su proceso generado malicioso, entonces eso puede ser detectado por el complemento Volatility ‘malfind’. Malfind busca la sección de memoria que tiene privilegios PAGE_EXECUTE_READWRITE y no se puede asignar al disco. También vuelca el código ensamblador en esa sección de memoria y la verificación final para ver si hay un código ejecutable en el código de volcado queda para los analistas.

Primero ejecutamos el complemento malfind en una imagen de muestra y obtuvimos el siguiente resultado

Aquí ocurrió un claro proceso de santificación. Se están ejecutando varias instancias de lsass.exe cuando, en circunstancias normales, solo debería ejecutarse una. Para compararlos con un lsass.exe normal, ejecutamos el complemento pslist y obtuvimos el siguiente resultado

Ahora el proceso 680 tiene el padre 624 y los procesos 868 y 1928 tienen el padre 668. Ejecutar un pstree nos dará una buena indicación de la relación padre-hijo.

De lo anterior podemos concluir que el proceso 680 parece legítimo ya que tiene un padre winlogon.exe válido y no estaba presente en la salida malfind. Para ilustrar esto mejor, veremos las secciones de memoria volcadas del proceso 868,1928.

Aquí podemos ver que ambos tienen un encabezado MZ pero no se pueden asignar al disco (requisito previo para una búsqueda incorrecta). Sin embargo, los autores de malware pueden manipular fácilmente este encabezado MZ. Para superar este problema, le brinda todas las secciones sagradas/inyectadas posibles que Redline pasa por alto si la sección de memoria no tiene un encabezado MZ.

Vale la pena señalar que mientras se realiza el análisis de la memoria, el proceso de santificación y la inyección de código se ven muy iguales.

Comparar el tamaño de varias instancias del mismo proceso

Incluso podemos ver los tamaños de todos los procesos de clase. Primero, volcaremos estos procesos lsass utilizando el complemento procdump de Volatility. Luego hacemos un ls en el directorio donde volcamos los 3 procesos lsass. Podemos ver claramente una diferencia en el tamaño del 680 frente al 1928 y el 868.

Después de deshacerme de estos dispositivos, los conecté a una máquina que tiene antivirus instalado. McAfee reconoció 1928 como un proceso malicioso y según las políticas configuradas a continuación

Para otro proceso, es decir, 868, lo envío a virus total y confirma que el proceso es malicioso (39/54)

Comparando los procesos con hash difuso

Incluso podemos utilizar hash difuso para ver en qué medida estos procesos coinciden entre sí. Con hash como md5 solo podemos ver si una salida coincide o no, pero con hash difuso podemos ver cómo diferentes archivos están cerca de ser iguales. Usaremos la herramienta ssdeep sobre los procesos volcados en volatilidad.

A continuación se muestra la herramienta ssdeep que ejecuta los ejecutables descartados por la volatilidad en el paso anterior.

A continuación podemos ver que el proceso 680 no coincide con los procesos 868 y 1928.

Entonces, en este artículo vemos cómo se realiza la santificación de procesos y cómo podemos detectarla con complementos de volatilidad y hashing difuso.