Знаходження атак доступу до облікових даних у Linux за допомогою Wazuh

Атаки доступу до облікових даних – це кібератаки, метою яких є отримання облікових даних для входу в систему. Ці облікові дані можуть включати імена користувачів, паролі, токени безпеки або іншу автентифікаційну інформацію. Вони залишаються однією з критичних загроз безпеці для організацій. Такі атаки дозволяють зловмисникам отримати неавторизований доступ до систем, полегшуючи розгалуження атаки та підвищення рівня привілеїв у цільовому середовищі. Такий прихований підхід полегшує зловмисникам досягнення їхніх цілей, залишаючись непоміченими.

Щоб ефективно виявляти та реагувати на атаки з використанням облікових даних в системах Linux, організаціям слід впровадити надійну систему моніторингу безпеки для виявлення аномальної поведінки. У цій статті продемонстровано, як виявити наступні методи атак на облікові дані:

• Офлайн злом паролів
• Незахищений доступ до облікових даних

Інфраструктура

Для демонстрації виявлення атак на облікові дані за допомогою Wazuh використовується наступна інфраструктура.

• Налаштована і готова до використання остання версія віртуальної машини Wazuh OVA, що включає основні компоненти рішення (сервер, indexer, дешборд).
• Встановлена та зареєстрована на сервері Wazuh кінцева точка Ubuntu 22.04 з агентом Wazuh.

Методи атак на облікові дані

Можливі цілі для зловмисників на кінцевих точках Linux включають, але не обмежуються ними:

• Браузери
• Менеджери паролів
• Hash dump (який також вимагає офлайн-злому)
• SSH-ключі

Офлайн-злом паролів

Офлайн-злом паролів – це метод, який використовується фахівцями з безпеки та зловмисниками для відновлення паролів з хешованих або зашифрованих файлів без активної взаємодії з цільовою системою.

Цей метод зосереджений на отриманні хешів (hashes) паролів, що зберігаються в системних файлах, таких як etc/passwd і etc/shadow. Потім зловмисники намагаються зламати їх, використовуючи brute-force або атаки з використанням словників на окремій кінцевій точці.

Виявлення цієї техніки зосереджується на моніторингу доступу на зчитування до файлів etc/shadow та etc/passwd, які за замовчуванням доступні лише користувачеві root.

Незахищений доступ до облікових даних

Зловмисники часто шукають незахищені облікові дані, щоб полегшити розгалуження атаки в мережі. Вони можуть використовувати незахищені облікові дані, які зберігаються у відкритому вигляді, слабо зашифровані, не хешовані та знаходяться в легкодоступних місцях. Вони можуть переглядати файл bash_history, щоб виявити раніше використані облікові дані, і шукати приватні SSH-ключі в каталозі ~/.ssh.

Зусилля з виявлення повинні бути зосереджені на виявленні спроб виконання дій читання цих файлів, оскільки вони можуть свідчити про зловмисні наміри.

Виявлення за допомогою Wazuh

У цьому розділі розглянуто, як налаштувати відстежувані кінцеві точки на виявлення потенційних шкідливих дій, що виконуються користувачами, які не мають права root, і як використовувати правила виявлення Wazuh для запуску сповіщень.

Примітка: Для виконання наведених нижче команд потрібні привілеї root-користувача.

Налаштування кінцевого пристрою Ubuntu

Тут налаштовується кінцева точка Ubuntu для виявлення автономного доступу до файлів облікових даних. Крім того, реєструються команди, запущені з інтерфейсу командного рядка (CLI), щоб виявити потенційні зловмисні команди за допомогою Auditd.

Щоб встановити Auditd і створити необхідні правила аудиту, важливо виконати наступні дії:

1) Встановити, запустити та ввімкнути Auditd, якщо він ще не присутній в системі:

# apt -y install auditd audispd-plugins
# systemctl start auditd
# systemctl enable auditd

2) Виконати наступну команду, щоб додати правила аудиту до файлу /etc/audit/rules.d/audit.rules:

# cat << EOF >> /etc/audit/rules.d/audit.rules
-a exit,always -F arch=b64 -F auid!=-1 -F euid!=0 -S execve -k audit-wazuh-c
-a exit,always -F arch=b64 -F path=/etc/shadow -F auid!=-1 -F euid!=0 -F perm=r -k shadow_access
-a exit,always -F arch=b64 -F path=/etc/passwd -F auid!=-1 -F euid!=0 -F perm=r -k passwd_access
-a exit,always -F arch=b64 -F path=/<USER_HOME_DIRECTORY>/.bash_history -F auid!=-1 -F euid!=0 -F perm=r -k history_access
-a exit,always -F arch=b64 -F dir=/<USER_HOME_DIRECTORY>/.ssh/ -F auid!=-1 -F euid!=0 -F perm=r -k ssh_access
EOF

