Въведение

В „Първа част от тази серия“ споделихме какво представляват PE метаданните и как да идентифицираме PE метаданните, свързани с разработчиците. Хвърлихме бегъл поглед как прозренията от PE метаданните могат да ни помогнат да открием зловреден софтуер, да припишем неговия източник и да разберем неговата еволюция. Може също да си спомните, че говорихме за друг тип PE метаданни, които могат да бъдат полезни за анализ. Точно така, PE метаданни, свързани с дизайна!

За разлика от свързаните с разработчиците PE метаданни в част първа, които са подобни на „пръстови отпечатъци“ на отделни автори на злонамерен софтуер, свързаните с дизайна PE метаданни в тази статия се произвеждат въз основа на дизайна и средата за компилиране на злонамерения софтуер. Такива метаданни не само предоставят на анализаторите различен набор от прозрения, но също така са по-трудни за модифициране, без да се засяга последователността на PE файла, като например прекъсване на изпълнението на злонамерения софтуер или оставяне на „навигационни трохи“, които показват доказателства за подправяне от автори на зловреден софтуер.

В CSIT анализаторите трябва да преминават през планински товар от зловреден софтуер всеки ден. В края на краищата, самият обем на нов зловреден софтуер, открит всеки ден може да бъде огромен! Добрата новина е, че има ползи от работата с огромни количества данни. Той отваря нови възможности за анализ, които могат да разкрият значими перспективи, които надхвърлят дребномащабния анализ на проби.

Техниките за машинно обучение са част от нашия набор от инструменти за изграждане на автоматизирана система, която разбива зловреден софтуер в голям мащаб и извежда изчислени прогнози. За да направим това, трябва да изградим модел, който може да извърши цялата тежка обработка вместо нас, и да подготвим подходящи входни данни за нашата автоматизирана система. PE метаданните (както свързани с разработчиците, така и свързани с дизайна) са един такъв ценен вход. Може да се използва за разграничаване на членове на едно семейство зловреден софтуер от друго или за идентифициране на прилики между нова проба и анализирани по-рано проби. Видяхме част от това в част първа и ще видим повече в тази статия.

За тази статия нека започнем с разопаковането на това, което се крие в PE метаданните, свързани с дизайна. След това ще използваме нашето новооткрито разбиране, за да изградим автоматизирана система, която може да използва машинното обучение и за двата типа метаданни: и да започнем да клъстерираме проби от зловреден софтуер в мащаб!

Имена на секции — Глави на злонамерен софтуер

Таблицата със секции показва всички секции, които присъстват в PE файла. Можем да мислим за таблица със секции като нещо като страница със съдържание на книга. Таблицата със секции включва подробности, които са свързани с всяка секция, като име, местоположение и размер на данните.

Някои често срещани секции, които можете да намерите в повечето PE файлове, са:

Понякога виждаме необичайни имена на секции, които са били наименувани умишлено от авторите на зловреден софтуер или добавени от други програми, като например packers. Пакерите се използват от авторите на злонамерен софтуер, за да компресират и прикриват своя злонамерен софтуер, като по този начин скриват своя злонамерен код. UPX е един пример за пакет, който се използва широко в зловреден софтуер. Оригиналният файл се предава в рутинната програма за пакетиране, съхранява се в пакетирана секция и обикновено му се дава уникално име на секция, като например „UPX0“, в нов PE файл.

Тъй като имената на секциите, добавени от опаковчиците, са склонни да стърчат, идентифицирането им ни помага да открием подозрителни файлове. Благодарение на @Hexacorn, този изчерпателен списък с известни имена на секции може да се използва за бързо филтриране на PE файлове с подозрителни имена на секции от купчина проби.

Импортиране на данни — Импортиране на сходството

Има много начини да напишете програма - инженерите използват различни API, библиотеки и последователности от функции за импортиране. Тези разлики водят до разнообразни конструкции на импортираната адресна таблица (IAT), която съхранява информация за импортирани функции. Авторите на злонамерен софтуер понякога използват повторно код в извадки или дори варианти и това може да генерира точни или подобни данни за импортиране сред техните извадки. Следователно откриването на идентични или подобни IAT (като например чрез сравняване на хешовете на IAT, наричани още ImpHash-es) е начин за идентифициране на клъстери от зловреден софтуер.

