Ryuk - гэта адзін з самых вядомых варыянтаў шыфравальшчыкаў за апошнія некалькі гадоў. З таго часу, як ён упершыню з'явіўся летам 2018 года, ён сабраў , асабліва ў бізнес-асяроддзі, якая з'яўляецца галоўным аб'ектам яго нападаў.
1. Агульная інфармацыя
Дадзены дакумент утрымоўвае аналіз варыянту шыфравальшчыка Ryuk, а таксама загрузніка, які адказвае за загрузку шкоднаснай праграмы ў сістэму.
Шыфравальшчык Ryuk упершыню з'явіўся летам 2018 года. Адно з адрозненняў Ryuk ад іншых шыфравальшчыкаў заключаецца ў тым, што ён нацэлены на атаку карпаратыўных акружэнняў.
У сярэдзіне 2019 года кібер-крымінальныя групоўкі атакавалі вялізную колькасць іспанскіх кампаній з дапамогай гэтага шыфравальшчыка.
Мал. 1: Урывак з El Confidencial з нагоды нападу шыфравальшчыка Ryuk [1]
Мал. 2: Урывак з El País аб нападзе, вырабленай з дапамогай шыфравальшчыка Ryuk [2]
У гэтым годзе Ryuk атакаваў вялікую колькасць кампаній у розных краінах. Як Вы можаце бачыць на прыведзеных ніжэй малюнках, найбольш пацярпелі Германія, Кітай, Алжыр і Індыя.
Параўноўваючы колькасць кібер-нападаў, мы можам бачыць, што ад Ryuk пацярпелі мільёны карыстачоў і скампраметаваны велізарны аб'ём дадзеных, што прывяло да сур'ёзнай эканамічнай шкоды.
Мал. 3: Ілюстрацыя глабальнай актыўнасці Ryuk.
Мал. 4: 16 краін, найбольш пацярпелых ад Ryuk
Мал. 5: Колькасць карыстальнікаў, атакаваных шыфравальшчыкам Ryuk (у мільёнах)
Паводле звычайнага прынцыпу працы падобных пагроз, дадзены шыфравальшчык пасля завяршэння шыфравання паказвае ахвяры апавяшчэнне аб выкупе, які павінен быць выплачаны ў біткоінах на паказаны адрас для ўзнаўлення доступу да зашыфраваных файлаў.
Гэтая шкоднасная праграма змянілася з моманту свайго першага з'яўлення.
Аналізаваны ў дадзеным дакуменце варыянт гэтай пагрозы быў знойдзены пры спробе ажыццяўлення нападу ў студзені 2020 гады.
У сілу сваёй складанасці дадзеная шкоднасная праграма часта прыпісваецца арганізаваным кібер-злачынным групоўкам, вядомым таксама як APT-групы.
Частка кода Ryuk мае прыкметнае падабенства з кодам і структурай іншага вядомага шыфравальшчыка Hermes, з якім яны маюць шэраг аднолькавых функцый. Менавіта таму першапачаткова Ryuk звязвалі з паўночнакарэйскім гуртом Lazarus, які ў той час падазраваўся ў тым, што стаіць за шыфравальшчыкам Hermes.
Пасля служба Falcon X кампаніі CrowdStrike адзначыла, што фактычна Ryuk быў створаны групай WIZARD SPIDER [4].
Ёсць некалькі доказаў у падтрымку гэтай здагадкі. Па-першае, гэты шыфравальшчык рэкламаваўся на вэб-сайце exploit.in, які з'яўляецца вядомым расійскім рынкам шкоднасных праграм і раней быў звязаны з некаторымі расійскімі APT-групамі.
Гэты факт выключае тэорыю аб тым, што Ryuk мог быць распрацаваны APT-групай Lazarus, т.я. гэта не адпавядае таму, як дзейнічае група.
Акрамя таго, Ryuk рэкламаваўся як шыфравальшчык, які не будзе працаваць на расійскіх, украінскіх і беларускіх сістэмах. Такія паводзіны вызначаюцца функцыяй, выяўленых у некаторых версіях Ryuk, дзе яна правярае мову сістэмы, у якой запушчаны дадзены шыфравальшчык, і спыняе яго працу ў тым выпадку, калі ў сістэмы рускую, украінскую ці беларускую мову. Нарэшце, пры правядзенні экспертнага аналізу машыны, якая была ўзламаная групай WIZARD SPIDER, было выяўлена некалькі «артэфактаў», якія меркавана былі скарыстаны пры распрацоўцы Ryuk як варыянту шыфравальшчыка Hermes.
З іншага боку, эксперты Габрыэла Нікалаа і Лючана Марцінс выказалі здагадку, што шыфравальшчык, магчыма, быў распрацаваны APT-групай CryptoTech [5].
Гэта вынікае з таго факту, што за некалькі месяцаў да з'яўлення Ryuk гэты гурт размясціў на форуме таго ж сайта інфармацыю аб тым, што яны распрацавалі новую версію шыфравальшчыка Hermes.
Некалькі карыстальнікаў форума задаліся пытаннем, ці сапраўды CryptoTech стварыў Ryuk. Пасля гэтага дадзеная група абараніла сябе і заявіла, што ў яе ёсць доказы таго, што яны распрацавалі 100% гэтага шыфравальшчыка.
2. Характарыстыкі
Мы пачынаем з загрузніка, чыя задача складаецца ў тым, каб ідэнтыфікаваць сістэму, у якой ён знаходзіцца, каб можна было запусціць "правільную" версію шыфравальшчыка Ryuk.
Хэш загрузніка наступны:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
Адна з асаблівасцяў гэтага загрузніка складаецца ў тым, што ён не ўтрымоўвае ніякіх мета-дадзеных, г.зн. стваральнікі гэтай шкоднаснай праграмы не ўлучылі ў яго ніякіх звестак.
Часам яны ўключаюць памылковыя дадзеныя для таго, каб прымусіць карыстальніка думаць, што ён нібыта запускае легітымнае прыкладанне. Аднак, як мы ўбачым пазней, у тым выпадку, калі заражэнне не мяркуе ўзаемадзеянне з карыстачом (як у выпадку з гэтым шыфравальшчыкам), то зламыснікі не лічаць неабходным выкарыстоўваць мета-дадзеныя.
Мал. 6: Мета-дадзеныя ўзору
Узор быў скампіляваны ў 32-разрадным фармаце, каб яго можна было запускаць як у 32-разрадных, так і ў 64-разрадных сістэмах.
3. Вектар пранікнення
Узор, які загружае і запускае Ryuk, патрапіў у нашу сістэму праз выдаленае злучэнне, а параметры доступу былі атрыманы дзякуючы папярэдняй RDP-нападу.
Мал. 7: Рэестр атакі
Зламысніку ўдалося выдалена ўвайсці ў сістэму. Пасля гэтага ён стварыў выкананы файл з нашым узорам.
Гэты выкананы файл быў заблакаваны антывірусным рашэннем перад запускам.
Мал. 8: Блакаванне ўзору
Мал. 9: Блакаванне ўзору
Калі шкоднасны файл быў заблакаваны, зламыснік паспрабаваў загрузіць зашыфраваную версію выканаўчага файла, які таксама быў заблакаваны.
Мал. 10: Набор узораў, якія зламыснік спрабаваў запусціць
Нарэшце, ён паспрабаваў загрузіць іншы шкоднасны файл праз зашыфраваную кансоль.
PowerShell для таго, каб абыйсці антывірусную абарону. Але ён таксама быў заблакаваны.
Мал. 11: PowerShell з заблакаваным шкоднасным кантэнтам
Мал. 12: PowerShell з заблакаваным шкоднасным кантэнтам
4. Загрузчык
Калі ён выконваецца, ён запісвае файл ReadMe у тэчку % Temp%, Што тыпова для Ryuk. Дадзены файл - гэта патрабаванне аб выкупе, якое змяшчае адрас электроннай пошты ў дамене protonmail, які даволі часта сустракаецца ў гэтым сямействе шкоднасных праграм: [электронная пошта абаронена]
Мал. 13: Патрабаванне аб выкупе
Падчас выканання загрузніка Вы можаце ўбачыць, што ён запускае некалькі выкананых файлаў са выпадковымі назовамі. Яны захоўваюцца ва ўтоенай тэчцы ГРАМАДСКАЕ, але калі ў аперацыйнай сістэме не актыўная опцыя «Паказваць утоеныя файлы і тэчкі», то яны так і застануцца ўтоенымі. Больш за тое, гэтыя файлы 64-разрадныя у адрозненне ад бацькоўскага файла, які 32-разрадны.
Мал. 14: Выконваныя файлы, якія запускаюцца ўзорам
Як Вы можаце бачыць на прыведзеным вышэй малюнку, Ryuk запускае icacls.exe, які будзе выкарыстоўвацца для змены ўсіх спісаў кантролю доступу ACL (Access control list), такім чынам гарантуючы доступ і змена сцягоў.
Ён атрымлівае поўны доступ пад усімі карыстальнікамі да ўсіх файлаў на прыладзе (/T) незалежна ад памылак (/C) і без паказу якіх-небудзь паведамленняў (/Q).
Мал. 15: Параметры выканання icacls.exe, запушчанага ўзорам
Важна ўлічваць, што Ryuk правярае, якая запушчана версія Windows. Для гэтага ён
выконвае праверку версіі з дапамогай GetVersionExW, у якім ён правярае значэнне сцяга lpVersionInformation, які паказвае, ці з'яўляецца бягучая версія Windows пазнейшай, чым Windows XP.
У залежнасці ад таго, ці працуе ў Вас пазнейшая версія за Windows XP, загрузнік будзе запісваць у тэчку лакальнага карыстальніка - у дадзеным выпадку ў тэчку %Public%.
Мал. 17: Праверка версіі аперацыйнай сістэмы
Запісваны файл - гэта Ryuk. Затым ён запускае яго, перадаючы свой уласны адрас у якасці параметра.
Мал. 18: Выкананне Ryuk праз ShellExecute
Першае, што робіць Ryuk, - гэта атрыманне ўваходных параметраў. На гэты раз існуе два ўваходных параметра (сам выкананы файл і адрас дроппера), якія выкарыстоўваюцца для выдалення ўласных слядоў.
Мал. 19: Стварэнне працэсу
Вы таксама можаце бачыць, што як толькі ён запусціў свае выкананыя файлы, ён выдаляе сябе, такім чынам не пакідаючы ніякіх слядоў уласнай прысутнасці ў той тэчцы, дзе ён быў выкананы.
Мал. 20: Выдаленне файла
5. RYUK
5.1 Прысутнасць
Ryuk, падобна іншым шкоднасным праграмам, спрабуе заставацца ў сістэме як мага даўжэй. Як было паказана вышэй, адзін са спосабаў для дасягнення гэтай мэты - гэта ўтойлівае стварэнне і запуск выкананых файлаў. Для гэтага найболей распаўсюджанай практыкай з'яўляецца змена ключа рэестра CurrentVersionRun.
У дадзеным выпадку Вы можаце бачыць, што для гэтай мэты першы які запускаецца файл VWjRF.exe
(назва файла генеруецца выпадковым чынам) запускае cmd.exe.
Мал. 21: Выкананне файла VWjRF.exe
Затым уводзіцца каманда RUN з імем "свчос". Такім чынам, калі Вы захочаце ў любы час праверыць ключы рэестра, то Вы дастаткова лёгка зможаце не заўважыць гэтую змену, улічваючы падабенства гэтай назвы з svchost. Дзякуючы гэтаму ключу Ryuk забяспечвае сваю прысутнасць у сістэме. Калі сістэма да гэтага часу не была заражаная , то калі Вы перазагрузіце сістэму, выкананы файл паўторыць спробу зноў.
Мал. 22: Узор забяспечвае прысутнасць у ключы рэестра
Мы таксама можам убачыць, што гэты выкананы файл спыняе дзве службы:
"audioendpointbuilder", якая, як вынікае з яе назвы, адпавядае сістэмнаму аўдыё,
Мал. 23: Узор спыняе службу сістэмнага аўдыё
и samss, Якая з'яўляецца службай кіравання уліковымі запісамі. Прыпынак гэтых двух службаў з'яўляецца характарыстыкай Ryuk. У дадзеным выпадку, калі сістэма злучана з SIEM-сістэмай, то шыфравальшчык спрабуе спыніць адпраўку ў якіх-небудзь папярэджанняў. Такім чынам, ён абараняе свае наступныя крокі, паколькі некаторыя SAM-службы не змогуць правільна пачаць сваю працу пасля выканання Ryuk.
Мал. 24: Узор спыняе службу Samss
5.2 Прывілеі
Наогул кажучы, Ryuk пачынаецца з гарызантальнага перасоўвання ўсярэдзіне сетак ці ён запускаецца іншай шкоднаснай праграмай, такі як або , якія ў выпадку эскалацыі прывілеяў перадаюць гэтыя падвышаныя правы шыфравальшчыку.
Загадзя, у якасці прэлюдыі да працэсу ўкаранення, мы бачым, што ён выконвае працэс ImpersonateSelf, а гэта азначае, што змесціва бяспекі токена доступу будзе перададзена ў паток, дзе яно будзе неадкладна атрымана з дапамогай GetCurrentThread.
Мал. 25: Выклік ImpersonateSelf
Затым мы бачым, што ён звяжа токен доступу з патокам. Мы таксама бачым, што адзін са сцягоў - гэта DesiredAccess, Які можа выкарыстоўвацца для кантролю доступу, які будзе мець паток. У гэтым выпадку значэнне, якое атрымае edx, павінна быць TOKEN_ALL_ACESS або ў адваротным выпадку - TOKEN_WRITE.
Мал. 26: Стварэнне токена патоку
Затым ён будзе выкарыстоўваць SeDebugPrivilege і зробіць выклік для атрымання адладкавых правоў Debug па адносінах да патоку, у выніку чаго, паказаўшы PROCESS_ALL_ACCESS, ён зможа атрымаць доступ да любога патрабаванага працэсу. Цяпер, улічваючы, што шыфравальшчык ужо мае падрыхтаваны паток, застаецца толькі прыступіць да завяршальнай стадыі.
Мал. 27: Выклік SeDebugPrivilege і функцыя эскалацыі правоў
З аднаго боку, мы маем LookupPrivilegeValueW, які прадстаўляе нам неабходную інфармацыю аб прывілеях, якія мы хочам павысіць.
Мал. 28: Запыт інфармацыі аб прывілеях для іх эскалацыі
З іншага боку, мы маем AdjustTokenPrivileges, Які дазваляе атрымаць неабходныя правы на наш паток. У гэтым выпадку самае важнае - гэта NewState, чый сцяг будзе прадастаўляць прывілеі.
Мал. 29: Настройка правоў для токена
5.3 Укараненне
У гэтым раздзеле мы пакажам, як узор выконвае працэс укаранення, раней ужо згаданы ў дадзенай справаздачы.
Асноўнай мэтай працэсу ўкаранення, як і эскалацыі, з'яўляецца атрыманне доступу да ценявым копіям. Для гэтага яму трэба працаваць з патокам з правамі вышэй, чым у лакальнага карыстальніка. Як толькі ён атрымае такія больш высокія правы, ён выдаліць копіі і ўнясе змены ў іншыя працэсы для таго, каб зрабіць немагчымым вяртанне да больш ранняй кропкі аднаўлення ў аперацыйнай сістэме.
Як гэта звычайна бывае з такім выглядам шкоднасных праграм, для выканання ўкаранення ён выкарыстоўвае CreateToolHelp32Snapshot, таму ён робіць здымак запушчаных у дадзены момант працэсаў і спрабуе атрымаць доступ да гэтых працэсаў з дапамогай OpenProcess. Як толькі ён атрымлівае доступ да працэсу, ён таксама адчыняе токен з яго інфармацыяй для атрымання параметраў працэсу.
Мал. 30: Атрыманне працэсаў з кампутара
Мы можам дынамічна бачыць, як ён атрымлівае спіс запушчаных працэсаў у падпраграме 140002D9C з дапамогай CreateToolhelp32Snapshot. Пасля іх атрымання ён праходзіць па спісе, спрабуючы адзін за іншым адкрыць працэсы з дапамогай OpenProcess датуль, пакуль у яго не атрымаецца гэта зрабіць. У дадзеным выпадку першы працэс, які ён змог адкрыць, - гэта «taskhost.exe».
Мал. 31: Дынамічнае выкананне працэдуры для атрымання працэсу
Мы можам бачыць, што пасля ён счытвае інфармацыю токена працэсу, таму ён выклікае OpenProcessToken з параметрам "20008"
Мал. 32: Чытанне інфармацыі токена працэсу
Ён таксама правярае, што працэс, у які ён будзе ўкараняцца, не з'яўляецца csrss.exe, explorer.exe, lsaas.exe ці што ён мае набор правоў NT authority.
Мал. 33: Выключаныя працэсы
Мы можам дынамічна бачыць, як ён спачатку выконвае праверку з дапамогай інфармацыі токена працэсу ў 140002Д9С з мэтай даведацца, ці з'яўляецца ўліковы запіс, чые правы выкарыстоўваюцца для выканання працэсу, уліковым запісам NT AUTHORITY.
Мал. 34: Праверка NT AUTHORITY
А пазней, па-за працэдурай, ён правярае, што гэта не csrss.exe, explorer.exe або lsaas.exe.
Мал. 35: Праверка NT AUTHORITY
Пасля таго як ён зрабіў здымак працэсаў, адкрыў працэсы і праверыў, што ніводзін з іх не з'яўляецца выключаным, ён гатовы запісваць у памяць працэсы, якія будуць укаранёны.
Для гэтага ён спачатку рэзервуе вобласць у памяці (VirtualAllocEx), запісвае ў яе (WriteProcessmemory) і стварае паток (CreateRemoteThread). Для працы з гэтымі функцыямі ён выкарыстоўвае PID-ы абраных працэсаў, якія ён папярэдне атрымаў з дапамогай CreateToolhelp32Snapshot.
Мал. 36: Код для ўкаранення
Тут мы можам дынамічна назіраць, як ён выкарыстоўвае PID працэсу для выкліку функцыі VirtualAllocEx.
Мал. 37: Выклік VirtualAllocEx
5.4 Шыфраванне
У дадзеным раздзеле мы разгледзім частку гэтага ўзору, звязанага з шыфраваннем. На наступным малюнку Вы можаце ўбачыць дзве падпраграмы пад назвай "LoadLibrary_EncodeString"і"Encode_Func", якія адказваюць за выкананне працэдуры шыфравання.
Мал. 38: Працэдуры шыфравання
Спачатку мы можам бачыць, як ён загружае радок, якая пазней будзе выкарыстоўвацца для дэабфускацыі за ўсё, што неабходна: імпарты, DLL, каманды, файлы і CSP.
Мал. 39: Ланцуг дэабфускацыі
На наступным малюнку паказаны першы імпарт, які ён дэабфускіруе ў рэгістры R4, LoadLibrary. Гэта будзе выкарыстоўвацца пазней для загрузкі неабходных DLL. Мы таксама можам бачыць іншы радок у рэгістры R12, якая выкарыстоўваецца разам з папярэднім радком для выканання дэабфускацыі.
Мал. 40: Дынамічная дэабфускацыя
Ён працягвае загружаць каманды, якія ён выканае пазней, каб адключыць рэзервовыя копіі, кропкі аднаўлення і бяспечныя рэжымы загрузкі.
Мал. 41: Загрузка каманд
Затым ён загружае лакацыю, куды ён кіне 3 файлы: Windows.bat, run.sct и start.bat.
Мал. 42: Лакацыі файлаў
Гэтыя 3 файла выкарыстоўваюцца для праверкі прывілеяў, якімі валодаюць кожная з лакацый. Калі патрабаваныя прывілеі недаступныя, Ryuk спыняе выкананне.
Ён працягвае загружаць радкі, якія адпавядаюць тром файлам. Першая, DECRYPT_INFORMATION.html, змяшчае інфармацыю, неабходную для аднаўлення файлаў. Другая, ГРАМАДСКАЕ, змяшчае адкрыты ключ RSA.
Мал. 43: Радок DECRYPT INFORMATION.html
Трэцяя, UNIQUE_ID_DO_NOT_REMOVE, змяшчае зашыфраваны ключ, які будзе выкарыстоўвацца ў наступнай падпраграме для выканання шыфравання.
Мал. 44: Радок UNIQUE ID DO NOT REMOVE
Нарэшце, ён загружае неабходныя бібліятэкі разам з патрабаванымі імпартамі і CSP (Microsoft Enhanced RSA и AES Cryptographic Provider).
Мал. 45: Загрузка бібліятэк
Пасля таго як уся дэабфускацыя завершана, ён пераходзіць да выканання дзеянняў, патрабаваных для шыфравання: перабор усіх лагічных кружэлак, выкананне таго, што было загружана ў папярэдняй падпраграме, узмацненне прысутнасці ў сістэме, закід файла RyukReadMe.html, шыфраванне, перабор усіх сеткавых кружэлак, пераход на выяўленыя прылады і іх шыфраванне.
Усё пачынаецца з загрузкі "cmd.exeі запісы адкрытага RSA-ключа.
Мал. 46: Падрыхтоўка да шыфравання
Затым ён атрымлівае ўсе лагічныя дыскі з дапамогай GetLogicalDrives і адключае ўсе рэзервовыя копіі, кропкі аднаўлення і бяспечныя рэжымы загрузкі.
Мал. 47: Дэактывацыя сродкаў аднаўлення
Пасля гэтага ён узмацняе сваю прысутнасць у сістэме, як мы бачылі вышэй, і запісвае першы файл RyukReadMe.html в TEMP.
Мал. 48: Публікацыя апавяшчэння аб выкупе
На наступным малюнку Вы можаце ўбачыць, як ён стварае файл, загружае змест і запісвае яго:
Мал. 49: Загрузка і запіс змесціва файла
Каб мець магчымасць выканаць гэтыя ж дзеянні на ўсіх прыладах, ён выкарыстоўвае
"icacls.exe", як мы паказвалі вышэй.
Мал. 50: Выкарыстанне icalcls.exe
І, нарэшце, ён пачынае шыфраванне файлаў за выключэннем файлаў "*.exe", "*.dll", сістэмных файлаў і іншых лакацый, указаных у выглядзе зашыфраванага белага спісу. Для гэтага ён выкарыстоўвае імпарты: CryptAcquireContextW (дзе паказана выкарыстанне AES і RSA), CryptDeriveKey, CryptGenKey, CryptDestroyKey і г.д. Таксама робіцца спроба пашырыць сваё дзеянне на выяўленыя сеткавыя прылады з дапамогай WNetEnumResourceW і затым зашыфраваць іх.
Мал. 51: Шыфраванне сістэмных файлаў
6. Імпарты і адпаведныя сцягі
Ніжэй прыведзена табліца са спісам найбольш рэлевантных імпартаў і сцягоў, якія выкарыстоўваюцца узорам:
7. IOC
Спасылкі
- usersPublicrun.sct
- Start MenuProgramsStartupstart.bat AppDataRoamingMicrosoftWindowsStart
- MenuProgramsStartupstart.bat
Тэхнічная справаздача аб шыфравальшчыка Ryuk складзены экспертамі антывіруснай лабараторыі PandaLabs.
8. Спасылкі
1. "Everis y Prisa Radio sufren un grave ciberataque que secuestra sus sistemas."https://www. elconfidencial.com/tecnologia/2019-11-04/ everis-la-ser-ciberataque-ransomware-15_2312019/, Publicada el 04/11/2019.
2. "Un virus d'origen ruso ataca a importantes empresas españolas."
3. “VB2019 paper: Shinigami's revenge: long tail of the Ryuk malware.”https://securelist.com/ story-of-the-year-2019-cities-under-ransomware-siege/95456/, Publicada el 11 /12/2019
4. “Big Game Hunting with Ryuk: Another LucrativebTargeted Ransomware.”https://www. crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Publicada el 10/01/2019.
5. “VB2019 paper: Shinigami's revenge: long tail of the Ryuk malware.”https://www. virusbulletin.com/virusbulletin/2019/10/ vb2019-paper-shinigamis-revenge-long-tail-r
Крыніца: habr.com