Де:

• –a exit, always вказує правило аудиту, застосоване до точки завершення системного виклику. Ключове слово always гарантує, що правило завжди буде активним.
• Фільтр -F auid!=-1 гарантує, що правило не застосовуватиметься до дій, для яких ідентифікатор користувача аудиту дорівнює -1. Значення auid -1 зазвичай вказує на те, що процес не пов’язано з користувачем, що часто спостерігається у потоках ядра або на ранніх стадіях завантаження.
• Фільтр -F arch=b64 вказує, що правило застосовується до системних викликів 64-бітної архітектури. Для 32-розрядних архітектур фільтр матиме значення arch=b32.
• -S execve вказує системний виклик, який буде перевірено. execve – це системний виклик, який використовується для виконання програм. Отже, це правило буде фіксувати кожне виконання програми, що відповідає вказаним фільтрам.
• -k audit-wazuh-c вказує ключ для запису аудиту. Опція -k дозволяє позначати журнали аудиту, згенеровані цим правилом, певним ідентифікатором, що полегшує пошук і аналіз пов’язаних журналів.
• -F perm=r вказує, що правило застосовується до операцій читання.
• -F euid!=0 вказує, що перевірятимуться події, в яких ефективний ідентифікатор користувача (euid) не дорівнює 0. EUID 0 зазвичай відповідає кореневому користувачеві в Unix-подібних операційних системах.
• -F path вказує повний шлях до файлу, який потрібно відстежувати. Необхідно замінити на домашній каталог користувача (<USER_HOME_DIRECTORY>), для якого потрібно відстежувати історію bash і доступ до файлів по SSH.

Важливо: Правило аудиту -a always,exit -F arch=b64 -S execve -F auid!=-1 -F euid!=0 -F key=audit-wazuh-c записує кожну команду, виконану на контрольованому кінцевому пристрої. Це призведе до запуску правила Wazuh auditd за замовчуванням з ідентифікатором 80792.

3) Перезавантажити правила і переконатися, що вони діють:

# sudo auditctl -R /etc/audit/rules.d/audit.rules

No rules
enabled 1
failure 1
pid 2652
rate_limit 0
backlog_limit 8192
lost 0
backlog 3
backlog_wait_time 60000
backlog_wait_time_actual 0
enabled 1
failure 1
pid 2652
rate_limit 0
backlog_limit 8192
lost 0
backlog 7
backlog_wait_time 60000
backlog_wait_time_actual 0
enabled 1
failure 1
pid 2652
rate_limit 0
backlog_limit 8192
lost 0
backlog 2
backlog_wait_time 60000
backlog_wait_time_actual 0

# sudo auditctl -l

-a always,exit -F arch=b64 -S execve -F auid!=-1 -F euid!=0 -F key=audit-wazuh-c
-a always,exit -F arch=b64 -S all -F path=/etc/shadow -F auid!=-1 -F euid!=0 -F perm=r -F key=shadow_access
-a always,exit -F arch=b64 -S all -F path=/etc/passwd -F auid!=-1 -F euid!=0 -F perm=r -F key=passwd_access
-a always,exit -F arch=b64 -S all -F path=/root/.bash_history -F auid!=-1 -F euid!=0 -F perm=r -F key=history_access
-a always,exit -F arch=b64 -S all -F dir=/root/.ssh/ -F auid!=-1 -F euid!=0 -F perm=r -F key=ssh_access

4) Додати наступну конфігурацію до файлу агента Wazuh /var/ossec/etc/ossec.conf. Це дозволить агенту Wazuh читати файл журналу auditd:

<ossec_config>  
  <localfile>
    <log_format>audit</log_format>
    <location>/var/log/audit/audit.log</location>
  </localfile>
</ossec_config>

5) Перезапустити службу агента Wazuh, щоб застосувати конфігурації:

# sudo systemctl restart wazuh-agent

Налаштування сервера Wazuh

1) Оновити список CDB /var/ossec/etc/lists/audit-keys користувацьким ключем аудиту:

# cat << EOF >> /var/ossec/etc/lists/audit-keys
passwd_access:passwd
shadow_access:shadow
history_access:history
ssh_access:ssh
EOF

2) Додати наступні правила до файлу /var/ossec/etc/rules/local_rules.xml, щоб генерувати сповіщення на інформаційній панелі Wazuh щоразу, коли зловмисник виконує будь-яку з атак, згаданих вище:

