Доступ до Linux без SSH та VNC

Вступ

Для доступу на Linux машину найчастіше використовують SSH чи VNC, і більшість SOCів фокусуються на тому, щоб якісно моніторити ці сервіси. Водночас часто забувають про неочевидні точки входу на Linux, як от через EDR консоль чи консоль гіпервізору. У цьому дописі я наведу декілька цікавих прикладів та поділюсь досвідом щодо їх моніторингу.

Логін Через C2 Агенти

Ваша компанія користується EDR, MDM, або SCCM типу Chef чи Puppet? Більшість рішень з цих категорій мають функцію віддаленого виконання команд на системі, як от запуск Bash скриптів. Відповідно, отримавши доступ до консолі, ви отримуєте доступ до всіх хостів.

В поганих руках наведені рішення можуть стати повноцінним C2. Наприклад, Storm-2603 розкидував шифрувальник через Velociraptor, а через консоль TrendMicro Apex One раніше можна було інсталювати малварь. Але сьогодні про те як моніторити таку активність на Linux:

Натомість щоб логувати активність, що походить від агентів, вам потрібно орієнтуватись на події запуску процесів (Auditd/EDR). До прикладу, ось так виглядає команда echo "hello world!", введена через EDR консоль CrowdStrike:

systemd
  └─falcond                              // EDR агент, systemd сервіс
      └─falcon-sensor-bpf                // Частина CrowdStrike агенту
          └─bash --noprofile ...         // Bash вказує на віддалений доступ через EDR
              └─echo "hello world!"      // Команда, віддалено введена через EDR косноль

Нагадую, що в системних логах ви не побачите слідів виконання команд через агент, а тому важливо збирати та моніторити логи процесів. До прикладу, можна написати правило New Remote Session From X Agent, логіка така ж як і для детекту веб шелів:

index=processes parent_process=<agent_name> process IN(sh, dash, bash)

AWS Session Manager

Якщо ви хостите Linux в хмарі, хостового захисту може бути недостатньо. Наприклад, AWS вбудовує свій SSM агент в більшість Linux образів. Фактично, SSM агент є C2 на вебсокетах, що виконує команди задані в AWS SSM консолі. Через цей агент також працює AWS Session Manager, сервіс що надає доступ до хостів прямо через браузер:

aws-session

AWS Systems Manager не використовує SSH, не вимагає публічної айпі, та працює з sudo правами. Все що потрібно для логіну це обліковий запис в AWS з достатніми IAM правами. Оскільки з’єднання утворюється через агент, ви не побачите звичного логіну в secure/auth.log логах:

# /var/log/auth.log під час першого SSM логіну
# В подальших логінах жодних подій не буде
2026-01-20 23:11:25 ec2-vm useradd[1660]: new group: name=ssm-user, GID=1001
2026-01-20 23:11:25 ec2-vm useradd[1660]: new user: name=ssm-user, UID=1001, ...

# /var/log/auth.log під час використання sudo
2026-01-20 23:12:55 ec2-vm sudo: ssm-user : TTY=pts/2 ; PWD=/ ; USER=root ; COMMAND=/usr/bin/su
2026-01-20 23:12:55 ec2-vm sudo: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1001)

Сесія проходить через SSM агент, а тому подій аутентифікації в auth.log/secure логах ви не побачите. Натомість щоб моніторити логіни через Session Manager на рівні хоста, ви можете орієнтуватись на дерево процесів:

systemd
  └─amazon-ssm-agent                                  // SSM агент, systemd сервіс
      └─ssm-agent-worker                              // SSM воркер під кожну сесію
          └─ssm-session-worker root-hzu9d...          // В аргументах видно ID сесії
              └─sh                                    // Шел, що ви бачите в браузері
                  └─echo "hello world!"

На рівні AWS, цей же логін логується CloudTrail подією StartSession, де буде видно ID сесії (root-hzu9d...). Зверніть увагу, що є безліч аналогів Session Manager, проте всі вони працюють або через SSH тунель (що буде видно з auth.log|secure), або через агент (що підтвердить дерево процесів).

VPS та Гіпервізори

Колись на двох Linux хостах на дешевому VPS раптово опинилась самописна малварь на Go та бекдорний користувач “service”. Жодного моніторингу на хостах не було, і я не зміг точно визначити точку входу, проте в auth.log було видно схожі стрічки:

2026-01-21T02:54:33.261450+01:00 vps-host systemd-logind[563]: New session 4 of user xxx.
2026-01-21T02:54:33.276730+01:00 vps-host login: DIALUP AT ttyS0 BY xxx
2026-01-21T02:54:34.354593+01:00 vps-host su[935]: (to root) xxx on ttyS0
2026-01-21T02:54:34.354806+01:00 vps-host su[935]: pam_unix(su:session): session opened for user root(uid=0) by xxx(uid=1000)
...

Таку послідовність подій ви побачите коли логін здійснюється локально або через консоль гіпервізору, як VMware, так і KVM. Враховуючи що VPS був дешевим та не дуже популярним, я схиляюсь до думки що надавача послуг VPS було скомпрометовано, і через його гіпервізор (KVM) зловмисники вже розкинули шкідливе ПЗ на всіх його клієнтів.

Цей інцидент був для мене показовим, адже раніше я не звертав уваги на systemd-logind[/login логіни та автоматично вважав їх легітимними. Нагадую, що логіни через гіпервізор не йдуть через мережу Інтернет та їх не заблокувати фаєрволом, а тому ваш єдиний шанс побачити підозріле це secure/auth.log чи подальші підозрілі процеси, що походять з утвореної сесії.

У Підсумку

У цьому дописі я навів три нетипових методи як зловмисники можуть зайти на Linux: EDR консоль, AWS Session Manager, та консоль гіпервізору. Усі ці методи актуальні й під віндовс, проте чомусь всі пов’язані інциденти що я мав, були на лінуксі. У підсумку, моніторинг процесів найкраще допоможе розібратись вам у будь-якій ситуації, а щодо подій аутентифікації: