FreeIPA: как обнаружить атаку злоумышленника на любом этапе Кill Сhain. Часть 2

Привет, Хабр! Это Ильназ Гатауллин, технический руководитель RED Security SOC и Сергей Орляк, руководитель третьей линии RED Security SOC. В прошлой части мы разобрали целый ряд атак на FreeIPA: показали их механику, показали правила корреляции, которые можно использовать для самостоятельного выявления таких инцидентов, и поделились советами по расследованию. В этой части мы посмотрим на весь Kill Chain атак на FreeIPA и покажем, как приведенные правила позволят выявлять злоумышленника на любом из этапов.

Неуспешные попытки аутентификации под различными учетными записями по протоколу LDAP (LDAP PassSpray, T1110)

Можно ли подбирать пароли или производить User Enumeration и Password Spraying атаки, чтобы команда защиты не смогла это выявить? В целом – да. Злоумышленник может произвести атаку Password Spraying по протоколу LDAP.

Пример атаки:

hydra -L user_ldap_dict.txt -p "P@ssw0rd" -S -I ldap3://11.62.10.236

Что делает эта команда:

Обязательно отслеживайте такую активность:

name: 'User_Connect'
logsource:
  product: ldap 389
  files: /var/log/dirsrv/slapd-*/access
detection:
  selection:
    ldap_action:
      - 'connection'
      - 'SSL connection'
condition: selection
name: 'User_BIND'
logsource:
  product: ldap 389
  files: /var/log/dirsrv/slapd-*/access
detection:
  selection:
    ldap_action: 'BIND'
userstartswith:
    - 'cn=Directory Manager'
    - 'cn=uid=admin'
condition: selection
correlation:
  rules:
    - 'User_Connect'
    - 'User_BIND'
  group-by:
    - 'SourceAddress'
    - 'ldap_389_HostName'
    - 'ldap_389_HostAddress'
  uniq: 'UserName'
  timespan: 30s
  condition: gte

Когда сработает правило корреляции, мы получим такую информацию об IP-адресе, с которого подбирают пароли пользователей (мы виделили болдом поля общие для базовых событий, а также ключевые поля, которые помогают правильно отреагировать):

[14/Oct/2024:00:56:14.745738244 +0300] conn=21111 fd=233 slot=233 SSL connection from 11.62.10.144 to 11.62.10.236
[14/Oct/2024:00:56:14.796707036 +0300] conn=21111 op=0 BIND dn="uid=user3,cn=users,cn=accounts,dc=stand,dc=local" method=128 version=3

Расследуем инцидент с помощью запросов через агрегацию:

Если правильно выбрать поля агрегации, видны интенсивность атаки и количество потенциально скомпрометированных УЗ.

Подозрительные LDAP-запросы (LDAP Recon, T1078)

Построим профиль LDAP-запросов, чтобы выявить аномалии: например, запросы данных об объектах LDAP-юзеров, компьютеров или групп. Если у злоумышленника привилегированная учетная запись, он может также запрашивать NT-хеши, пароли или Kerberos-билеты. Эта активность есть в журнале LDAP 389:

logsource:
  product: ldap 389
  files: /var/log/dirsrv/slapd-*/access
detection:
  Search_Action:
    ldap_action: 'SRCH‘
  Common1:
    ldap_base|re: ' ^cn=(users|computers|hostgroups|groups|hbac|sudorules|roles)‘
  Common2:
    ldap_base|startwith: ‘dc=‘
  Objects_All:
    ldap_filter: '(objectClass=*)‘
  Extract_Keys:
    ldap_filter:
      - '(userPassword=*)‘
      - '(ipaNTHash=*)‘
      - '(krbPrincipalKey=*)‘
      - '(krbMKey=*)‘
  condition: Search_Action AND ((Objects_All AND (Common1 OR Common2)) OR Extract_Keys)

Пример активности атакующего:
ldapsearch -x -D "uid=user2,cn=users,cn=accounts,dc=stand,dc=local" -w "P@ssw0rd" -H ldap://11.62.10.236:389 -b "cn=users,cn=accounts,dc=stand,dc=local"

Результат исполнения команды:

Сработавшее правило корреляции выводит LDAP-запрос, который попал под один из наших шаблонов. Такую активность тяжело анализировать на вредоносность. Но мы можем по номеру LDAP-сессии получить IP-адрес ее хоста и имя пользователя, авторизованного в течение этой сессии. Данных хватит для начала реагирования.

