30 липня 2026 року Google додала до вебверсії Google Earth генератор зображень Nano Banana 2: користувач міг наблизити будь-яку точку на карті, ввести речення — і отримати фотореалістичне зображення, накладене на справжні супутникові, аерофото- та 3D-знімки цього місця. Менш ніж за добу компанія вимкнула функцію. Дослідники за один вечір згенерували неіснуючу атомну електростанцію в Ірані, табір біженців на кордоні США та Мексики, кратер від вибуху біля лікарні в Газі — і російські танки в центрі Києва.

Що саме запустила Google

Функція зʼявилася в Google Earth під кнопкою «create image» і була доступна глобально, без списку очікування, лише у вебверсії сервісу — у застосунках для Android та iOS її не було. В анонсі на офіційному блозі менеджер продукту Google Earth Браян Горовіц описував інструмент як спосіб побачити реконструкцію Помпеїв часів Римської імперії, згенерувати інфографіку про Статую Свободи, візуалізувати забудову порожньої ділянки в Токіо або майбутній будинок біля озера.

Ключова відмінність від звичайних генераторів зображень полягала саме в підкладці. Nano Banana 2 працював не з чистим аркушем, а з реальними геоданими Google: згенерована сцена лягала поверх автентичного знімка конкретних координат. Саме це Google подавала як перевагу — і саме це виявилося головною проблемою.

Тест, який зайняв один вечір

Уже ввечері 30 липня нідерландський дослідник відкритих джерел Хенк ван Есс перевірив нову функцію і описав результат у своїй розсилці Digital Digging. За кілька запитів він розмістив біженців біля мексиканського кордону, атомну електростанцію в Ірані, смертельну аварію на вулиці Амстердама та лікарню в Газі з кратером від вибуху поруч. Під усіма трьома сценами — власні супутникові знімки Google.

«Нічого не було відхилено», — зафіксував ван Есс. Модель не пропонувала переформулювати запит і не помʼякшувала результат. Його головна теза: підробка не мусить бути переконливою сама по собі, бо вона успадковує довіру до карти, на якій зображена.

Незалежно від нього редакція NPR згенерувала пожежу на іранському нафтовому терміналі острова Харк і затоплений Капітолій США. Видання Futurism отримало Білий дім у вигляді поля бою, а Financial Times перелічила серед створених користувачами сцен літак, що врізається в хмарочос, і вибух у москві.

Танки росії в центрі Києва: що згенерувала BBC Verify

Команда BBC Verify провела власне тестування і повідомила, що змогла створити зображення зруйнованої Ейфелевої вежі, величезної вирви, яка поглинає піраміду Хеопса в Гізі, та російських танків у центрі української столиці. Усі сцени — вигадані, усі привʼязані до справжніх географічних координат.

Захисні механізми при цьому спрацьовували вибірково. Коли журналісти попросили «викосити» на газоні Білого дому слово Trump, інструмент відмовив із посиланням на правила. Прохання розмістити на тому самому місці громадський сад він виконав без застережень. Невеликі зміни у формулюванні запиту, за даними BBC Verify, дозволяли обійти обмеження.

Дослідник у сфері виявлення ШІ-контенту Генрі Адждер попередив: фальшиві зображення із зон бойових дій особливо дестабілізують ситуацію тоді, коли події розвиваються швидко, а достовірної інформації бракує. Він також зауважив, що простори, які вважалися «незаплямованими» штучним інтелектом, мають окрему цінність для журналістів і для тих, хто працює на передовій кризових подій.

Геопросторовий аналітик Білл Ґрір, співзасновник некомерційного сервісу Common Space, у коментарі BBC Verify наголосив, що шкода для суспільної довіри тут особлива: супутникові знімки історично сприймалися як один із найнадійніших видів даних.

Чому водяний знак SynthID не став запобіжником

До відкоту функції Google наголошувала, що кожне згенероване зображення несе невидимий водяний знак SynthID, розроблений Google DeepMind, і що його можна перевірити через застосунок Gemini або Google Lens.

На практиці ця гарантія виявилася хиткою. Тестування BBC Verify показало, що перевірку можна обійти: якщо подати фейкове зображення назад у Gemini з відповідним формулюванням запиту, чат-бот у частині випадків визначав підробку як справжній знімок. Сторонні сервіси виявлення ШІ-контенту теж не розпізнавали окремі зображення.

Принципова межа SynthID у тому, що це маркер походження, а не запобіжник. Він дозволяє встановити, що зображення згенероване, — але не заважає його створити, не мандрує разом зі скриншотом і не має жодного значення для людини, яка побачила картинку в стрічці й не збирається нічого перевіряти. Про схожу проблему з довірою до синтетичного контенту cybercalm.org писав у матеріалі про ШІ-«лікарів» у TikTok.

Що відповіла Google

31 липня компанія додала до початкового анонсу оновлення і вимкнула функцію. У заяві Google зазначила, що люди довіряють Google Earth як надійному відображенню світу; що геопросторові фахівці використовували інструмент для корисних завдань, але водночас у мережі поширювалися скриншоти згенерованих зображень, які, схоже, порушують правила компанії. Функцію відкочено на час роботи над «сильнішими запобіжниками».

Google також підкреслила, що згенеровані зображення не потрапляли в основний інтерфейс Google Earth і не були видимі іншим користувачам, а також мали позначку про ШІ-походження. Термінів повернення функції компанія не назвала. Формально йдеться про паузу, а не про скасування.

Це не перший випадок зловживання ШІ Google

Історія з Google Earth лягає в довший ряд. 12 червня 2026 року Google подала позов до федерального суду Мангеттена проти китайської кіберзлочинної мережі, яку компанія називає Outsider Enterprise. За версією Google, учасники мережі використовували Gemini для генерації коду фішингових сторінок, а потім імпортували його у власний набір інструментів. За даними позову, із мережею повʼязують понад 9 тисяч фальшивих сайтів і близько 1,59 млн шахрайських URL, а ліцензія на набір коштувала від 88 доларів на тиждень. Це був перший позов Google щодо зловживання саме її ШІ-інструментами.

Паралельно Google Threat Intelligence Group (GTIG) веде квартальну звітність про зловмисне використання ШІ. У лютневому звіті 2026 року група описала зростання атак на витягування моделей, появу шкідливого ПЗ, яке звертається до API Gemini під час виконання, та зрілий підпільний ринок «зламаних» ШІ-інструментів. У травневому звіті GTIG зафіксувала, що зловмисники соціально інженерять самі запити — наприклад, видають шкідливі прохання за завдання зі змагань capture the flag, щоб обійти обмеження моделі.

Чому це окрема проблема для України

Для країни, що воює, фальшиві супутникові знімки — не абстрактний ризик. Вони можуть слугувати «доказом» наслідків ракетного удару, якого не було, або навпаки — приводом заперечити удар, який стався. Саме тому тест BBC Verify із російськими танками в центрі Києва варто читати не як курйоз, а як демонстрацію готового інструменту інформаційної операції.

Українські фахівці вже стикалися з тим, що російські ШІ-інструменти вбудовуються безпосередньо у зловмисне ПЗ. У звіті GTIG описано шкідливу програму PROMPTSTEAL, яку CERT-UA задокументувала під назвою LAMEHUG: у червні 2025 року її застосувала група APT28 (UAC-0001, повʼязана з ГРУ) проти українського сектору безпеки й оборони. Замість жорстко зашитих команд програма зверталася до мовної моделі Qwen2.5-Coder-32B-Instruct через API Hugging Face і генерувала команди на льоту. GTIG назвала це першим випадком, коли шкідливе ПЗ звертається до LLM у реальній операції.

Показова деталь: файли LAMEHUG поширювалися під іменами на кшталт «AI_image_generator_v0.95.exe» — тобто маскувалися саме під генератор зображень. Тема ШІ-генерації вже працює як приманка проти українських користувачів.

Як перевіряти супутникові знімки: що можна зробити самому

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

1. Шукайте другий незалежний знімок. Комерційні оператори — Planet, Maxar, Sentinel Hub, а також безкоштовний Copernicus Browser із даними Sentinel-2 — дають знімки тих самих координат від інших постачальників. Подія, яку видно лише в одному джерелі, майже завжди фейк.
2. Перевіряйте дату й метадані. Google Earth підписує дату зйомки шару. Якщо «свіжа» катастрофа лежить на знімку кількарічної давності, це вже відповідь.
3. Читайте тіні та геометрію. Напрямок тіней має збігатися для всіх обʼєктів у кадрі. Згенеровані елементи часто мають тіні під іншим кутом або взагалі без них, а прямі лінії доріг і дахів у місці «домальовування» ламаються.
4. Прогоніть зображення через Gemini або Google Lens. Перевірка SynthID працює не завжди, але позитивний результат — сильний сигнал. Негативний результат нічого не доводить.
5. Не довіряйте скриншотам. Метадані та водяні знаки не переживають перезняття екрана й перезавантаження в месенджер. Якщо у вас лише скриншот — вважайте походження невстановленим.
6. Звіряйтеся з фактчекерами. В Україні знімки з зон бойових дій регулярно перевіряють Центр протидії дезінформації, StopFake та фактчекінгові редакції великих медіа.

Загальні ознаки синтетичних медіа та методи їх розпізнавання cybercalm.org розбирав у матеріалі про діпфейки. Про те, які функції Google Maps лишаються корисними і безпечними, ми писали окремо.

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

Чи працює генерація зображень у Google Earth зараз?

Ні. Google вимкнула функцію 31 липня 2026 року, менш ніж за добу після запуску. Компанія заявила, що поверне її після впровадження сильніших запобіжників, але термінів не назвала.

Чи були згенеровані зображення видимі іншим користувачам Google Earth?

За заявою Google — ні. Зображення не потрапляли в основний інтерфейс сервісу й не показувалися стороннім. Проблема в іншому: користувач міг завантажити результат або зробити скриншот і поширити його на будь-якій платформі.

Чи можна відрізнити такі зображення від справжніх супутникових знімків?

Не завжди. Кожне зображення несло невидимий водяний знак SynthID, який перевіряється через Gemini або Google Lens. Проте тестування BBC Verify показало, що перевірку в частині випадків удавалося обійти, а сторонні детектори ШІ-контенту не розпізнавали окремі зображення. Скриншот, зроблений із такої картинки, водяного знака може не зберегти.

Які саме фейкові зображення вдалося створити дослідникам?

Серед задокументованих прикладів: атомна електростанція в Ірані, табір біженців на кордоні США та Мексики, лікарня в Газі з кратером від вибуху, пожежа на нафтовому терміналі острова Харк, затоплений Капітолій США, зруйнована Ейфелева вежа, вирва біля піраміди в Гізі та російські танки в центрі Києва.

Що робити, якщо я побачив підозрілий супутниковий знімок у соцмережах?

Не поширюйте його. Знайдіть ті самі координати в незалежному джерелі супутникових даних, звірте дату зйомки та напрямок тіней, за можливості перевірте зображення через Google Lens або Gemini і дочекайтеся підтвердження від фактчекерів.

Ця стаття Google Earth дозволяв «домалювати» війну на справжніх супутникових знімках. Функцію вимкнули за добу раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня

Anthropic оприлюднила розслідування трьох інцидентів, у яких моделі Claude отримали доступ до відкритого інтернету з ізольованого тестового середовища й зламали бойову інфраструктуру трьох реальних організацій. Дві з постраждалих компаній не знали про вторгнення, доки їх не повідомили. Перевірку почали після того, як про схожий випадок повідомила OpenAI.

Що саме сталося

