Накратко: Криптоминърът на сървъра се проявява обикновено чрез постоянно високо натоварване на процесора без ясна причина, чрез чужди процеси, често под потребителя на уеб сървъра, и чрез изходящи връзки към непознати цели. Не прекратявайте процеса прибързано: първо запазете следите, потърсете механизмите, които го стартират наново, и затворете входната врата. Майнърът означава, че някой е могъл да изпълнява код на Вашия сървър.
Когато сметката на облачния доставчик е първото предупреждение
Често криптоминърът не се забелязва от аларма за сигурност, а между другото. Уебсайтът става муден, хостерът съобщава за превишаване на изчислителното време, вентилаторът в собствения център за данни върти постоянно или сметката при облачния доставчик расте без нови проекти. За нападателите майнърът е прост начин да се превърне компрометиран сървър в пари.
Майнингът означава ползване на изчислителната мощ на чужда система за генериране на криптовалута. Щетата изглежда обозрима, защото не се криптират данни. Това лъже: който може да стартира майнър, може и да чете данни за достъп, да копира бази данни и да създава други задни вратички.
След PHP2Shell проверката си заслужава особено. Уязвимостите CVE-2026-109618 и CVE-2026-109619 позволяват изпълнение на злонамерен код без влизане. Потвърдени Indicators of Compromise няма, а майнърът не е специфичен знак за тези уязвимости. Високото натоварване от непознати процеси спада обаче към общите признаци, описани в Компрометиран ли съм вече?.
Правилно тълкуване на признаците на криптоминър
Високото натоварване има много безобидни причини. Таблицата помага при първата класификация:
| Наблюдение | Възможно безобидно обяснение | Какво проверявате |
|---|---|---|
| CPU трайно близо до пълно натоварване | резервно копие, обработка на изображения, изграждане на индекс | Натоварването равномерно ли е и нощем и през почивните дни? |
| Процес с име като системна услуга | рядко | Файлът на програмата в очаквания системен път ли стои? |
Процес под www-data, apache или nginx, който не е PHP |
едва ли | Кой го е стартирал, от коя директория? |
Програма в /tmp, /var/tmp или /dev/shm |
едва ли | От кога съществува файлът, на кого принадлежи? |
| Трайна изходяща връзка към непозната цел | мониторинг, актуализации | Целта принадлежи ли към позната услуга? |
| Натоварването спада, щом влезете | рядко | Някои злонамерени програми спират, когато работят инструменти за наблюдение |
Колкото повече редове съвпадат, толкова по-вероятна е находка. Че потребителят на уеб сървъра изобщо стартира чужди програми, е сам по себе си силен предупредителен сигнал, както показва статията Уеб сървърът стартира shell.
Така проверявате процесите и връзките
Следните команди само четат. Запишете резултата и часа, преди да промените каквото и да било:
# Процеси по натоварване на CPU, с потребител, време на стартиране и пълна команда
ps -eo pid,ppid,user,lstart,%cpu,%mem,args --sort=-%cpu | head -20
# Файл на програмата и работна директория на подозрителен процес (поставете PID)
sudo ls -l /proc/PID/exe /proc/PID/cwd
# Изходящи връзки с процес
sudo ss -tnp state established
# Изпълними файлове във временни директории
sudo find /tmp /var/tmp /dev/shm -type f -perm -u+x -ls 2>/dev/null
Ако /proc/PID/exe сочи към файл с добавката (deleted), програмата е била изтрита след стартирането. Това е типичен опит за маскиране. Процесът продължава да работи и докато работи, файлът на програмата още може да се запази през /proc. Това трябва да поеме някой, който умее да борави със зловреден софтуер; никога не изпълнявайте файла.
Как да преминете систематично през процесите отвъд майнъра, описва Намиране на подозрителни процеси на Linux сървъри.
Защо майнърът все се връща
Много оператори прекратяват процеса, радват се на спадащото натоварване и на следващия ден установяват, че всичко започва отначало. Майнърите почти винаги се инсталират с механизъм за рестарт. Типични места са:
- Cron задачи на потребителя на уеб сървъра или общосистемни, които на всеки няколко минути проверяват дали майнърът работи, а иначе го зареждат наново.
- Системни услуги с неугледни имена, които стартират при зареждане.
- Уеб шел в уеб директорията, през която нападателят може по всяко време да стартира майнъра наново.
- Променени стартови скриптове или профилни файлове на потребители.
- Чужди SSH ключове, с които нападателят влиза директно отново.
# Cron задачи на потребителя на уеб сървъра и общосистемни записи
sudo crontab -u www-data -l
ls -la /etc/cron.d /etc/cron.hourly /var/spool/cron 2>/dev/null
# Наскоро променени unit файлове на systemd
sudo find /etc/systemd/system /lib/systemd/system -name '*.service' -newermt "2026-10-17" -ls
Едва когато всички механизми са намерени, сървърът остава трайно спокоен. Ако нападателят е имал права на root, ново изграждане върху свежа система е обикновено по-надеждно от търсенето на всяко скривалище.
Правилният ред след находката
Майнърът изглежда като техническо неудобство, но е инцидент със сигурността. Затова действайте подредено:
- Запазете: Копирайте списъка с процеси, връзките, подозрителните файлове и логовете с контролна сума, преди нещо да бъде прекратено.
- Ограничете: Изолирайте сървъра или блокирайте изходящите връзки, ако е възможно без загуба на данни.
- Затворете причината: Приведете PHP в отстранено състояние (8.5.12, 8.4.27, 8.3.36, 8.2.35 или потвърден backport), рестартирайте всички worker-и, актуализирайте CMS и разширенията.
- Почистете или изградете наново: Премахнете майнъра, механизмите за рестарт и задните вратички, при съмнение инсталирайте наново.
- Проверете последствията: Могли ли са да бъдат прочетени данни за достъп или лични данни? Тогава изяснете защитата на данните и евентуално задълженията за уведомяване.
Включете рано Вашия хостер или облачен доставчик. Много доставчици блокират превантивно сървъри с необичайно натоварване или необичаен мрежов трафик. Който сам информира доставчика и съгласува действията, по-вероятно запазва контрола над момента на изключване. Попитайте при това и за мрежовите протоколи и протоколите за достъп на доставчика, защото те са извън Вашия сървър и трудно се променят от нападател.
За ръководството е важна кратка, честна класификация: самият майнър струва преди всичко изчислително време и производителност. Същинският въпрос е обаче какво друго е видял нападателят. Докато това не бъде изяснено, инцидентът не бива да се счита за приключен, дори натоварването да е отново нормално.
Криптоминърът показва, че на Вашия сървър е бил изпълняван код. Третирайте всички данни за достъп, стояли на сървъра, като евентуално изтекли и ги подновете след почистването.
Как помага PHP SOS конкретно?
- Класифицираме натоварването и разграничаваме безобидните причини от чужди процеси.
- Запазваме процеси, файлове и връзки, преди майнърът да бъде прекратен.
- Търсим всички механизми за рестарт и задни вратички и почистваме сървъра в рамките на премахването на зловреден софтуер или го изграждаме наново.
- Затваряме входната врата, подновяваме достъпите и настройваме наблюдение на натоварването, което съобщава рано за необичайни модели.
Често задавани въпроси
По какво разпознавам криптоминър на моя сървър?
Типично е постоянно високо натоварване на процесора, което не съответства на броя посетители или на планираните задачи. Към това се добавят процеси с непознати или безобидно звучащи имена, често под потребителя на уеб сървъра, и изходящи връзки към чужди адреси. Отделен признак още не е доказателство.
Достатъчно ли е да прекратя процеса на майнинг?
Не. Майнърите обикновено се стартират отново и отново през cron задачи, системни услуги или уеб шел. Който прекрати само процеса, често го вижда пак след кратко време. Освен това входната врата, през която майнърът е попаднал на сървъра, остава отворена.
Безобиден ли е криптоминърът, защото само краде изчислителна мощ?
Не. Който е могъл да инсталира майнър, е могъл да изпълнява код на сървъра. Това по правило означава, че конфигурационни файлове, данни за достъп и бази данни са били достъпни. Майнърът е видимият симптом на проникване.
Какви безобидни причини има за високо натоварване на сървъра?
Резервни копия, обработка на изображения, изграждане на търсачкови индекси, агресивни crawler-и или неизправно разширение също могат да изразходват много изчислително време. Тези причини обикновено могат да се причислят към познат процес и график. Ако натоварването остане без обяснение, проверете по-внимателно.