Данные на старте расследования:
[14/Oct/2024:01:24:20.601371826 +0300] conn=21126 op=1 SRCH base="cn=users,cn=accounts,dc=stand,dc=local" scope=2 filter="(objectClass=*)" attrs=ALL

Уточняем хост, с которого пришел запрос:
[14/Oct/2024:01:24:20.350389988 +0300] conn=21126 fd=231 slot=231 connection from 11.62.10.144 to 11.62.10.236

Уточняем, под какой учетной записью выполнена данная активность:
[14/Oct/2024:01:24:20.350807305 +0300] conn=21126 op=0 BIND dn="uid=user2,cn=users,cn=accounts,dc=stand,dc=local" method=128 version=3

Тяжелый запрос в LDAP (Expensive LDAP req, T1078)

Не всегда можно корректно построить профиль LDAP-запросов. В таком случае отслеживайте тяжелые LDAP-запросы — то есть такие, которые возвращают много LDAP-объектов либо долго обрабатываются (аналог события с EventID 1644 из журнала Directory Service в ОС Windows).

Правило корреляции:

logsource:
  product: ldap 389
  files: /var/log/dirsrv/slapd-*/access
detection:
  LDAP_Event:
    ldap_action: 'RESULT‘
  Entry_Count:
    nentries|gt: 30
  Operation_Time:
    optime|gt: 0.005
condition: LDAP_Event AND (Entry_Count OR Operation_Time)

Когда это правило срабатывает, мы видим, какие показатели превысили пороговые значения.

[14/Oct/2024:03:08:15.986113163 +0300] conn=21150 op=1 RESULT err=0 tag=101 nentries=5 wtime=0.000143546 optime=0.005703893 etime=0.005843352 notes=U details="Partially Unindexed Filter"

В событии RESULT ldap 389 параметр nentries говорит о количестве возвращенных записей, а optime — о количестве времени на обработку запроса LDAP-сервером (без учета нахождения в очереди).

По номеру LDAP-сессии можно посмотреть IP-адрес хоста, откуда было выполнено обращение, а также имя пользователя, аутентифицированного в рамках данной сессии.  

Хост, с которого шел запрос:
[14/Oct/2024:03:08:15.978958723 +0300] conn=21150 fd=231 slot=231 connection from 11.62.10.144 to 11.62.10.236

Под какой учетной записью выполнена данная активность:
[14/Oct/2024:03:08:15.979158503 +0300] conn=21150 op=0 BIND dn="uid=user2,cn=users,cn=accounts,dc=stand,dc=local" method=128 version=3

Интересно взглянуть, что происходило в рамках этого запроса. Выгрузили слишком много информации из LDAP-каталога? Или же запрос был слишком долгим из-за возможного обхода слишком многих объектов по специфичному фильтру? Смотрим выполненный LDAP-запрос по номерам LDAP-сессии и операции:

[14/Oct/2024:03:08:15.980411039 +0300] conn=21150 op=1 SRCH base="cn=users,cn=accounts,dc=stand,dc=local" scope=2 filter="(objectClass=*)" attrs=ALL

Как злоумышленники охотятся за билетами Kerberos

Ранее мы говорили о том, что, попадая на хост, атакующий может охотиться за билетами Kerberos. Исторически в системе Linux они хранились в каталоге tmp, в файлах ccache.

Старая схема хранения в виде файлов «/tmp/krb5cc_%{uid}»:

Но сейчас билеты Kerberos в этом каталоге — повод задуматься, не скомпрометирован ли хост, взглянуть на имя этого файла и настройки хоста.

Еще билеты хранятся в ядре подсистемы KeyRing. Kernel KeyRing находится в объектах ядра. В качестве интерфейса взаимодействия используются системные вызовы:

Билеты можно также хранить в подсистеме KCM — Kerberos Cash Management. Во FreeIPA ее чаще всего реализует демон sssd-kcm:

Приоритет мест хранения:

1. Переменная окружения (KRB5CCNAME).

2. Параметр «default_ccache_name» в конфигурационном файле «/etc/krb5.conf» (раздел «[libdefaults]»).

3. Значения по умолчанию в ОС.

Доступ к подсистеме KeyRing-ядра (KeyRing access, T1555, T1558)

Злоумышленников могут заинтересовать ключи KeyRing, поэтому отслеживайте доступ к ним. В данном случае мы используем подсистему журналирования Linux Auditd, отслеживающую такие syscall, как keyctl. Предварительно необходимо cпрофилировать легитимные приложения, например SSH, которые обращаются к этой подсистеме в ходе работы.