Семейството зловреден софтуер MiniDuke, използвано в кампаниите „Dukes“, показва метаданни за импортиране на данни в игра. Във визуализацията по-долу има 11 уникални ImpHash-а, които са картографирани от повече от 2000 проби. Вероятно тези проби са създадени от малък набор от кодови бази, където клъстерите представляват проби, които вероятно споделят много подобни реализации на код.

Въпреки че ImpHash-es са мощен начин за идентифициране на свързан злонамерен софтуер въз основа на относителната уникалност на импортираните данни, те не са достатъчно надеждни, за да открият незначителни разлики при импортиране. Авторите на зловреден софтуер могат да променят реда, в който импортират функции или библиотеки, така че техните проби да не генерират същия ImpHash. За да се компенсират недостатъците на ImpHash, FuzzyImportHash може да се използва за измерване на степента на сходство на импортираните данни, вместо да се прави двоично сравнение.

Rich Header — Наистина „най-богатата“ информация!

Rich Header е част от PE файловия формат от пускането на Visual Studio 1997 SP3. Той съдържа информация като компилатор, линкер, импортирани файлове, използвани в компилацията, и кратко описание на цялостната структура на PE файла. Въпреки това до днес Microsoft не е публикувала въведение или документация и това остава мистериозна „кутия със съкровища“.

Rich Header се състои от няколко записа в Rich Header и ключ XOR, който се използва за криптиране на целия Rich Header. Всеки запис има следната структура:

ID на продукта и версията на продукта се използват като уникална двойка в записите в Rich Header. И общото появяване за всяка двойка е посочено в полето Брой.

В този раздел ще използваме PE Studio за извличане на Rich Header и ще покажем как може да се използва за клъстериране на зловреден софтуер. Ако искате сами да проучите отключването на тази „кутия със съкровища“, можете да се обърнете към това „подробно ръководство“ от Ерик Пистели.

На фигурата (извлечена RICH заглавка) по-долу, информация като

  1. Очакван брой файлове и импортирани файлове, използвани в проекта за разработка;
  2. Индикация за съществуването на директории с данни в PE файла — директории за експорт и ресурси; и
  3. Извличане на „най-вероятния“ времеви печат на компилация, който може да бъде изведен чрез сравняване на датите на пускане на компилатора и линкера

Следователно записите в Rich Header, когато са поставени заедно, могат да се считат за относително уникални за даден проект, тъй като те могат да останат непроменени седмици или дори месеци през целия му цикъл на разработка.

„Обширно проучване на SANS“ изследва ефективността на използването на Rich header за откриване и свързване на зловреден софтуер. В документа Rich Header Hash (Product ID, Product Version & Count) и Rich Header PV Hash (Product ID & Product Version) са изчислени и използвани като отпечатъци на злонамерения софтуер. Два PE файла с идентични Rich Header Hashes (вероятно различни версии на един и същи проект) могат да бъдат идентифицирани като изградени от една и съща среда.

Въпреки че е възможно да се модифицира Rich Header, е много по-трудно да се създаде реалистичен и все още да се поддържа съгласуваност с други части на PE метаданните. Тази трудност може да се види в един от „„най-измамните хакове в историята““, случаят „Olympic Destroyer“ през 2018 г., където Rich Header беше умишлено модифициран, за да маскира своя произход и да причини погрешно приписване. В статията анализаторите могат да определят, че злонамереният софтуер е създаден с помощта на Visual Studio 6.0 от неговия Rich хедър. Въпреки това, когато информацията беше сравнена с другите части на PE файла, изглежда, че импортира функции от библиотека (mscoree.dll), която дори не е съществувала в този момент!

Фалшификацията на Rich Header в крайна сметка доведе до несъответствие между Rich Header и другите компоненти на зловредния софтуер. Това предизвика подозренията на анализаторите, които продължиха да разкриват намерението на автора на зловреден софтуер да имитира образци на други заплашителни групи. Наистина, актът за убедително модифициране на Rich Header не е лесен и вместо това може да се превърне в индикатор, използван за разкриване на истинските цветове на зловреден софтуер. Следователно търсенето на такива несъответствия може потенциално да ни помогне да извършим по-точно приписване.

