⚠️ Один рускомовний хакер за 5 тижнів зламав 600+ FortiGate у 55 країнах — і значну частину роботи за нього зробив ШІ. Я перечитав звіт Amazon і, чесно, це виглядає як «Skynet для тих, хто ледве вміє кодити».Фокус не в якихось «суперексплойтах», а в банальщині: відкриті з інтернету адмінки FortiGate, слабкі паролі, без MFA 🔐. Далі — масовий брутфорс VPN, злив повної конфігурації (паролі, топологія, бекапи) і аналіз цілей скриптами, які йому допомагали писати генеративні LLM 🤖. Код місцями кривий, зате автоматизує рутину й дає швидкість.Найцікавіше — він прикрутив власний сервер, який підсовував вкрадені дані в LLM і отримував від ШІ готові плани атак 🧠. Мені здається, це перший гучний приклад, коли слабкий технічно зловмисник за рахунок ШІ виходить на глобальний рівень. Як ви це бачите: перебільшена паніка чи реальна загроза, під яку вже зараз треба перешивати свою безпеку❓🔗 Докладніше:https://cybersecurefox.com/uk/fortigate#кібербезпека #штучнийінтелект #fortigate #інфобез #україна #бізнесCyberSecureFox
🔥 В кібербезпеці тихо формується розрив на два табори. І мені здається, за пару років різниця між ними стане болісно відчутною.До 2026 частина компаній вже живе в режимі Continuous Threat Exposure Management (CTEM) і має до 50% кращу видимість поверхні атаки. Решта досі грають у «латання дір» — періодичні скани, разові проєкти, купа звітів без системи, хоча 87% керівників уже визнають, що безперервна модель потрібна.Мене особливо чіпляє тема visibility gap 💣 — різниці між тим, за що ви реально відповідаєте, і тим, про що взагалі знаєте. Чим більше доменів, SaaS, інтеграцій — тим швидше класичне управління вразливостями перестає масштабуватись, з’являються «сліпі зони», які ніхто не моніторить.Логіка CTEM проста: спочатку повна інвентаризація активів, потім прив’язка до бізнесу, далі постійна валідація ризиків і пріоритизація реагування 🧩. Я все більше бачу, що continuous-експозиції скоро стануть must-have, як колись антивірус — а ви зараз більше в таборі «разові аудити» чи вже рухаєтесь у бік CTEM? 🤔🔗 Докладніше:https://cybersecurefox.com/uk/ctem-neperervne-upravlinnia-poverkhneiu-ataky#кібератаки_ctem_кібербезпека_бізнес_ризики_itбезпекаCyberSecureFox
🔍 Microsoft 365 Copilot щойно показав, наскільки крихка наша віра в «розумні» асистенти. Коротко: ІІ від Microsoft зміг читати й підсумовувати листи, які мали бути надійно захищені політиками DLP та мітками чутливості. Я натрапив на інцидент CW1226324: у Copilot Chat вкладка Work лізла в “Надіслані” та “Чернетки” й обробляла навіть конфіденційні листи, ігноруючи обмеження. Тобто Copilot міг узяти шматки чутливої переписки й спокійно видати їх у відповіді на інший запит 🤖 — саме те, від чого нас мали захищати DLP та sensitivity labels.Microsoft уже розгортає виправлення з початку лютого, але масштаб інциденту й досі неясний ⚠️. Мені здається, що це хороший тригер подивитись на Copilot як на окремий застосунок із чіткими правами доступу, переглянути політики DLP, ввімкнути більше логування й підтягнутися до підходу Zero Trust 🛡️. Я б зараз дуже обережно давав Copilot доступ до особливо чутливих даних. А ви вже дозволяєте ІІ-асистентам працювати зі своїми «чернетками» та «надісланими»? 🤔🔗 Докладніше:https://cybersecurefox.com/uk/microsoft-365-copilot-dlp-bug-cw1226324#кібербезпека_microsoft365_copilot_dlp_ai_безпекаданихCyberSecureFox
🔥 Я щойно натрапив на кейс, який дуже добре показує, наскільки крихка наша «анонімність» в інтернеті. Компанію Tenga (ті самі японці з товарами для дорослих) зламали через звичайну корпоративну пошту, і це вдарило по даних, які дуже не хочеться світити.Хакер отримав доступ до листування з клієнтами: імена, email-и, деталі замовлень, переписка з підтримкою 😬. Плюс з цього ж акаунта пішов спам, що відкриває двері для цільового фішингу під виглядом “офіційних” листів Tenga – з реальними даними всередині.Що зробили в компанії? Перелогінились, увімкнули MFA “для всіх систем” і порадили клієнтам змінити паролі. Але мені здається, головний урок для нас: для чутливих покупок краще мати окрему пошту, унікальні паролі й завжди перевіряти листи, які просять «терміново перейти за посиланням» 🔐.Мене в цій історії найбільше лякає не сам злам, а те, як легко це можна використати для шантажу й маніпуляцій 🙃. А ви розділяєте пошти/акаунти для “звичайного” життя й більш приватних речей, чи все летить на одну скриньку? 🤔🔗 Докладніше:https://cybersecurefox.com/uk/vitik-personalnyh-danyh-tenga-korporatyvna-poshta#кібербезпека #приватність #товаридлядорослих #витікданих #цифровагігієна #фішингCyberSecureFox
🚨 Щойно натрапив на кейс, від якого трохи мороз по шкірі: інфостілер Vidar вперше вкрав конфіги локального ІІ-агента OpenClaw. Це не просто ще один злив паролів, а доступ до всього «внутрішнього світу» вашого асистента 🤖OpenClaw зберігає локально токени, криптоключі, «пам’ять», листування, нотатки – все в каталозі .openclaw. Vidar просто пройшовся по файлах з підозрілими словами типу «token», «private key» і забрав openclaw.json, device.json, MEMORY.md та інше. У результаті зловмисник отримує і ключі до пристрою, і структурований психологічний та робочий профіль користувача 🧠😬Мені здається, ми підходимо до моменту, коли ІІ-агенти стають новою критичною точкою атаки: вони бачать більше, ніж пошта чи браузер, і вже зручно все зберігають за нас. Я б точно тримав таких асистентів в окремих профілях/VM, шифрував конфіги й регулярно крутив токени 🔐 А ви вже даєте своїм ІІ-друзям доступ до пошти/доків – і як взагалі плануєте їх захищати? ❓🔗 Докладніше:https://cybersecurefox.com/uk/pershyi-vypadok-kradizhky-konfiguratsii-openclaw-infostealer-vidar#кібербезпека #штучнийінтелект #aiагенти #openclaw #інфостілер #приватністьCyberSecureFox
🔍 Сиджу, розбираю черговий звіт по атаках — і натрапляю на цікавий апдейт по групі Head Mare. Це проукраїнські хлопці, які зараз дуже прицільно працюють по російських держструктурах і промисловості — і роблять це все дедалі елегантніше.Замість «важких» файлів вони майже повністю переїхали в PowerShell і підхід Living-off-the-Land 🧩 — коли використовується максимум вбудованих засобів Windows. Новий бекдор PhantomHeart через уразливість в TrueConf Server (BDU:2025-10114) або фішинг пролазить у мережу, підіймає SSH-тунель 🛠, збирає технічні дані й ховається в планувальнику задач, маскуючись під оновлення LiteManager.Паралельно працює PhantomProxyLite, який теж на PowerShell, автоматом створює «SSHService»-задачу від SYSTEM і через ssh.exe тримає стабільний зворотний доступ 🧨. Мені здається, тренд очевидний: хто не моніторить PowerShell, планувальник задач і каталоги віддаленого адмін-ПЗ — той просто не бачить пів атаки 🛡️. Як у вас з цим: стоїть EDR/логування, чи все ще «антивірус і на тому дякую»?🔗 Докладніше:https://cybersecurefox.com/uk/powershell-bekdor-phantomheart-head-mare-living-off-the-land#кібервійна_кібербезпека_powershell_lotl_headmare_itsecCyberSecureFox
🧩 Натрапив на кейс, після якого ще раз подивився на свої розширення в браузері. Виявилось, що під виглядом кастомізації ВК сиділа ціла мережа «тихих» плагінів для Google Chrome з понад 500 000 установок. Розширення VK Styles обіцяло теми й плюшки для інтерфейсу, а натомість непомітно інжектило свій код у кожну сторінку й крутило вашим акаунтом. 🧠 Воно з ~75% ймовірністю оформлювало автопідписку на їхню групу з 1,4 млн учасників, а якщо ви відписувались — пробувало підписати знову. Раз на місяць ще й скидувало частину налаштувань, змінювало стрічку на «Нещодавні» – мені від цього не по собі. Найцікавіше, що вся «командна інфраструктура» ховалась на звичайному профілі VK і в репозиторії GitHub, а оновлення розширення браузера прилітали автоматично 🔐. З таким підходом оператор у будь-який момент може докрутити код до чогось набагато жорсткішого 🤦♂️. Я для себе вирішив: мінімізую кількість плагінів і раз на місяць влаштовую їм ревізію 🧹 — а ви коли востаннє чистили свої розширення?🔗 Докладніше:https://cybersecurefox.com/uk/vk-styles-shkidlyvi-rozshirennia-chrome-dlia-vkontakte#кібербезпека_браузерні_розширення_vk_приватність_інформаційна_гігієнаCyberSecureFox
🧠 У Google помітили доволі нетипове «піратство»: зловмисники просто викачують знання з Gemini, щоб зібрати власну копію моделі — без обмежень і фільтрів. І це вже не теорія, а реальні кампанії з сотнями тисяч промптів.Мені здається, дистиляція LLM тихо перетворюється на новий клас атак: беруть потужну модель, масово розпитують, навчають «студента» й отримують свій Gemini‑клон без політик безпеки. Така модель може спокійно генерувати малвару, фішинг і підказки з обходу захисту 🔐 — і оригінальний вендор про це навіть не дізнається.Паралельно APT‑групи з Китаю, Ірану, КНДР та РФ вже юзають Gemini для розвідки, соціальної інженерії, написання коду малварі й навіть C2‑інфраструктури. Є PoC‑фреймворки на кшталт HonestCue, які напряму тягнуть другу стадію атаки через Gemini API 🧪. Я все більше думаю, що захист ІІ‑інфраструктури тепер такий самий обов’язковий, як firewall чи EDR.Як вам ідея: атакуючий ШІ, навчений на відповідях захисного ШІ? 🤔 Ви вже закладаєте такі сценарії в свої моделі загроз чи це ще «проблема майбутнього»?🔗 Докладніше:https://cybersecurefox.com/uk/zlovzhyvannya-google-gemini-apt-hrupy-distyljatsiya-llm#кібербезпека_штучнийінтелект_llm_gemini_apt_malwareCyberSecureFox
🛡️ Ніколи не замислювались, що небезпечний лінк може ховатись прямо в команді, яку ви щойно вставили в термінал? Сьогодні натрапив на тулзу, яка змусила мене інакше дивитись на звичний copy-paste.Браузери вже більш-менш навчилися ловити підроблені домени, а от термінал 💻 чесно рендерить будь-який Unicode — хоч кириличну «о» в середині «google.com». Саме тут під’їжджає Tirith: він стає тонким шаром між мною та оболонкою, перехоплює команду до виконання і блокує її, якщо всередині є підозрілий URL з міксом алфавітів чи омогліфами ⚠️.Мені подобається, що все працює локально, без телеметрії, і підтримує zsh, bash, fish, PowerShell та Windows, Linux, macOS 🐧. Плюс open source, можна вбудувати в DevSecOps-пайплайни й CI, а ще використовувати як фільтр для навчальних середовищ 🔍. Я от думаю: чи не час вважати такий “щит для термінала” базовим інструментом для розробників?А ви б поставили собі такий фільтр у термінал, чи це вже оверкіл і достатньо просто бути уважним до команд?🔗 Докладніше:https://cybersecurefox.com/uk/tirith-zahyst-terminalu-vid-omohrafichnyh-atak#кібербезпека_devops_термінал_unicode_tools_opensourceCyberSecureFox
⚠️ Сьогодні натрапив на кейс, від якого реально холоне всередині. Якщо працюєте з dYdX або тягнете їх SDK в проєкти — це прямо має значення.Кілька версій офіційних клієнтів dYdX v4 в npm та PyPI виявилися троянізованими: зловмисники крали seed-фрази і підсовували RAT для віддаленого доступу 💻. Пакети виходили з офіційних акаунтів dYdX, тобто це класична supply chain-атака через довірені джерела, а не якийсь no-name форк.У JS-клієнті код забирав seed + робив fingerprinting пристрою й відправляв це на підробний домен dydx.priceoracle[.]site 🎯. У Python-клієнті все ще цікавіше: після імпорту запускався прихований RAT, що кожні 10 секунд тягнув довільний Python-код з того ж домену й виконував його мовчки 🕵️♂️.Мені здається, це показовий момент: одного компрометованого акаунта в реєстрі пакетів достатньо, щоб «відкрити двері» в інфраструктуру розробників і до чужих коштів. Як вам таке і чи перевіряєте ви взагалі, що тягнете з npm/PyPI? 🤔🔗 Докладніше:https://cybersecurefox.com/uk/supply-chain-ataka-na-dydx-v4-komprometaciya-npm-pypi#кібербезпека_web3_crypto_розробка_devsecops_supplychainCyberSecureFox