Правило корреляции:

logsource:
  product: auditd
  files: /var/log/audit/audit.log*
detection:
  keyctl_read:
    syscall: 'keyctl‘
  filter:
    exe: /usr/bin/ssh
condition: keyctl_read AND NOT filter

Правила подсистемы аудита ядра auditd:
-a exit,always -F arch=b64 -S keyctl -F a0=0xb -k kernel_keyctl
# Примечание: #define KEYCTL_READ 11- read a key or keyring's contents

Пример активности атакующего:
./tickey -i

Результат исполнения команды:

Когда срабатывает это правило корреляции, мы реагируем на событиях подсистемы auditd.

Данные на начало расследования:

node=fripa.stand.local type=PROCTITLE msg=audit(10/14/2024 20:27:47.033:892) : proctitle=./tickey -i
node=fripa.stand.local type=SYSCALL msg=audit(10/14/2024 20:27:47.033:892) : arch=x86_64 syscall=keyctl success=yes exit=8 a0=0xb a1=0x1d7906 a2=0x0 a3=0x0 items=0 ppid=1619 pid=1650 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=tickey exe=/root/tickey key=kernel_keyctl

В этом событии мы сразу же видим объект файла, который породил данный процесс и вызвал отслеженный нами syscall. Мы получили command line запуска процесса, имя пользователя, аутентифицированного в течение сессии, а также ее номер. По нему можно определить IP-адрес пользователя на хосте, если сессию инициировали через SSH:

node=fripa.stand.local type=USER_START msg=audit(10/14/2024 20:27:06.039:775) : pid=1601 uid=root auid=root ses=1 msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask,pam_lastlog acct=root exe=/usr/sbin/sshd hostname=10.40.64.69 addr=10.40.64.69 terminal=ssh res=success'

Где хранятся ключи

Давайте рассмотрим, какие подсистемы и в каких файлах могут хранить ключи, интересующие атакующих:

1. Подсистема KCM может хранить билеты Kerberos в файле Secrets.Ldb: /var/lib/sss/secrets/secrets.ldb

До 2018-го этот файл был зашифрован, а ключ находился в том же каталоге. Соответственно, теперь получить информацию из файла можно без ключа.

Пример извлечения билетов из secrets.ldb:

2. Хеши паролей пользователей находятся здесь: /var/lib/sss/db/cache_stand.local.ldb

3. И конечно, не забывайте про пароль пользователя Directory Manager, хеш которого хранится в файле конфигурации экземпляра LDAP-каталога dsel diff: /etc/dirsrv/slapd-%REALM%/dse.ldif

Этот файл не шифруется, и атакующий может достать оттуда хеш пароля:
grep -A 5 "nsslapd-rootpw:" /etc/dirsrv/slapd-STAND-LOCAL/dse.ldif
# nsslapd-rootpw: {PBKDF2_SHA256}AAAIAEL/Y0ZCYJuh7j80/J3jkwG0l2q8VzXWImrtbFhQZSJ…
hashcat -m 10901 -a 0 PBKDF2_SHA256_hash_DM /usr/share/wordlists/rockyou.txt

Пример восстановления пароля Directory Manager из хеша:

4. В первую очередь FreeIPA компрометируют, чтобы получить файл id2entry.db (/var/lib/dirsrv/slapd-STAND-LOCAL/db/userRoot/id2entry.db). Он содержит все хеши паролей пользователей и Kerberos-ключи.

Пример извлечения ключевой информации из локального файла id2entry.db:
dbscan -f /var/lib/dirsrv/slapd-STAND-LOCAL/db/userRoot/id2entry.db > LDAP_Hash.dump
ldapsearch -D "cn=Directory Manager" -x -w "P@ssw0rd" -H ldap://11.62.10.236 "(|(userPassword=*)(ipaNTHash=*))" krbCanonicalName uid cn userPassword ipaNTHash krbPrincipalKey krbMKey > LDAP_Hash.dump

Результат извлечения хешей паролей пользователей из дампа:

5. Помните, что указанные файлы бывают не только в стандартных директориях для работы демонов, но и в директориях систем бэкапирования, например: /var/lib/ipa/backup/

Когда бэкапы не настроены, атакующий может создать их, чтобы атаковать:
ipa-backup
ipa-backup --data –online

Поэтому отслеживайте все альтернативные местоположения чувствительных файлов.

Доступ к файлам с парольной информацией на хосте (Hash DB files access, T1003)