<group name="cred_access,">
<!--Detect access to offline password storing files-->
  <rule id="100110" level="7">
    <if_sid>80700</if_sid>
    <list field="audit.key" lookup="match_key_value" check_value="passwd">etc/lists/audit-keys</list>
    <description>File access - The file $(audit.file.name) was accessed</description>
    <group>audit_command,</group>
    <mitre>
      <id>T1003.008</id>
    </mitre>
  </rule>

  <rule id="100120" level="10">
    <if_sid>80700</if_sid>
    <list field="audit.key" lookup="match_key_value" check_value="shadow">etc/lists/audit-keys</list>
    <description>Possible adversary activity - $(audit.file.name) was accessed</description>
    <group>audit_command,</group>
    <mitre>
      <id>T1003.008</id>
    </mitre>
  </rule>

<!--Detecting suspicious activities related to unsecured credentials -->
  <rule id="100131" level="0">
    <if_sid>80700</if_sid>
    <list field="audit.key" lookup="match_key_value" check_value="ssh">etc/lists/audit-keys</list>
    <description>Possible adversary activity - $(audit.file.name) was accessed</description>
    <group>audit_command,</group>
  </rule>

  <rule id="100132" level="0">
    <if_sid>80700</if_sid>
    <list field="audit.key" lookup="match_key_value" check_value="history">etc/lists/audit-keys</list>
    <description>Possible adversary activity - $(audit.file.name) was accessed</description>
    <group>audit_command,</group>
  </rule>

  <rule id="100133" level="0">
    <if_sid>80700</if_sid>
    <field name="audit.exe" type="pcre2">/usr/bin/*grep</field>
    <field name="audit.execve.a2">cred|password|login</field>
    <description>Possible adversary activity - $(audit.file.name) was accessed</description>
    <group>audit_command,</group>
  </rule>

  <rule id="100130" level="10">
    <if_sid>100131, 100132, 100133</if_sid>
    <description>Possible adversary activity - searching for previously used credentials in system files</description>
    <group>audit_command,</group>
    <mitre>
      <id>T1552.001</id>
    </mitre>
  </rule>

</group>

Де:

• Правило з ID 100110 спрацьовує при спробі доступу на читання до файлу /etc/passwd.
• Правило з ID 100120 спрацьовує при спробі доступу на читання до файлу /etc/shadow.
• Правило з ID 100131 спрацьовує при спробі читання файлу bash_history.
• Правило з ID 100132 спрацьовує при спробі читання файлів з каталогу .ssh.
• Правило з ID 100133 спрацьовує, якщо в каталогах .ssh або bash_history записано процес grep для певних ключових слів.
• Правило з ID 100130 спрацьовує, коли спрацьовують правила з ідентифікаторами 100131, 100132 і 100133. Це означає пошук облікових даних у каталогах .ssh або перевірку bash_history на наявність раніше використаних облікових даних.

Важливо: Залежно від різних служб, встановлених на контрольованому кінцевому пристрої, правило ID 100110 може видавати кілька попереджень при перезавантаженні системи та вході користувачів в систему. Це пов’язано з тим, що деякі з цих програм потребують автентифікації користувача, а отже, читають файл /etc/passwd.

3) Перезапустити менеджер Wazuh, щоб застосувати зміни конфігурації:

# systemctl restart wazuh-manager

Результати виявлення

На наведеному нижче знімку екрана показано сповіщення, згенеровані на інформаційній панелі Wazuh, коли моделюються зловмисні дії, пов’язані з атаками доступу до облікових даних на кінцевих точках атакованого. На інформаційній панелі Wazuh перейти до “Threat hunting“, щоб переглянути згенеровані сповіщення.

Якщо події не видно безпосередньо:

1. Натиснути +Add filter. Потім відфільтрувати rule.id у полі “Field”.
2. У полі “Operator” вибрати фільтр для is one of.
3. Задати значення 100110, 100120 і 100130 у полі “Values”.
4. Натиснути кнопку “Save”.

Висновок

У цій статті було розглянуто, як Wazuh допомагає виявляти загрози доступу до облікових даних на кінцевих точках Linux. Оскільки зловмисники стають все більш досвідченими, захист від компрометації облікових даних стає все більш важливим для забезпечення безпеки та цілісності інформаційних активів.

Використовуючи Wazuh, можна виявити потенційні загрози, пов’язані з крадіжкою облікових даних, а отже, зробити крок вперед у захисті облікових даних організації та підтримці безпеки цифрового середовища.