Інцидент із зламом «Новин Донбасу» є показовим прикладом сучасної атаки на медіа, де поєднуються класичні технічні вектори з елементами інформаційно-психологічного впливу. Навіть обмежений набір даних – повідомлення редакції, заява атакуючої сторони та один скриншот помилки – дозволяє реконструювати доволі цілісну картину подій. Звісно, якщо технічний скриншот є реальним, а не сфабрикованим.
За інформацією Детектор медіа, 18 березня було атаковано сайт «Новини Донбасу». Початковою точкою інциденту стала компрометація облікового запису адміністратора. З технічної точки зору це одразу зміщує фокус: йдеться не про «злам сервера» у класичному сенсі, а про отримання легітимного доступу через викрадені або скомпрометовані облікові дані. Такий сценарій є значно небезпечнішим, оскільки дозволяє обійти більшість периметрових засобів захисту і діяти в системі як довірений користувач.
Після отримання доступу, за інформацією від редакції та атакуючої сторони, було здійснено копіювання бази даних. Це означає, що відбулася повноцінна ексфільтрація – вивантаження контенту, інформації про авторів та, ймовірно, частини службових даних. У контексті медіа це має не лише технічний, а й безпековий вимір, оскільки такі дані можуть використовуватися для подальших атак, ідентифікації джерел або тиску на журналістів.
Окремий інтерес становить питання знищення даних. Атакуюча сторона заявляє про повне видалення інфраструктури, однак коментарі редакції вказують на часткову втрату – зокрема, проблеми з відновленням матеріалів за останній період. Це типова ситуація, коли риторика атакуючих перебільшує масштаби, але при цьому реальні технічні наслідки залишаються серйозними. Найбільш вірогідно, йдеться про логічне знищення частини бази даних – видалення таблиць або записів, а також про відсутність або пошкодження актуальних резервних копій.
Скриншот помилки з телеграм каналу хакерської групи
Саме тут ключову роль відіграє технічний скриншот із помилкою фреймворку Yii Framework. Повідомлення про відсутність таблиці lang у базі даних прямо вказує на порушення цілісності структури. Це непряме, але доволі надійне підтвердження того, що база була змінена або частково знищена. Важливо, що мова не йде про недоступність сервера – система працює, але її логічна структура порушена.
Ще більш показовим є ім’я бази даних – nddev. Така назва практично однозначно вказує на середовище розробки. Це означає, що внаслідок атаки або помилки відновлення продакшн-сайт почав працювати з dev-конфігурацією, або ж відповідні налаштування були змінені під час інциденту. У будь-якому випадку це свідчить про відсутність належної ізоляції середовищ, що є системною проблемою в багатьох організаціях.
Скриншот також розкриває частину внутрішньої інфраструктури. Зокрема, видно шлях до директорії /var/lib/jenkins/..., що прямо вказує на використання Jenkins для CI/CD. Це означає, що процеси розгортання автоматизовані, але водночас відкриває додатковий вектор аналізу: якщо атакуючі отримали доступ до адміністративного облікового запису, вони потенційно могли впливати і на процес деплою або конфігурацію застосунку.
Цікавим є і фрагмент SQL-запиту з порожнім параметром WHERE url = "". У нормальних умовах такі ситуації повинні відловлюватися на рівні валідації. Їх наявність може свідчити про те, що в умовах атаки або після неї система опинилася в неконсистентному стані, де частина логіки обробки запитів працює некоректно. Хоча це не обов’язково є причиною інциденту, але точно вказує на загальний рівень зрілості обробки помилок.
Важливим доповненням до картини є інформація про паралельну DDoS-атаку. Такий підхід добре відомий у практиці: навантаження на інфраструктуру використовується не як основний вектор, а як інструмент для ускладнення реагування. Поки команда намагається відновити доступ і аналізує інцидент, ресурси додатково виснажуються через перевантаження.
У підсумку вимальовується досить типова, але від цього не менш небезпечна схема. Компрометація облікового запису дає початковий доступ. Далі відбувається ексфільтрація даних, після чого – часткове знищення або пошкодження бази. Паралельно здійснюється тиск через DDoS і публічні заяви про «повне знищення», що має посилити ефект і деморалізувати як редакцію, так і аудиторію.
З точки зору уроків для інших медіа, цей кейс чітко демонструє зміщення центру ваги в кібербезпеці. Найслабшою ланкою виявляється не сервер як такий, а облікові записи та процеси навколо них. Відсутність багатофакторної автентифікації, недостатній контроль доступів і слабка культура роботи з обліковими даними створюють передумови для подібних інцидентів. Не менш критичною є ситуація з резервними копіями: якщо останні дані неможливо відновити, це означає, що стратегія бекапів або була відсутня, або не враховувала сценарій цілеспрямованої атаки.
Інцидент також підсвічує типову проблему DevSecOps – недостатню ізоляцію середовищ і ризики, пов’язані з CI/CD. Використання таких інструментів, як Jenkins, саме по собі не є проблемою, але без належного контролю доступу і захисту секретів воно може стати додатковою точкою входу або каналом впливу на систему.
Окремо варто звернути увагу на відображення технічних помилок у скриншоті. Скриншот демонструє повний стек і внутрішні шляхи, що є класичним прикладом information disclosure. У нормальних умовах такі дані повинні бути доступні лише в логах, а не кінцевому користувачу.
Важливо також, що від початку інциденту редакція взаємодіяла з командою CERT-UA (Computer Emergency Response Team of Ukraine), сектором з кіберзахисту управління Держспецзв’язку в Донецькій області та Службою безпеки України, а також паралельно консультувалась з Лабораторією цифрової безпеки (громадський сектор) щодо подальших дій.
Загальний висновок полягає в тому, що атака на «Новини Донбасу» не є унікальною з технічної точки зору – але вона є дуже показовою. Вона демонструє, як поєднання відносно простих векторів (компрометація акаунта) з організаційними недоліками (бекапи, ізоляція середовищ, контроль доступів) призводить до серйозних наслідків. Для медіа, особливо тих, що працюють із чутливою тематикою, це сигнал про необхідність зміщення фокусу з «захисту сайту» на захист доступів, даних і процесів.
Доповнено 21.03.2026:
Історія зі зламом сайту «Новин Донбасу» заграла новими фарбами. В Лабораторії цифрової безпеки, яка допомагає редакції «Новин Донбасу» пом’якшити наслідки нещодавньої атаки, розповіли про зраду у керівництві оборонного підрядника уряду США, продаж секретних кіберінструментів росіянам та подальше інфікування сайту «Новин Донбасу» (і не тільки його) з метою зламу мобільних пристроїв на базі iOS. Більш детально читайте в їх матеріалі «Атаки через браузер: як українців зламують за допомогою Coruna та DarkSword».
В редакції «Новин Донбасу» в свою чергу повідомили, що після хакерської атаки вони провели додаткову технічну перевірку. Шкідливий код видалений, сайт ізольований, тривають консультації з фахівцями. Триває робота над відновленням ресурсу. В процесі було з’ясовано, що сайт «Новин Донбасу» (як і низка інших українських ресурсів) міг бути використаний для поширення нового типу атаки на iPhone та iPad зі старими версіями програмного забезпечення.
Читайте також: Рекомендації для медіа з підвищення рівня кібербезпеки