Zobrazují se příspěvky se štítkemDuqu. Zobrazit všechny příspěvky
Zobrazují se příspěvky se štítkemDuqu. Zobrazit všechny příspěvky

středa 25. dubna 2012

Duqu FAQ


Aktualizováno dne 27. březen 2012 (Přejděte do dolní části)

Jedná se o aktivní vyšetřování Global Research společnosti Kaspersky Lab a Analysis Team. Budeme aktualizovat tento dokument dotazy podle potřeby.

Co přesně je Duqu? Jak je to souvisí s Stuxnet?

sledovat Ryan Naraine na twitteru
Duqu je sofistikovaný Trojan, který se zdá k byli napsáni stejnými lidmi, kteří vytvořili nechvalně známého červa Stuxnet. Jeho hlavním cílem je působit jako backdoor do systému a usnadní krádeže soukromých informací. To je hlavní rozdíl v porovnání s Stuxnet, který byl vytvořen k provádění průmyslové sabotáže.Je také důležité zdůraznit, že zatímco Stuxnet je schopen replikovat z jednoho počítače do druhého pomocí různých mechanismů, Duqu je Trojan, který nevypadá, že replikovat sama o sobě.

Má tohoto cíle by žádné PLC / SCADA zařízení? Přesně, kdo / co jsou cíle? Víme?

Na rozdíl od Stuxnet, Duqu se nezaměřuje na PLC / SCADA zařízení přímo, i když některé z jeho podprogramů může být použita k odcizení informací týkajících se průmyslových zařízení. Zdá se, že Duqu byl vytvořen za účelem sběru zpravodajských informací o jeho cílech, které mohou zahrnovat skoro vše, co je k dispozici v digitální podobě na počítači oběti.

Jak Duqu infikovat počítače? Může šířit prostřednictvím USB zařízení?

V případech jsme analyzovali, Duqu infikuje počítač prostřednictvím cíleného útoku zahrnující Word dokument, který užívá CVE-2011-3402 zranitelnost. To je 0-day zranitelnosti v jádře Win32k.sys součástí systému Windows, která umožňuje útočníkům spustit kód s nejvyšší úroveň oprávnění, obcházet skoro většina z ochranných mechanismů z Windows nebo bezpečnostního softwaru. Podle našich poznatků, Duqu je jediný malware pomocí této chyby zabezpečení se infikovat počítače. Všechny společnosti Kaspersky Lab bezpečnostní řešení odhalit tuto chybu zabezpečení, pod názvem Exploit.Win32.CVE-2011-3402.a z 6. listopadu 2011.

Existuje nějaký exploit, a to zejména zero-day v Duqu?

Tam je opravdu 0-day zranitelnost se používá k infikování počítačů v počáteční fázi. Společnost Microsoft vydala poradenství (2639658) se základními informacemi a zmírnění kroků .

Jak AV prodejci vědomi této hrozby? Kdo oznámil to?

Duqu byla upozorněna bezpečnostní komunity v maďarských CrySyS Research Lab . Oni byli první, kdo poukazují na podobnost s Stuxnet a provést to, co zůstává nejdůkladnější analýzu malwaru dosud.

Když byla tato hrozba poprvé spatřil?

První Duqu útoky byly spatřeny již v polovině dubna 2011. Útoky pokračovaly v následujících měsících až do 18. října, kdy byla zpráva o Duqu zveřejněny.

Kolik variant Duqu existují? Existují velké rozdíly ve variantách?

Zdá se, že existuje nejméně sedm variant řidičů Duqu, spolu s několika dalšími komponenty. To vše jsou detekovány s různými názvy od různých antivirových společností, vytváří dojem, že existuje několik různých variant. V době psaní tohoto článku, jsme si vědomi dvou Infostealer komponent a sedmi řidičů.Navíc máme podezření na existenci alespoň další Infostealer složky, která měla možnost přímo vyhledávat a krást dokumenty z oběti stroje.

Hovoří se, že to konkrétně zaměřuje na certifikační orgány . Je to pravda?

Zatímco tam jsou opravdu zprávy naznačující, že hlavním cílem je Duqu ukrást informace z CA, není tam žádný jasný důkaz v tomto okamžiku na podporu tohoto tvrzení. Naopak jsme přesvědčeni, že hlavním účelem Duqu byla jiná a CA byly jen vedlejší obětí.

Symantec tvrdí, toto je zaměřena na konkrétní organizace, případně s cílem shromáždit specifické informace, které by mohly být použity pro budoucí útoky. Jaké druhy dat jsou hledají a jaké budoucích útoků jsou možné?

Jedním z podezření, že byl použit Duqu ukrást certifikáty od certifikačních autorit, které mohou být použity k podpisu škodlivý kód, aby bylo těžší chytat. Funkčnost backdoor v Duqu je ve skutečnosti dosti složitý a může být použit pro mnohem víc. V podstatě to může ukrást všechno, ale vypadá to, že útočníci byli především zájem o sběr hesel, takže na ploše obrazovky (špehovat uživatele) a krást různé druhy dokumentů.

Je příkaz-a-Control Server používá Duqu stále aktivní? Co se stane, když nějaká infikovaný počítač kontakty C & C?

Počáteční Duqu C & C server, který moderoval v Indii již není aktivní. Stejně jako v případě Stuxnet, to bylo docela rychle vytáhl v režimu offline, jakmile novinky zlomil. Kromě toho jsme si vědomi další C & C serveru v Belgii, která byla také rychle offline. Vlastně se zdá, že každý Duqu cílený útok použít samostatný C & C server.