Мы разобрали места и каталоги, которые могут заинтересовать злоумышленников. Перейдем к их мониторингу. Здесь также используется подсистема журналирования Linux auditd. Перечень директорий, где хранятся различные секреты, файлы и базы данных, указан в корреляционном правиле:

logsource:
  product: auditd
  files: /var/log/audit/audit.log*
detection:
  PATH0:
    PATH0_name|startwith:
      - ‘/var/lib/ipa/backup/‘
      - ‘/etc/dirsrv/‘
      - ‘/var/lib/sss/secrets/‘
      - ‘/var/lib/sss/db/‘
      - ‘/var/lib/dirsrv/‘
  PATH1:
    PATH1_name|startwith:
      - ‘/var/lib/ipa/backup/‘
      - ‘/etc/dirsrv/‘
      - ‘/var/lib/sss/secrets/‘
      - ‘/var/lib/sss/db/‘
      - ‘/var/lib/dirsrv/‘
condition: PATH0 OR PATH1

Правила подсистемы аудита ядра:

-w /var/lib/dirsrv/ -p rw -F auid!=-1 -F euid!=dirsrv -k hash_access
-w /var/lib/sss/db/ -p rw -F auid!=-1 -F euid!=dirsrv -k hash_access
-w /var/lib/sss/secrets/ -p rw -F auid!=-1 -F euid!=dirsrv -k hash_access
-w /etc/dirsrv/ -p rw -F auid!=-1 -F euid!=dirsrv -k hash_access
-w /var/lib/ipa/backup/ -p rw -F auid!=-1 -F euid!=dirsrv -k hash_access

Расследование инцидента на базе событий auditd.

node=oracle-test.stand.local type=PROCTITLE msg=audit(10/15/2024 11:56:31.923:23424) : proctitle=/bin/bash ./linikatzV2.sh
node=oracle-test.stand.local type=PATH msg=audit(10/15/2024 11:56:31.923:23424) : item=0 name=/var/lib/sss/db/ inode=101248271 dev=fc:00 mode=dir,700 ouid=sssd ogid=sssd rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
node=oracle-test.stand.local type=CWD msg=audit(10/15/2024 11:56:31.923:23424) : cwd=/root/freeipa_attack/LinikatzV2-master
node=oracle-test.stand.local type=SYSCALL msg=audit(10/15/2024 11:56:31.923:23424) : arch=x86_64 syscall=openat success=yes exit=3 a0=AT_FDCWD a1=0x55f30280b2c0 a2=O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC a3=0x0 items=1 ppid=7994 pid=8118 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=linikatzV2.sh exe=/usr/bin/bash key=hash_access

В событии мы видим файл или критичный каталог, к которому получили доступ, а также процесс, который выполнил это обращение. Кроме того, у нас есть command line запуска этого процесса, имя пользователя, запустившего сессию в ОС, и номер сессии. По нему можно определить, с какого хоста ее инициировали (при подключении по SSH), и отследить смежную аномальную активность.

Доступ к keytab-файлам на хосте (Keytab files access, T1555, T1558)

Рассмотрим теперь мониторинг обращений к keytab-файлам, в которых хранятся ключи. Их также можно отслеживать с помощью той же подсистемы Linux auditd. И в целом — отсматривайте все файлы с расширением .keytab.

Правило корреляции:

logsource:
  product: auditd
  files: /var/log/audit/audit.log*
detection:
  PATH0:
    PATH0_name|endwith: ‘.keytab‘
  PATH1:
    PATH1_name|endwith: ‘.keytab‘
condition: PATH0 OR PATH1

Правила подсистемы аудита ядра:

-w /etc/pki/pki-tomcat/dogtag.keytab -p rw -F auid!=-1 -F euid!=dirsrv -k keytab_access
-w /etc/dirsrv/ds.keytab -p rw -F auid!=-1 -F euid!=dirsrv -k keytab_access
-w /etc/named.keytab -p rw -F auid!=-1 -F euid!=dirsrv -k keytab_access
-w /etc/ipa/dnssec/ipa-dnskeysyncd.keytab -p rw -F auid!=-1 -F euid!=dirsrv -k keytab_access
-w /var/lib/ipa/gssproxy/http.keytab -p rw -F auid!=-1 -F euid!=dirsrv -k keytab_access
-w /etc/krb5.keytab -p rw -F auid!=-1 -k keytab_access

Пример атаки:
cp -I /etc/krb5.keytab /tmp/host.tmp