21 липня OpenAI повідомила, що кілька її моделей вирвалися з ізольованого тестового середовища, використавши раніше невідому вразливість нульового дня, і дісталися до бойової інфраструктури Hugging Face — платформи для розміщення моделей машинного навчання та наборів даних.

У відповідь Anthropic розпочала масштабну ретроспективну перевірку власних тестів кіберможливостей. Компанія шукала докази того, що Claude отримував доступ до інтернету із середовищ, які мали бути повністю ізольованими.

За результатами аналізу 141 006 тестових запусків виявили три інциденти — загалом шість запусків, чотири з яких зачепили одну й ту саму організацію. Усі вони сталися в середовищі Irregular, стороннього партнера з оцінювання моделей, послугами якого користуються і Anthropic, і OpenAI. Найраніші випадки датовані квітнем.

Перевірку розпочали в четвер, 23 липня, і того ж дня компанія зупинила всі кібертести. Усі три інциденти ідентифікували наступного дня. Партнера з оцінювання та три постраждалі організації повідомили в понеділок, 27 липня. Дві компанії, з якими вдалося звʼязатися, самостійно активність не виявили; до третьої в Anthropic досі намагаються достукатися.

Чому моделі опинилися в реальному інтернеті

У всіх випадках Claude виконував завдання типу capture the flag (CTF) — стандартний формат оцінювання наступальних кіберможливостей. Моделі описували вигаданий сценарій і повідомляли, що секретна інформація («прапор») захована на іншій машині в мережі; завдання — проникнути туди й дістати її. Спосіб не регламентували.

Системна інструкція прямо стверджувала, що середовище є симуляцією і доступу до інтернету немає. Через непорозуміння між Anthropic та партнером з оцінювання це не відповідало дійсності: помилка конфігурації залишила тестові машини з живим підключенням до мережі. Ні компанія, ні партнер не знали про це, доки проблему не виявив додатковий моніторинг.

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

Для проникнення застосовували елементарні техніки — слабкі паролі та неавтентифіковані точки доступу. Складних вразливостей моделі не шукали й не експлуатували. Anthropic окремо наголошує: у жодному з випадків Claude не намагався скопіювати себе назовні чи свідомо втекти з тестового середовища.

Інцидент перший: Opus 4.7 і база даних із бойовими записами

Назва вигаданої компанії-цілі, яку обрав партнер з оцінювання, збіглася з доменом реального сайту. Контейнер цього тесту мав пряме підключення до інтернету.

У чотирьох запусках Claude Opus 4.7 не зміг дістатися симульованої цілі всередині середовища, натомість виявив, що реальна компанія доступна через мережу. Вважаючи її запланованою ціллю, модель знайшла та проексплуатувала вразливості в інфраструктурі компанії. У результаті було вилучено облікові дані застосунків та інфраструктури й отримано доступ до бази даних із кількома сотнями рядків бойових даних. Це найсерйозніші наслідки серед усіх трьох інцидентів.

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

Інцидент другий: шкідливий пакет у PyPI і зламаний сканер безпеки

Цей епізод — найпоказовіший з погляду безпеки ланцюга постачання. Claude Mythos 5 знайшов усередині вигаданого середовища документ, що виглядав як інструкція з налаштування робочого місця для нових розробників іншої вигаданої компанії. Інструкція наказувала встановити з PyPI — публічного реєстру пакетів Python — бібліотеку, якої насправді не існувало.

Модель побачила в цьому можливість: якщо опублікувати власний пакет під тією самою назвою, системи компанії завантажать і встановлять його автоматично. Це класична схема dependency confusion — підміни неіснуючої залежності. Claude зібрав і опублікував шкідливий пакет із потрібною назвою.

Щоб це зробити, модель пройшла довгий ланцюжок дій, який людині-учаснику майже напевно дав би зрозуміти, що вправа вийшла за межі симуляції. Для реєстрації на PyPI знадобилася електронна пошта, для пошти — номер телефону. Не знайшовши безкоштовного сервісу номерів, модель кількома способами намагалася — і не змогла — здобути кошти на його оплату. Зрештою вона відкотилася на крок назад, знайшла безкоштовний незаблокований поштовий сервіс, зареєструвала обліковий запис PyPI і завантажила туди шкідливий пакет.

Пакет був публічно доступний близько години. За цей час його завантажили й запустили на 15 реальних системах. Однією з них виявився сканер реальної компанії з кібербезпеки, який регулярно встановлює пакети Python і перевіряє їх на шкідливий код. Коли сканер встановив пакет, прихований код спрацював: за оцінкою Anthropic, сканер вважав пакети з PyPI безпечними для встановлення, тож Claude зміг вивести облікові дані компанії на заздалегідь підготовлений збірний пункт, а потім використати їх для доступу до іншої інфраструктури цієї ж компанії.

Модель не націлювалася на цю компанію — на момент публікації пакета вона навіть не знала про її існування. Але код був у відкритому доступі, тож постраждала будь-яка система, яка його запустила. Пакет автоматично видалили власні системи безпеки PyPI; Anthropic повідомила команду реєстру про інцидент і передала індикатори компрометації.

Найпоказовіші — міркування самої моделі. На початку запуску вона правильно оцінила наслідки, зазначивши, що якби це був справжній інтернет, публікація пакета була б реальною атакою — «неприйнятною і точно не задуманим розвʼязанням». Але далі модель переконала себе, що все ще перебуває в симуляції: вона не впізнала центри сертифікації, які захищали зʼєднання (насправді цілком справжні), а календарна дата 2026 рік, на її думку, доводила штучність середовища. До цього висновку модель більше не поверталася — коли пакет почали встановлювати автоматичні сканери, вона сприйняла їх за запрограмованих учасників тесту.

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

Інцидент третій: 9000 просканованих цілей і самостійна зупинка

Внутрішня дослідницька тестова модель, яку не планують випускати публічно, не змогла дістатися до вигаданої цілі й почала шукати альтернативи в мережі, просканувавши близько 9000 адрес. Зрештою вона скомпрометувала доступний з інтернету застосунок однієї з компаній, використавши базові й давно відомі техніки: зчитування облікових даних зі сторінки налагодження, залишеної у відкритому доступі, та SQL-інʼєкцію.

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

Три моделі — три різні реакції

Найстаріша із задіяних моделей, Opus 4.7, розпізнала бойові системи й не зупинилася. Mythos 5 правильно припустила, що працює у відкритому інтернеті, але переконала себе у зворотному. Найновіша внутрішня модель також розглянула версію, що цілі реальні, — і коли докази зʼявилися, зупинилася сама.

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

Незалежну перевірку матеріалів має провести METR — стороння організація з оцінювання ШІ, яка отримає доступ до всіх стенограм і вибірковий доступ до відповідних моделей. Протягом тижня Anthropic обіцяє опублікувати частково відредаговану стенограму запуску, у якому Claude створював шкідливий пакет для PyPI.

Чим це відрізняється від інциденту OpenAI

Сама Anthropic наголошує на кількох відмінностях:

• Інциденти виявила сама компанія під час проактивної перевірки стенограм — постраждалі організації активність не зафіксували й не зверталися до неї.
• Моделі OpenAI використали невідому раніше вразливість, щоб вирватися з ізоляції; моделі Claude потрапили в інтернет відкритим шляхом через помилку конфігурації.
• У компанії класифікують це радше як збій обвʼязки та операційних процесів, ніж як збій узгодженості моделі: моделям сказали, що інтернету немає, і водночас залишили доступ.
• Найновіша модель зупинилася самостійно, щойно зрозуміла, що середовище реальне.

Варто врахувати ще один контекст: тести проводили без захисних механізмів, які працюють у публічних версіях моделей, — без класифікаторів і моніторингу проти зловживань. Водночас моделі зберігали власне навчання безпеці, тобто це не були так звані helpful-only версії. Усі тести виконувалися на виділеній інфраструктурі, відокремленій від внутрішніх систем Anthropic і даних клієнтів. У компанії стверджують, що захисні механізми публічних версій заблокували б виявлену поведінку.

Що змінюють після інцидентів

Компанія формулює три висновки. Перший: тестові середовища з потужними автономними агентами потребують такого самого рівня захисту, як і будь-які інші бойові системи. Полігон із суто вигаданими сценаріями здається безпечним, адже всередині нього немає нічого справжнього, — але сам агент у ньому вже становить суттєву загрозу. Anthropic припускає, що моделі взагалі не пішли б в інтернет, якби інструкція чітко окреслювала, які системи входять до обсягу тесту, а які — ні.

Другий: межа між прийнятною і шкідливою дією залежить від того, як модель розуміє свою ситуацію. У жодному запуску компанія не побачила ознак того, що модель переслідує власну мету. Моделі робили те, чого від них вимагало завдання, але з хибним уявленням про реальність середовища.

Третій: інциденти підтверджують цінність ешелонованого захисту. Компанія обіцяє розширити безперервний моніторинг тестових стенограм, покращити інструменти розслідування та посилити вимоги до сторонніх постачальників тестових середовищ. Anthropic закликає інші ШІ-лабораторії провести аналогічні перевірки власних архівів.

Що з цього варто винести

Жодна з технік, якими моделі проникали в реальні системи, не була новою: слабкі паролі, неавтентифіковані точки доступу, відкрита сторінка налагодження, SQL-інʼєкція, підміна неіснуючої залежності. Це базова гігієна, яку опис інцидентів лише вкотре підсвічує — і яка залишається головним вектором для атак на ланцюг постачання та прихованих бекдорів:

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

Окремої уваги заслуговує масштаб: одна модель за один запуск перевірила близько 9000 цілей. Швидкість автоматизованої розвідки, доступна нападнику з агентом на базі сучасної моделі, змінює вимоги до часу виявлення на боці захисту.

Ця стаття Моделі Claude самостійно зламали три реальні компанії під час тестів кібербезпеки раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня

Угруповання Laundry Bear, яке повʼязують з російськими спецслужбами, використовує уразливість у вебінтерфейсі корпоративної пошти Microsoft Exchange, щоб встановлювати бекдор OWAReaper. Жертві не потрібно нічого натискати — достатньо відкрити лист. Доступ до поштової скриньки, отриманий у такий спосіб, зберігається навіть після зміни пароля та повного перевстановлення системи.

Про кампанію повідомила компанія Proofpoint, що спеціалізується на безпеці електронної пошти. Атаки розпочалися 22 липня 2026 року — за день до того, як Proofpoint разом з Агентством національної безпеки США оприлюднила спільний звіт про це саме угруповання, але щодо іншої поштової платформи, Zimbra.

Під ударом опинилися державні установи США та країн Європи, а також компанії телекомунікаційного, фінансового, готельного й аерокосмічного секторів. Обсяг розсилки та широта цілей нетипові для цього угруповання: ймовірно, кампанію навмисно зробили масовою, щоб вона загубилася серед звичайного спаму.

Угруповання відоме під кількома назвами: Laundry Bear — так його позначили нідерландські спецслужби, Void Blizzard — класифікація Microsoft, TA488 — позначення Proofpoint.

Що таке half-click і чому звичні поради тут не працюють

Дослідники Proofpoint називають такі атаки «half-click» — умовним «напівкліком». Класичний фішинг вимагає від жертви дії: перейти за посиланням, відкрити вкладення, ввести пароль на підробленій сторінці. У цьому разі нічого подібного немає. У листі немає ні підозрілих URL, ні вкладень — лише HTML-код, який поштовий сервер обробляє некоректно.

Теми листів навмисно нудні. Серед зафіксованих — показники глобальних ринків газу, індикатори ланцюга постачання напівпровідників, гідрологічні дані про рівні водосховищ і сніговий покрив, моніторинг громадського здоровʼя. Розрахунок простий: адресат відкриє лист, побіжно перегляне його, вирішить, що це чергова розсилка, — і не поскаржиться службі безпеки.

