Fråga:
Omvänd teknik Windows Defenders signatur för Metasploit Framework's metsrv.dll
plowsec
2018-10-25 00:47:57 UTC
view on stackexchange narkive permalink

Som en pentester för en konsultbyrå är det en del av vårt jobb att "undvika" antivirus efter att ha fått kodkörning på informationssystem. Det är verkligen nödvändigt att bevisa utnyttjande av sårbarheter, i motsats till att bara rapportera dem. Om en AV upptäcker de verktyg vi använder kommer kunder ofta att bortse från sårbarheten eftersom de inte är övertygade om risken det orsakar.

Vi märkte att Windows Defender upptäcker metsrv.dll från Metasploit Framework i minnet och dödar. vårt skal. Detekteringen görs av mpengine.dll och görs antingen genom någon form av kriterier på den emulerade binära eller är ett mönster av byte i DLL.

Nu när frågan är klar är här den faktiska frågan: hur kan jag fortsätta att peka ut exakt vad signaturen för den här filen är?

Innan du svarar här är de slutsatser jag redan har kommit till: p>

  • Windows Defenders skannmotor upptäcker metsrv.dll från Metasploit när den laddas in i minnet.
  • Jag kan använda Tavisos loadlibrary för att återge detektionen statiskt på GNU / Linux med följande kommando:

./mpclient metsrv.x64.dllmain (): Skanning metsrv.x64.dll ... EngineScanCallback (): Skanning inputEngineScanCallback (): Hot HackTool: Win64 / Meterpreter.A! dll identifierad.

  • Jag har minskat provstorleken ner från 200 kb till 13 kb med GNU split verktyg och en "binär sökning" -metod: provet är uppdelat i två delar , matas båda till Windows Defender och den del som detekteras delas sedan upp i ytterligare två delar. Upprepa tills det är möjligt för att minimera testfallet.
  • Demontering av mpengine.dll är inte särskilt användbart, eftersom det finns mer än 30 000 funktioner som IDA Pro hittar i det.
  • Kodtäckningsanalys med Pin gör det möjligt att minska denna uppsättning till 3k-funktioner, vilket fortfarande är för mycket att analysera statiskt.
  • mpengine.dll kan felsökas i gdb. Jag satte en vaktpunkt på strängen "Win64 / Meterpreter.A! Dll" för att se om jag kunde hitta en intressant funktion som skulle läsa på den här platsen, kanske vid en tidpunkt nära domens tid. Fortfarande förlorat på grund av kodens storlek, även om övervakningspunkten utlöses två gånger.
  • Ett skript på GitHub som heter avwhy.py gör det möjligt att avleda signaturer från AV-enheter genom att ändra en byte åt gången och memorera de som påverkar AV: s dom. Efter att ha kört mer än 16 timmar returnerade verktyget mig hela filen som en del av signaturen, vilket ser ut som ett felresultat: det är osannolikt att jag har hittat den exakta signaturen med hjälp av delningsverktyget, eftersom jag förväntar mig att antingen ha för mycket byte eller att ha tagit bort användbara byte från signaturen.

Som ni kan se har jag lagt ner många timmar på detta. Målet är att hitta den exakta signaturen , inte att undvika den genom att tillämpa någon form av transformation på metsrv.dll . Jag tycker att det är en rolig reverse engineering-utmaning men jag sitter fast för nu.

Vilka är stegen som jag behöver ta för att uppnå mitt mål?

Redigera: För att klargöra vad jag försöker göra , här är ett självpublicerat papper från Tavis Ormandy: Sophail: En kritisk analys av Sophos Antivirus

På sidan 3 visar han signaturen för filen "Attention 629". Jag försöker uppnå samma resultat. Naturligtvis kan jag attackera 3k-funktionerna och arbeta härifrån, men jag antar att Tavis hade ett mer intelligent tillvägagångssätt, och det är den typ av svar jag letar efter.

