Rubeus contra YARA: Qui guanyarà? Descobreix la clau de l'evasió
Celia Catalán
Introducció
En entorns corporatius, l'execució d'eines com Mimikatz, Rubeus i altres binaris àmpliament coneguts sol ser bloquejada a causa de la implementació de mesures avançades de seguretat, com solucions d'antivirus (AV) i EDRs. Aquestes barreres representen un repte significatiu a l'hora de demostrar vulnerabilitats de seguretat. Davant d'aquest problema, hi ha dos enfocaments principals:
- Utilitzar eines alternatives que implementin les mateixes tècniques d'explotació de manera diferent
- Modificar les eines existents per evitar que siguin detectades
Objectiu
En aquesta píndola ens centrarem en el segon enfocament: com modificar una eina el codi font de la qual està disponible, sense comprometre la seva funcionalitat. Per a això, és fonamental entendre les metodologies que els sistemes de detecció empren per identificar i catalogar aquestes eines com a malicioses. Generalment, aquests sistemes utilitzen dues estratègies principals:
- Anàlisi estàtica del binari: Examina l'arxiu sense executar-lo per identificar patrons, signatures i artefactes maliciosos
- Anàlisi dinàmica i detecció per comportament: Monitora el binari en execució, avaluant les seves accions i com interactua amb el sistema
En aquest cas, ens enfocarem en l'anàlisi estàtica, que, en termes pràctics, es basa en la detecció de signatures. Les eines d'anàlisi estàtica poden descompilar binaris i cercar patrons específics en el codi, determinant si una eina podria ser maliciosa. Per exemple, noms de funcions, cadenes estàtiques o seqüències de bytes característiques poden ser marcades com a sospitoses.
Si adaptem aquest concepte a l'ús de regles YARA, l'explicació esdevé més intuïtiva. Les regles YARA són utilitzades per analistes de seguretat i eines de detecció per identificar fitxers sospitosos mitjançant un conjunt de patrons definits. Aquestes regles consisteixen en:
- Cadenes hexadecimals: Definen patrons binaris o bytes específics en el fitxer
- Cadenes de text: Identifiquen paraules o frases rellevants
- Expressions regulars: Permeten definir patrons més complexos i flexibles
En l'exemple, existeixen certes cadenes des de $a - $d definides inicialment que més endavant són utilitzades en la condició de la regla. Si es compleix $a o $b i es compleix $c o $d, la regla serà executada i mostrada com a resultat de l'anàlisi de la mostra.
Exemple
Per a l'exemple següent, utilitzarem un combo de regles ja predefinides Yaraforge per evadir Rubeus.
Rubeus és una eina escrita en C# per interactuar i abusar de Kerberos, permetent atacs com Kerberoasting, ASREPRoasting, Overpass-the-Hash, Pass-the-Ticket, abusos de delegació de recursos i persistència al directori actiu. Es pot trobar el codi font al seu repositori. Aquest disposa d'una regla yara ja proporcionada pel creador i fàcil d'entendre.
Si no es compleix una de les dues condicions (definides amb l'operador lògic AND), la regla no s'executarà, evadint-la. La cadena fa referència al GUID del projecte per defecte, per tant, creant un nou GUID i modificant-lo a les propietats del projecte hauria d'aconseguir evadir la regla.
Per conèixer les regles que s'apliquen al projecte de Rubeus, s'ha de comptar amb:
- Rubeus inicial compilat
- Binari YARA per comprovar les regles
- Les regles de Yara Forge
Con la següent sintaxi s'executarà el binari compilat inicialment. Es poden veure quatre regles yara que s'aniran a evadir a continuació, utilitzant Visual Studio amb la utilitat Buscar i Substituir.
Regla: FIREEYE_RT_Hacktool_MSIL_Rubeus_1
Aquesta regla ja la vam comentar prèviament, ja que és la mateixa que existeix al repositori. Modificant el GUID del projecte amb un altre de vàlid, serà possible evadir aquesta regla.
Es modifica el GUID en el codi del projecte de Rubeus. En tornar a compilar i llançar l'escaneig de regles yara, eliminarem la capacitat de detecció basada en aquesta regla.
Regla: SIGNATURE_BASE_HKTL_NET_GUID_Rubeus
Durant l'execució de l'anterior escaneig, ens adonarem que no només hem eliminat una, sinó que han estat dues, està inclosa. Això es deu al fet que aquesta regla contempla també el GUID del projecte per a la seva detecció.
Regla: ELASTIC_Windows_Hacktool_Rubeus_43F18623
La següent regla té com a objectiu buscar els literals dels missatges de sortida de Rubeus. En aquest cas, l'operador lògic OR contempla ambdós costats per tenir en compte, tant el GUID com obtenir quatre dels literals definits prèviament. Com que al costat esquerre ja no existeix el GUID al projecte canviat per a les anteriors regles, només queda eliminar quatre dels vuit literals. Tots ells comparteixen alguna cosa en comú, l'identificador [Y] on Y pot ser un valor entre *,+,X o !. Si utilitzem la funcionalitat de Buscar i Substituir, podrem canviar tots aquests valors entre claudàtors per eliminar el match amb el literal. Aquest canvi és segur ja que els claudàtors solen ser usats com a decoració en els missatges de sortida, però depenent de l'escenari, cal comprovar que no perdem usabilitat del binari.
Repetim el procés en els símptomes restants eliminant la detecció de la regla yara
Regla: DITEKSHEN_INDICATOR_TOOL_PWS_Rubeus
Aquesta darrera regla contempla noms de les funcions utilitzades internament per Rubeus, així com alguns dels paràmetres d'entrada. En el primer cas no hi ha cap dificultat a l'hora de modificar el codi, però amb els paràmetres cal tenir una consideració especial, ja que alterem paràmetres d'entrada que s'hauran de tenir en compte. Un dels casos és el de rc4opsec utilitzat com a paràmetre de consulta per forjar un tiquet segur. Perquè la regla es trenqui, al ser un operador AND, s'ha d'eliminar un dels segments, per exemple, que existeixin vuit dels deu literals definits anteriorment. Amb la modificació de tres d'ells, aquesta regla ja no serà marcada.
Busquem tres literals i els modifiquem amb noms alternatius per complir amb els requisits. Per exemple:
Repetim aquest procés amb els següents literals:
- EscriureContrasenyaUsuariAFitxer per EscriureLesCredencialsDeContrasenyaUsuariAFitxer
- rc4opsec per errec4opsec
Aquesta regla ja no s'executarà, eliminant la capacitat de detecció dels sistemes de defensa que utilitzin aquest escaneig.
Conclusions
En aquesta entrega hem explorat com, d'una manera senzilla, és possible amagar eines mitjançant la modificació del seu codi original. Aquest enfocament busca eliminar Indicadors de Compromís (IOC) i traces típiques d'eines conegudes, que solen ser ràpidament detectades en entorns protegits. No obstant això, en escenaris reals, la complexitat és molt més gran, i aquestes modificacions bàsiques solen ser insuficients per evadir solucions modernes de Antivirus (AV) i EDR, a causa de factors com:
- Regles de detecció propietàries: Cada producte de seguretat compta amb regles específiques no públiques, la qual cosa complica la seva evasió.
- Anàlisi dinàmic: A més de les signatures, molts EDR incorporen anàlisi de comportament que monitoren com interactuen les eines amb el sistema.
A continuació, enumerem alguns punts clau i dificultats que s'han de considerar en dissenyar tècniques d'evasió més avançades:
- Regles YARA avançades:
- Regles propietàries dels productes de seguretat: Les deteccions no públiques requereixen proves extensives i un enfocament iteratiu per trobar tècniques efectives d'evasió.
- Factors addicionals: Més enllà de les regles estàtiques, els sistemes de seguretat avaluen accions sospitoses, signatures digitals del binari i anomalies en el flux d'execució, per la qual cosa l'evasió ha de ser integral.
Axel Losantos, Consultor Sènior de Seguretat Ofensiva a Zerolynx per Cybertix