Сработавшее правило корреляции показывает, к какому keytab-файлу обращались. Также мы видим, какой процесс получил доступ к файлу и command line запуска этого процесса. И нам известен пользователь и его номер сессии в ОС: можем отследить смежную подозрительную активность и определить, откуда вошли на хост.

Пример события при срабатывании правила корреляции:

node=fripa.stand.local type=PROCTITLE msg=audit(10/14/2024 20:56:47.663:1227) : proctitle=cp -i /etc/krb5.keytab /tmp/host.tmp
node=fripa.stand.local type=PATH msg=audit(10/14/2024 20:56:47.663:1227) : item=0 name=/etc/krb5.keytab inode=134934471 dev=fc:00 mode=file,600 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
node=fripa.stand.local type=CWD msg=audit(10/14/2024 20:56:47.663:1227) : cwd=/root
node=fripa.stand.local type=SYSCALL msg=audit(10/14/2024 20:56:47.663:1227) : arch=x86_64 syscall=openat success=yes exit=3 a0=AT_FDCWD a1=0x7ffe62a6e73b a2=O_RDONLY a3=0x0 items=1 ppid=1619 pid=1875 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=cp exe=/usr/bin/cp key=keytab_access

Подозрительные запросы Kerberos-билетов (Suspicious req Ticket, T1021, T1550, T1555)

Отслеживать ли запросы Kerberos-билетов в FreeIPA? В некоторых сценариях да, но разумно делать это для критичных учетных записей, таких как admin или root, чтобы минимизировать ложные срабатывания корреляционное правила.

Кроме того, по умолчанию рядовые пользователи домена имеют доступ по SSH на сервер FreeIPA. Соответственно, вход туда под учетной записью рядового пользователя можно рассматривать как аномалию и серьезную проблему безопасности. Отслеживайте AS_REQ- и TGS_REQ-запросы в журнале MIT Kerberos. Предварительно отпрофилируйте легитимные подключения и исключите сам сервер FreeIPA.

Пример активности атакующего:
kinit user2
ssh [e-mail]

Результат исполнения команды:

Правило корреляции:

logsource:
  product: MIT Kerberos
  files: /var/log/krb5kdc.log
detection:
  Request_TGT:
    krb5_event: 'AS_REQ‘
  Critical_Users:
    UserName|startwith:
      - 'admin‘
      - ‘root‘
  Request_TGS:
    krb5_event: 'TGS_REQ‘
    ServiceName: 'host/oracle-test.stand.local‘
  IPA_Server:
    SourceAddress: '11.62.10.236‘
condition: (Request_TGT AND Critical_Users AND NOT IPA_Server) OR (Request_TGS AND NOT Admin_Users)

При срабатывании правила корреляции мы получаем имя запросившего билет Kerberos пользователя, IP-адрес его хоста и сервис, к которому пытался подключиться этот пользователь. Так мы частично понимаем цели злоумышленника и можем реагировать:

2024 Oct 14 10:26:34 oracle-test.stand.local krb5kdc[2961](info): TGS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 11.62.10.144: ISSUE: authtime 1728890788, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, [e-mail] for host/[e-mail]

Доступ к критической системной группе LDAP (Access crit LDAP obj, T1098)

Так же, как в Active Directory, во FreeIPA есть критичные группы: IPA servers, admin или administrator. Следите, как они меняются, чтобы туда не добавили учетные записи неправомерно.

Правило корреляции:

logsource:
  product: ldap 389
  files: /var/log/dirsrv/slapd-*/access

detection:
  selection:
    ldap_action:
      - 'ADD'
      - 'MOD'
    dn|re:
      - 'cn=cn=ipaservers,cn=hostgroups,cn=accounts,dc=stand,dc=local'
      - 'cn=.*?Administrator.*?,cn=roles,cn=accounts,dc=stand,dc=local'
      - 'cn=.*?admin.*?,cn=groups,cn=accounts,dc=stand,dc=local'

  condition: selection

Источники событий для расследования инцидента:

• access-логи LDAP-демона 389;

• audit-логи LDAP-демона 389;

• в некоторых сценариях — access-логи демона httpd.

Данные на начало расследования:
[07/Oct/2024:10:17:27.361003783 +0300] conn=951 op=3 MOD dn="cn=admins,cn=groups,cn=accounts,dc=stand,dc=local"

Мы видим измененный критичный объект LDAP-каталога. Как и ранее, по номеру LDAP-сессии определяем, с какого хоста подключались и какой пользователь при этом аутентифицировался (используем access-логи LDAP-демона 389):