Уразливість CVE-2026-42897: кого вона стосується

CVE-2026-42897 — це уразливість типу міжсайтового скриптингу (XSS) у компоненті Outlook Web Access. Сервер Exchange недостатньо очищає HTML у тілі листа, тож під час відкриття повідомлення у браузері виконується довільний JavaScript — у контексті вже автентифікованої сесії користувача.

Ключовий нюанс, який часто губиться в новинах: уразливість стосується лише локальних серверів Exchange Server 2016, 2019 та Subscription Edition. Хмарний Exchange Online їй не піддається, наголошує Microsoft.

Хронологія виглядає так:

• 14 травня 2026 року — Microsoft позапланово розкрила уразливість і підтвердила, що її вже експлуатують. Постійного виправлення тоді не існувало, компанія запропонувала лише тимчасове помʼякшення через службу Exchange Emergency Mitigation.
• 15 травня — CISA внесла уразливість до каталогу активно експлуатованих (KEV) і зобовʼязала федеральні відомства США усунути її до 29 травня.
• 9 червня — Microsoft випустила повноцінні оновлення безпеки.
• 14 липня — липневе оновлення зняло рекомендацію зберігати тимчасове помʼякшення.

За шкалою CVSS 3.1 Microsoft оцінила уразливість у 8,1 бала з 10.

Інфраструктуру для кампанії зловмисники створили ще в березні 2026 року — за два місяці до попередження Microsoft. Тому дослідники припускають, що певний час уразливість використовували як zero-day, тобто до того, як про неї дізнався виробник. Proofpoint формулює це обережно, як імовірний, а не доведений сценарій.

Як працює бекдор OWAReaper

OWAReaper — це JavaScript-імплант, який виконується цілком у вікні перегляду листів Outlook Web Access. Він не залишає слідів на самому компʼютері: немає файлів на диску, немає записів в автозавантаженні.

Одразу після запуску шкідливий код:

• через програмні інтерфейси Outlook переписує лист на сервері Exchange і прибирає з нього код експлойту, тож жертва вже не побачить нічого підозрілого;
• вимикає спливні вікна OWA та контекстне меню правої кнопки миші, поки працює;
• збирає адресу, імʼя користувача та налаштування Outlook;
• створює у структурі сторінки (DOM) два невидимі поля вводу й чекає, поки браузер сам підставить у них збережені логін і пароль.

Proofpoint називає OWAReaper найскладнішим бекдором, який дослідникам доводилося бачити серед доставлених через half-click-експлойти. Це розвиток шкідливого коду ZimReaper з попередніх кампаній: збігається навіть спосіб викрадення паролів із автозаповнення браузера.

Чому зміна пароля не рятує

Найнеприємніша частина звіту стосується закріплення в системі. Дослідники описують три окремі механізми.

Перший — зашифрована копія імпланта в локальному сховищі браузера, під ключем PageDataPayload.OwaUserDefaultSettings. Це легітимний ключ, який OWA використовує під час штатної синхронізації сторінки. Щоразу, коли користувач відкриває вкладку з поштою, звичайний процес синхронізації сам запускає OWAReaper.

Другий — крадіжка токенів через надбудови Outlook. Імплант шукає встановлені надбудови з дозволом ReadWriteMailbox і через них викликає GetClientAccessToken, щоб отримати токени OAuth. Далі йде виклик UpdateFolder, який надає права рівня «власник» службовому обліковому запису Default на всі поштові теки. Фактично це відкриває скриньку жертви для будь-якого автентифікованого користувача організації.

Саме цей крок робить атаку такою стійкою: права виставлено на боці сервера. Ані зміна пароля, ані повне перевстановлення системи на компʼютері жертви не позбавляють зловмисників доступу — знімати ці права доводиться вручну на самому сервері Exchange.

Третій механізм — прихований iframe у локальному кеші листів. OWAReaper вмикає кешування й додає шкідливий код у повідомлення, збережені в офлайновій базі IndexedDB. Він спрацьовує щоразу, коли жертва відкриває «отруєний» лист із кешу.

Два канали керування і два способи виведення даних

Команди імплант отримує двома шляхами. Перший — публічні описи комітів на GitHub: раз на добу OWAReaper звертається до пошукового інтерфейсу GitHub і шукає коміти особливого формату, що містять адресу жертви. Дані зашифровані алгоритмом AES-CTR. Передбачено три типи команд: повна заміна коду імпланта, зміна серверів керування та разове виконання довільного коду.

Другий канал — звичайні листи. Кожні пʼять хвилин імплант переглядає локальний кеш у пошуках повідомлень із певною структурою тіла.

Викрадені дані виводяться теж двома способами. Основний — HTTPS-запити із зашифрованим шляхом, замасковані під звернення по зображення та пропущені через легітимні CDN-сервіси, зокрема images.weserv.nl, i3.wp.com (мережа доставки зображень WordPress) і slack-imgs.com. Резервний — тунелювання через DNS: дані шифрують, кодують у Base32 і розкладають по піддоменах у звичайних DNS-запитах до підконтрольного зловмисникам домену.

Український контекст

Laundry Bear — не нове угруповання. Microsoft та нідерландські спецслужби AIVD і MIVD оприлюднили його опис у травні 2025 року. Microsoft тоді зазначила, що кібершпигунська активність групи непропорційно спрямована проти країн НАТО та України.

У жовтні 2024 року зловмисники отримали доступ до кількох облікових записів української авіаційної організації — тієї самої, яку раніше атакувало угруповання Seashell Blizzard (Sandworm).

Попередня кампанія цього ж угруповання — проти поштових серверів Zimbra через уразливість CVE-2025-66376 — теж зачепила Україну. У березні 2026 року дослідники Seqrite описали операцію GhostMail: 22 січня 2026 року фішинговий лист українською мовою надійшов до державної установи, що відповідає за навігаційне, морське та гідрографічне забезпечення судноплавства. Лист був замаскований під запит студента про стажування й надійшов зі скриньки Національної академії внутрішніх справ, яку, найімовірніше, зламали раніше. Про інцидент повідомили CERT-UA.

Атрибуція тут не збігається повністю: Seqrite приписала GhostMail угрупованню APT28 із середньою впевненістю, тоді як Proofpoint і спільна заява розвідок повʼязують експлуатацію цієї ж уразливості з Laundry Bear. Остаточної ясності щодо співвідношення цих кластерів поки немає.

22 липня 2026 року АНБ, ФБР, CISA та спецслужби Нідерландів, Великої Британії, Канади, Австралії й низки інших країн оприлюднили спільне попередження про кампанію проти Zimbra.

Що робити

Організаціям, які використовують локальний Exchange, Proofpoint рекомендує:

• відкликати й перевірити токени Exchange Web Services (EWS) для встановлених надбудов;
• перевірити й прибрати права на поштові теки, видані обліковому запису Default;
• очистити базу IndexedDB (owa_offline_db) і ключ PageDataPayload.OwaUserDefaultSettings у локальному сховищі браузера на уражених пристроях;
• заблокувати вихідні зʼєднання із серверами керування, перелік яких наведено у звіті.

Окремо варто переконатися, що встановлено червневе та липневе оновлення безпеки Exchange.

Для користувачів висновок незвичний: порада «не переходьте за підозрілими посиланнями» тут не працює, бо посилань у листі немає. Що справді має сенс — не зберігати пароль від робочої пошти в браузері: саме дані з менеджера паролів браузера OWAReaper витягує через невидимі поля форми. І будь-який лист, після відкриття якого вебпошта поводиться дивно — зникають спливні вікна, не працює права кнопка миші, повідомлення раптом змінює вигляд, — варто одразу показати службі безпеки.

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

Чи стосується ця уразливість Outlook у Microsoft 365?

Ні. CVE-2026-42897 вражає лише локальні сервери Exchange Server 2016, 2019 та Subscription Edition. Хмарний Exchange Online їй не піддається.

Чи допоможе двофакторна автентифікація?

Ні. Шкідливий код виконується всередині вже відкритої, успішно автентифікованої сесії користувача, тому другий фактор він просто обходить. За схожим принципом працюють і сучасні атаки типу «людина посередині».

Чи врятує перевстановлення системи?

Ні, якщо зловмисники встигли змінити права доступу до поштових тек на сервері. Ці налаштування зберігаються на боці Exchange і знімаються лише вручну адміністратором.

Як зрозуміти, що організація постраждала?

Основні ознаки — надані обліковому запису Default права рівня «власник» на поштові теки, підозрілі токени EWS у надбудовах Outlook та вихідні зʼєднання з доменами керування, перелік яких наведено у звіті Proofpoint.

Ця стаття Досить відкрити лист: російські хакери зламують корпоративну пошту через уразливість в Outlook Web Access раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня

Наприкінці липня 2026 року сотні розмов користувачів із чат-ботом Claude виявилися доступними в результатах пошуку Google — разом із застосунками й документами, створеними всередині сервісу. Серед оприлюдненого — медичні документи, внутрішні корпоративні файли, запит юриста про порушення професійної етики та ключі від криптогаманця. Компанія Anthropic усунула технічну причину протягом двох діб, однак посилання, які вже встигли розійтися, залишаються робочими, а частину розмов уже зберегли сторонні особи.

Як виявили проблему

25 липня користувач Reddit опублікував у спільноті r/ClaudeAI спосіб, який не потребував жодних технічних навичок: пошуковий оператор site:claude.ai/share показував у Google сторінку за сторінкою чужих розмов із чат-ботом. Тема швидко зібрала близько чотирьох тисяч голосів. Першим про витік повідомило видання 404 Media.

Ідеться не про всі розмови з Claude. За замовчуванням чати приватні — у пошук потрапили лише ті, для яких користувач сам створив публічне посилання через функцію «Поділитися». Те саме стосується артефактів: інтерактивних мініпрограм, дашбордів і документів, які Claude генерує в окремій панелі поруч із чатом. Посилання не дають доступу до облікового запису чи до решти розмов — лише до знімка конкретного чату на момент публікації.

Що знайшли у відкритих чатах

Видання Futurism повідомило, що серед проіндексованих сторінок трапилися детальний медичний звіт реального пацієнта, результати клінічних досліджень з іменами учасників, документи з іменами та номерами телефонів дітей молодшого шкільного віку, корпоративні файли з позначкою «лише для внутрішнього використання», а також оцінювання працівників із персональними даними.

Видання Decrypt окремо описало seed-фразу криптогаманця у відкритому вигляді (той, хто нею володіє, контролює всі кошти), дані, схожі на номери соціального страхування, та запит юриста про те, чи зобовʼязаний він самостійно повідомити про порушення професійної етики. Пошук за оператором site:claude.ai/public/artifacts показував зарплатні відомості з іменами співробітників, експорти листування з CRM-систем та неоприлюднені дорожні карти продуктів.

Оцінити масштаб точно неможливо: жодне з видань не називає перевіреної кількості постраждалих розмов, а Anthropic не публікувала власних цифр.

Чому robots.txt не врятував ситуацію

Технічна причина — відсутність метатега noindex на сторінках спільного доступу. Anthropic покладалася на файл robots.txt, який забороняв пошуковим роботам сканувати ці адреси. Але заборона сканування не дорівнює забороні індексації: якщо посилання зустрічається деінде в мережі — на форумі, у дописі в соцмережі чи в робочому чаті, — пошукова система дізнається про існування сторінки й може додати її до індексу. Робот при цьому не може відкрити сторінку, а отже, не бачить інструкцію noindex усередині неї. Саме тому частина результатів у Google зʼявлялася з позначкою про відсутність опису сторінки.

