Да избягаме от пясъчника
Технологията "sandbox" е изключително важна при анализите на заплахите за киберсигурността, в частност проверка на зловреден код, и въпреки, че много компании предлагат различни подобни системи, те определено могат да подведат потребителите си. В следващите редове ще опиша един изключително тривиален и праволинеен подход с който тествах, дали може да открием изолирането и да представим кода не като злонамерен. Резултатите за съжаление се оказаха ... положителни.
Кое провокира този анализ? В ASOC екипа на Telelink Business Services се наложи да анализираме работата на специализирана система за анализ на зловреден код, на един от водещите производители в световен мащаб. Четейки описанието, преминавайки обученията за продукта и познавайки репутацията на компанията си изградих мнение, че това ще е решението на проблема със зловредния код. Всеки съмнителен файл ще бъде изпратен към системата, тя ше извърши своята магия (ще го стартира в "sandbox", ще анализира поведението му, ще търси познати индикатори и т.н.) и ще ни каже, дали има риск от зловреден код. Това беше теорията. Практиката показа малко по-различен резултат. Един от нашите водещи експерти - Илия Дафчев дойде и каза - "заобиколих sandbox-a по най-простия начин". Познавайки уменията на Илия не се усъмних в резултата, а колко е прост подхода, но тук грешах - наистина по най-тривиалният начин проверката беше заобиколена и код, наподобяващ злонамерен беше маркиран като безопасен.
Ето и някои от най-простите методи, с които да проверим дали приложението се стартира в изолирана среда:
- При Windows може да се извърши проверка, дали към процеса има прикачен debugger. Това е сравнително просто и се изисква да се повика IsDebuggerPresent() или CheckRemoteDebuggerPresent().
- Да се провери пътят от където е стартиран изпълнимия файл. Ако той е прекалено къс или съдържа странни директории (например C:\Windows\malware") това е индикация за потенциално изолиране.
- Да се провери броя на ядрата на процесора. Ако те са под 2, това може да е индикация за виртуализиране. Почти всеки актуален процесор има поне 4 логически ядра.
- Да се провери в регистрите на Windows, дали има последно отваряни документи от различни типове, например .docx, .xlsx, .jpg и други. Това се прави с цел да се види, дали е имало потребителска намеса в работата на операционната система.
Има и други подходим, но тези четири са достатъчно базови и прости за реализиране. Написах просто конзолно приложение на C#, което има следната функционалност:
- Проверява, дали има прикачен към порцеса debugger и ако открие такъв прекъсва своята работа.
- Проверява пътя, от където е стартиран файла и ако е прекалено къс, изпълнението спира.
- Проверява дали броя на ядрата на процесора е повече от 2 и ако това не е изпълнено стартирането се прекратява.
- Проверява, дали има последно отваряни документи от тип .docx и ако няма такива отново изпълнението се прекъсва.
- Добавя запис в HKCU\Software\Microsoft\Windows\CurrentVersion\Run за автоматично стартиране на изпълним файл от странна директория със странно име.
- Изтегля от интернет изпълним файл, съдържащ зловредния код Petya.
Точки 5 и 6 от логиката на приложението следва да го маркират като злонамерено.
Компилирах кодът за платформа "Any CPU" и ".Net framework 4". Използвах стария инструмент за обфускиране Confuser и имах тестови изпълним файл.
Стартирах го на моят компютър (Windows 10 1903) и резултатите бяха както очаквах. В регистрите имаше новата стойност:
Windows Defender засече Petya:
Време беше за малко игра в пясъчника ...
Качих изпълнимият файл в Hybrid Analysis и след около 5 минути се получи следният резултат:
Бяха открити 3 индикатора, че кода е злонамерен и 3, че е подозрителен. По-важните от тях бяха, че се повиква функция за проверка за наличие на debugger и че кода е обфускиран. До тук 1:0 за sandbox технологията. Признавам си, мислех, че няма да бъда открита заплаха. Премахнах проверката за debugger и обфускирането и отново качих файла за проверка.
Файлът вече беше само подозрителен, а индикаторите за това бяха:
Резултатът стана 1:0.5.
Време беше за анализ в Any.run. Използвах обфускирания файл с всички проверки за "sandbox". След приключване на анализа не бяха открити заплахи:
Активирах опцията "Heavy Anti-Evasion" и отново стартирах теста. Нямаше разлика - отново приложението не беше разпозната като заплаха.
Настъпи моментът за тежката артилерия в лицето на FireEye AX. Използвах следните настройки:
След около 10 минути се получи резултат "Non malicious"
FireEye AX маркира поведението като подозрително, но крайната оценка беше, че няма зловреден код.
Да теглим чертата.
От горните редове не искам да си направите извода, че "sandbox" системите са нефункционални и че не трябва да разчитаме на тях. Напротив, те са важна част от анализа на зловредния код, но при автоматизирани проверки има риск приложението да ги идентифицира и да прикрие своята функционалност.
Важно е да обръщаме внимание на подозрителната работа на изпълнимите файлове и при нужда да пристъпим към ръчен анализ във виртуална среда (с повече виртуални процесори, инсталиран Office и отворени Word файлове).