Справяне с целия зловреден софтуер

Както споменахме в началото, според Kaspersky, около 360 000 злонамерени файла са били откривани дневно през 2020 г. и този брой се увеличава всяка година! Когато бъде открит нов подозрителен артефакт, анализаторите трябва първо да определят дали е злонамерен или доброкачествен, след това да идентифицират семейството, към което принадлежи, и накрая да изработят подпис, за да го открият. Това може да бъде много предизвикателство и средното време, необходимо за ръчно анализиране и изработване на подписа за всеки зловреден софтуер, може да отнеме часове, дни или дори месеци.

Въз основа на средно 360 000 нови зловреден софтуер, които се откриват дневно, средно около 5 000 000 часа на ден са необходими за ръчен анализ и бърз отговор на всички тях. Можете да разберете накъде отива това - човешко е невъзможно ръчно да се анализира такова огромно количество зловреден софтуер. Ето защо тук влизат в действие техниките за машинно обучение, които ни позволяват да изградим автоматизирана система, която ни помага да анализираме, пресеем и приоритизираме файловете, които изискват по-задълбочен анализ. Но има толкова много техники за машинно обучение; кой използваме?

Ще опишем как използваме клъстериране, общ подход за машинно обучение без надзор, за клъстериране и анализиране на проби въз основа на PE метаданни. Клъстерирането работи върху набори от данни, в които няма променлива за резултата (целевата) или нещо известно за връзката между точките от данни, т.е. немаркирани данни. Алгоритмите за клъстериране намират структура в данните, така че елементите на един и същ клъстер (или група) са по-сходни един с друг, отколкото с тези на различни клъстери. Моделът за машинно обучение ще може да изведе най-вероятните класове за групиране на извадките само чрез сравняване на извадките една с друга, без предварителна информация за данните. Следователно е известно още като учене без учител.

Клъстериране на злонамерен софтуер, управлявано от метаданни – Къде принадлежи това?

Има много модели и алгоритми, които можем да използваме за извършване на клъстерен анализ. За тази статия ще използваме една от готовите техники, алгоритъма K-средства. Ще демонстрираме приложенията за използване на алгоритъма K-means с входни данни, идващи от комбинация от PE метаданни, свързани с дизайна и разработчиците. Това приложение може да извърши бързо сортиране, което ни позволява да отсеем интересни проби в рамките на минути, което помага да се приоритизират интересуващите ни проби за по-подробен анализ.

Внедряването на алгоритъма на K-средства изисква от нас да предоставим предположение или да „познаем“ „истинския“ брой клъстери „k“ и идентифицира тези клъстери сред входните данни чрез процес на обучение. За да се намери задоволителен резултат от клъстерирането, обикновено са необходими няколко итерации за експериментиране с различни стойности на k. Това може да се извърши с „няколко статистически измервания“ или визуална проверка. Визуалната проверка често се прилага широко и се използва за представяне на резултатите от групирането поради своята простота и възможности за обяснение.

За да опростим нещата, ще работим с PE метаданни, извлечени от проби от трите кампании за злонамерен софтуер (Cloud Hopper, Hangover и Dukes), които видяхме в тази серия, и ще използваме визуална проверка, за да идентифицираме оптимален брой клъстери за нашите набори от данни . За простота ще приемем също, че пробите не са били умишлено променени. В нашата демонстрация ще увеличим стойностите на k (k = 3, 4 и 5) и ще сравним образуването на различните клъстери.

В различните k диаграми на клъстери по-горе можем да видим, че много от пробите в първите две диаграми не са силно гравитирани към центроида на своя клъстер (маркиран с червен кръст). Това може да се види за пробите, които бяха идентифицирани като клъстер, означен като A (кафявата област, когато k е 3) и B (циановата област, когато k е 4) . От тук вероятно можем да предположим, че настройката на k = 5 може да бъде оптимална стойност за нашите набори от данни.

Нашата автоматизирана система (модел за обучение без надзор) е групирала тези проби без набор от данни за обучение или известни резултати. По същество нашата автоматизирана система подхожда на сляпо към проблема с клъстерирането — само с входните данни, които обработват, за да сортират пробите в клъстери. За да разширим допълнително нашето разбиране за тези клъстери, нека да видим как се оказват, когато разкрием „моделните отговори“ (кампании за злонамерен софтуер, към които принадлежат пробите).