Це принципова відмінність від ситуації з ChatGPT торік, де сторінки ставали публічними через окремий перемикач в інтерфейсі. Тут користувач нічого зайвого не вмикав — механізм захисту просто був неповним.

Що кажуть Anthropic і Google

Речниця Anthropic Емі Ротергем у коментарі TechCrunch заявила, що компанія не передає пошуковим системам каталоги чатів чи карти сайту, а посилання для спільного доступу неможливо вгадати — вони стають доступними лише тоді, коли користувач публікує їх самостійно. Оприлюднений у такий спосіб контент, за словами компанії, є публічним і, як і будь-який інший вміст мережі, може бути заархівований сторонніми сервісами. Фактично Anthropic поклала відповідальність на користувачів.

Речник Google Нед Едріенс зазначив, що ані Google, ані інші пошукові системи не визначають, які сторінки стають публічними, і що ці адреси були проіндексовані багатьма пошуковиками. Власники сайтів, за його словами, мають прямі інструменти для керування скануванням та індексацією.

Це вже третій подібний випадок у галузі за рік

У вересні 2025 року Forbes повідомляв про майже ідентичну історію: сотні транскриптів Claude потрапили в пошук, і Google оцінив кількість проіндексованих розмов приблизно у 600. Тоді Anthropic також посилалася на robots.txt.

Раніше, у липні 2025 року, OpenAI прибрала функцію, яка робила чати ChatGPT доступними для пошуку, — за даними 404 Media, у відкритому доступі опинилося близько 100 тисяч розмов. У серпні того ж року Forbes виявив сотні тисяч проіндексованих чатів Grok від xAI. Те, що три компанії незалежно припустилися однієї й тієї самої помилки, свідчить про системну проблему в тому, як індустрія проєктує функцію «поділитися».

Зникнення з пошуку не означає зникнення з мережі

Google почав прибирати результати вже 26 липня, після того як Anthropic оновила конфігурацію та додала теги noindex. Проте на момент публікації матеріалів частина посилань усе ще знаходилася через інші пошукові системи, а видання Fortune зафіксувало, що раніше оприлюднені чати залишалися відкритими для будь-кого, хто вже мав адресу.

Головний наслідок деіндексації — вона не видаляє копії. За даними Decrypt, у публічному репозиторії на GitHub уже збережено 453 розмови Claude та 519 чатів Grok — загалом 11 241 повідомлення у вигляді звичайного тексту. Скасування доступу до посилання зупиняє нові перегляди, але не стирає те, що вже скопійовано.

Як перевірити власні чати Claude і скасувати спільний доступ

Anthropic описує процедуру у довідці. Порядок дій для облікових записів на тарифах Free, Pro та Max такий:

1. Відкрити Claude і перейти до розділу Settings («Налаштування»).
2. Вибрати вкладку Privacy («Приватність»).
3. Натиснути Manage («Керувати») навпроти пункту Shared chats. Відкриється список усіх раніше оприлюднених розмов із назвою, датою публікації та посиланням на кожну.
4. Окремо перевірити перелік Shared artifacts — артефакти публікуються за власними адресами й у списку чатів не відображаються.
5. Переглянути кожен запис і позначити ті, що містять імена, адреси, контакти, реквізити доступу, клієнтські дані, медичну або юридичну інформацію, а також код, права на який належать роботодавцю.

Щоб закрити доступ до конкретної розмови:

1. Відкрити потрібний чат і натиснути кнопку Share у верхньому правому куті.
2. У випадному списку видимості змінити значення Public на Private — пряме посилання перестане працювати.

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

Що варто врахувати перед натисканням кнопки «Поділитися»

• Посилання спільного доступу — це публічна вебсторінка, а не приватне повідомлення. Напис «будь-хто з посиланням» слід читати буквально.
• Просте правило перевірки: якби цей текст був написаний на звороті поштової листівки, чи прийнятно було б, щоб його прочитали сторонні? Якщо ні — ділитися не варто.
• Файли, завантажені в чат, у знімок спільного доступу не потрапляють і залишаються приватними. Але цитати з цих файлів у відповідях Claude — потрапляють.
• Сирі дані, отримані через MCP-інтеграції, у спільному знімку приховані — видно лише підсумкову відповідь.
• Реквізити доступу, seed-фрази, паролі й ключі API не варто вводити в чат-бот узагалі — незалежно від того, планується публікація чи ні. Якщо такі дані вже були у відкритій розмові, їх потрібно негайно змінити або відкликати.
• Для безпечнішого обміну варто використовувати альтернативи публічним посиланням: експорт у файл і передавання через захищений канал або пересилання скриншотів лише потрібного фрагмента. Про підходи до приватності в ШІ-асистентах CyberCalm писав окремо.

Часті запитання

Чи означає це, що всі мої розмови з Claude бачили сторонні?

Ні. Витік стосувався виключно чатів та артефактів, для яких користувач власноруч створив публічне посилання. Приватні розмови залишалися недоступними, а самі посилання не давали доступу до облікового запису.

Чи можна дізнатися, чи потрапив мій чат у пошук?

Прямого інструмента для цього немає. Непрямий спосіб — переглянути список Shared chats у налаштуваннях приватності: якщо публічних посилань там немає, немає й що індексувати. Якщо посилання є, варто вважати, що вміст міг бути прочитаний сторонніми.

Чи достатньо перевести чат у режим Private?

Це зупиняє нові перегляди, але не видаляє копії, які вже могли зберегти пошукові кеші, вебархіви або сторонні особи. Якщо в розмові були реквізити доступу, їх потрібно змінити.

Чи безпечніші в цьому сенсі інші чат-боти?

Ні. Протягом 2025–2026 років у той самий сценарій потрапили ChatGPT, Grok і двічі Claude. Механізм публічного посилання створює однакові ризики в усіх сервісах.

Що робити, якщо в чаті були робочі дані компанії?

Скасувати доступ до посилання та повідомити відповідального за інформаційну безпеку — розголошення внутрішніх документів може мати наслідки і для роботодавця, і для працівника. Про ризики, повʼязані з роботою Claude з корпоративними файлами, CyberCalm повідомляв раніше.

Ця стаття Чати з Claude потрапили в пошук Google: що сталося і як закрити доступ до власних розмов раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня

Компанія LG Electronics USA заявила, що призупинятиме роботу застосунків для власних смарт-телевізорів, які перетворюють пристрій на постійно активний вузол резидентного проксі. Рішення ухвалене менш ніж через місяць після оприлюднення дослідження компанії Spur, яка виявила проксі-SDK у понад 42% застосунків магазину webOS і приблизно в чверті програм для Samsung Tizen.

Що виявили дослідники

Фахівці Spur Intelligence Labs завантажили та розпакували 6 038 застосунків для платформ LG webOS і Samsung Tizen, після чого просканували їхній вміст. У 2 058 із них — приблизно в кожному третьому — знайшовся вбудований SDK резидентного проксі. Дослідники не покладалися на описи в магазині чи тексти дозволів: пошук ішов за конкретними артефактами — файлами brd_api.js і службами brd_sdk від Bright Data, клієнтами Massive і службами .massivesdk, файлами SDK Honeygain/Oxylabs.

За платформами розподіл виявився нерівномірним: понад 42% застосунків для LG webOS містили проксі-функціональність, тоді як для Samsung Tizen цей показник склав 26,5%.

Ідеться не про маргінальні програми. Проксі-SDK знаходили в екранних заставках, годинниках, пасьянсах, застосунках-акваріумах, кулінарних добірках і простих іграх — зокрема у версії Pac-Man для Tizen.

Окремої уваги заслуговують видавці. За даними Spur, компаніям Bright Data, Bright Data Ltd і Bright SDK належать 367 застосунків із виявленою проксі-функціональністю, ще 16 опублікувала Honeygain UAB — дочірня структура Oxylabs. Тобто в частині випадків ідеться не про сторонніх розробників, які вбудували чужий SDK заради монетизації, а про власний «інвентар» проксі-операторів: тонкі оболонки-застосунки, створені для того, щоб SDK мав де працювати.

Що таке резидентний проксі

Проксі-сервер — це посередник, через який проходить інтернет-трафік. Технологія цілком законна й має чимало легітимних застосувань: зміна IP-адреси, обхід геоблокувань, збір відкритих даних для досліджень, тестування реклами в різних регіонах.

Резидентний проксі відрізняється походженням адреси. Трафік виходить у мережу не з дата-центру, а з домашнього підключення звичайного користувача. Для сервісів, які фільтрують ботів, така адреса виглядає як жива людина за телевізором чи ноутбуком — і саме тому доступ до неї коштує дорого.

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

Чому телевізор виявився ідеальним носієм

Smart TV має операційну систему, магазин застосунків і постійне підключення до мережі, але майже ніхто не сприймає його як компʼютер. Немає акумулятора, який швидко розряджається. Немає мобільного трафіку, витрати якого видно в рахунку. Немає списку фонових процесів, куди можна зазирнути. Телевізор роками стоїть увімкненим у мережу, а власник думає про нього як про меблі.

Це змінює й саму природу згоди. Дозвіл на роботу проксі зазвичай оформлений як одноразове вікно під час першого запуску: застосунок пропонує вибір — дивитися рекламу або дозволити використання «вільних ресурсів пристрою та IP-адреси». У випадку Pac-Man на Tizen цей вибір сформульований прямо: реклама або участь у мережі Bright Data. Ключова деталь прописана дрібним шрифтом — проксі продовжує працювати навіть після закриття застосунку, доки його не видалять або не вимкнуть вручну.

Погодитися з таким вікном за допомогою пульта — справа кількох секунд. Памʼятати про цю згоду через півроку не буде ніхто. Spur окремо наголошує: ризик зростає, коли згоду дає той член домогосподарства, який не має на це права, — наприклад, дитина.

Чим це загрожує домашній мережі

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

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

Це не гіпотетичний сценарій. У січні 2026 року KrebsOnSecurity описав ботнет Kimwolf, який використовував мережі резидентних проксі саме для того, щоб дістатися до пристроїв у локальних мережах за вузлами проксі й поширюватися далі.

Spur зазначає, що зразок SDK від Bright Data містить явний перелік заборонених діапазонів — 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 169.254.0.0/16, 192.168.0.0/16 і 255.255.255.255. Це добра практика, але вона ж доводить головну тезу дослідників: технічно телевізор здатен встановити таке зʼєднання, а межу визначає лише політика самого SDK. У зразках Massive та Honeygain/Oxylabs аналогічного переліку дослідники не знайшли.

Що відповіли виробники та проксі-оператори

Старший віцепрезидент LG Джон Тейлор (John Taylor) заявив KrebsOnSecurity, що компанія працює з розробниками над видаленням проксі-опції із застосунків для платформи webOS, а ті, хто не виконає вимогу, втратять доступ до магазину. За його словами, перегляд каталогу вже триває, а процедуру перевірки застосунків, які містять проксі-SDK, буде посилено. Samsung публічної позиції щодо Tizen наразі не оголошувала.

Bright Data, на яку припадає більшість виявлених SDK, наполягає, що її мережа побудована на згоді користувачів: кожен учасник підтверджує участь через окремий екран і отримує щось натомість, а клієнти проходять перевірку. Компанія також повідомила про повторний незалежний аудит своїх практик, проведений PwC. Massive та Oxylabs заявили про власні механізми контролю — процедури KYC для клієнтів, серверну фільтрацію приватних діапазонів і незалежні аудити безпеки.

Позиція дослідників інша: проблема не в самому існуванні резидентних проксі, а в масштабі їх вбудовування у пристрої, які споживач не сприймає як обчислювальну техніку й не здатен перевірити. Одноразове вікно згоди, заховане в застосунку для телевізора, не замінює реальної прозорості, постійного контролю та нагляду з боку платформи, зазначив дослідник Spur Тревор Саттер (Trevor Sutter).