Proč je Duqu nakonfigurován pro spuštění na 36 dní?

Možná, že autor byl fanoušek kulatých čísel, jako je 6x6? :) Ve skutečnosti je doba, po kterou Duqu běží v systému definován v konfiguračním souboru a pohybuje se mezi útoky. Viděli jsme také případy, kdy byla doba stanovená na 30 dnů.

Kdo stojí za tímto útokem?

Stejný gang, který byl za Stuxnet. Kupodivu se zdá, že se zvedl zájem o astronomii, infostealer spustitelný soubor má část souboru JPEG zvedl o Hubble Space Telescope ("Interakce galaxie NGC 6745 System"):
Obrázek zachycuje následek přímé kolize dvou galaxií (!), Několik milionů let dříve. si můžete přečíst příběh zde .
UPDATE (15. listopadu 2011):

Otázka: Co přesně je ukraden z cílových počítačích?

Při aktivaci hlavní Duqu programu těla se připojí k jeho C & C serverem a stažení aktualizace a doplňkové moduly. Jeden takový modul je Duqu "infostealer," pro které jsou známy dvě verze a další jsou věřil k existovali v různých bodech v čase.
"Infostealer" modul je stažen do paměti a proveden prostřednictvím techniky procesu vstřikování používaného Stuxnet a Duqu, aby se zabránilo dočasné soubory. Toto je děláno s cílem zajistit, aby "infostealer" složka (a další Duqu aktualizace), nezachytí, nebo zanechali na infikovaný počítač. To také znamená, že mají omezenou životnost, v podstatě až do příštího restartu systému.
Nejsilnější verze "infostealer" má schopnost zachytit stisky kláves, to dělá screenshoty celé obrazovky (poprvé) a aktivního okna, sbírá IE historii procházení a různé údaje týkající se konfigurace systému sítě.K dispozici je také kód, který může dělat procházení sdílených položek v síti. Všechny tyto informace jsou pěkně zabalené do souboru, který je zapsán do složky TEMP%% ve výchozím nastavení. Je BZIP2 komprimovaný formát s modifikovanými záhlaví. Díky BZIP2 komprese, soubory jsou menší, než si myslíte.
Tyto "komponenty" infostealer jsme viděli vytvářet soubory s názvem "~ DQx.tmp". Kromě toho jsme si vědomi jiných souborů s názvem "souboru ~ DFxxxxx.tmp" a "~ DOxxxxx.tmp". "DF" a "DO" mají podobný formát a zdá se, byly získány od starší verze "infostealer". Oni také obsahují více informací, včetně různých souborů obětí PC, jako je Word nebo Excel dokumenty. V "~~~HEAD=NNS DF" soubory jsou obecně mnohem větší, vzhledem k jejich další obsah souborů.
Ve všech případech, které lze snadno rozeznat v záhlaví "ABh91AY & SY". Najdete-li takové soubory v počítači pak s největší pravděpodobností jste se stali obětí Duqu. Pokud chcete skenovat systém pro takové soubory, milí lidé v CrySyS mít sadu nástrojů , které mohou pomoci.

Otázka: Slyšel jsem, že Duqu a Stuxnet jsou psány stejnými lidmi. Také jsem slyšel, že Duqu a Stuxnet jsou psány různými lidmi. Jaká je pravda?

Duqu a Stuxnet mají spoustu věcí společných. Použití různých šifrovacích klíčů, včetně těch, které nebyly zveřejněny, před Duqu, vstřikovacích techniky, využití zero-day exploitu, využití odcizených certifikátů k podepisování ovladačů, to vše nás věří, jak bylo napsáno stejný tým.
Takže, co to přesně znamená? Jednoduše řečeno, různí lidé mohou pracovali na Duqu a Stuxnet, ale s největší pravděpodobností pracovali pro stejnou "nakladatelství." Pokud chcete analogii, Duqu a Stuxnet je jako Windows a Office. Oba jsou od společnosti Microsoft, i když různí lidé mohli na nich pracoval.

Otázka: Jaká je souvislost mezi Duqu a Showtime Dexter?

V incidentech jsme analyzovali, Duqu přijede do systému ve formě dokumentu aplikace Microsoft Word.Dokument obsahuje exploit pro zranitelnost známou jako CVE-2011-3402 . To je přetečení zásobníku v závislosti na Win32k.sys, které se týkají True Type fonty. Ke zneužití této konkrétní chyby, útočník potřebuje k řemeslu speciální True Type písmo a vložit ji do dokumentu, například dokumentu aplikace Word.
Nyní, na připojovací části - v incidentu jsme se analyzovat (a to platí i pro další známé události), útočníci použili písmo, pravděpodobně s názvem "Dexter Regular", a "Showtime Inc," (c) 2003 . To je další žert přitáhl autory Duqu, protože Showtime Inc kabelové vysílání společnost za televizním seriálu Dexter, o CSI lékař, který také se stane být sériový vrah, který pomstí zločinci v některých post-moderní zvrácenosti charakteru Charles Bronson je v Death Wish.

Otázka: Takže, Duqu autoři sociopat, sérioví vrazi, kteří mají zájem počítačového malware?

Doufáme, že oni jsou jen fanoušci Dexter.

Otázka: Stuxnet obsahuje konkrétní proměnnou, která ukazuje na 9. května 1979 , datum, kdy byl prominentní židovský obchodník tzv. Habib Elghanian popraven popravčí četou v Teheránu. Jsou tyto termíny v Duqu stejně?