В диаграмите (актуализирани с „моделните отговори“) по-горе, нашата автоматизирана система успя да идентифицира и групира повечето проби от злонамерен софтуер с проби от съответните кампании за злонамерен софтуер (Cloud Hopper, Hangover и Dukes). Също така потвърждава нашата хипотеза, че настройката на k = 5 може да бъде по-оптималната стойност на k. Въпреки това може да бъде озадачаващо защо пет „k“ хомогенни групи (т.е. клъстери) от злонамерен софтуер се смятат за най-оптималната стойност, въпреки че има само три кампании за злонамерен софтуер. Ще продължим да се гмуркаме по-дълбоко в разбирането на възможните обяснения за този резултат.

След идентифициране на оптималната стойност на k, вече можем да изследваме степента на сходство между зловреден софтуер от различни семейства, използван в една и съща кампания. Можем да видим, че семействата Dukes и Cloud Hopper образуват по-тесен клъстер сред съответните им проби в сравнение със семейството Hangover. Резултатът от по-тесен клъстер може да се дължи на пробите в рамките на семейството, показващи по-силни прилики в техните фрагменти на PE метаданни. От резултатите вероятно бихме могли да заключим, че образците на Dukes и Cloud Hopper принадлежат съответно към неговата кампания, тъй като те показват подобни характеристики на PE метаданни в рамките на собствената му кампания. Анализаторите могат да използват тези черти, за да извлекат обобщени подписи, които могат да работят срещу тях.

Едно наблюдение, което може би сте забелязали, е образуването на три отделни групи от семейство Hangover вътре в себе си. На този етап можем да предположим, че проби от кампании Hangover споделят три уникални набора от PE метаданни. Но какво означава това и как да разберем? Нека да разгледаме по-отблизо, за да разберем как могат да се формират тези три клъстера Hangover.

Три клъстера Hangover? — Разбиране на клъстерите

Тъй като има три клъстера и за по-лесна идентификация между тях, ние ги премаркирахме в група A, група B и група C. Сега нека увеличим мащаба на PE метаданните на групите, за да открием дали някой се откроява! С анализа на PE метаданните на всяка група може да успеем да изведем някои модели, които нашият модел е уловил и които анализаторите биха могли да пропуснат.

Група A е най-голямата група (над 100+ Hangover проби) сред трите и на пръв поглед има една забележителна характеристика: липсата на информация от Export Data (0 експортирани функции) и Debug Data (само 3 уникални PDB пътя, извлечени от 3 различни проби). Това може да означава, че образци, класифицирани като група A, са изпълними (EXE) и че техните данни за отстраняване на грешки са премахнати по време на процеса на компилиране.

Докато продължаваме да разглеждаме другите PE метаданни в група A — Импортиране на данни (ImpHash, генериран от импортираните функции) и Rich Header (RichHash, генериран от записите в Rich Header) , виждаме някои интересни точки: Над 50 проби имат идентичен ImpHash `c24262a0a40a5019cec3329c7b32c5a3` и RichHash `9072098ed4c00fe3b7cac80383a6f05e`. Едно възможно обяснение за горното наблюдение е, че тези проби имат подобни реализации и са изградени в една уникална среда за разработка. Това е пример за това как комбинацията от PE метаданни, когато се използва заедно, може да потвърди сходството на образците на злонамерен софтуер един с друг.

Може би се чудите как тази информация може да бъде полезна. Не забравяйте, че една от нашите причини да създадем автоматизиран анализатор е да пресеем масивни данни и да маркираме интересните файлове за вниманието на анализаторите? От резултатите от нашия анализ можете да видите, че тези 50+ проби е много вероятно да имат подобни реализации, рутинни процедури и функции. Тези проби, ако бъдат анализирани преди това, може да не изискват толкова много ресурси за повторен анализ, ако няма значителна разлика в сравнение с по-старите им версии. Това намалява допълнителните усилия, необходими за приписване на тези образци на техния автор. След това анализаторите могат да съсредоточат усилията си върху справянето с нов или подобрен зловреден софтуер.