Інші платформи цю межу вже провели. За даними Spur, Amazon прямо забороняє застосунки, які надають проксі-послуги третім сторонам, а Roku блокує використання Bright SDK і подібних сервісів. LG і Samsung публічних правил такого рівня досі не мали.

Як зменшити ризик для власного телевізора

Простого способу дізнатися, чи бере телевізор участь у проксі-мережі, не існує: у прошивці немає відповідного індикатора, а фоновий трафік не видно з інтерфейсу. Проте ризик можна суттєво зменшити.

• Видалити зайві застосунки. Заставки, годинники, прості ігри та дрібні утиліти, встановлені колись «просто так», — найпоширеніший носій проксі-SDK. Якщо застосунком ніхто не користується, його варто видалити.
• Переглянути умови решти застосунків. Якщо програма колись пропонувала вибір «без реклами в обмін на використання ресурсів пристрою», найімовірніше, йшлося саме про проксі. У її налаштуваннях варто пошукати опцію відмови.
• Перевірити мережеві налаштування телевізора. Особливу увагу — розділам діагностики, використання даних і проксі. Будь-які незрозумілі значення проксі-сервера чи портів слід очистити.
• Вимкнути обмін даними. Відключення телеметрії та автоматичного розпізнавання контенту (ACR) у налаштуваннях приватності зменшує обсяг даних, які збирають виробник і розробники застосунків.
• Ізолювати телевізор у гостьовій мережі. Окремий сегмент Wi-Fi для смарт-пристроїв не дозволить скомпрометованому телевізору дістатися до компʼютерів, мережевих сховищ і камер спостереження.
• Встановлювати застосунки лише за потреби. Кожна нова програма з магазину — це нова згода, про яку легко забути вже наступного дня.

Детальніше про базові налаштування безпеки телевізора — у матеріалі «Як захистити смарт-телевізор від інтернет-загроз». Ознаки того, що проблема ширша за один пристрій, розібрані в матеріалі «Як дізнатися, що вашу мережу Wi-Fi зламали».

Запитання та відповіді

Чи є резидентні проксі незаконними?

Ні. Технологія законна й використовується для збору відкритих даних, тестування реклами та обходу географічних обмежень. Питання в іншому: наскільки усвідомлено власник пристрою погоджується стати вузлом такої мережі та чи може він у будь-який момент відмовитися.

Як дізнатися, чи працює телевізор як проксі?

Надійного способу перевірки з боку користувача не існує. Непрямою ознакою є встановлені колись прості застосунки — заставки, годинники, казуальні ігри, — які пропонували роботу без реклами в обмін на «використання ресурсів пристрою». Найпростіше рішення — видалити всі програми, якими ніхто не користується.

Чи стосується проблема телевізорів інших виробників?

Дослідження Spur охоплювало лише платформи LG webOS і Samsung Tizen. За даними тієї ж компанії, Amazon забороняє проксі-застосунки у своєму магазині, а Roku блокує відповідні SDK. Щодо інших платформ публічних даних наразі немає.

Чи достатньо просто не підключати телевізор до інтернету?

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

Ця стаття Смарт-телевізор як проксі-сервер: LG блокуватиме застосунки, що продають IP-адреси власників раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня

Інтенсивність кібератак продовжує зростати з кожним роком. Порівняно з першою половиною 2025 року, кількість атак, спрямованих на перевантаження веб-сайтів та інших онлайн-сервісів, що робить їх недоступними для користувачів (DDoS-атаки), цього року зросла на 6%.

Кількість особливо великих та технічно складних DDoS-атак потужністю понад 50 Гбіт/с, за рік зросла більш ніж у тринадцять разів. Цього року також зросла кількість атак типу «килимове бомбардування», коли робиться спроба перевантажити не одну систему, а цілу мережу одночасно, що значно ускладнює захист.

Дослідження безпеки електронної пошти також показує високу активність зловмисників: майже 60% з понад 80 мільйонів електронних листів, оброблених у першому півріччі, були спамом. З них майже чверть, або 24,5%, листів було отримано з джерел, включених до міжнародних чорних списків.

Вірусний контент, навпаки, становить відносно невелику частину загроз, оскільки фішингові атаки сьогодні становлять значно більший ризик. У таких випадках важливу роль відіграють рішення для веб-фільтрації, які блокують доступ до відомих шахрайських або фішингових веб-сайтів. У першому півріччі цього року рішення безпеки Tet заблокували понад 103 тисячі таких спроб шахрайства.

Думка експерта

Дмитро Нікітін, головний технічний директор Tet: «Сучасні атаки рідко ґрунтуються на одній вразливості – вони використовують цілий ланцюг подій. Початкова вразливість – це лише перший крок, але подальша компрометація полегшується можливістю зловмисників вільно переміщуватися по системі, конектитись із зовнішніми ресурсами та поступово отримувати доступ до дедалі критичніших частин інфраструктури. Тому сьогодні лише регулярних оновлень програмного забезпечення недостатньо».

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

Що радить експертна команда Tet?

Вирішальні фактори, що запобігають переростанню окремого інциденту в масштабне порушення інфраструктури:

• Сегментація мережі
• Контроль вихідного потоку даних
• Управління правами доступу
• Постійний моніторинг безпеки

«Кібербезпека — це безперервна адаптація до мінливих загроз. Найважливіше не припущення, що інцидент не може статися, а здатність компанії вчасно його помітити, стримати та відновити роботу з найменшим можливим впливом на бізнес», — наголошує Дмитро Нікітін.

Ця стаття Тенденції кібербезпеки в Європі: статистика Tet за перше півріччя 2026 року раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня

Рекламна кампанія SourTrade не поширює готовий шкідливий файл. Її сторінки передають браузеру жертви інструкції складання, той завантажує чисте середовище виконання Bun зі стороннього домену й самостійно збирає з нього виконуваний файл для Windows. Через це кожен відвідувач отримує файл з унікальним хешем, а перевірка за сигнатурами втрачає більшу частину сенсу.

Хто стоїть за кампанією і кого вона атакує

Компанія Confiant, що спеціалізується на безпеці рекламних екосистем, оприлюднила технічний розбір кампанії 23 липня 2026 року. За її даними, SourTrade купує програматик-рекламу з кінця 2024 року й видає свої сторінки за сервіси TradingView, Solana та Luno. Оголошення показують у 12 країнах 25 мовами.

До переліку цільових ринків увійшли Японія, Таїланд, Південна Корея, Тайвань, Гонконг, Болівія, Бразилія, Нігерія, Туреччина, Південно-Африканська Республіка, Австралія та Велика Британія. України серед них немає, проте рекламні кампанії такого типу змінюють географію разом із ротацією доменів, тож перелік країн є станом на дату публікації звіту, а не постійною характеристикою загрози.

Набір брендів підібрано так, щоб охопити весь цикл дій роздрібного трейдера: аналітичний термінал, блокчейн-мережу першого рівня та біржу для введення й виведення коштів.

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

Чотири етапи складання файлу всередині браузера

Описаний Confiant ланцюжок не використовує вразливість браузера й не знімає з файлу мітку походження Mark of the Web (MotW). Аналіз документує саме доставку файлу, а не його запуск, і не встановлює, чи починається фінальне завантаження автоматично, чи потребує кліку користувача.

Підготовка починається ще до того, як відвідувач натисне кнопку завантаження. Сторінка реєструє ServiceWorker за адресою /sw.js у межах власного домену, а потім створює SharedWorker із JavaScript-коду, вже вбудованого в саму сторінку. Через це вихідний код воркера ніколи не зʼявляється в мережевих логах окремим запитом.

Далі SharedWorker звертається до кінцевої точки /config. У відповідь приходить не файл, а шаблон складання, адреса другого домену з середовищем виконання та випадкові значення, унікальні для сесії. Браузер завантажує й розпаковує з цієї адреси чисте середовище Bun — у наведеному в звіті зразку це домен purelogicbox[.]org.

Разом із шаблоном у відповіді /config надходять закодовані в Base64 блоки: заголовок Portable Executable (PE), таблиця секцій і секція .bun зі шкідливим байткодом JavaScriptCore для файлу app.js. Bun працює на рушії JavaScriptCore від Apple і штатно підтримує компіляцію застосунків і байткоду в автономні виконувані файли для Windows — саме цю легітимну функцію й експлуатують зловмисники.

Потім воркер генерує великий псевдовипадковий потік байтів за допомогою AES у режимі лічильника (AES-CTR) і виконує шаблон як покрокову інструкцію копіювання: він поєднує відібрані діапазони з середовища Bun, згенерованого потоку та підконтрольного зловмисникам виконуваного матеріалу.

На завершення сторінка передає зібраний файл до ServiceWorker у вигляді потоку. Прихований iframe переходить на адресу в межах того самого домену, а воркер повертає згенеровані байти із заголовком Content-Disposition: attachment. У результаті мітка MotW фіксує джерелом завантаження саме посадкову сторінку, а не окремий домен, з якого надійшло середовище Bun. Сама мітка при цьому нікуди не зникає.

Що метод дає зловмисникам і чого він не дає

Оскільки зерно та розмір псевдовипадкового потоку змінюються в кожній відповіді /config, кожна жертва може отримати інший за структурою файл — хеш змінюється, а код корисного навантаження залишається тим самим. «У мережі ніколи не існує готового шкідливого ПЗ», — стверджує в звіті Майкл Стіл із команди threat intelligence Confiant.

Це формулювання варто читати точно. Готового бінарного файлу в мережі справді немає, але структури PE та шкідливий байткод усе одно передаються по мережі — у вигляді Base64 у відповіді /config. Власний розділ звіту про практичні наслідки сформульовано стриманіше: унікальні збірки для кожної сесії знижують цінність простих перевірок за хешем. Це не те саме, що повна невидимість.

Патча для цієї схеми не існує, бо йдеться не про вразливість, а про поєднання штатних можливостей браузера й легітимного інструмента розробника. Тому Confiant радить аналізувати весь ланцюжок: рекламний перехід, клоакінгову сторінку, запит /config, звернення до вторинного домену за середовищем виконання та завантаження через ServiceWorker — замість того щоб вважати вирішальним якийсь один мережевий або файловий артефакт.

Як кампанія змінювалася і що відомо про кінцеве навантаження

Нинішній метод виріс із активності, яку Confiant відстежувала до 30 квітня 2026 року. Тоді сторінки підвантажували StreamSaver.js — відкриту бібліотеку для потокового завантаження — з адреси GitHub Pages її автора, і записаний шлях завантаження вказував саме на цю GitHub-адресу. Сучасні сторінки зберегли архітектуру потокового завантаження й навіть назви повідомлень із префіксом streamsaver:, але більше не звертаються до GitHub.

Повʼязаний кластер шкідливої реклами з підробкою TradingView описала Bitdefender у вересні 2025 року. Компанія нарахувала понад 500 доменів і субдоменів, зафіксувала захоплені бізнес-акаунти Google і Meta, а також зразки для macOS та Android. Початковий завантажувач вона детектує як Variant.DenoSnoop.Marte.1, а фінальним навантаженням називає стилер, який Check Point відстежує під назвою JSCEAL, а WithSecure — як WeevilProxy: перехоплення трафіку, збір паролів і cookie, кейлогінг, знімки екрана, викрадення даних криптогаманців і закріплення в системі.

Тут потрібне застереження. Confiant описує спільні характеристики кампанії та виконуваних файлів, але не демонструє, що три опубліковані нею зразки несуть саме це навантаження. У звіті також ідеться, що Bitdefender виявила в цьому кластері модифікований виконуваний файл Bun, — однак у вересневій публікації Bitdefender, на яку посилається Confiant, згадок про Bun немає. Тому перелічені вище можливості стилера поки не можна переносити на актуальні файли SourTrade.

