Казино-сторінка, яку бачив лише Google, — прибрана, і п’ять входів закрито.

симптом

Антивірус хостингу позначив акаунт. У браузері магазин виглядав нормально — так само в curl, PageSpeed і моніторингу доступності. Клоак мав список User-Agent, для яких мовчав: curl, wget, python, Ahrefs, Semrush, Lighthouse, PageSpeed, GTmetrix, UptimeRobot, ChatGPT, Claude. Казино-сторінку отримував лише запит, схожий на Googlebot.

як зайшли: мапа

28 серпня скрипт перебирав відомі діри в сторонніх темах OpenCart — по одному запиту, після кожного перевіряючи, чи з’явився шел. Четверта спроба влучила в тему цього магазину: контролер «показати ще» передавав дані з POST просто в unserialize(). Двадцять чотири секунди від першого запиту до робочого шела. Через сім годин скрипт повернувся встановити файловий менеджер; увечері людина з іншої IP-адреси і справжнього браузера завантажила бекдор-панель. Клоак з’явився 1 вересня.

Той самий рядок стояв у п’яти місцях — чотири контролери теми й cookie блогу. Використали один; відкриті були всі п’ять.

Два закріплення не залежали одне від одного. Перше — блок, вставлений на початок index.php, після чого зловмисник повернув файлу стару дату зміни через touch; його видав час зміни метаданих, який без root не підробити. Друге — .user.ini, що підвантажував клоак перед кожним запитом, хоч би що було в index.php. Прибрати одне без другого означало б нічого не змінити для Googlebot.

що зроблено

1. Вхід знайдено в журналі доступу, а не вгадано: запит о 04:49:05, що створив перший шел, і точки теми, які скрипт пробував перед ним.
2. Клоак вимкнено його ж власним вимикачем і перевірено запитом від імені Googlebot — до цього заголовок казино, після — заголовок магазину.
3. Усі п’ять викликів unserialize обмежено звичайними даними, зокрема в згенерованій копії одного контролера, яку OpenCart реально виконує: виправлення лише оригіналу лишило б найнавантаженішу точку відкритою. «Показати ще» після цього перевірено — працює; payload з об’єктом перевірено — відкидається.
4. Шели й бекдор-панель перенесено в карантин разом із хешами, потім видалено. Заражений index.php очищено й порівняно з чистою копією — збіг байт у байт.
5. Увесь акаунт хостингу прочесано на маркери кампанії, prepend-файли й нещодавно змінений PHP. Нічого не лишилось.

що не знадобилось

Ні перебудови, ні нової теми, ні підписки на «плагін безпеки». Магазин увесь час працював.

що далі

Передано власнику: змінити паролі бази, FTP і адмінки — у зловмисника кілька днів був файловий менеджер, і він міг прочитати конфіг; перевірити Search Console на власника, якого ніхто не додавав, бо файл верифікації з’явився через три хвилини після клоака; заборонити виконання PHP у теках картинок і завантажень. Після цього кожен магазин, який веде агенція, перевірено на ту саму категорію дір — 22 магазини, у списку це рядок про аудит.