Introducción
Las protecciones basadas en la reputación, como el servicio de reputación de Elastic, pueden mejorar significativamente las capacidades de detección mientras se mantienen bajas las tasas de falsos positivos. Sin embargo, como cualquier capacidad de protección, existen debilidades y es posible que se omitan. Comprender estas debilidades permite a los defensores centrar su ingeniería de detección en las principales brechas de cobertura. En este artículo se explorará Windows Smart App Control y SmartScreen como caso práctico para investigar las omisiones a los sistemas basados en la reputación, y luego se demostrarán las detecciones para cubrir esos puntos débiles.
Puntos clave:
- Windows Smart App Control y SmartScreen tienen varios puntos débiles de diseño que permiten a los atacantes obtener acceso inicial sin advertencias de seguridad ni ventanas emergentes.
- Un error en el manejo de archivos LNK también puede eludir estos controles de seguridad
- Los defensores deben comprender las limitaciones de estas características del sistema operativo e implementar detecciones en su pila de seguridad para compensar
Fondo SmartScreen/SAC
Microsoft SmartScreen fue una característica integrada del sistema operativo desde Windows 8. Opera en archivos que tienen la "Marca de la Web" (MotW) y en los que los usuarios hacen clic. Microsoft introdujo Smart App Control (SAC) con el lanzamiento de Windows 11. SAC es, en cierto modo, una evolución de SmartScreen. Microsoft dice que "agrega una protección significativa contra amenazas nuevas y emergentes al bloquear aplicaciones que son maliciosas o no confiables". Funciona consultando un servicio en la nube de Microsoft cuando se ejecutan aplicaciones. Si se sabe que están a salvo, se les permite ejecutar; Sin embargo, si son desconocidos, solo se ejecutarán si tienen una firma de firma de código válida. Cuando SAC está habilitado, reemplaza y deshabilita SmartScreen de Defender.
Microsoft expone API no documentadas para consultar el nivel de confianza de los archivos para SmartScreen y Smart App Control. Para ayudar con esta investigación, desarrollamos una utilidad que mostrará la confianza de un archivo. El código fuente de esta utilidad está disponible aquí.
Malware firmado
Una forma de eludir el Control inteligente de aplicaciones es simplemente firmar el malware con un certificado de firma de código. Incluso antes de SAC, hubo una tendencia a que los atacantes firmen su malware para evadir la detección. Más recientemente, los atacantes obtuvieron de forma rutinaria certificados de firma de validación extendida (EV). Los certificados EV requieren una prueba de identidad para obtener acceso y solo pueden existir en tokens de hardware especialmente diseñados, lo que dificulta su robo. Sin embargo, los atacantes encontraron formas de hacerse pasar por compañías y comprar estos certificados. El grupo de amenazas detrás de SolarMarker aprovechó más de 100 certificados de firma únicos en sus campañas. Las autoridades de certificación (CA) deben hacer más para acabar con los abusos y minimizar los certificados adquiridos de forma fraudulenta. Es posible que sea necesaria una mayor investigación pública para ejercer presión sobre las CA que con mayor frecuencia venden certificados fraudulentos.
Secuestro de reputación
El secuestro de reputación es un paradigma de ataque genérico en los sistemas de protección contra malware basados en la reputación. Es análogo a la investigación de confianza fuera de lugar de Casey Smith y otros contra los sistemas de control de aplicaciones, así como a la investigación de controladores vulnerables de Gabriel Landau y yo. Desafortunadamente, la superficie de ataque en este caso es aún mayor. El secuestro de reputación consiste en encontrar y reutilizar aplicaciones con buena reputación para eludir el sistema. Para funcionar como un vector de acceso inicial, una restricción es que la aplicación debe controlar sin ningún parámetro de línea de comandos, por ejemplo, un host de script que carga y ejecuta un script en una ruta de archivo previsible.
Los hosts de scripts son un objetivo ideal para un ataque de secuestro de reputación. Esto es especialmente cierto si incluyen una capacidad de interfaz de función externa (FFI). Con FFI, los atacantes pueden cargar y ejecutar fácilmente código arbitrario y malware en la memoria. A través de búsquedas en VirusTotal y GitHub, identificamos muchos hosts de scripts que tienen una buena reputación conocida y pueden ser cooptados para la ejecución de código completo. Esto incluye intérpretes de Lua, Node.js y AutoHotkey. Un ejemplo para demostrar esta técnica está disponible aquí.
En el siguiente video se muestra el secuestro con la utilidad de compilación JamPlus para eludir el control de aplicaciones inteligentes sin advertencias de seguridad:
En otro ejemplo, las advertencias de seguridad de SmartScreen se omitieron mediante el uso de un intérprete de teclas de acceso rápido automático conocido:
Otra vía para secuestrar la reputación de una aplicación conocida es explotarla. Esto podría ser simple, como un desbordamiento de búfer tradicional de la lectura de un archivo INI en una ruta previsible. Podría ser algo más complejo que encadena otras primitivas (como ejecución de comandos/escritura de registro/etc.). Además, se pueden encadenar varias aplicaciones conocidas para lograr la ejecución completa del código. Por ejemplo, una aplicación que lee un archivo de configuración y ejecuta un parámetro de línea de comandos se puede usar para iniciar otra aplicación conocida que requiere un conjunto de parámetros para obtener la ejecución de código arbitrario.
Siembra de reputación
Otro ataque a las protecciones de reputación es sembrar binarios controlados por el atacante en el sistema. Si se elaboran con cuidado, estos binarios pueden parecer benignos y lograr una buena reputación, al tiempo que siguen siendo útiles para los atacantes más adelante. Podría ser simplemente un nuevo binario de host de script, una aplicación con una vulnerabilidad conocida o una aplicación que tiene una primitiva útil. Por otro lado, podría ser un binario que contiene código malicioso incrustado pero que solo se activa luego de una fecha determinada o un desencadenante ambiental.
El control inteligente de aplicaciones parece vulnerable a la propagación. Luego de ejecutar una muestra en una máquina, recibió una buena etiqueta luego de aproximadamente 2 horas. Observamos que las técnicas básicas de antiemulación parecían ser un factor para recibir un veredicto o reputación benigna. Afortunadamente, SmartScreen parece tener una barra de prevalencia global más alta antes de confiar en una aplicación. Un ejemplo que demuestra esta técnica está disponible aquí y se muestra a continuación:
Manipulación de la reputación
Una tercera clase de ataque contra los sistemas de reputación es la manipulación de la reputación. Normalmente, los sistemas de reputación emplean sistemas de hash criptográficamente seguros para hacer que la manipulación sea inviable. Sin embargo, nos dimos cuenta de que ciertas modificaciones en un archivo no parecían cambiar la reputación de SAC. SAC puede emplear hash aproximado o comparaciones de similitud basadas en características en lugar de o además del hash de archivos estándar. También puede aprovechar un modelo de ML en la nube para permitir archivos que tengan un puntaje muy benigna (como ser muy similares a los conocidos). Sorprendentemente, algunas secciones del código podrían modificar sin perder su reputación asociada. A través de prueba y error, pudimos identificar segmentos que podrían ser manipulados de manera segura y mantener la misma reputación. Creamos un binario manipulado con un hash único que nunca fue visto por Microsoft o SAC. Esto incrustaba un shellcode "execute calc" y podía ejecutar con SAC en modo de cumplimiento:
Pisotón de LNK
Cuando un usuario descarga un archivo, el navegador creará un archivo "Zone.Identifier" asociado en un flujo de datos alternativo conocido como Mark of the Sitio web (MotW). Esto permite que otro software (incluidos AV y EDR) en el sistema sepa que el archivo es más riesgoso. SmartScreen solo analiza archivos con la marca de la Web. SAC bloquea completamente ciertos tipos de archivos si los tienen. Esto hace que MotW sea un objetivo de investigación interesante, ya que generalmente puede conducir a eludir estos sistemas de seguridad. Los grupos de amenazas motivados financieramente descubrieron y aprovechado múltiples vulnerabilidades para eludir las comprobaciones de MotW. Estas técnicas implicaban anexar firmas de firma de código creadas y no válidas a archivos javascript o MSI.
Durante nuestra investigación, nos topamos con otro desvío de MotW que es trivial de explotar. Implica la creación de archivos LNK que tienen rutas de destino o estructuras internas no estándar. Al hacer clic en ellos, estos archivos LNK se modifican mediante explorer.exe con el formato canónico. Esta modificación conduce a la eliminación de la etiqueta MotW antes de que se realicen los controles de seguridad. La función que sobreescribir los archivos LNK es _SaveAsLink() como se muestra en la siguiente pila de llamadas:
La función que realiza la comprobación de seguridad es CheckSmartScreen() como se muestra en la siguiente pila de llamadas:
La demostración más sencilla de este problema es agregar un punto o espacio a la ruta ejecutable de destino (por ejemplo, powershell.exe.). Como alternativa, se puede crear un archivo LNK que contenga una ruta relativa, como .\target.exe. Luego de hacer clic en el enlace, explorer.exe buscará y encontrará el nombre de .exe coincidente, corregirá automáticamente la ruta completa, actualizará el archivo en el disco (eliminando MotW) y, finalmente, iniciará el objetivo. Otra variante implica la creación de una ruta de varios niveles en una sola entrada de la matriz de rutas de destino del LNK. Normalmente, la matriz de ruta de destino debe tener 1 entrada por directorio. La utilidad pylnk3 muestra la estructura de un exploit LNK (formato no canónico) antes y luego de la ejecución (formato canónico):
Un script de Python que demuestra estas técnicas está disponible aquí.
A continuación se muestra un archivo LNK que omite las restricciones de MotW en Smart App Control para iniciar Powershell y pop calc:
En otro ejemplo, mostramos esta técnica encadenada con el depurador de línea de comandos cdb de Microsoft para lograr la ejecución de código arbitrario y ejecutar shellcode para pop calc:
Identificamos varias muestras en VirusTotal que exhiben el error, lo que demuestra que existe en la naturaleza. La muestra más antigua identificada fue presentada hace más de 6 años. También revelamos detalles del error al MSRC. Es posible que se solucione en una futura actualización de Windows. Vamos a publicar esta información, junto con la lógica de detección y las contramedidas, para ayudar a los defensores a identificar esta actividad hasta que haya un parche disponible.
Detecciones
El secuestro de reputación, por su naturaleza, puede ser difícil de detectar. Innumerables aplicaciones pueden ser cooptadas para llevar a cabo la técnica. Catalogar y bloquear aplicaciones que se sabe que se abusan es un paso inicial (y continuo).
process where process.parent.name == "explorer.exe" and process.hash.sha256 in (
"ba35b8b4346b79b8bb4f97360025cb6befaf501b03149a3b5fef8f07bdf265c7", // AutoHotKey
"4e213bd0a127f1bb24c4c0d971c2727097b04eed9c6e62a57110d168ccc3ba10" // JamPlus
)Sin embargo, este enfoque siempre irá a la zaga de los atacantes. Un enfoque un poco más robusto es desarrollar firmas de comportamiento para identificar categorías generales de software abusado. Por ejemplo, podemos buscar nombres o módulos comunes de funciones Lua o Node.js en pilas de llamadas sospechosas:
sequence by process.entity_id with maxspan=1m
[library where
(dll.Ext.relative_file_creation_time <= 3600 or
dll.Ext.relative_file_name_modify_time <= 3600 or
(dll.Ext.device.product_id : ("Virtual DVD-ROM", "Virtual Disk","USB *") and not dll.path : "C:\\*")) and
_arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info: "*!luaopen_*")] by dll.hash.sha256
[api where
process.Ext.api.behaviors : ("shellcode", "allocate_shellcode", "execute_shellcode", "unbacked_rwx", "rwx", "hook_api") and
process.thread.Ext.call_stack_final_user_module.hash.sha256 : "?*"] by process.thread.Ext.call_stack_final_user_module.hash.sha256api where process.Ext.api.name : ("VirtualProtect*", "WriteProcessMemory", "VirtualAlloc*", "MapViewOfFile*") and
process.Ext.api.behaviors : ("shellcode", "allocate_shellcode", "execute_shellcode", "unbacked_rwx", "rwx", "hook_api") and
process.thread.Ext.call_stack_final_user_module.name : "ffi_bindings.node"Los equipos de seguridad deben prestar especial atención a los archivos descargados. Pueden emplear la reputación local para identificar valores atípicos en su entorno para una inspección más detallada.
from logs-* |
where host.os.type == "windows"
and event.category == "process" and event.action == "start"
and process.parent.name == "explorer.exe"
and (process.executable like "*Downloads*" or process.executable like "*Temp*")
and process.hash.sha256 is not null
| eval process.name = replace(process.name, " \\(1\\).", ".")
| stats hosts = count_distinct(agent.id) by process.name, process.hash.sha256
| where hosts == 1El pisotón de LNK puede tener muchas variantes, lo que dificulta la detección basada en firmas en archivos LNK. Sin embargo, todos deberían desencadenar una señal de comportamiento similar: explorer.exe sobreescribir un archivo LNK. Esto es especialmente anómalo en la carpeta de descargas o cuando el LNK tiene la Marca de la Web.
file where event.action == "overwrite" and file.extension : "lnk" and
process.name : "explorer.exe" and process.thread.Ext.call_stack_summary : "ntdll.dll|*|windows.storage.dll|shell32.dll|*" and
(
file.path : ("?:\\Users\\*\\Downloads\\*.lnk", "?:\\Users\\*\\AppData\\Local\\Temp\\*.lnk") or
file.Ext.windows.zone_identifier == 3
)Por último, la estable cobertura de comportamiento en torno a las técnicas comunes de los atacantes, como la evasión en memoria, la persistencia, el acceso a credenciales, la enumeración y el movimiento lateral, ayuda a detectar intrusiones realistas, incluido el secuestro de reputación.
Conclusión
Los sistemas de protección basados en la reputación son una capa poderosa para bloquear el malware básico. Sin embargo, como cualquier técnica de protección, tienen debilidades que se pueden pasar por alto con cierto cuidado. Smart App Control y SmartScreen tienen un serial de debilidades de diseño fundamentales que pueden permitir el acceso inicial sin advertencias de seguridad y con una interacción mínima del usuario. Los equipos de seguridad deben examinar cuidadosamente las descargas en su pila de detección y no confiar únicamente en las características de seguridad nativas del sistema operativo para la protección en esta área.