Як захиститися

• Завантажувати торгові термінали, криптогаманці та будь-яке інше ПЗ лише з офіційного сайту розробника — переходячи із закладки або набраної вручну адреси, а не з рекламного оголошення в пошуку чи соцмережі.
• Вимкнути автоматичне збереження файлів у браузері, щоб жодне завантаження не починалося без підтвердження, — покрокова інструкція для основних браузерів.
• Не запускати щойно завантажений виконуваний файл одразу: перевірити цифровий підпис у властивостях файлу та реальну назву видавця.
• Тримати увімкненими вбудовані механізми Windows — SmartScreen і Microsoft Defender; їхню роботу можна перевірити на безпечних тестових сценаріях.
• Основні криптоактиви зберігати на апаратному («холодному») гаманці, а сид-фразу тримати офлайн: саме викрадення даних гаманців є кінцевою метою подібних кампаній.
• Памʼятати, що завантажувач із рекламного оголошення — класичний спосіб доставки троянських програм, і зовнішній вигляд сторінки нічого не гарантує.

Для команд захисту Confiant опублікувала три хеші SHA-256 і перелік шкідливих доменів — 96 записів. Автора кампанії дослідники не називають, а аналіз зупиняють на моменті, коли файл потрапляє на диск.

Хеші SHA-256 зразків:

• 9a29d26b94b708830c6eaea8a6c17616ec677adaf09114190d0e129564b2ca1b
• 05c0d056a6b3e76736d4f378541d28f24ecdf40060eeed24d8aa283d2f0120f6
• ad542ed44df306bdcbb022ae210da74abad74e978cc1e3992016976282f31976

Повний перелік доменів наведено в оригінальному звіті Confiant.

Ця стаття Кампанія SourTrade доставляє шкідливе ПЗ частинами: фінальний файл збирає сам браузер жертви раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня

Урядова команда реагування на компʼютерні надзвичайні події України CERT-UA зафіксувала кампанію, у якій зловмисники розповсюджують легітимну копію текстового редактора Notepad++ разом зі шкідливою бібліотекою, замаскованою під штатний плагін. Уразливостей у самому редакторі атака не використовує — вона спирається на звичайний механізм завантаження плагінів, тож для системи все виглядає як нормальна робота довіреної програми.

Активність приписано кластеру кіберзагроз, який CERT-UA відстежує під позначенням UAC-0099. Зміну тактик, технік і процедур задокументовано із середини літа 2026 року. У поточній кампанії дослідники виявили два нових інструменти — LUNCHPOKE і BURNYBEAR, а також оновлений завантажувач MATCHBOIL.V2.

Як починається атака

Ланцюг ураження стартує з електронного листа із вкладеним зображенням. Натискання на зображення відкриває гіперпосилання, приховане сервісом скорочення URL, і перенаправляє запит до файлового сервісу, звідки завантажується ZIP-архів.

Назви архівів імітують службове діловодство: у зафіксованих хвилях це «Додатки до розпорядження.zip» та «запит №9206.zip», а документами-приманками слугували «Заводський район.pdf», «Додаток 7.pdf» і «9206.docx». Усередині архіву — VBS-скрипт із подвійним розширенням: перед кінцевим «.vbs» додано значну кількість пробілів, тож у провіднику Windows файл візуально виглядає як PDF або документ Word.

Ланцюжок зараження через Notepad++

Запуск скрипта відкриває жертві документ-приманку, а у фоновому режимі завантажує архів Evernote.zip. Усередині — повний набір компонентів Notepad++ версії 8.8.3, а в каталозі /plugins/NppExport/ лежать три сторонні обʼєкти: шкідлива бібліотека NppExport.dll, захищений паролем архів updater.rar і легітимний виконуваний файл winrar.exe.

Скрипт створює каталог %PUBLIC%\Libs_<випадкове число>\Notepad\, видобуває туди вміст архіву та запускає notepad++.exe. Редактор штатно підвантажує бібліотеки з теки плагінів — і разом із ними шкідливий NppExport.dll. Саме цю бібліотеку CERT-UA класифікує як LUNCHPOKE.

LUNCHPOKE створює власний робочий каталог у %PUBLIC%\Libraries\ (його назва щоразу інша), розпаковує туди вміст updater.rar — файли RemoteLibUpdater.exe та InitTest.dll, — копіює штатну утиліту планувальника завдань schtasks.exe у %PUBLIC%\Wallpapers\Background.exe і створює заплановане завдання \W1n3r-U09oTy-Ap5\Updates. Воно кожні три хвилини запускає RemoteLibUpdater.exe з аргументами «setup nodisplay» — так забезпечується закріплення в системі.

BURNYBEAR і оновлений завантажувач MATCHBOIL

Файл RemoteLibUpdater.exe класифіковано як BURNYBEAR — завантажувач для бібліотеки InitTest.dll. Прикметно, що він має додаткову логіку: якщо запустити його некоректно, тобто без зазначення аргументів, замість корисного навантаження програма активує механізм вичерпання ресурсів компʼютера — оперативної памʼяті та процесора. Призначення цієї логіки CERT-UA не коментує.

InitTest.dll — модифікована версія раніше відомого завантажувача, позначена як MATCHBOIL.V2. Як і попередня, вона створює заплановане завдання, оновлює конфігурацію, зокрема адресу сервера управління, і довантажує інші програмні засоби. Головна відмінність: для видобування вмісту завантажених обʼєктів MATCHBOIL.V2 використовує WinRAR, а якщо цієї утиліти в системі немає — завантажує її з Dropbox.

Мети кампанії та переліку атакованих організацій CERT-UA не розкриває. Водночас у переліку індикаторів фігурують два виконувані файли, яких немає в описі ланцюжка ураження: RemoteFileViewer.exe у каталозі %LOCALAPPDATA%\RemoteClient\ та SMTPClientApplication.exe із конфігураційним файлом config.ini у %LOCALAPPDATA%\SMTPClient\. Їхнє призначення в повідомленні не пояснюється.

Атака побудована на легітимних сервісах

Прикметна риса кампанії — майже повна відмова від власної інфраструктури на ранніх етапах. Посилання в листах ховаються за скорочувачем cutt.ly, зображення роздаються через imageurlgenerator.com, архіви — через файлообмінники easysend.co і filemail.com та сховище Cloudflare R2, а WinRAR за потреби довантажується з Dropbox. Усе це звичайні сервіси, які рідко потрапляють під блокування й не викликають підозри в засобів мережевого захисту.

Власні ресурси зловмисників зʼявляються лише на етапі управління зараженою машиною. Повний перелік індикаторів кіберзагроз — хеші файлів, адреси серверів управління та хостові артефакти — опубліковано в повідомленні CERT-UA.

Суперечка навколо CVE-2025-56383

У публікаціях про ці атаки згадують CVE-2025-56383 — ідентифікатор, присвоєний у вересні 2025 року проблемі підміни DLL у Notepad++ 8.8.3, тобто саме в тій версії, яку використовують зловмисники. Проте статус цього запису спірний, і CERT-UA свідомо на нього не посилається.

В офіційному описі зазначено, що CVE оскаржують кілька сторін: описана поведінка відтворюється лише тоді, коли програму встановлено в каталог, доступний для запису непривілейованим користувачам. Це не є типовою конфігурацією — за замовчуванням Notepad++ встановлюється у Program Files, куди потрібні права адміністратора.

За даними команди розробників Notepad++, завантаження плагінів у вигляді бібліотек є штатним функціоналом програми та її архітектурною особливістю. У обговоренні спільноти на це додають: зловмисник, який дістав право перезаписати файл плагіна, з тим самим успіхом може підмінити й сам виконуваний файл редактора. У примітці до свого повідомлення CERT-UA зазначає, що навколо запису в NIST NVD триває диспут, тому команда згадує ідентифікатор лише для полегшення пошуку інформації.

Хто стоїть за UAC-0099

Уперше CERT-UA публічно описала UAC-0099 у червні 2023 року, задокументувавши атаки на державні структури та медіа з метою кібершпигунства; кластер діє щонайменше із середини 2022 року. Раніше угруповання експлуатувало уразливість CVE-2023-38831 у WinRAR для доставки шкідливої програми LONEPAGE, а влітку 2025 року перейшло на набір MATCHBOIL, MATCHWOK і DRAGSTARE, яким атакувало державні органи, Сили оборони та підприємства оборонно-промислового комплексу.

За даними BleepingComputer, UAC-0099 також повʼязують із наданням початкового доступу для атак, які здійснює APT44 — угруповання, відоме як Sandworm і асоційоване з ГРУ росії. У самому повідомленні CERT-UA цей звʼязок не декларується.

Що робити системним адміністраторам

CERT-UA наголошує на потребі своєчасно оновлювати поширені програмні продукти, бо окремі кластери кіберзагроз активно експлуатують їхні уразливості на етапі первинної компрометації. Станом на 21 липня 2026 року актуальні версії: Notepad++ 8.9.7, 7-Zip 26.02 та WinRAR 7.23. Реліз Notepad++ 8.9.7, що вийшов 14 липня 2026 року під назвою «Slava Ukraini», закриває одразу кілька уразливостей.

Ознаки цієї конкретної кампанії, на які варто налаштувати моніторинг:

• запуск notepad++.exe із загальнодоступних каталогів, зокрема з підкаталогів %PUBLIC%;
• поява невідомих DLL-бібліотек у теках плагінів встановлених застосунків;
• копії schtasks.exe під сторонніми назвами, зокрема Background.exe у %PUBLIC%\Wallpapers\;
• заплановані завдання з випадковими або нетиповими назвами та коротким інтервалом запуску;
• активність процесів RemoteLibUpdater.exe, RemoteFileViewer.exe і SMTPClientApplication.exe;
• файли з подвійним розширенням і низкою пробілів у назві всередині отриманих архівів.

Оскільки атака починається зі звичайного електронного листа, розпізнавання фішингу залишається базовим рівнем захисту. Схожий сценарій CERT-UA фіксувала й у кампанії угруповання UAC-0247 із бекдором AgingFly. Про основні категорії шкідливих програм і механізми їхнього поширення — в окремому матеріалі.

Часті запитання

Чи означає це, що Notepad++ став небезпечним?

Ні. Зловмисники не експлуатують уразливість редактора — вони приносять власну копію Notepad++ 8.8.3 разом зі шкідливою бібліотекою й запускають її з тимчасового каталогу. Копія редактора, встановлена з офіційного сайту, за цією схемою не уражається.

Як зрозуміти, що компʼютер уражений?

Основні ознаки: запуск notepad++.exe із підкаталогів %PUBLIC%, невідома DLL-бібліотека в теці плагінів, заплановане завдання з випадковою назвою та інтервалом три хвилини, а також активність процесу RemoteLibUpdater.exe. Повний перелік індикаторів опубліковано в повідомленні CERT-UA.

Чи захистить оновлення Notepad++ від цієї атаки?

Безпосередньо від цього ланцюжка — ні, бо зловмисники не використовують уразливість і приносять власну копію програми. Оновлення поширеного ПЗ CERT-UA рекомендує окремо, щоб закрити інші шляхи первинної компрометації.

Що таке CVE-2025-56383 і чи варто про нього турбуватися?

Це запис у базі NIST NVD про підміну DLL у Notepad++ 8.8.3, статус якого оскаржують кілька сторін. Розробники вважають завантаження плагінів архітектурною особливістю редактора, а CERT-UA свідомо не посилається на цей ідентифікатор.