Välkommen till SE. vilken del av binären är de 13K? koda? data? rubrikdata?
Du har rätt, jag glömde att nämna att dessa 13K är PE-rubriken och en del av .text-avsnittet.
Har du tittat på [Alexei Bulazels Windows Defender-forskning] (https://i.blackhat.com/us-18/Thu-August-9/us-18-Bulazel-Windows-Offender-Reverse-Engineering-Windows-Defenders- Antivirus-Emulator.pdf)? "mpengine.dll" har redan analyserats i viss utsträckning. Du behöver inte börja från grunden. Hans verktyg finns här: https://github.com/0xAlexei/WindowsDefenderTools
Ja det har jag. Men Alexei släppte bara en liten del av sin forskning, som de flesta BlackHat-pratare gör. Om du gräver hans repo kommer du att upptäcka att han behöll den viktiga koden och verktyget som "övningar för läsaren". Dessutom gynnade han av mpengine.dlls felsökningssymboler, som jag inte kunde få tag på. Jag vill inte heller undgå emulatorn utan att hitta det statiska signatur- / detekteringsmönstret.
Jag tror att du ställer en fel fråga. Visst, du kan spendera ett halvt år på att vända upptäckten som Alex gjorde. Men då kommer du tillbaka till det ursprungliga problemet: hur man undviker upptäckten. Och i själva verket kan du förmodligen uppnå det andra utan att veta det exakta svaret på det första (även om det kan ge dig några tips), så jag personligen skulle börja på undvikelsen direkt.
Se t.ex. https://security.stackexchange.com/q/44345/26747 för några idéer
Igor, jag kan redan undvika upptäckten, eftersom signaturer inte är motståndskraftiga mot enkla omvandlingar. Som jag sagt är målet inte att undgå signaturen, utan att hitta den för att förstå vad som är dolt.
Två svar:
Lisbeth
2018-10-25 14:18:51 UTC
view on stackexchange narkive permalink

Ett tillvägagångssätt som du kan överväga är att sammanställa olika versioner av metsrv.dll från källan och sedan observera vilka som upptäcks och vilka som inte är. Till exempel:

  1. Kommentera halva koden i huvud och kontrollera om den resulterande DLL-filen upptäcks. Eftersom ditt mål är att undvika statisk detektering spelar det ingen roll för nu att DLL inte är helt funktionell.
  2. Om du inte upptäcker, avmarkera den första halvan av koden som kommenterades första gången och kontrollera igen detekteringen . Annars kan du kommentera den andra halvan av koden som användes i föregående steg och kontrollera igen detekteringen.
  3. Upprepa denna binära sökmetod tills du har begränsat den till en viss funktion som orsakar detekteringen.
  4. Upprepa steg 1-3 för kod för den funktionen och alla ytterligare kapslade funktionssamtal. Så småningom bör du nå en punkt där det inte finns några fler funktionsanrop och där du kommenterar en enda kodrad ger filens detekteringsstatus.
  5. Kontrollera mönstret för byte (maskinkod) som motsvarar detta sista kodraden och experimentera med att mutera den för att testa robustheten i mpengine s detektionskriterier.

Du kan också överväga olika kompilator- eller byggalternativ (t.ex. kompilera med felsymboler eller annan optimeringsnivå) med den ursprungliga koden för att se om det gör att upptäckten går bort. Om så är fallet kan en jämförelse av de två binärfilerna med fc eller något annat verktyg peka på orsaken till upptäckten.

@UnitedCoconut Dina invändningar mot detta svar görs på irrelevanta grunder. Skalbarhet och tillgång till källkod är uppenbarligen inte ett problem i det här fallet eftersom vi har att göra med en enda öppen källkod. Dessutom nämndes inte dina bekymmer här i din fråga. Vänligen avstå från att vara oförskämd. Oavsett är jag inte säker på vad du förväntar dig. Det finns inga magiska knep eller hemliga tekniker här - det finns inget sätt att vända mpengine.dll.
@United Kokosnöt Om du inte ens är villig att lura med några rader källkod för att hitta ett svar när källan är tillgänglig, vilket hopp har du att hitta ett svar när det inte är det?
@SYS_V Ber om ursäkt om jag lät oförskämd, var säker på att det inte var min avsikt. Scabilitet är ett problem eftersom jag föredrar att ha bestående resultat på grund av den tid som krävs för att få dessa resultat, och min insekt säger till mig mpengine.dll hittade flera signaturer i metsrv.dll. Samantha: Jag är villig att fiska med koden , men på ett sätt som gör mitt arbete återanvändbart och långsiktigt motståndskraftigt. Jag kommer att klargöra mitt svar baserat på dina kommentarer.
plowsec
2018-12-14 03:43:08 UTC
view on stackexchange narkive permalink

Jag hittade alla signaturer genom att utföra en Out-of-Band-attack på motorn och med hjälp av en enorm uppsättning muterade filer. Massor av reverse engineering också. Jag var tvungen att pröva många falska positiva effekter och det krävde manuellt arbete, så det här är fortfarande inte det perfekta tillvägagångssättet, men klart mer skalbart än de andra föreslagna.

Jag har delat några av resultaten med rapid7-team som du kan se här: https://github.com/rapid7/metasploit-framework/issues/10815

Nedan följer copy-paste för efterlevnad av detta forums regler :

Låt oss säga att du har en FUD-stager och att du kodar STAGEN. Windows Defender kan fortfarande upptäcka din meterpreter-session eftersom den har en kärna-land-återuppringning för att upptäcka när bilder laddas i minnet (som alla konkurrerande AV). Detta görs med PsSetLoadImageNotifyRoutine &co.

Vid dessa händelser utför Windows Defender en genomsökning av minnesregionen där bilden laddas och sök efter STATIC-signaturer (långt ifrån maskininlärning och beteendeanalys ...)

Vanliga upptäckta artefakter är:

  • Konstanter som strängar ("[*] Försök att lägga till användare% s till grupp% s på domänkontrollanten% s") => sådan en hög poäng att det nästan är ett EICAR-test, även om WD kontrollerar att det hör hemma i en fil som följer PE-formatet.
  • Stort heltal (till exempel 0x6A4ABC5B i ReflectiveLoader.h, vilket är en rot13-hash används för att lokalisera API: er som alla kopierar klistras in i flera år);
  • Delar av hårdkodad skalkod (var och en i base_inject.c, till exempel x48 \ xC1 \ xE8 \ x20);
  • DLL-export (till exempel söks exporten "ReflectiveLoader" både av WD och Kaspersky).

Vissa strängar har mycket låg poäng men har fortfarande betydelse i domen. Om du har något av elementen ovan kommer du att bli flaggad med säkerhet och att ta bort de låga poängen kommer inte att ha någon inverkan. Ett exempel på en sådan sträng är "scheduler_insert_waitable".

Allt som allt, "göm din fru dölj dina strängar" ...



ⓘ
Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 4.0-licensen som det distribueras under.
Loading...