Нека продължим да разглеждаме PE метаданните на група B и група C. Една ясна прилика между двете групи са припокриващите се имена на PDB файлове като „HTTP_T.pdb”, „Ron.pdb”, „FirstBloodA1.pdb” намерени в данните за отстраняване на грешки (PDB пътища, извлечени от пробите). Когато анализираме пътищата на PDB, може да разгледаме абсолютния път на PDB или само името на файла на PDB, като и двете са ценни като част от PE метаданните. За нашата демонстрация нашият модел използва абсолютния PDB път като една от характеристиките си. Разбира се, има няколко начина за внедряване на функции за данни за отстраняване на грешки, като използване на името на PDB файла или по-нататъшна обработка чрез „разрязване на абсолютния път“ на няколко части и използването им като функции.

Като разгледаме по-отблизо пробите от група B и C, повечето от пътищата на PDB са уникални и не показват ясни модели на клъстери. По същия начин не бяха открити дефиниращи прилики за данни за импортиране и обогатено заглавие, извлечени от пробите в тези две групи. Като се имат предвид PE метаданните на групите, тези характеристики не разкриват силни обяснения защо са формирани двата клъстера. Все още не знаем защо има два различни клъстера вместо само един или няколко мини клъстера.

Но когато разгледахме другите PE метаданни, открихме една възможна характеристика, която нашият модел е идентифицирал и използвал за формиране на тези две групи. Установено е, че уникалните езици, които са специфични за всяка група (ResourcesLangHash, генериран от езика на ресурсите), съдържат различни набори от PE метаданни, като данни за отстраняване на грешки, данни за импортиране и обогатена заглавка. Това може да е причината да има два клъстера, идентифицирани от нашия модел. В този случай разделянето може да си струва да се разгледа повторно от анализатори, като поставят пробите на по-висок приоритет.

Това разделяне може да е индикация за еволюция в характеристиките на пробите. Или може да се използва за идентифициране на други участници в зловреден софтуер, които се опитват да вмъкнат подвеждащи отпечатъци, за да насочат неправилно усилията на анализаторите за приписване. При този сценарий тези проби могат да бъдат класирани по-високо, където се изисква преоценка на пробите.

Досега обсъждахме как техниките за машинно обучение могат да бъдат приложени към PE метаданни, за да помогнат на анализаторите да извършат бързо сортиране на новите проби, които се появяват ежедневно. Например, вместо ръчно да се опитваме да идентифицираме клъстери, можем да прехвърлим задачата към автоматизираната система, която е не само по-бърза, но може да бъде и по-ефективна! Но не трябва да забравяме, че техниките за машинно обучение не винаги могат да дадат „правилния“ отговор. Резултатите все още могат да бъдат пристрастни поради неадекватни модели или непредставителни набори от данни. Така че трябва да знаем как да подобрим нашия модел, така че нека помислим за експериментиране с различни функции и параметри за обучение.

Отговор на по-големите въпроси (I) – Какво ще кажете за създадените PE метаданни?

Едно ограничение на нашия модел е, че той не отчита проблема с дезинформацията в PE метаданните. В нашата поредица от две части видяхме как някои автори на зловреден софтуер изработват PE метаданни, за да подведат усилията на анализаторите за приписване. От друга страна, ние също видяхме как тези изработени PE метаданни могат да бъдат нож с две остриета, който може да бъде използван срещу тях чрез разкриване на сигнални знаци.

Например, ако злонамереният софтуер винаги има своя Rich Header, копиран от друго семейство злонамерен софтуер, това става разпознаваема черта на семействата злонамерен софтуер или дори на авторите. Такива хипотези могат да бъдат сгънати в модела на клъстериране, за да помогнат на анализаторите да открият дезинформация в PE метаданните и да извършат по-прецизно приписване. С други думи, след като дезинформацията бъде идентифицирана, тя се превръща от пречка в ценен компонент на вашия анализ.

Отговор на по-големите въпроси (II) — Как можем да повишим ефективността на модела?