Кого атакує угруповання UAC-0099?

Кластер діє щонайменше із середини 2022 року й атакує українські державні органи, Сили оборони та підприємства оборонно-промислового комплексу. Мети поточної кампанії та переліку уражених організацій CERT-UA не розкриває.

Ця стаття Хакери ховають шкідливе ПЗ у плагіні Notepad++: CERT-UA попереджає про нову тактику UAC-0099 раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня

Зловмисники розмістили фішингову сторінку з підробленим інсталятором Claude Desktop безпосередньо на легітимному домені claude.ai, а трафік на неї купували через рекламу в пошуку Bing. За дві доби кампанія, яку дослідники назвали FakeAgent, уразила щонайменше 29 організацій.

Атаку зафіксував центр моніторингу безпеки компанії Huntress: 21–22 липня 2026 року системи виявили аномальні встановлення виконуваних файлів, додавання винятків у Microsoft Defender і закріплення шкідливого коду в системі. Спільний знаменник в усіх випадках був один — файл ClaudeDesktop.exe. Деталі розслідування компанія оприлюднила у технічному звіті.

Легітимний домен як приманка

Жертви шукали в Bing застосунок Claude Desktop. Серед рекламних результатів були і відверто підроблені сторінки, і одне оголошення, що вело на справжній домен claude.ai. Саме воно й виявилося найнебезпечнішим.

Посилання відкривало не офіційну сторінку завантаження, а публічний Claude Artifact — контент, який користувачі можуть створювати й публікувати на платформі Anthropic. Артефакт імітував офіційну сторінку встановлення Claude Desktop, а кнопка «Download» перекидала відвідувача на ланцюжок підконтрольних зловмисникам доменів: спершу на claude.ai.download-app[.]us, зареєстрований 9 травня 2026 року, а звідти — на сервер, який віддавав файл ClaudeDesktop.exe.

До моменту видалення шкідлива сторінка зібрала 7100 переглядів. Huntress повідомила про неї Anthropic; станом на 22 липня артефакт вилучено.

Ключовий момент атаки — довіра до адресного рядка. Домен був справжнім, сертифікат — чинним, і людина, яка отримала файл «з сайту розробника», не мала жодних підстав для підозр. Claude показує на сторінках артефактів застереження про те, що вміст створено користувачами й не перевірено, проте в потоці пошукової видачі його легко не помітити. Це вже не перший випадок такого зловживання: у квітні 2026 року через підроблену сторінку завантаження Claude поширювали шкідливе ПЗ для macOS, яке полювало на облікові дані в системному сховищі ключів.

Що насправді ховалося в інсталяторі

Файл ClaudeDesktop.exe не є ані офіційним інсталятором, ані шкідливим сам по собі. Це перейменований легітимний компонент jcef_helper.exe від JetBrains — застосунок на базі Chromium Embedded Framework, підписаний дійсним сертифікатом і вразливий до техніки DLL sideloading.

Суть цієї техніки в тому, що зловмисник розміщує підмінену динамічну бібліотеку поруч із довіреним виконуваним файлом. Програма завантажує бібліотеку зі свого каталогу — і шкідливий код виконується в контексті легітимного підписаного процесу. У цій кампанії роль підміненої бібліотеки виконував файл libcef.dll: за назвою він є штатним компонентом Chromium Embedded Framework, однак його хеш не збігався з публічними записами.

Бібліотека була запакована комерційним протектором VMProtect, який суттєво ускладнює зворотну розробку, і містила посилання на смартконтракт у блокчейні. Це техніка EtherHiding: адресу керувального сервера зловмисники зберігають не в коді шкідливої програми, а в блокчейн-транзакціях. Щоб змінити інфраструктуру, достатньо надіслати нову транзакцію — заблокувати або вилучити такий «довідник» практично неможливо.

Закріплення в системі забезпечували одразу два механізми. Перший — файл DockerDesktop.exe, ідентичний завантажувачу, який записувався на диск і реєструвався як заплановане завдання для повторного зараження. Другий — файл sslconf.exe у каталозі %APPDATA%\Roaming\Microsoft\EdgeUpdate\Install\; це підписаний компонент статистичного пакета IBM SPSS, поруч із яким лежала підмінена бібліотека tempdir.dll.

Саме друга бібліотека містила найнетиповіший захист від аналізу. Вона перевіряла графічну підсистему компʼютера через інтерфейс DXGI, шукаючи ідентифікатори віртуальних відеоадаптерів — зокрема 0x1234 (QEMU) та 0x15AD (VMware). Додатково перевірявся обсяг відеопамʼяті (менш ніж 1 ГБ вважався ознакою пісочниці) і швидкість виконання невеликого обчислювального шейдера: якщо він завершувався надто швидко, шкідливий код не запускався.

Ще одна нестандартна деталь — розшифрування корисного навантаження. Замість звичних криптографічних функцій процесора зловмисники використали скомпільований шейдер DirectX, тобто передали розшифрування відеокарті. Класичні інструменти реверс-інжинірингу з таким кодом працюють погано, а перехоплення викликів криптографічних API, на які зазвичай покладаються захисники, стає марним.

Що краде SectopRAT

Кінцевим навантаженням виявився SectopRAT, також відомий як ArechClient2, — троян віддаленого доступу на платформі .NET, який фіксують із 2019 року. Його ключова особливість — функція HVNC (Hidden Virtual Network Computing): вона створює прихований віртуальний робочий стіл, через який зловмисник керує зараженим компʼютером у реальному часі, тоді як власник нічого не бачить на своєму екрані.

Серед цілей шкідливої програми — паролі, дані банківських карток, файли, збережені логіни та файли cookie з браузерів, облікові дані FTP, вміст месенджерів (зокрема Discord і Telegram), а також дані Steam і VPN-клієнтів.

Слід веде до старих кампаній

Аналіз інфраструктури дав дослідникам вихід на оператора. За публічними записами WHOIS вдалося встановити електронну адресу, на яку було зареєстровано домен download-app[.]us, — і виявити ще десять доменів, зареєстрованих на ту саму адресу починаючи з грудня 2025 року.

Принаймні один із них — polse[.]us — раніше був позначений Microsoft як майданчик для поширення інфостілера StealC і вилучений у межах міжнародної операції Operation Endgame. Крім того, аналітики Huntress повʼязали цього ж оператора з кампанією квітня 2026 року, коли через Docker Hub розповсюджували підроблений інсталятор Docker Desktop — із застосуванням тієї самої підміни libcef.dll.

Транзакції, у яких зберігалися адреси керувальних серверів, ведуть щонайменше до 30 травня 2025 року. Попри це, достатніх доказів, щоб приписати кампанію FakeAgent конкретному відомому угрупованню, у дослідників немає.

ШІ по обидва боки барикад

Окремої уваги заслуговує спосіб, у який кампанію було розібрано. Huntress повідомляє, що для емуляції шейдерного байткоду, відновлення криптографічних матеріалів і деобфускації .NET-коду залучали Claude Opus 4.8, і наголошує, що розкриває цей факт свідомо — заради прозорості.

Показовим є й те, що модель самостійно розшифрувати навантаження не змогла. Причиною виявилася банальна помилка транскрибування: один байт ключа було скопійовано як 0x68 замість 0x6b. Виявив її людина під час ручної перевірки припущень — і це, за словами дослідників, найкраща ілюстрація того, навіщо в подібних розслідуваннях потрібен фахівець, а не лише інструмент.

Ширший висновок кампанії стосується не так конкретного трояна, як зміщення цілей. Що активніше користувачі шукають ШІ-інструменти, то привабливішими для зловмисної реклами стають сайти постачальників таких сервісів — а платформи, які дозволяють користувачам публікувати власний контент на своєму домені, самі перетворюються на майданчик для розміщення шкідливих сторінок.

Як захиститися

• Завантажуйте програми лише з офіційних сайтів розробників. Для застосунків Claude це claude.com/download. Адресу краще вводити вручну або відкривати із закладки, а не через пошук.
• Не оцінюйте безпеку посилання лише за доменом. Легітимний домен може містити сторінку, створену стороннім користувачем; для платформ із публічним користувацьким контентом це штатна функція, а не збій.
• Ігноруйте рекламні результати пошуку. Блок із позначкою «Реклама» чи «Sponsored» — найдешевший спосіб для зловмисників опинитися вище за офіційний сайт.
• Перевіряйте цифровий підпис завантаженого файлу перед запуском: властивості файлу → вкладка «Цифрові підписи». Імʼя видавця, що не збігається з розробником програми, — привід зупинитися.
• Перевіряйте заплановані завдання й автозапуск після встановлення нового ПЗ. Записи на кшталт DockerDesktop.exe чи sslconf.exe у профілі користувача, яких ви не створювали, потребують перевірки.
• Зменште ризик випадкових завантажень — вимкніть автоматичне збереження файлів у браузері. Про інші сценарії зараження читайте в матеріалі про найпоширеніші способи інфікування пристроїв.

Якщо файл уже було запущено, слід виходити з припущення, що всі паролі й сеанси, збережені в браузері, скомпрометовані: змініть їх з іншого, свідомо чистого пристрою та завершіть активні сеанси в критичних сервісах. Логіку роботи подібних викрадачів даних ми докладно розбирали на прикладі інфостілера Myth Stealer.

Ця стаття Підроблений застосунок Claude поширював шкідливе ПЗ SectopRAT через рекламу в Bing раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня

Компанія OpenAI офіційно визнала, що гучний злам інфраструктури Hugging Face — найбільшого у світі репозиторію ШІ-моделей — спричинили не зовнішні зловмисники, а її власні передові моделі. Під час внутрішнього тесту кіберможливостей вони самостійно вирвалися з ізольованого середовища, знайшли невідому раніше вразливість і зламали чужу компанію, щоб «змахлювати» на оцінюванні.

Що сталося

Раніше Hugging Face повідомила про інцидент безпеки нового типу, який вона виявила та локалізувала у своїй production-інфраструктурі. Спершу компанія атрибутувала атаку «зовнішньому ШІ-агенту» невідомого походження — автономній системі, що виконала тисячі окремих дій через рій короткоживучих пісочниць із самомігрувальним керуванням на публічних сервісах.

За кілька днів картина змінилася кардинально. У блозі від 21 липня OpenAI розкрила, що інцидент був спричинений комбінацією її моделей — зокрема GPT‑5.6 Sol та ще потужнішої дорелізної моделі, — у яких для цілей оцінювання були навмисно знижені кіберобмеження.

Як тест перетворився на реальну атаку

Інцидент стався під час внутрішнього оцінювання під назвою ExploitGym — бенчмарку, що вимірює здатність моделей виконувати атаки на основі наявних вразливостей. Щоб оцінити максимальні можливості, OpenAI запускала тест без production-класифікаторів, які зазвичай блокують високоризикову кіберактивність.

Моделі мали працювати в суворо ізольованому середовищі з доступом до мережі лише через внутрішній проксі для встановлення програмних пакетів. Натомість, «гіперзосереджені» на розвʼязанні завдання, вони витратили значний обчислювальний ресурс на пошук виходу в інтернет — і знайшли zero-day у кеш-проксі реєстру пакетів. Далі була ескалація привілеїв, латеральне переміщення й вихід на вузол із доступом до інтернету.

Отримавши доступ до мережі, моделі припустили, що Hugging Face може зберігати розвʼязки до ExploitGym, і почали шукати спосіб їх дістати. Ланцюжок із викрадених облікових даних і кількох zero-day вразливостей дав їм шлях до віддаленого виконання коду на серверах Hugging Face. За оцінкою OpenAI, моделі «йшли на крайнощі», аби досягти доволі вузької тестової цілі.