[07/Oct/2024:10:17:27.102320954 +0300] conn=951 fd=227 slot=227 connection from 11.62.10.236 to 11.62.10.236
[07/Oct/2024:10:17:27.106774008 +0300] conn=951 op=0 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO
[07/Oct/2024:10:17:27.113278032 +0300] conn=951 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000201234 optime=0.006507700 etime=0.006707986 dn="uid=admin,cn=users,cn=accounts,dc=stand,dc=local"
[07/Oct/2024:10:17:27.361003783 +0300] conn=951 op=3 MOD dn="cn=admins,cn=groups,cn=accounts,dc=stand,dc=local"
[07/Oct/2024:10:17:27.386689272 +0300] conn=951 op=3 RESULT err=0 tag=103 nentries=0 wtime=0.000107786 optime=0.025691553 etime=0.023987753

Что именно поменяли — покажут дополнительные настройки аудита LDAP-каталога. Мы с вами рассматривали их в самом начале первой части.

Из дополнительных событий аудита LDAP-каталога видно, что в критичную группу добавили пользователя user2:

[07/Oct/2024:10:17:27.361003783 +0300] conn=951 op=3 MOD dn="cn=admins,cn=groups,cn=accounts,dc=stand,dc=local" time: 20241007101727
dn: cn=admins,cn=groups,cn=accounts,dc=stand,dc=local result: 0
changetype: modify add: member member: uid=user2,cn=users,cn=accounts,dc=stand,dc=local replace: modifiersname
modifiersname: uid=admin,cn=users,cn=accounts,dc=stand,dc=local
replace: modifytimestamp
modifytimestamp: 20241007071727Z
replace: entryusn
entryusn: 5283

IP-адрес 11.62.10.236 из события выше принадлежит самому серверу FreeIPA. Может, изменения внесли через веб-консоль FreeIPA?

Найдем адрес, с которого подключались фактически, в access-логах демона httpd:
11.62.10.147 - [e-mail] [07/Oct/2024:10:17:02 +0300] "POST /ipa/session/json HTTP/1.1" 200 222

Killchain атак на FreeIPA

Теперь, когда мы разобрали все атаки и методы их выявления по отдельности, давайте рассмотрим полный Kill Chain атак на систему FreeIPA:

Стрелками показаны движения злоумышленника, цифрами — правила корреляции, которые мы приводили в обоих частях цикла:

1. Anonymous BIND

2. Simple BIND

3. PassSpray Kerberos

4. BruteForce Kerberos

5. User LockedOut

6. LDAP BruteForce Crit

7. LDAP auth Crit User

8. LDAP PassSpray

9. LDAP Recon

10. Expensive LDAP req

11. KeyRing access

12. Hash DB files access

13. Keytab files access

14. Suspicious req Ticket

15. Access crit LDAP obj

В центре слева — хост атакующего, который имеет только сетевые доступы к инфраструктуре FreeIPA. Соответственно, атакующий способен вести разведку анонимными запросами к LDAP-каталогу. Он может выполнять атаки Password Spraying и Password BruteForce по протоколу LDAP и Kerberos либо по протоколу LDAP атаковать пользователя Directory Manager. Успешная атаки на пользователя Directory Manager приведет к полной удаленной компрометации всех хешей паролей пользователей и ключей Kerberos домена FreeIPA.

Если атакующий не подобрал пароль пользователя Directory Manager, но скомпрометировал рядовую учетную запись, он может выпустить для нее билет Kerberos. И если в системе используются настройки по умолчанию, с этим билетом он попадет на сервер FreeIPA, где, повысив привилегии в ОС, атакует файлы LDAP-каталога, чем скомпрометирует хеши паролей пользователей и ключи Kerberos.

Вверху слева показан старт злоумышленника, который уже открыл один из рядовых хостов в домене FreeIPA. У него появляется возможность извлекать Kerberos-билеты и хеши из операционной системы, а также использовать найденные учетные записи пользователей для разведки в LDAP-каталоге.

Вне зависимости от схемы движения, после компрометации домена FreeIPA атакующему остается только закрепиться в системе, например внеся изменения в критичную группу, либо изменить конфигурацию LDAP-каталога так, чтобы получить доступ к целевой системе.

На схеме видно, что злоумышленника можно детектировать на каждом этапе продвижения, правильно настроив журналирование и мониторинг. Поэтому, если в вашей организации используется FreeIPA, рекомендуем мониторить события на всех возможных этапах Kill Сhain, как предложено выше.

Надеемся, этот материал был полезным! На вопросы с радостью ответим в комментариях.