Contents

/wordpress-sc-backdoor-rebuilds-itself/wordpress-sc-backdoor-rebuilds-itself.png

Пълен курс по етично хакерство от нула до експерт

Хаквайте като „черни шапки“ (black hat) хакери. Тестване за проникване, Kali Linux, хакване на WiFi и уеб сайтове, както и хакерският начин на мислене зад всичко това.

Задна врата (backdoor) във WordPress беше изтрита и се върна в рамките на секунди. Изтрита отново, върна се отново. Тя живееше на поне 8 места, включително в паметта на сървъра, и разполагаше със скрит администратор, който можеше да се вписва без парола.

Това е с което се сблъска екипът по почистване на Sucuri в сайт, в който бяха извикани да отстранят проблем. Те премахваха зловредния софтуер внимателно, файл по файл, и същата задна врата продължаваше да се връща секунди след всяко премахване. Техният аналитик Gabriel Barbosa публикува пълния разбор на 30 септември. Изследователите наричат семейството SC по маркерите „SC_“, които откриват в инжектирания код.

Продължаваше да се връща, защото всяко копие може да запише останалите отново на диска. По думите на изследователите: „Изтрийте разширението (plugin) и drop-in го презаписва. Изтрийте drop-in файла и темата го презаписва.“ Изчистете файловете на диска и следващото зареждане на страница ги връща всичките от базата данни или от блок в споделената памет.

Това са местата, където я откриха на този сайт. Имената на файловете се променят от сайт на сайт, така че ето как изглеждаше тук:

Файлът .user.ini е малък файл с настройки, който PHP чете за всяка папка. Един ред в него, auto_prepend_file, кара PHP да изпълнява избран файл преди всяка PHP заявка в тази папка и папките под нея. Това включва заявки, които никога не стигат до WordPress. Избраният файл е кратък и изглежда обикновен, зареждащ модул (loader): единствената му работа е да зареди скрит файл до него, чието име започва с точка. Изтрийте само скрития файл и зареждащият модул тихомълком не прави нищо. Сайтът остава активен и изглежда наред, докато друго копие възстановява скрития файл.

db.php и advanced-cache.php са drop-in файлове, които WordPress зарежда самостоятелно много рано, преди обикновените разширения. db.php носи пълната задна врата в себе си, компресирана и кодирана. WordPress зарежда advanced-cache.php винаги когато кеширането е включено, а този файл може да възстанови задната врата от пет различни източника в определен ред. Темата получава блок от код, добавен в долната част на functions.php, който се изпълнява на почти всяка страница, и този блок върши същата работа.

Самата задна врата се намира на две места. Едното копие е задължително за използване разширение (must-use plugin), което WordPress зарежда автоматично и скришом. Другото е нормално разширение със собствена страница с настройки, така че бърз преглед го кара да изглежда като разширение за кеширане. Двете копия поддържат една и съща версия помежду си. Когато зареждащият модул запише ново копие, той казва на PHP да отхвърли старата кеширана версия, така че новият файл да се изпълни веднага.

Кодът е труден за четене. Всеки файл съдържа таблица от кодирани текстови низове и малък декодер, който превръща число в името на функцията, за която се отнася. Имената, които бихте търсили, не са във файла. SC работи без eval, PHP функцията, която изпълнява парче текст като код, а най-новите части не носят никакъв маркер.

Чистите файлове все още не са достатъчни. Изследователите откриха активни копия на задната врата на три места, които не са файлове. Пълно копие на задната врата се намира в ред от таблицата с опции на WordPress в базата данни под произволно име. На сървъри, които го поддържат, задната врата също така записва копие в споделената памет — блок от оперативната памет (RAM) на сървъра, под фиксиран номер. Това копие оцелява както след изтриване на файлове, така и след почистване на базата данни, а при споделен хостинг блокът може дори да принадлежи на друг профил.

Третото място са планираните задачи. Собственият cron на сървъра изпълнява файла със задачи на WordPress по таймер, без нито един посетител, и това връща файловете обратно по график.

Свързани SC варианти отиват стъпка по-далеч с тригер вътре в самата база данни, който създава нов администратор при вкарване на нов ред. Изтрийте профила и следващият нов ред го връща обратно.

Задната врата също така дава на атакуващия вход, който не можете да видите. Тя създава администраторски профил или превзема скрит такъв, който вече съществува, и когато нормалният маршрут е блокиран, тя записва този профил директно в таблиците с потребители. След това филтрира профила извън списъка с потребители, извън броя на потребителите и извън изгледа по роли. Вашето табло за управление показва администраторите, които познавате, а допълнителният може да не е в списъка. Тя фалшифицира валидни бисквитки за вход за този профил, така че киберпрестъпникът да може да се впише без парола.

Тя се крие по същия начин. Премахва собствения си ред от списъка с разширения и от проверките за обновления. Като резервен вариант изпълнява малко JavaScript в администраторския екран, който я премахва от таблицата с разширения. Когато авторът на заплахата ѝ даде команда, тя изключва разширение за сигурност и изтрива папката на това разширение, като първо може да промени или повиши правата на друг профил.

Атакуващият може да изпрати на сайта една конкретна заявка — кратък префикс с фиксирана стойност, и задната врата я прихваща, преди WordPress да е приключил със зареждането. Докато задната врата е там, тази заявка получава обратно нормална страница, което им показва отвън, че задната врата е все още на мястото си. Изследователите я наричат сигнален маяк на живо (live beacon).

За своите команди задната врата носи списък от около двадесет публични Ethereum шлюза (gateways) — услуги, които четат данни от блокчейна при заявка. Тя иска от тези шлюзове да прочетат нейните инструкции от интелигентен договор (smart contract). Блокирайте единия шлюз, който виждате в логовете си, и задната врата се премества към следващия, така че те трябва да бъдат блокирани като комплект.

Укриването на инструкции в блокчейн е по-старо от SC. През октомври 2023 г. изследователите от Guardio Labs го нарекоха EtherHiding. Хакнати WordPress сайтове четяха код от интелигентен договор в BNB Smart Chain и показваха на посетителите фалшиво обновление на браузъра, което инсталираше софтуер за кражба на информация (info-stealers), като например Lumma. Техният аргумент тогава беше, че след като договорът е в веригата, Binance не може просто да го спре.

На 16 октомври 2025 г. екипът за анализиране на заплахи на Google съобщи за около 14 000 уеб страници, където една група, използваща метода, е инжектирала своя код до юни същата година. Четенето от договор по този начин не струва нищо и не създава транзакция. Промяната на съдържанието на договора е струвала на атакуващите между 0.25 и 1.50 долара на път.

В същия ден екипът написа, че UNC5342, група, която се свързва със Северна Корея, е използвала EtherHiding от февруари 2025 г., също в мрежата на Ethereum. Групата разпространява зловреден код чрез фалшиви интервюта за работа и краде криптовалута. Това е първият път, в който екипът вижда подкрепяна от държава група да приема този метод. Тази връзка е оценка на екипа за тази конкретна кампания. Изследователите, които са открили SC, не казват кой стои зад него.

В кампаниите срещу WordPress от 2023 г. и 2025 г. справката се е изпълнявала като JavaScript в браузъра на посетителя. SC извършва справката от PHP, на самия уеб сървър. Изследователите посочват заявките, излизащи от уеб сървъра към Ethereum шлюзове, като един от признаците за инфекция.

Задна врата (backdoor) направи същото от сървъра по-рано тази година. През април 2026 г. някой купува комплект от повече от 30 разширения (plugins) за WordPress и залага задна врата в тях. Тя се записва в wp-config.php и от PHP вика смарт договор на Ethereum за адреса на своя команден сървър през публични шлюзове. На 7 април екипът за разширения на WordPress.org затваря 31 от тези разширения в рамките на един ден. Остин Гинндър от компанията за WordPress хостинг Anchor Hosting го описва два дни по-късно. Нищо в неговия материал или в връзките на Sucuri не свързва двата случая.

SC събира URL адреса и хоста на сайта, версиите на WordPress и разширенията, активните теми и задължителните разширения (must-use plugins). Той взема токените за сесия на администраторите, които са влезли в профила си в този момент — ключовете, които ги поддържат влезли. Той криптира всичко това и го изпраща. Отговорът може да съдържа нов PHP за инсталиране, списък с разширения за сигурност за премахване и JavaScript за инжектиране в страниците, които вашите посетители зареждат. В онлайн магазин, пишат изследователите, този скрипт позволява checkout skimming — код, който копира данните от картите, които клиентите въвеждат при плащане.

Изследователите не са казали колко сайта съдържат SC. WordPress задвижва 40.1 процента от всички уебсайтове, според W3Techs.

В материала също така не се казва как SC е попаднал на този сайт. Изследователите казват, че в повечето хакнати сайтове, които почистват, е било пробито чрез стари дупки в разширения, теми и други части, за които вече е имало налична корекция за сигурност.

Почистването на SC означава това да се направи в правилния ред, наведнъж. Ако първо изтриете файловете, останалите копия ги записват обратно. Подходът, който работи, пишат изследователите, е да спрете изпълнението на кода, да изчистите копията, които не са файлове, преди тези, които са, и едва след това да премахнете файловете. Редът, който те дават:

  • → Първо направете реда в .user.ini безвреден. PHP помни тази настройка до 300 секунди. Ако изтриете файла, към който той сочи, докато PHP все още го помни, PHP заявките към акаунта ще се провалят, докато изтече времето. Затова първо изпразвате този файл, след което премахвате реда от .user.ini, php.ini и .htaccess.
  • → След това копията, които не са файлове: редът в таблицата с опции, блокът в споделената памет и допълнителните настройки, които задната врата съхранява до него. При споделен хостинг блокът памет може да принадлежи на друг акаунт. В такъв случай само този акаунт или хостинг доставчикът може да го премахне, а той не прави нищо, след като drop-in скриптовете, които го четат, ги няма.
  • → След това планираните задачи и всички тригери в базата данни, които създават администратор.
  • → След това скритият администраторски акаунт.
  • → Едва след това файловете, на един ход, включително и двете копия на разширението, възстановителният ZIP файл и инжектираният блок в functions.php.
  • → Сканирайте отново и продължавайте да наблюдавате. Файл, който се появява отново, означава, че дадено копие е оцеляло или че входната точка все още е отворена.

След това затворете дупката, през която е влязъл атакуващият, и променете паролите и ключовете, до които той би могъл да е имал достъп.

Къде да проверите на собствения си сайт:

  • → .user.ini, php.ini или .htaccess с ред auto_prepend_file, който сочи към скрит файл
  • → wp-content/db.php и wp-content/advanced-cache.php, които вие или разширение, което познавате, не сте поставили там
  • → Разширение, което се намира както в mu-plugins, така и в plugins с едно и също съдържание
  • → ZIP файл с произволно хексадесетично име в wp-content, wp-content/uploads или в папка на тема
  • → Голяма, кодирана стойност в таблицата с опции под име, което не разпознавате
  • → Администратори в таблицата с потребители на базата данни, които не се появяват във вашето табло за управление
  • → Заявки от вашия уеб сървър към публични Ethereum шлюзове

Ако нещо, което сте изтрили, продължава да се появява отново, дадено копие все още е живо някъде извън диска или планирана задача все още е активна. Повторното изтриване на същия файл няма да отстрани проблема.