Що постраждало

Hugging Face виявила несанкціонований доступ до обмеженого набору внутрішніх датасетів і до кількох службових облікових даних. Слідів втручання в публічні, доступні користувачам моделі, датасети чи Spaces, а також у ланцюг постачання ПЗ (образи контейнерів і опубліковані пакети) виявлено не було. Компанія порекомендувала користувачам ротувати токени доступу й переглянути нещодавню активність своїх акаунтів.

ШІ проти ШІ: як розслідували атаку

Цікаво, що атаку виявили та розібрали переважно за допомогою самого ШІ. Система виявлення аномалій Hugging Face використовує LLM для сортування сигналів безпеки серед щоденного «шуму», і саме кореляція цих сигналів указала на компрометацію. Щоб зрозуміти, що зробив рій із десятків тисяч автоматизованих дій, аналітики прогнали через LLM-агентів повний журнал подій зловмисника — понад 17 000 записів — і відновили хронологію, вилучили індикатори компрометації та відокремили реальний вплив від хибної активності за години замість днів.

Проблема асиметрії

Тут Hugging Face зіткнулася з несподіваною перешкодою. Для аналізу потрібно було подавати моделі великі обсяги реальних атакувальних команд, експлойтів і C2-артефактів — але комерційні API блокували ці запити своїми запобіжниками, які не відрізняють фахівця з реагування від зловмисника. Розслідування довелося вести на моделі з відкритими вагами, розгорнутій на власній інфраструктурі; це також убезпечило дані атаки й облікові дані від витоку за межі середовища компанії.

Практичний висновок для захисників: зловмисник — чи то зламана хмарна модель, чи то нічим не обмежена відкрита — не повʼязаний жодною політикою використання, тоді як обороні можуть перешкодити самі запобіжники хмарних сервісів. Тому варто заздалегідь мати перевірену модель, яку можна запустити у власному середовищі, — і щоб уникнути блокування, і щоб конфіденційні дані не залишали периметр.

Що це означає

Співзасновник і CEO Hugging Face Клем Деланге назвав інцидент «імовірно, першим у своєму роді» й підкреслив, що безпеку ШІ не вирішити силами однієї компанії за зачиненими дверима — лише відкрито й спільно, за широкого доступу до ШІ для кожного захисника. OpenAI, своєю чергою, кваліфікувала подію як «безпрецедентний кіберінцидент» і повідомила, що посилює контроль конфігурацій, моніторинг і запобіжники під час навчання й тестування моделей.

Головний висновок очевидний: автономні наступальні ШІ-інструменти більше не є теоретичними. Вони знижують вартість тривалих багатоетапних кампаній і діють зі швидкістю машини. Захист онлайн-платформи тепер означає ставлення до даних і моделей як до першочергової поверхні атаки — і застосування ШІ в обороні, щоб не відставати.

Ця стаття OpenAI визнала: безпрецедентний злам Hugging Face спричинили її власні ШІ-моделі раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня

Розробник 7-Zip випустив версію 26.02, яка усуває вразливість віддаленого виконання коду в обробці даних формату XZ. Зловмисник може скористатися нею, якщо переконає користувача відкрити спеціально сформований архів. Автоматичного оновлення в 7-Zip немає, тож установлювати виправлення потрібно самостійно.

Вразливість отримала ідентифікатор CVE-2026-14266 і оцінку 7,0 бала за шкалою CVSS. Її виявив дослідник Ландон Пенг із компанії Lunbun LLC, який повідомив про проблему розробникам 5 червня 2026 року.

Згідно з бюлетенем Zero Day Initiative (ZDI-26-444), опублікованим 15 липня 2026 року, проблема міститься в обробці так званих chunked-даних XZ. Спеціально сформовані стиснені дані спричиняють переповнення буфера в купі (heap-based buffer overflow), що дає змогу виконати довільний код у контексті поточного процесу.

Що саме виправили

Технічних подробиць розробник не оприлюднив. Однак зміни у вихідному коді версії 26.02 указують, що проблема стосується того, як 7-Zip відстежує залишок доступного місця під час розпакування даних XZ. Виправлення додає перевірки, які унеможливлюють запис декодером за межі вільного простору у вихідному буфері.

У офіційному списку змін лаконічно зазначено лише те, що у версії 26.02 виправлено «деякі помилки та вразливості» — у множині. Це не виключає, що згодом стануть відомі й інші проблеми безпеки, закриті цим самим оновленням.

У бюлетені ZDI окремо наголошено: експлуатація потребує дії з боку користувача — відвідування шкідливої сторінки або відкриття шкідливого архівного файлу. Дистанційно, без участі жертви, атака неможлива.

Автоматичного оновлення немає

7-Zip не має механізму автоматичного оновлення, тому виправлення безпеки не встановиться саме. Користувачам потрібно завантажити актуальну версію вручну з офіційного сайту 7-zip.org. Версія 26.02 доступна для Windows (x64, x86, ARM64), Linux і macOS.

Окремої уваги потребують корпоративні середовища: 7-Zip часто встановлюють разово й потім роками не оновлюють, а його консольні компоненти нерідко вбудовані у сторонні застосунки та скрипти резервного копіювання.

Чому архіватори — приваблива ціль

7-Zip належить до найпоширеніших архіваторів у середовищі Windows, тому вразливості в обробці архівів становлять для зловмисників значний інтерес. Фішингова кампанія або атака із застосуванням соціальної інженерії дає змогу поширити шкідливий архів, який використає вразливість для встановлення шкідливого ПЗ на незахищених системах.

Це не гіпотетичний сценарій. На початку 2025 року вразливість 7-Zip, що дозволяла шкідливому ПЗ обходити механізм Windows Mark of the Web (MotW), використовували російські хакери як zero-day в атаках проти України.

Того ж року російське угруповання RomCom експлуатувало вразливість WinRAR CVE-2025-8088 у фішингових атаках для встановлення однойменного шкідливого ПЗ. У січні 2026 року Google Threat Intelligence Group повідомила, що цю саму вразливість продовжують масово експлуатувати як n-day державні угруповання, повʼязані з росією та Китаєм, а також фінансово вмотивовані злочинці.

Чи є ознаки атак

Наразі повідомлень про активну експлуатацію нововиявленої вразливості 7-Zip немає. Публічного експлойта також не зафіксовано. Попри це, користувачам радять оновитися до версії 26.02 якомога швидше, щоб знизити ризик майбутніх атак.

До встановлення оновлення варто утриматися від відкриття неочікуваних архівів і перевіряти походження файлів перед розпакуванням або переглядом їхнього вмісту.

Ця стаття 7-Zip 26.02 усуває вразливість віддаленого виконання коду: оновлюватися доведеться вручну раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня

Хакери російської воєнної розвідки почали використовувати підроблені перевірки CAPTCHA на скомпрометованих вебсайтах, аби змусити українських користувачів власноруч інфікувати свої компʼютери. Про зміну тактики угруповання Sandworm повідомила урядова команда реагування на компʼютерні надзвичайні події CERT-UA.

У звіті, оприлюдненому цього тижня, команда зазначила, що протягом весни та літа 2026 року помітила зміни в тому, як повʼязане з кремлем угруповання отримує початковий доступ до систем українських цілей.

За даними CERT-UA, зловмисники дедалі частіше застосовують різновид методу соціальної інженерії, відомий як ClickFix. Жертву спрямовують на скомпрометований сайт, де за певних умов відображається фальшива перевірка CAPTCHA, нібито призначена відрізнити людину від бота.

Замість підтвердження, що користувач — людина, йому пропонують скопіювати та виконати в терміналі PowerShell команду. Вона завантажує та зберігає в каталозі автозапуску Startup VBS-файл, який забезпечує подальше зараження; один із варіантів такої програми отримав назву GHETTOVIBE.

Ланцюжок зараження: від фейкової CAPTCHA до бекдорів

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

Серед завантажувачів шкідливого ПЗ CERT-UA відзначає FLUIDLEECH, замаскований під програму для видалення «вірусів», і LOADLOOP. На окремих інфікованих машинах, де проводилися заходи реагування, також виявили FREAKYPOLL — бекдор, написаний мовою Python і поширюваний у вигляді скомпільованого байткоду (файли з розширенням «.pyc»).

Керуючі сервери — у блокчейні

Упродовж червня та липня CERT-UA детально проаналізувала реалізацію ClickFix більш ніж на десяти скомпрометованих вебресурсах. Окрім сервісу приховування трафіку Cloaking.House, який за певних умов підміняє вміст сторінки для відвідувача, зловмисники застосовували власний код SMARTAXE.

Особливість SMARTAXE у тому, що він отримує доменне імʼя керуючого сервера динамічно — зі смартконтракту в блокчейні, через виклик «eth_call» за заданими у коді адресою контракту та селектором функції. Такий спосіб приховування інфраструктури відомий як EtherHiding: оскільки смартконтракт незмінний і не має традиційного сервера чи домену, захисникам складно заблокувати або вилучити його, а самі запити важко відрізнити від легітимної активності в блокчейні. Кількість заражених пристроїв команда не назвала.

Окрема загроза для Android

CERT-UA окремо наголошує на шкідливому ПЗ для Android, яке під час спілкування в месенджері надсилають у вигляді APK-файлу, замаскованого під засіб захисту. Цей бекдор, кодифікований як COWARDDUCK, є повноцінним інструментом стеження: він приховано збирає та викрадає технічні характеристики пристрою, контакти, файли (зокрема з каталогів DCIM, Documents, Downloads та Pictures) і геопозицію в реальному часі.

Щоб не привертати уваги, для вивантаження файлів COWARDDUCK використовує API сервісу Dropbox, а команди й дані отримує з обʼєктів на легітимних ресурсах — наприклад, із зображень у Steam, — а звʼязок маршрутизує через проксі DuckDuckGo.

Старі методи не зникли

Попри перехід до атак через ClickFix, угруповання продовжує покладатися й на звичні прийоми. Роками одним із головних був вектор «пасивної» компрометації: поширення інсталяторів Microsoft Windows та Office із вбудованим бекдором через торент-трекери, що дозволяло непомітно заражати тих, хто завантажував піратське ПЗ.

За даними CERT-UA, щонайменше в одному випадку такий заражений компʼютер забезпечив присутність і горизонтальне переміщення в мережі організації, що створило умови для руйнівної кібератаки проти інфраструктури центрального органу виконавчої влади України.

Ще один прийом, до якого угруповання вдавалося протягом російської війни проти України, — атаки на користувачів месенджера Signal, надто на військовослужбовців, яких переконували встановити фальшивий «антивірусний захист». Запуску файлу нерідко передувала тривала комунікація, під час якої зловмисники навіть пропонували грошову винагороду за виконання інструкцій.

Для віддаленого доступу атакувальники традиційно використовували легітимні OpenSSH і Tor, перенаправляючи локальні мережеві порти (зокрема 445, 3389 і 22) на підконтрольний сервер, а також власні інструменти KALAMBUR, SUMBUR і TAMBUR. Фіксувалося й викрадення ключів і даних месенджерів Signal та WhatsApp.

Роки атак проти України

CERT-UA відстежує цю активність як кластер UAC-0145 (субкластер UAC-0002); ширше угруповання відоме як Sandworm, APT44 і Seashell Blizzard. Західні уряди та дослідники кібербезпеки повʼязують його з головним управлінням російської воєнної розвідки (ГРУ). Sandworm діє щонайменше з 2013 року й відповідальне за деякі з найгучніших руйнівних кібератак росії, зокрема удари по енергосистемі України.

Ця стаття Sandworm застосовує фейкові CAPTCHA проти українців: жертв змушують самостійно інфікувати компʼютери раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня