Сайт зламали, але ви цього не помітили: що показав аудит безпеки

Сайт може швидко завантажуватися, дозволяти вхід користувачам і надсилати листи — та все одно бути зламаним.

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

Тому невідомий проєкт я не запускаю одразу на новому сервері. Спочатку потрібно зрозуміти, що саме ми приймаємо: код, налаштування сервера, облікові записи, залежності, завантаження, резервні копії та доступні журнали. Якщо хостинг або Google надіслали попередження, з’явилися редиректи чи ви підозрюєте шкідливий код, OROS починає технічний аудит і відновлення від €550 без ПДВ. Перші дані можна надіслати через форму контакту, телефонна розмова не потрібна.

Сайт зламали: що зробити спочатку

Не видаляйте файли навмання. Так можна стерти докази, зламати робочу функцію або прийняти заражену резервну копію за чисту.

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

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

Сайт виглядав цілком справним

Середовище містило кілька PHP-застосунків, стару версію та багато років завантажених медіафайлів. Публічні сторінки й форма входу працювали. У відкритому сховищі я знайшов cache.php, маленькі PHP-завантажувачі, змінені .htaccess і код, замаскований під зображення чи відео. Файл із розширенням .bmp містив PHP, інший приймав зашифрований запит, розкодовував його та виконував результат.

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

Одна перевірка malware пропустила найважливіше

Перша перевірка ClamAV не показала нічого. Ручний аналіз і YARA-правила для web shell знайшли шкідливі файли. Пізніше VirusTotal класифікував зашифрований завантажувач як шкідливий у 27 із 61 рушія, а файл, замаскований під bitmap, — у 12 із 60.

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

Під час PHP-аудиту я поєдную метадані й хеші файлів, аналіз патернів PHP, YARA, антивірус, пошук PHP у файлах з іншими розширеннями, перевірку .htaccess і конфігурації, огляд архівів, composer audit, npm audit та ручну оцінку найбільш небезпечних знахідок. Жоден сканер не має останнього слова.

Файлова система показала часову лінію

Перші web shell з’явилися до більшої хвилі атаки. Пізніше сотні файлів записалися в активний застосунок і збережену резервну копію. Однакові назви папок, часові мітки та структури пакетів вказували на автоматичне поширення. Тому backup не був надійним джерелом відновлення.

Нове розміщення коду не видаляє файли поза пакетом, не змінює викрадені паролі, не перевіряє базу даних і не закриває старі шляхи доступу. Чисте відновлення та ротація облікових даних — окремі етапи.

Вразлива версія — це підказка, а не доказ

Сервер працював на PHP 8.3, тому немає підстав звинувачувати застарілий PHP. У lock-файлі була Livewire 3.5.12. Офіційна рекомендація вказує, що версії до 3.6.4 у певних конфігураціях могли дозволяти виконання команд без входу (CVE-2025-54068). Це найсильніша гіпотеза першого доступу, але не доведена причина: історичних HTTP-логів уже не було.

Пізніші рекомендації для Filament і Kirby показали, чому одне оновлення не є стратегією підтримки. PHP, Laravel, Livewire, Filament, Kirby, плагіни, Composer-пакети, JavaScript-пакети та сервер мають власні цикли оновлень і підтримки.

Завантаження перетворилися на виконуваний код

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

Спочатку ми заблокували публічне сховище. Інвентаризація відокремила справжні фото, PDF і відео від PHP-розширень, вкладених .htaccess, некоректних медіафайлів і ZIP-пакетів з вікна атаки. Для довгострокового захисту безпечніше зберігати файли поза безпосередньо публічним web root, перевіряти користувача перед видачею файлу, дозволяти лише потрібні розширення, генерувати імена та встановлювати ліміти. Дані Content-Type від браузера не є доказом типу файлу. Це також відповідає рекомендаціям OWASP File Upload Cheat Sheet.

Що перевіряє аудит безпеки сайту?

Я починаю з аналізу без виконання невідомих скриптів. Залежно від сайту перевіряються:

1. Структура хостингу, домени, публічні папки, PHP, cron-завдання, акаунти та права.
2. Імена, розміри, часові мітки, власники й хеші файлів до видалення.
3. Код в ізольованому середовищі без production-даних.
4. Виконуваний код у папках завантажень, тимчасових каталогах, старих версіях і backup.
5. Реальний вміст файлів: розширення .jpg саме по собі нічого не доводить.
6. Конфігурація сервера, яка може зробити несподівані розширення виконуваними.
7. composer.lock, package-lock.json, результати composer audit і npm audit.
8. Відмінності між старою та поточною версіями і ознаки часткового очищення.
9. Чисте тестове середовище з тією самою версією PHP, що планується для production.
10. Production-конфігурація до зміни публічної папки чи способу розгортання.

Вебсервер має відкривати лише потрібну public-папку. Backup, .git, логи, вихідний код і каталоги пакетів не повинні бути доступними напряму. Документація Laravel також рекомендує спрямовувати запити до public/index.php (документація розгортання).

Дослідження, обмеження шкоди та відновлення — різні кроки

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

Скільки коштує відновлення зламаного сайту?

В OROS технічний аудит і відновлення після malware починаються від €550 без ПДВ. Після первинної оцінки я підтверджую обсяг і ціну до початку робіт. Вартість залежить від технологій, кількості застосунків і доменів, обсягу завантажень, доступів і логів, стану backup та необхідності чистої перебудови.

Стартова ціна не означає, що кожен інцидент можна вирішити за €550. Спочатку ви отримуєте чітке розділення робіт на аудит, обмеження шкоди та відновлення.

Підтримка після зараження

PHP-проєкту потрібні відповідальний за технічний стан і бюджет на підтримку. Моя базова схема включає автоматичні перевірки Composer і npm, щомісячний огляд пакетів, тестовані оновлення, контроль дат підтримки, інвентаризацію доступів, резервні копії поза public root і реальні тести відновлення. Автоматичний звіт — це вхід для обслуговування, а не автоматичний ремонт.

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

Як зрозуміти, що сайт зламали?

Можливі ознаки: дивні редиректи, невідомі сторінки в Google, попередження хостингу, нові адміністратори, змінені файли, спам із домену або блокування браузером. Зараження може бути непомітним, тому потрібна технічна перевірка.

Що зробити спочатку?

Збережіть попередження, логи та копію поточного стану до видалення файлів. Обмежте активну шкоду, а потім визначте розташування malware, спосіб виконання коду й потенційно відкриті доступи. Не відновлюйте старий backup, поки не перевірите його.

Чи можна видалити malware без повної перебудови?

Іноді так. Все залежить від якості коду, масштабу зараження та надійності backup. За серйозного або нечітко обмеженого інциденту чисте нове розгортання може бути безпечнішим.

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

Ні. Сканування — лише одна перевірка в ширшому технічному аудиті. У цій історії ClamAV пропустив файли, які ручний аналіз і додаткові правила визначили як шкідливі точки доступу.

Перевірте свій сайт

Якщо ви підозрюєте malware, хостинг заблокував сайт або потрібно безпечно прийняти PHP-проєкт, надішліть через форму контакту URL, відому технологію, симптоми та доступи, які є у вас.

Про автора

Daniel Orosz

Веброзробник і засновник

Даніел створює сайти та цифрові системи в Керкраде. Він працює з вебтехнологіями понад 16 років і пояснює складні рішення простою мовою.

Більше про Даніела →