Ограничение на по-ранния модел на клъстериране е, че PE метаданните се третират с еднаква тежест, но в действителност някои PE метаданни са по-полезни от други. Друго ограничение е, че използвахме само PE метаданни, които са само една част от PE файла, но други части могат да помогнат за прецизиране на нашия модел. Нека обмислим разхлабването на тези условия.

Отдалечаване от еднакво третиране на PE метаданните...

Тъй като PE метаданните, свързани с дизайна, не могат лесно да се променят без последствия, те заслужават по-висока тежест от свързаните с разработчиците PE метаданни. Естественият последващ въпрос е колко повече тегло. Техниките за машинно обучение могат да ни помогнат да отговорим на този въпрос. Итеративното обучение може да прецизира теглата, за да ни даде оптималните стойности за характеристиките на PE метаданни въз основа на техните относителни корелации със семейството и авторството. Подобренията ще подобрят способността на модела да приема широкомащабни PE метаданни.

Преминаване само от PE метаданни...

Клъстерният анализ, който използва само PE метаданни, не взема предвид динамичното поведение/евристика на фамилиите злонамерен софтуер, обикновено класифицирани като тактики, техники и процедури (TTP). Някои примери включват комуникационните механизми за командване и контрол на злонамерения софтуер или уникални файлови пътища, които зловредният софтуер е създал за своето изпълнение. Тези уникални черти са полезна информация, която може да се използва като част от семейството на зловреден софтуер или идентификация на автора. Две общи рамки, използвани от анализаторите на зловреден софтуер за идентифициране на тези характеристики, са MITRE ATT&CK и Каталог на поведението на зловреден софтуер (MBC). Тези рамки могат да бъдат извлечени от инструменти за динамичен анализ с отворен код като Cuckoo Sandbox или инструменти за откриване на способности като Capa от FLARE екипа на Mandiant, за да подобрим нашите модели.

Включването на такива точки от данни и функции може да даде по-добра представа, за да помогне при идентифицирането на заплахи, изработването на по-ефективни подписи и създаването на хипотези за приписване. Обхватът на тази статия не обхваща как да използвате такива TTP за анализ, но ако се интересувате, потърсете я като следваща учебна глава.

Примери за зловреден софтуер — къде да ги вземете?

Сега разгледахме как клъстери от злонамерен софтуер от различни семейства (или дори кампании) могат да бъдат формирани с PE метаданни. В същото време получихме някои значими прозрения, които анализаторите могат да използват, за да прецизират нашия модел. Ако сте развълнувани да започнете, но ви липсват най-важните компоненти, за да започнете — примери за зловреден софтуер, не се страхувайте! Защото нямате нужда от тях.

EMBER: набор от етикетирани сравнителни данни (сканиран с VirusTotal) е хранилище с отворен код, което използва LIEF проекта за извличане на PE метаданни, байтови хистограми и т.н. от над 1 милион доброкачествени и злонамерени PE файлове. Функциите в EMBER имат и могат да се използват за създаване на различни модели за машинно обучение за статично откриване на злонамерени Windows PE файлове. С това вече можете да започнете пътуването си като анализатор на зловреден софтуер! Ако желаете да развиете интереса си (и да получавате месечна заплата, докато правите това — намигване), приветстваме ви да се присъедините към нас в CSIT или да изпробвате други подобни възможности.

Заключение

PE метаданните съдържат множество улики, които анализаторите могат да използват в проучванията за клъстериране на зловреден софтуер. След това можем да предвидим предстоящи заплахи и да създадем правила/сигнатури за премахване на нов зловреден софтуер, преди той да стане следващото заглавие. Анализът трябва да се извърши внимателно, тъй като PE метаданните може да бъдат изработени за погрешно насочване. Но това измерение прави целия процес предизвикателен и постоянно интересен.

Мащабната наличност на проби е богат на информация актив, който може да бъде проучен с нововъзникващи технологии като машинно обучение. Изследванията показват, че машините могат да бъдат значително по-добри от хората в откриването на модели, както по отношение на скоростта, така и на производителността. Това проправя пътя за вълнуващи нови идеи на този кръстопът на киберсигурност и анализ на машинно обучение. Съюзът на данни и технологии е нов свят от възможности за изграждане на решения за киберсигурност. Бъдете част от екипа на CSIT, който търси промени в играта в защитата срещу зловреден софтуер!