Zajímavé je, že stejná konstanta se nachází v Duqu také. Maďarský CrySyS laboratoř byla první poukázat na využití 0xAE790509 v Duqu. V případě Stuxnet je číslo 0x19790509 použít jako infekce kontroly, v případě Duqu, konstanta je 0xAE790509.
Co je méně známo, že 0xAE790509 byl také použit v Stuxnet, ale před Duqu to nebyla zařazena do žádné z veřejných analýz jsme zvyklí.
Tam je také mnoho jiných míst, kde se používá konstantní 0xAE, a to jak v Duqu a Stuxnet.
Nakonec je konstanta 0xAE240682 používá Duqu jako součást dešifrování rutiny pro jeden z PNF známých souborů. V případě, že vás zajímá, 24. června 1982 je opravdu zajímavé datum - podívejte se na případ letu BA 9 .
* Výzkum společnosti Kaspersky Lab pro výzkum a Global Analysis Team.
Další literatura:
  • Část první . Spojení mezi Duqu a Stuxnet týden 20 říjen 2011
  • Část druhá . Jeden z prvních skutečných případů infekce se konala v Súdánu. 25 říjen 2011
  • Část třetí . Detekce hlavní chybějící článek - kapátko, které provedla počáteční systémové infekce.02.11.2011
  • Část čtvrtá: Zadejte pana B. Jasona a televizoru Dexter. Puzzle s fotkou NGC 6745 galaxie a televizním seriálu Dexter. 11.11.2011
  • Část pátá . Recenze komponentů Duqu je. 15.listopadu 2011
  • Část šestá . Zkoumá velení a řízení infrastruktury, kterou využívají Duqu. 30.listopadu 2011
  • Část sedmá . Stuxnet / Duqu: Vývoj ovladačů. 28.prosince 2011
  • Část osmá . Tajemství Duqu rámce
  • Devět částí . Tajemství Duqu rámce vyřešen
  • Část deset . Tajemství Duqu: Část Deset

  • Podcast

    Costin Raiu globálního výzkumu společnosti Kaspersky Lab a mluví Analysis Team o vyšetřování Duqu, pravděpodobnost, že to bylo napsáno ve stejném týmu jako Stuxnet, zda vláda je za jeho rozvoj a jaké chyby provedené autoři.
    Stáhněte si podcast z Threatpost webu.

    Tajemství Duqu rámce vyřešen


    Pátrání po identifikaci

    V mé předchozí blogpost o rámcové Duqu, jsem popsal jednu z největších zbývajících záhad asi Duqu - zvláštností C & C komunikačního modulu, který se zdá být napsána v jiném jazyce než zbytek kódu Duqu.Pokud jde o technické odborníky, jsme našli na tuto otázku velmi zajímavý a záhadný a my jsme chtěli sdílet s komunitou.
    Zpětnou vazbu jsme dostali předčil naše nejdivočejší očekávání. Máme více než 200 připomínek a 60 a více e-mailové zprávy s návrhy o možných jazycích a rámců, které by byly použity pro generování rámcového Duqu kód. Rádi bychom říci velký "Děkujeme!" všem, kteří se podíleli na této cestě, aby nám pomohli identifikovat záhadný kód.
    Podívejme nejoblíbenější návrhy jsme dostali od Vás:
    • Varianty LISPu
    • Dále
    • Erlang
    • Google Go
    • Delphi
    • OO C
    • Staré kompilátory pro C + + a dalších jazycích
    Díky některé velmi užitečné a znalý připomínky, můžeme nyní říci, s vysokým stupněm jistoty, že jsme našli správnou odpověď. Chtěl bych citovat nejdůležitější připomínky, které nám pomohlo vyřešit hádanku:
    igorsk Simple Object Orientace (pro C)

    Zdá se, že někdo po dobu reddit odst. http://www.reddit.com/r/ReverseEngineering/ ) jackpot: kód úryvky vypadají _very_ podobného, ​​co by to přinést: http:// daifukkat.su / wiki / index.php / SOO
    Existuje několik dalších OO rámce pro C, ale oni neodpovídají také: http://ooc-coding.sourceforge.net/ http://sooc.sourceforge. net /
    Jonwil Re: Ostatní C / C + +?

    Viděl jsem, jak GCC pracuje interně a jeho ABI (pro množství různých verzí), a mohu potvrdit, že kód Duqu rozhodně není generován GCC. Nevím, jak ostatní C + + kompilátory práce, ale věci, které vidím v ASM (např. kde se odkazy na funkce odejít, jak "to" ukazatel je předán atd.) nevyplývá, že C + + se mi, ale něco úplně jiného. (Jako výše uvedené "objektově orientované" rámců pro C, které existují)
    igorsk Re: Ostatní C / C + +?

    jsem 99% jistý, strojový kód byl vytvořen MSVC. Je to něco, co budete mít pocit, který má zkušenosti, ale mohu poukázat na dvě věci, které jsou zcela charakteristické pro MSVC: 1), které používá ESI jako první kandidát na dočasné uskladnění, 2) "pop ecx" místo "add esp, 4" .
    Také jsme obdrželi dvě velmi zajímavé e-mailové zprávy. Pascal Bertrand aka bps a další autor, který se raději zůstat v anonymitě navrhl, že kód byl generován z vlastní objektově orientované C dialekt, obecně zvané "OO C".
    Připomínky byly velmi důležité, protože nám umožnila sledovat přesnou kompilátor používaný v projektu: Microsoft Visual Studio kompilátoru. Jsem strávil více času experimentovat s různými verzemi překladačů MSVC a různých zdrojových kódů a kompilace možností se snaží reprodukovat binární kód konstruktoru funkce uvedené v předchozí blogpost a nakonec podařilo.

    Demontáž původního kódu Duqu: konstrukce spojené seznam třídy

    Ručně rozložit C kód, který má stejný kód
    Výše C kód, když sestaven s MSVC 2008 a možnosti / O1 (minimalizovat velikost) / OB1 (pouze rozšířit __ inline) vyrábí operační kódy shodné s těmi v binární Duqu. Změna pořadí operací a if / else bloky mění výsledný kód, MSVC 2005 kompilátor produkuje trochu jiný kód, taky. Takže lze říci, s vysokým stupněm jistoty, že výsledný binární byla sestavena s MSVC 2008 a možnosti / O1 / OB1 a vstupní zdrojový kód byl čistý C.
    Takže, co to znamená? Stručně řečeno, existují dva velmi pravděpodobné odpovědi na naši úvodní otázku:
    1. Kód byl psán používat vlastní OO C rámec založený na makra preprocesoru nebo vlastních směrnic.To bylo navrhl vaše komentáře, protože to je nejčastější způsob, jak zkombinovat objektově orientované programování s C.
    2. Všechny kód byl napsán v C OO ručně, bez rozšíření do jazyka. Nemůžeme popřít, tuto možnost úplně, protože technicky je téměř nemožné rozlišit kód psaný s makro směrnic z ručně kopírování vložený kód.
    Soudě podle množství podobně vypadající kódu v každém konstruktoru funkce a funkce členů, lze předpokládat, že zdrojový kód byl použit předzpracování a varianta 1 je blíže k pravdě.
    Nyní existuje několik open-source "OO C" rámce k dispozici, a některé z nich vyrábějí kódu staveb, které jsou velmi podobné těm, které v kódu Duqu. Nejlepší zápas jsme našli, je SOO (Simple Object Orientace pro C), ale to nemohlo být použity v Duqu, protože to bylo jen zveřejněn při Trojan už ve volné přírodě.
    Bez ohledu na to, která z těchto dvou variant je pravda, že důsledky jsou působivé. Užitečná knihovna obsahuje 95 kB na řízené událostmi kód napsaný s OO jazyka C, který nemá automatickou správu pamětí nebo bezpečné uvedeme. Tento druh programování je více obyčejně nachází v komplexu občanských států softwarových projektů, spíše než současný malware. Dále musí být celá akce řízené architektury byly vyvinuty jako součást kódu Duqu nebo jeho rozšíření OOC.
    Neexistuje žádná jednoduchá vysvětlení, proč byl OO C namísto C + +, ale jsme viděli podobné případy v minulosti. S mluvil s některými lidmi, kteří dávají přednost takové techniky, dali dva hlavní důvody:
    1. Oni nevěří C + + kompilátory, což jsou většinou lidé, kteří začali programovat v dávných dobách, kdy byl assembler nejlepší volba. C byla přímá evoluční krok po assembleru a rychle se stal standardem. Když C + + byla publikována, mnoho starých školních programátorů raději vyhýbat, protože nedůvěra v přidělování paměti a dalších temných jazykových prvků, které způsobují nepřímé provádění kódu (například konstruktéři).
    2. Extrémní přenositelnost. Ještě jednou, za starých časů (10-12 let) C + + není zcela standardizována a to bylo možné, aby C + + kód, který by se kompilovat MSVC ale nekompiluje se s (řekněme) Watcom C + +. Pokud byste chtěli jít na extrémní přenositelnost a zaměřit všechny stávající platformu venku, měli byste jít s C.
    Oba důvody se objeví uveďte kód byl napsán týmem zkušených, "staré školy" vývojářů.

    Závěry

    • Rámcová Duqu se skládá z "C" kód kompilován s MSVC 2008 pomocí speciální volby "/ O1" a "/" OB1
    • Kód byl pravděpodobně napsán s vlastní rozšíření C, obecně nazýván "OO C"
    • Event-driven architektury byl vyvinut jako součást rámce Duqu nebo jeho rozšíření OO C
    • C & C kód mohl být znovu z již existujícího softwarového projektu a je začleněn do trojan Duqu
    Všechny výše uvedené závěry ukazují spíše profesionální tým vývojářů, které se zdají být opětovné použití staršího kódu napsaný top "old school" vývojářů. Tyto techniky jsou běžně vidět v profesionální software a téměř nikdy v dnešní malware. Opět se jedná naznačují, že Duqu, stejně jako Stuxnet, je "jediná svého druhu" kus malware, který vyniká jako klenot z velkého množství "němý" škodlivého programu jsme normálně vidět.

    Tajemství Duqu rámce


    Zatímco analýzu složek Duqu , jsme objevili zajímavou anomálii v hlavní součást, která je odpovědná za jeho obchodní logiky a Payload DLL. Chtěli bychom se podělit o své poznatky a požádat o pomoc identifikační kód.

    Kód rozvržení

    Na první pohled vypadá jako Payload DLL pravidelně Windows PE souboru DLL kompilován s Microsoft Visual Studio 2008 (linker verze 9.0). Vstupní bod kód je naprosto standardní, a tam je jedna funkce vyváží pořadové číslo 1, která také vypadá jako MSVC + +. Tato funkce je volána z DLL PNF a to je vlastně "hlavní" funkce, která provádí veškeré logiky kontaktu s C & C serverů, obdrží další užitečné zatížení modulů a spuštění je. Nejzajímavější je, jak byla tato logika naprogramován a jaké nástroje byly používány.
    Kód část Payload DLL je společné pro binární, která byla provedena z několika kusů kódu. Skládá se z "řezy" kódu, které mohou být zpočátku sestavených v samostatném objektu soubory předtím, než byly spojeny v jediném DLL. Většina z nich lze nalézt v jakémkoli jazyce C + + programu, jako Standard Template Library (STL) funkce, run-time knihovna funkcí a uživatelsky literou zákona, s výjimkou Největší část, která obsahuje většinu z C & C interakce kód.

    Uspořádání kódu části Payload DLL souboru
    Tento řez se liší od ostatních, protože nebyl sestaven z C + + zdrojů. Neobsahuje žádné odkazy na jakékoliv úrovni, nebo uživatelsky napsaných C + + funkce, ale je rozhodně objektově orientovaný.Říkáme, že rámcová Duqu.

    Rámcová

    Funkce

    Kód, který implementuje rámec Duqu má několik charakteristické vlastnosti:
    • Vše je zabaleno do objektů
    • Funkce stůl je umístěn přímo do instance třídy a může být změněno po výstavbě
    • Neexistuje žádný rozdíl mezi užitkových tříd (spojené seznamy, hashe) a uživatelsky písemného kód
    • Objekty komunikují pomocí metody hovory, odložené spuštění fronty a událostmi řízené zpětných volání
    • Neexistují žádné odkazy na run-time knihovny funkcí, je nativní Windows API používá místo

    Objekty

    Všechny objekty jsou instance nějaké třídy, jsme identifikovali 60 tříd. Každý objekt je konstruován s "konstruktor" funkci, která alokuje paměť, vyplní v tabulce a inicializuje funkce členů.

    Funkce konstruktoru pro propojeného seznamu třídy.
    Uspořádání jednotlivých objektů závisí na jeho třídě. Některé třídy Zdá se, že binárně kompatibilní funkce tabulek, ale nic nenasvědčuje tomu, že mají nějaké společné nadřazené třídy (stejně jako v jiných jazycích OO). Kromě toho je umístění stolu funkce není pevně stanovena: některé třídy mají to na posunu 0 instance, ale některé ne.

    Uspořádání propojeného seznamu objektu. Prvních 10 pole jsou odkazy na členské funkce.
    Objekty jsou zničeny příslušných funkcí "destruktor". Tyto funkce obvykle zničí všechny objekty, které odkazuje členských polí a bez jakékoliv použité paměti.
    Členské funkce lze odkazovat pomocí objektu funkce stolu (stejně jako "virtuální" funkcí v C + +), nebo mohou volat přímo. Ve většině objektově orientovaných jazycích, členské funkce obdrží "to" parametr, který odkazuje na instanci objektu, a tam je volání konvence, která definuje umístění parametru - buď v registru nebo v zásobníku. To není případ rámcových tříd Duqu - mohou přijímat "to" parametr v každém rejstříku nebo v zásobníku.

    Člen funkce propojeného seznamu, dostane parametr "to" na zásobníku

    Událostmi řízené rámec

    Uspořádání a realizace objektů v rámci Duqu rozhodně není nativní C + +, který byl použit k naprogramování zbytek Trojana. Tam je ještě zajímavější vlastnost rámce, který je používán značně v průběhu celého kódu: je řízené událostmi.
    Existují speciální objekty, které implementují událost-řízený model:
    • Objekty událostí, založené na nativní Windows API rukojetí
    • Objekty závit souvislosti, které drží seznamy událostí a odložené exekučního fronty
    • Callback objekty, které jsou spojené s akcí
    • Událost monitory, vytvořené každým závitem kontextu pro monitorování událostí výkonných zpětné volání objekty
    • Závit souvislosti skladování spravuje seznam aktivních vláken a poskytuje přístup k za-závit kontext objektů
    Tato událost-řízený model se podobá Cíl C a jeho poselství procházející funkce, ale kód nemá žádné přímé odkazy na jazyk, ani to vypadá sestavují se známými cíle kompilátory C.

    Událostmi řízený model Duqu rámce
    Každý závit daný objekt může začít "hlavní smyčku", který hledá a zpracovává nové položky v seznamu.Většina kódu Duqu podle stejného principu: vytvořit objekt, svázat několik zpětná volání na vnitřní nebo vnější události a zpět. Zpětné volání rutiny jsou pak prováděny objektu události monitoru, který je vytvořen v rámci každé vlákno kontextu.
    Zde je příklad pseudokód pro socket objektu:
    SocketObjectConstructor {
        NativeSocket = socket ();
        SocketEvent = new MonitoredEvent (NativeSocket)
        SocketObjectCallback = new ObjectCallback (to, SocketEvent, OnCallbackFunc),
        connect (NativeSocket, ...);
    }
    {OnCallbackFunc
        switch (GetType (událost)) {
        případ Připojeno : ...
        případ ReadData: ...
    ...}
    }

    Závěry

    • Rámcová Duqu Zdá se, že byl napsán v neznámém programovacím jazyce.
    • Na rozdíl od zbytku těla Duqu, že to není C + + a to není zkompilován s Microsoft Visual C + + 2008.
    • Velmi událostmi architekturu body kódu, který byl navržen pro použití v docela hodně jakékoli podmínky, včetně asynchronních commutations.
    • Vzhledem k velikosti projektu Duqu, je možné, že jiný tým byl zodpovědný za rámec, než tým, který vytvořil ovladače a napsal systému infekci a využívá.
    • Tajemný programovací jazyk není rozhodně C + +, Objective C, Java, Python, Ada, Lua a mnoho dalších jazyků jsme zkontrolovali.
    • Ve srovnání s Stuxnet odst. celý napsán v MSVC + +), to je jeden z určujících zvláštnosti rámci Duqu.

    Duqu Framework: Co to bylo?

    Po provedení analýzy bezpočet hodin, jsme 100% přesvědčeni, že Duqu rámec nebyl naprogramován s Visual C + +. Je možné, že autoři používají in-house rámec pro generování kódu C zprostředkovatele, nebo použít jiný úplně jiný programovací jazyk.
    Chtěli bychom podat odvolání do programovacího komunity a zeptejte se někoho, kdo uznává rámec, toolkit nebo programovací jazyk, který může generovat kód podobné stavby, aby nás kontaktovat a napište nám komentář v tomto blogpost. Jsme přesvědčeni, že s Vaší pomocí můžeme vyřešit tuto záhadu hluboko v příběhu Duqu.

    Tajemství Duqu: Část sedmá (Zpět na Stuxnet)


    Stuxnet / Duqu: Vývoj ovladačů

    Jsme studovali Trojan Duqu za dva měsíce, prozkoumání toho, jak se ukázalo, kde to bylo distribuováno a jak to funguje. Přes velké množství dat získaných (z nichž většina má zatím být zveřejněn), jsme stále chybí odpověď na základní otázku - kdo je za Duqu?
    Kromě toho existují i ​​další problémy, většinou do činění s vytvořením Trojan, nebo spíše na platformě použije k provádění Duqu stejně jako Stuxnet.
    Z hlediska architektury, platforma slouží k vytvoření Duqu a Stuxnet je stejný. To je soubor ovladače, který načte hlavní modul určený jako šifrované knihovny. Zároveň je zde samostatný konfigurační soubor pro celou škodlivého komplexu a šifrovaný blok v systémovém registru, která definuje umístění modul načítání a název procesu vstřikování.

    Konvenční platformy pro Stuxnet a Duqu
    Tato platforma se obvykle pojmenovaný jako "Tilded", jak jeho autoři jsou z nějakého důvodu, tendenci používat názvy souborů, které začínají "~ d".
    Věříme, že Duqu a Stuxnet byl současně projekty podpořené stejným týmem vývojářů.
    Několik dalších detailů, které byly odkryté naznačují, že byl možná nejméně jeden další spyware modul založený na stejné platformě, v letech 2007-2008, a několik dalších programů, jejichž funkce je nejasná mezi roky 2008 a 2010.
    Tyto skutečnosti výrazně zpochybňovat stávající "oficiální" historie Stuxnet. Budeme se snažit pokrýt je v této publikaci, ale nechal nás nejprve shrnout příběh tak daleko.

    "Oficiální" Stuxnet příběh

    Dovolte mi začít otázkou: kolik Stuxnet soubory ovladače jsou známy? Od dnešního dne by správná odpověď je čtyři . Viz níže pro více informací o nich.
    Název souboruVelikost (bajtů)Kompilace datumKde a kdy to bylo používánoDigitální podpis / podpis datum
    Mrxcls.sys1984001.01.2009Stuxnet (22.06.2009)Ne
    Mrxcls.sys2661601.01.2009Stuxnet (01.03.2010/14.04.2010)Realtek, 25.01.2010
    Mrxnet.sys1740025.01.2010Stuxnet (01.03.2010/14.04.2010)Realtek, 25.01.2010
    Jmidebs.sys2555214.07.2010Lze předpokládat, že StuxnetJMicron, neznámý

    První změna červa Stuxnet, vytvořený v roce 2009, který se používá pouze jeden soubor ovladače - mrxcls.sys bez digitálního podpisu.
    V roce 2010, autoři vytvořili druhý ovladač mrxnet.sys v skrýt červa dílčích souborů na USB disky) a vybavené mrxnet.sys a mrxcls.sys ovladače s digitálními certifikáty od Realtek. Řidič mrxnet.sys nemá žádný velký význam pro náš příběh, jak to je samostatný modul není součástí dodávky do celkové architektury platformy.
    Dne 17. července 2010, ESET zjistila další ovladač "v divočině" - jmidebs.sys - který byl velmi podobný již známým mrxcls.sys, ale byly vytvořeny jen tři dny předtím, než byla objevena Tento ovladač byl podpořen s novým. certifikát - tentokrát od JMicron.
    Až do nedávné doby to bylo nejasné, jaký je účel tohoto souboru byl, ale veřejné mínění za to, že byl spojen s Stuxnet. Jedna z teorií je, že Stuxnet C & C se snažil nahradit starou verzi s Realtek certifikátu s novou. Přitom autoři červa byly buď doufat, aby se zamezilo jejímu zvedl antivirových programů, nebo bylo nahrazení certifikátu, který byl zablokován.
    Bohužel, tato teorie nebyla potvrzena - Jmidebs.sys nebylo nikdy nalezeno kdekoliv. Nová verze Stuxnet může instalovat soubor také nebylo nalezeno.
    Toto je oficiální historie Stuxnet. Nicméně, jak jsem se zmínil výše, v rámci našeho výzkumu jsme zjistili, nové důkazy, které budou popsány níže.

    Dříve neznámých řidičů

    rtniczw.sys

    Při analýze uživatelské události související Duqu, jsme objevili něco nového - něco, co by mohla potenciálně ovlivnit celý Stuxnet příběh, jak ho známe.
    Podivný soubor byl objeven na počítači oběti, která byla zjištěna u nás antivirovým programem jako Rootkit.Win32.Stuxnet.a. Tento verdikt měl odpovídat souborů známých mrxcls.sys popsaných výše, ale zjištěné název souboru a kontrolní součet se liší!
    Soubor byl rtniczw.sys a 26,872 bytů ve velikosti, MD5 546C4BBEBF02A1604EB2CAAAD4974DE0.
    Soubor byl trochu větší, než mrxcls.sys, který měl Realtek digitální podpis. To znamenalo, že rtniczw.sys také měl digitální podpis. Podařilo se nám získat kopii souboru, a byli jsme překvapeni, zjistí, že používá stejný Realtek certifikát, ale s jiným datem podpisu souboru z mrxcls.sys: rtniczw.sys byla podepsána dne 18. března 2010, zatímco řidič mrxcls byla podepsána dne 25. ledna téhož roku.
     
    Mrxcls.sys
     
    Rtniczw.sys

    Kromě toho, rtniczw.sys použit klíč registru a konfigurace bloku dat, který nebyl použit v Stuxnet. Stuxnet použít tlačítka "MRxCls" a hodnotu "Data", zatímco v případě rtniczw.sys, klíč byl "rtniczw" a hodnota byla "Config".
    Podrobná analýza kód v rtniczw.sys identifikovány žádné jiné odlišnosti od "referenční 'Ovladač: Toto bylo stejné mrxcls.sys soubor, vytvořený ve stejném roce, ve stejný den a hodinu - k 1. lednu 2009.
    Hledali jsme další informace o ostatních uživatelích, kteří měli stejný soubor, ale nepodařilo se najít nic!Navíc jsme nenašli žádnou informaci vůbec o názvu souboru odst. rtniczw.sys) nebo jeho MD5 v kterémkoli vyhledávači. Soubor byl identifikován jen jednou: to bylo zasláno pro skenování na VirusTotal z Číny v květnu 2011.
    Zdá se, že systém, který jsme studovali byl napaden na konci srpna 2011. Je třeba poznamenat, že jsme nenašli Stuxnet infekce v systému žádné další soubory z kitu Stuxnet byl nalezen. Nicméně, jsme našli Duqu soubory.
    Došli jsme k závěru, že by mohl být další soubory ovladače podobné "referenční" mrxcls.sys souborů, které nejsou u známých variant Stuxnet.

    rndismpc.sys

    Kontrola v naší sbírce malware pomohla identifikovat další zajímavý soubor, který byl zahrnut ve sbírce více než před rokem. Soubor se jmenuje rndismpc.sys je 19,968 bajtů ve velikosti, MD5 9AEC6E10C5EE9C05BED93221544C783E.

    Ukázalo se, že další řidič, s funkčností téměř shodné s tím mrxcls.sys kromě z následujících výjimek:
    1. rndismpc.sys používá klíč registru, který je odlišný od klíčů používaných oběma mrxcls a rtniczw - to je hlavní "rndismpc" s hodnotou "akci";
    2. používá šifrovací klíč, který je odlišný od toho použitý mrxcls / rtniczw - 0x89CF98B1;
    3. Soubor je kompilace datum 20.ledna 2008 , tedy rok před byly vytvořeny mrxcls / rtniczw.
    Stejně jako rtniczw.sys, že souborů rndismpc.sys nikdy se setkal na strojích našich uživatelů. Nevíme, které škodlivý program nainstalován, nebo které hlavní modul se mělo pracovat.

    Spojovacím článkem: mrxcls.sys -> -> jmidebs.sys Duqu řidiči

    Údaje získané a dostupné informace o rizikových faktorech použitých v Duqu (viz Tajemství Duqu a části první a druhá část ) lze shrnout v následující tabulce:
    JménoVelikostCompi-
    zení data
    Hlavní modulŠifrovací klíčKlíč registruHodnotaZařízení
    jméno
    rndismpc.sys1996820.01.
    2008
    Neznámá0x89CF98B1rndismpc"Akce""Rndismpc"
    mrxcls.sys1984001.01.
    2009
    Stuxnet.a0xAE240682MRxCls"Data""MRxClsDvX"
    mrxcls.sys (podepsaný)2661601.01.
    2009
    Stuxnet.b / .c0xAE240682MRxCls"Data""MRxClsDvX"
    rtniczw.sys (podepsaný)2687201.01.
    2009
    Neznámá0xAE240682rtniczw"Config""RealTekDev291"
    jmidebs.sys (podepsaný)2550214.07.
    2010
    Neznámá0xAE240682jmidebs"IDE"{} 3093983-109232-29291
    <name>. sys *Odlišný03.11.
    2010
    Duqu0xAE240682<jméno>"FILTER"{3093AAZ3-1092-2929-9391}
    <name>. sys *Odlišný17.10.
    2011
    Duqu0x20F546D3<jméno>"FILTER"{624409B3-4CEF-41c0-8B81-7634279A41E5}

    * Známé Duqu řidiči mají jedinečné názvy souborů pro každou z variant. Jejich funkce je však naprosto stejné.
    Podle naší analýzy, jmidebs.sys je spojovacím článkem mezi mrxcls.sys a řidiče později použitý v Duqu.
    Kód mrxcls a jmidebs řidičů je do značné míry podobné. Některé drobné rozdíly mohou být způsobeny různými nastaveními a minimální změny ve zdrojovém kódu, zatímco bod kód zůstává stejný.
    Nicméně, další významné změny lze najít v několika funkcí:
    1. Funkce služby, které získá adresy funkcí API: verze v mrxcls používá funkce MmGetSystemRoutineAddress pro tento účel a příslušných textových jména a adresy příchozích API funkcí. Verze v jmidebs volá své funkce k získání API adresy pomocí hash-sumy jejich jména. Stejné funkce jsou použity u řidičů Duqu, zatímco seznam hash funkce 'je dvakrát tak dlouho.
    2. Funkce, která vytváří pahýly vnést PNF DLL do procesů: verze mrxcls používá útržek o celkové velikosti 6332 bajtů. Jmidebs a Duqu řidiči používají útržky o celkové velikosti 7061 bajtů. Kód používaný v testovacím kódu modulů pro tyto řidiče je stejná, ale má různé kompilace data.
     Mrxcls (Stuxnet)jmidebsDuqu
    APIRtlGetVersion, KeAreAllApcsDisabled, získat voláním MmGetSystemRoutineAddressRtlGetVersion, KeAreAllApcsDisabled, PsGetProcessSessionId, PsGetProcessPeb lékařský svých funkcíPodobně jako jmidebs, 4 další funkce přidané
    Injekčně EXE6332 1.leden 2009 22:53:237061 14.červenec 2010 13:05:317061 Různé kompilace data

    Řidič evoluce

    Jsme zmapovali vazby mezi známých ovladačů, jejichž vývoj a klíčové etapy vývoje lze snadno sledovat.
     
    Řidič vývoj od roku 2008 do roku 2011

    rndismpc.sys a rtniczw.sys a jmidebs.sys

    Jak můžete vidět z grafu, není známo, který škodlivý program, ve styku s těmito třemi řidiče: rndismpc.sys a rtniczw.sys a jmidebs.sys. Zřejmé, otázkou by bylo: oni byli používáni v Stuxnet? Podle našeho názoru by odpověď musí být " ne ".
    Za prvé, pokud byl použit v Stuxnet, oni by nám zanechaly daleko větší stopu než v jednotlivých případech jsme zjištěných. Za druhé, tam nebyl jediný varianta Stuxnet, který je schopen komunikovat s těmito ovladači.
    Souborů rtniczw.sys byla podepsána dne 18. března 2010, ale dne 14. dubna 2010 se Stuxnet autoři vytvořili novou variantu červa, který využil mrxcls.sys "odkaz". Je zřejmé, že rtniczw.sys byla určena pro jiné použití. Totéž lze říci o jmidebs.sys. Jsme přesvědčeni, že tři jezdci jsou jen nepřímo souvisí s Stuxnet a může být bezpečně vymazat z historie Stuxnet.
    Pak je tu další otázka: mohl tyto ovladače byly použity s Duqu?
    Není tam žádná jednoznačná odpověď zde. I když všechny známé varianty Duqu jsou z období od listopadu 2010 do října 2011, věříme, že tam byly starší verze trojské špion vytvořené krást informace.Tři jezdci v otázce mohly být snadno použity v raných verzích Duqu nebo s jinými trojských koní na základě Stuxnet / Duqu platformě. Stejně jako Duqu byly tyto trojské koně s největší pravděpodobností použit v cílených útoků před vzhledu Stuxnet (datovat se k přinejmenším 2008), oba zatímco to bylo aktivní a po jeho C & C byl zavřen. Byli to pravděpodobně k byli paralelní projekty, a Stuxnet byl následně na základě této získané zkušenosti a kód, který již napsal. Zdá se velmi nepravděpodobné, že by to byl jediný projekt, který jeho autoři byli zapojeni palců

    Řidič proces tvorby

    Zkusme si představit, co řidič proces vytváření vypadá. Několikrát ročně se autoři sestavit novou verzi souboru ovladače, vytvoření referenčního souboru. Primárním účelem tohoto souboru je načíst a spustit hlavní modul, který je vytvořen samostatně. Mohlo by to být Stuxnet, nebo Duqu nebo něco jiného.
    Kdy je nutné použít ovladač pro nový modul, autoři používají speciální program, upravit informace pro řidiče "odkaz", tj. soubor jeho jméno a servisní informace, stejně jako klíč registru a jeho hodnota.
    Je důležité si uvědomit, že vyladit hotové soubory a není vytvořit novou úplně od začátku. To znamená, že může mít tolik různých souborů ovladače, jak se jim líbí, z nichž každá má přesně stejné funkce a datum vytvoření.
    V závislosti na cíli útoku a trojské je obětí, několik soubory ovladače pak měla být podepsána s oprávněnými digitálních certifikátů, jejichž původ zůstává neznámý.

    Závěr

    Z údajů, které máme k dispozici, můžeme říci s notnou mírou jistoty, že "Tilded" platforma byla vytvořena kolem roku 2007 nebo začátkem roku 2008 dříve než došlo k jeho nejvýznamnější změny v létě / na podzim 2010. Tyto změny byly zažehnuty pokroky v kódu a na potřebu vyhnout detekci antivirových řešení. Tam bylo několik projektů, které zahrnují programy založené na "Tilded" platformy v celém období 2007-2011. Stuxnet a Duqu jsou dvě z nich - tam by mohlo být jiné, které zatím zůstávají neznámé. platforma se nadále rozvíjí, což může znamenat jen jedno - že jsme pravděpodobně další změny v budoucnosti.