• XSS.stack #1 – первый литературный журнал от юзеров форума

Статья Простой анализ логов [ OSQuery / MITRE / Doorman - Часть 2 ]

grozdniyandy

White-Hat
Premium
Регистрация
11.08.2023
Сообщения
522
Реакции
677
Гарант сделки
2

osqueryi​

Я решил завершить серию статей, которые собирался написать на форуме, а затем начать несколько новых тем, которые здесь особо не обсуждались. После 2-4 статей вы можете ожидать статьи о "Пентестировании мобильных приложений", "Анализе вредоносных программ", "DevSecOps" и "AWS Cloud Security". Я пишу это потому что был бы рад, если бы вы прислали мне материалы, которые, по вашему мнению, интересны. В этой статье мы познакомимся с Doorman и Mitre.

Содержание
  • То что осталось с первой части
  • Ознакомление с Doorman и Mitre
  • Лаборатории
У нас есть три нераскрытые лаборатории из прошлой статьи. После их завершения мы сами настроим Doorman и попробуем немного поработать с ним.

Лаборатория №5

1. Существует процесс, прослушивающий порт 80. Укажите абсолютный путь к файлу этого процесса.
Существует таблица под названием "listening_ports", как вы можете понять из ее названия, в ней показаны порты прослушивания на нашем компьютере, oткрытые порты кароч.

Изображение [1]: Открытые порты у меня в VM

Изображение [1]: Открытые порты у меня в VM​


Процесс, использующий порт "80", имеет pid "9"
Код:
osquery> select * from listening_ports;
+-----+-------+----------+--------+------------+----+-----------+----------------------------+---------------+
| pid | port  | protocol | family | address    | fd | socket    | path                       | net_namespace |
+-----+-------+----------+--------+------------+----+-----------+----------------------------+---------------+
| 204 | 8000  | 6        | 2      | 0.0.0.0    | 6  | 602965077 |                            | 4026534167    |
| -1  | 44939 | 6        | 2      | 127.0.0.11 | -1 | 602946074 |                            | 4026534167    |
| 9   | 80    | 6        | 2      | 0.0.0.0    | 3  | 602954902 |                            | 4026534167    |
| 39  | 22    | 6        | 2      | 0.0.0.0    | 3  | 602929870 |                            | 4026534167    |
| 53  | 23    | 6        | 2      | 0.0.0.0    | 4  | 602949112 |                            | 4026534167    |
| 20  | 21    | 6        | 10     | ::         | 3  | 602916743 |                            | 4026534167    |
| 39  | 22    | 6        | 10     | ::         | 4  | 602929872 |                            | 4026534167    |
| -1  | 43701 | 17       | 2      | 127.0.0.11 | -1 | 602946073 |                            | 4026534167    |
| 204 | 0     | 0        | 1      |            | 12 | 0         | /root/.osquery/shell.em    | 4026534167    |
| 1   | 0     | 0        | 1      |            | 4  | 0         | /var/run/supervisor.sock.1 | 4026534167    |
| 204 | 8000  | 6        | 2      | 0.0.0.0    | 6  | 602965077 |                            | 0             |
| -1  | 44939 | 6        | 2      | 127.0.0.11 | -1 | 602946074 |                            | 0             |
| 9   | 80    | 6        | 2      | 0.0.0.0    | 3  | 602954902 |                            | 0             | -----> Tuta
| 39  | 22    | 6        | 2      | 0.0.0.0    | 3  | 602929870 |                            | 0             |
| 53  | 23    | 6        | 2      | 0.0.0.0    | 4  | 602949112 |                            | 0             |
| 20  | 21    | 6        | 10     | ::         | 3  | 602916743 |                            | 0             |
| 39  | 22    | 6        | 10     | ::         | 4  | 602929872 |                            | 0             |
| -1  | 43701 | 17       | 2      | 127.0.0.11 | -1 | 602946073 |                            | 0             |
| 204 | 0     | 0        | 1      |            | 12 | 0         | /root/.osquery/shell.em    | 0             |
| 1   | 0     | 0        | 1      |            | 4  | 0         | /var/run/supervisor.sock.1 | 0             |
+-----+-------+----------+--------+------------+----+-----------+----------------------------+---------------+

Мы нашли процесс, он запущен apache2, и путь указан в таблице.
Код:
osquery> select * from processes where pid = 9;
+-----+---------+-------------------+-----------------------+-------+-------+------+-----+-----+------+------+------+------+---------+------------+---------------+------------+-----------+-------------+-----------------+--------------------+------------+--------+--------+---------+------+
| pid | name    | path              | cmdline               | state | cwd   | root | uid | gid | euid | egid | suid | sgid | on_disk | wired_size | resident_size | total_size | user_time | system_time | disk_bytes_read | disk_bytes_written | start_time | parent | pgroup | threads | nice |
+-----+---------+-------------------+-----------------------+-------+-------+------+-----+-----+------+------+------+------+---------+------------+---------------+------------+-----------+-------------+-----------------+--------------------+------------+--------+--------+---------+------+
| 9   | apache2 | /usr/sbin/apache2 | apache2 -D FOREGROUND | S     | /root | /    | 0   | 0   | 0    | 0    | 0    | 0    | 1       | 0          | 4932000       | 71580000   | 0         | 60          | 151552          | 16384              | 8486514    | 1      | 9      | 1       | 0    |
+-----+---------+-------------------+-----------------------+-------+-------+------+-----+-----+------+------+------+------+---------+------------+---------------+------------+-----------+-------------+-----------------+--------------------+------------+--------+--------+---------+------+

2. Сколько пользователей в данный момент вошли в систему?
Без комментов.
Код:
osquery> select * from logged_in_users;
+------+------+-------+------------------------------------------------+------------+-----+
| type | user | tty   | host                                           | time       | pid |
+------+------+-------+------------------------------------------------+------------+-----+
| user | john | pts/1 | 192.75.93.3                                    | 1696337513 | 181 |
| user | rose | pts/3 | 127.0.0.1                                      | 1696337505 | 86  |
| user | kate | pts/0 | mvruani0g2x3ovdw6ciappy3v.temp-network_a-75-93 | 1696337509 | 169 |
+------+------+-------+------------------------------------------------+------------+-----+

3. Какой пользователь вошел в систему с удаленного компьютера с помощью SSH?
В таблице "logged_in_users" у нас есть идентификаторы процессов, мы можем объединить их и идентификаторы процессов из таблицы "processes" и посмотреть, какие команды выполняются этими пользователями. Мы видим, что "john" и "rose" подключены с помощью "ssh", но "john" подключен удаленно (столбец host).
Код:
osquery> select processes.name,processes.cmdline,logged_in_users.pid,logged_in_users.host from processes inner join logged_in_users on processes.pid = logged_in_users.pid;
+------+-------------------+-----+------------------------------------------------+
| name | cmdline           | pid | host                                           |
+------+-------------------+-----+------------------------------------------------+
| sshd | sshd: john [priv] | 181 | 192.75.93.3                                    |
| sshd | sshd: rose [priv] | 86  | 127.0.0.1                                      |
| bash | -bash             | 169 | mvruani0g2x3ovdw6ciappy3v.temp-network_a-75-93 |
+------+-------------------+-----+------------------------------------------------+

4.Сколько раз пользователь "john" заходил на этот компьютер?
Существует таблица под названием "last", и, как я понимаю, в этой таблице отображается "история" входа по ssh. Я прикрепил скриншот ниже, потому что в нем есть столбец "type_name". Что показывает нам, что тип 7 означает живой процесс, тип 8 означает мертвый процесс.


Изображение [2]: Таблица last

Изображение [2]: Таблица "last"​
Пользователь "john" вошел в систему 2 раза, и оба подключения действительны (процессы не остановлены).
Код:
osquery> select * from last;
+----------+-------+-----+------+------------+------------------------------------------------+
| username | tty   | pid | type | time       | host                                           |
+----------+-------+-----+------+------------+------------------------------------------------+
| john     | pts/1 | 58  | 7    | 1696337504 | 192.75.93.3                                    |
| rose     | pts/3 | 86  | 7    | 1696337505 | 127.0.0.1                                      |
|          | pts/1 | 58  | 8    | 1696337508 |                                                |
| kate     | pts/0 | 57  | 7    | 1696337509 | mvruani0g2x3ovdw6ciappy3v.temp-network_a-75-93 |
| john     | pts/1 | 181 | 7    | 1696337513 | 192.75.93.3                                    |
+----------+-------+-----+------+------------+------------------------------------------------+

5. У какого пользователя есть приватный SSH-ключ?
Когда мы попытаемся получить ssh-ключи, поскольку у нашего пользователя их нет, мы получим пустой ответ. Мы можем объединить таблицы "users" и "user_ssh_keys", но мы должны понимать, какая информация нам от них нужна и какие столбцы у них общие. Мы можем видеть, что столбец "uid" присутствует в них обоих, таблица "user_ssh_keys" содержит столбец "path", который является путем к ssh-ключу, а таблица "users" имеет столбец "username", который является ответом на вопрос.
Код:
osquery> pragma table_info(user_ssh_keys);
+-----+-----------+---------+---------+------------+----+
| cid | name      | type    | notnull | dflt_value | pk |
+-----+-----------+---------+---------+------------+----+
| 0   | uid       | BIGINT  | 1       |            | 1  |
| 1   | path      | TEXT    | 1       |            | 2  |
| 2   | encrypted | INTEGER | 0       |            | 0  |
+-----+-----------+---------+---------+------------+----+
osquery> pragma table_info(users);
+-----+-------------+--------+---------+------------+----+
| cid | name        | type   | notnull | dflt_value | pk |
+-----+-------------+--------+---------+------------+----+
| 0   | uid         | BIGINT | 1       |            | 1  |
| 1   | gid         | BIGINT | 0       |            | 0  |
| 2   | uid_signed  | BIGINT | 0       |            | 0  |
| 3   | gid_signed  | BIGINT | 0       |            | 0  |
| 4   | username    | TEXT   | 1       |            | 2  |
| 5   | description | TEXT   | 0       |            | 0  |
| 6   | directory   | TEXT   | 0       |            | 0  |
| 7   | shell       | TEXT   | 0       |            | 0  |
| 8   | uuid        | TEXT   | 0       |            | 0  |
+-----+-------------+--------+---------+------------+----+
osquery> select user_ssh_keys.path,users.username from users inner join user_ssh_keys on user_ssh_keys.uid=users.uid;
+------------------------+----------+
| path                   | username |
+------------------------+----------+
| /home/rose/.ssh/id_rsa | rose     |
+------------------------+----------+

6. Какой протокол удаленного администрирования используется пользователем "kate" для текущего текущего сеанса?
Что ж, мы можем просто проверить столбец "host" таблицы "logged_in_users", а затем выполнить поиск команды, которая "содержит" значение в этом столбце.
Код:
osquery> select * from logged_in_users;
+------+------+-------+------------------------------------------------+------------+-----+
| type | user | tty   | host                                           | time       | pid |
+------+------+-------+------------------------------------------------+------------+-----+
| user | john | pts/1 | 192.75.93.3                                    | 1696337513 | 181 |
| user | rose | pts/3 | 127.0.0.1                                      | 1696337505 | 86  |
| user | kate | pts/0 | mvruani0g2x3ovdw6ciappy3v.temp-network_a-75-93 | 1696337509 | 169 |
+------+------+-------+------------------------------------------------+------------+-----+
osquery> select * from processes where cmdline like '%mvruani0g2x3ovdw6ciappy3v.temp-network_a-75-93%';
+-----+------------+------+------------------------------------------------------------+-------+-----+------+-----+------+------+------+------+------+---------+------------+---------------+------------+-----------+-------------+-----------------+--------------------+------------+--------+--------+---------+------+
| pid | name       | path | cmdline                                                    | state | cwd | root | uid | gid  | euid | egid | suid | sgid | on_disk | wired_size | resident_size | total_size | user_time | system_time | disk_bytes_read | disk_bytes_written | start_time | parent | pgroup | threads | nice |
+-----+------------+------+------------------------------------------------------------+-------+-----+------+-----+------+------+------+------+------+---------+------------+---------------+------------+-----------+-------------+-----------------+--------------------+------------+--------+--------+---------+------+
| 56  | in.telnetd |      | in.telnetd: mvruani0g2x3ovdw6ciappy3v.temp-network_a-75-93 | S     |     |      | 108 | 112  | 108  | 112  | 108  | 112  | -1      | 0          | 2124000       | 19168000   | 0         | 0           |                 | 0                  | 8486518    | 53     | 56     | 1       | 0    |
| 57  | login      |      | login -h mvruani0g2x3ovdw6ciappy3v.temp-network_a-75-93 -p | S     |     |      | 0   | 1002 | 0    | 1002 | 0    | 1002 | -1      | 0          | 3196000       | 67708000   | 0         | 0           |                 | 0                  | 8486518    | 56     | 57     | 1       | 0    |
+-----+------------+------+------------------------------------------------------------+-------+-----+------+-----+------+------+------+------+------+---------+------------+---------------+------------+-----------+-------------+-----------------+--------------------+------------+--------+--------+---------+------+
Ответ, telnet. Мы могли бы также проверить руководство по команде "login", так как вы можете видеть, что используется опция "-h".
Код:
       -h
           Used by other servers (such as telnetd(8) to pass the name of
           the remote host to login so that it can be placed in utmp and
           wtmp. Only the superuser is allowed use this option.
        
Ссылка: https://man7.org/linux/man-pages/man1/login.1.html

продолжение в комментах

Лаборатория №6

1. Найдите имя процесса, который прослушивает порт по протоколу UDP.
Сначала я проверил столбцы, которые есть в обеих таблицах. Как мы можем видеть, столбец "pid" существует в обеих таблицах. Мы должны найти процесс, который использует протокол UDP. Поэтому я буду использовать столбцы "port" и "protocol" из таблицы "listening_ports" и столбец "cmdline" из таблицы "processes".
Код:
osquery> pragma table_info(listening_ports);
+-----+---------------+---------+---------+------------+----+
| cid | name          | type    | notnull | dflt_value | pk |
+-----+---------------+---------+---------+------------+----+
| 0   | pid           | INTEGER | 0       |            | 0  |
| 1   | port          | INTEGER | 0       |            | 0  |
| 2   | protocol      | INTEGER | 0       |            | 0  |
| 3   | family        | INTEGER | 0       |            | 0  |
| 4   | address       | TEXT    | 0       |            | 0  |
| 5   | fd            | BIGINT  | 0       |            | 0  |
| 6   | socket        | BIGINT  | 0       |            | 0  |
| 7   | path          | TEXT    | 0       |            | 0  |
| 8   | net_namespace | TEXT    | 0       |            | 0  |
+-----+---------------+---------+---------+------------+----+
osquery> pragma table_info(processes);
+-----+--------------------+---------+---------+------------+----+
| cid | name               | type    | notnull | dflt_value | pk |
+-----+--------------------+---------+---------+------------+----+
| 0   | pid                | BIGINT  | 1       |            | 1  |
| 1   | name               | TEXT    | 0       |            | 0  |
| 2   | path               | TEXT    | 0       |            | 0  |
| 3   | cmdline            | TEXT    | 0       |            | 0  |
| 4   | state              | TEXT    | 0       |            | 0  |
| 5   | cwd                | TEXT    | 0       |            | 0  |
| 6   | root               | TEXT    | 0       |            | 0  |
| 7   | uid                | BIGINT  | 0       |            | 0  |
| 8   | gid                | BIGINT  | 0       |            | 0  |
| 9   | euid               | BIGINT  | 0       |            | 0  |
| 10  | egid               | BIGINT  | 0       |            | 0  |
| 11  | suid               | BIGINT  | 0       |            | 0  |
| 12  | sgid               | BIGINT  | 0       |            | 0  |
| 13  | on_disk            | INTEGER | 0       |            | 0  |
| 14  | wired_size         | BIGINT  | 0       |            | 0  |
| 15  | resident_size      | BIGINT  | 0       |            | 0  |
| 16  | total_size         | BIGINT  | 0       |            | 0  |
| 17  | user_time          | BIGINT  | 0       |            | 0  |
| 18  | system_time        | BIGINT  | 0       |            | 0  |
| 19  | disk_bytes_read    | BIGINT  | 0       |            | 0  |
| 20  | disk_bytes_written | BIGINT  | 0       |            | 0  |
| 21  | start_time         | BIGINT  | 0       |            | 0  |
| 22  | parent             | BIGINT  | 0       |            | 0  |
| 23  | pgroup             | BIGINT  | 0       |            | 0  |
| 24  | threads            | INTEGER | 0       |            | 0  |
| 25  | nice               | INTEGER | 0       |            | 0  |
+-----+--------------------+---------+---------+------------+----+
osquery> select listening_ports.port,listening_ports.protocol,processes.cmdline from listening_ports inner join processes on processes.pid=listening_ports.pid;
+------+----------+------------------------------------------------+
| port | protocol | cmdline                                        |
+------+----------+------------------------------------------------+
| 80   | 6        | apache2 -D FOREGROUND                          |
| 2000 | 6        | /opt/service                                   |
| 22   | 6        | /usr/sbin/sshd                                 |
| 4444 | 6        | /usr/bin/server5                               |
| 8000 | 6        | /usr/local/bin/ttyd -s SIGKILL -p 8000 osquery |
| 7777 | 6        | /home/john/server1                             |
| 9000 | 6        | /usr/local/bin/temp                            |
| 7977 | 6        | /home/john/server1                             |
| 21   | 6        | /usr/sbin/vsftpd                               |
| 22   | 6        | /usr/sbin/sshd                                 |
| 1888 | 6        | /home/tom/comm                                 |
| 8787 | 17       | /home/john/listener1                           | -------->Tuta
| 0    | 0        | /usr/bin/python /usr/bin/supervisord -n        |
| 0    | 0        | /usr/bin/receive                               |
| 0    | 0        | osqueryi --logger_min_status 1                 |
| 0    | 0        | /usr/bin/receive                               |
| 80   | 6        | apache2 -D FOREGROUND                          |
| 2000 | 6        | /opt/service                                   |
| 22   | 6        | /usr/sbin/sshd                                 |
| 4444 | 6        | /usr/bin/server5                               |
| 8000 | 6        | /usr/local/bin/ttyd -s SIGKILL -p 8000 osquery |
| 7777 | 6        | /home/john/server1                             |
| 9000 | 6        | /usr/local/bin/temp                            |
| 7977 | 6        | /home/john/server1                             |
| 21   | 6        | /usr/sbin/vsftpd                               |
| 22   | 6        | /usr/sbin/sshd                                 |
| 1888 | 6        | /home/tom/comm                                 |
| 8787 | 17       | /home/john/listener1                           | -------->Tuta
| 0    | 0        | /usr/bin/python /usr/bin/supervisord -n        |
| 0    | 0        | /usr/bin/receive                               |
| 0    | 0        | osqueryi --logger_min_status 1                 |
| 0    | 0        | /usr/bin/receive                               |
+------+----------+------------------------------------------------+
Каждый протокол, работающий по IP, имеет свой собственный номер, для TCP это номер 6, а для UDP - номер 17. Как вы можете видеть, команда "/home/john/listener1" имеет номер протокола 17, который является UDP.

2. Найдите путь к файлу родительского процесса, который создал дочерние (child) процессы для прослушивания на двух разных портах.
Я использовал запрос (query) для предыдущего вопроса и добавил возможность удалить дубликаты.
Код:
osquery> select listening_ports.port,listening_ports.protocol,processes.cmdline from listening_ports inner join processes on processes.pid=listening_ports.pid group by listening_ports.port
,listening_ports.protocol,processes.cmdline having count(*) > 1;
+------+----------+------------------------------------------------+
| port | protocol | cmdline                                        |
+------+----------+------------------------------------------------+
| 0    | 0        | /usr/bin/python /usr/bin/supervisord -n        |
| 0    | 0        | /usr/bin/receive                               |
| 0    | 0        | osqueryi --logger_min_status 1                 |
| 21   | 6        | /usr/sbin/vsftpd                               |
| 22   | 6        | /usr/sbin/sshd                                 |
| 80   | 6        | apache2 -D FOREGROUND                          |
| 1888 | 6        | /home/tom/comm                                 |
| 2000 | 6        | /opt/service                                   |
| 4444 | 6        | /usr/bin/server5                               |
| 7777 | 6        | /home/john/server1                             | -------->Tuta
| 7977 | 6        | /home/john/server1                             | -------->Tuta
| 8000 | 6        | /usr/local/bin/ttyd -s SIGKILL -p 8000 osquery |
| 8787 | 17       | /home/john/listener1                           |
| 9000 | 6        | /usr/local/bin/temp                            |
+------+----------+------------------------------------------------+
Как вы можете видеть, "/home/john/server1" использует 2 разных порта "7777" и "7977", это наш ответ.

3. Найдите имя процесса, который прослушивает локальный порт 1888 по ipv6-адресу локальной машины.
Как мы можем видеть из таблицы, ответом является "comm".
Код:
osquery> select listening_ports.port,listening_ports.protocol,processes.cmdline from listening_ports inner join processes on processes.pid=listening_ports.pid group by listening_ports.port
,listening_ports.protocol,processes.cmdline having count(*) > 1;
+------+----------+------------------------------------------------+
| port | protocol | cmdline                                        |
+------+----------+------------------------------------------------+
| 0    | 0        | /usr/bin/python /usr/bin/supervisord -n        |
| 0    | 0        | /usr/bin/receive                               |
| 0    | 0        | osqueryi --logger_min_status 1                 |
| 21   | 6        | /usr/sbin/vsftpd                               |
| 22   | 6        | /usr/sbin/sshd                                 |
| 80   | 6        | apache2 -D FOREGROUND                          |
| 1888 | 6        | /home/tom/comm                                 |
| 2000 | 6        | /opt/service                                   |
| 4444 | 6        | /usr/bin/server5                               |
| 7777 | 6        | /home/john/server1                             |
| 7977 | 6        | /home/john/server1                             |
| 8000 | 6        | /usr/local/bin/ttyd -s SIGKILL -p 8000 osquery |
| 8787 | 17       | /home/john/listener1                           |
| 9000 | 6        | /usr/local/bin/temp                            |
+------+----------+------------------------------------------------+

4. Найдите имя процесса, который установил соединение с удаленным хостом через локальный порт 2000.
Ответ очевиден, "service"
Код:
osquery> select listening_ports.port,listening_ports.protocol,processes.cmdline from listening_ports inner join processes on processes.pid=listening_ports.pid group by listening_ports.port
,listening_ports.protocol,processes.cmdline having count(*) > 1;
+------+----------+------------------------------------------------+
| port | protocol | cmdline                                        |
+------+----------+------------------------------------------------+
| 0    | 0        | /usr/bin/python /usr/bin/supervisord -n        |
| 0    | 0        | /usr/bin/receive                               |
| 0    | 0        | osqueryi --logger_min_status 1                 |
| 21   | 6        | /usr/sbin/vsftpd                               |
| 22   | 6        | /usr/sbin/sshd                                 |
| 80   | 6        | apache2 -D FOREGROUND                          |
| 1888 | 6        | /home/tom/comm                                 |
| 2000 | 6        | /opt/service                                   |
| 4444 | 6        | /usr/bin/server5                               |
| 7777 | 6        | /home/john/server1                             |
| 7977 | 6        | /home/john/server1                             |
| 8000 | 6        | /usr/local/bin/ttyd -s SIGKILL -p 8000 osquery |
| 8787 | 17       | /home/john/listener1                           |
| 9000 | 6        | /usr/local/bin/temp                            |
+------+----------+------------------------------------------------+

5. Найдите название процесса, который загружает данные с удаленного компьютера, прослушивающего удаленный порт 4000.
Существует таблица "process_open_sockets", в ней показаны все входящие и исходящие соединения. Нам придется использовать эту таблицу, чтобы ответить на этот вопрос.

Мы уже знаем, что таблица "processes" имеет столбец "pid", и мы видим, что таблица "process_open_sockets" имеет столбец "remote_port". Чтобы ответить на наш вопрос, мы просто объединим две таблицы.
Код:
osquery> pragma table_info(process_open_sockets);
+-----+----------------+---------+---------+------------+----+
| cid | name           | type    | notnull | dflt_value | pk |
+-----+----------------+---------+---------+------------+----+
| 0   | pid            | INTEGER | 1       |            | 1  |
| 1   | fd             | BIGINT  | 0       |            | 0  |
| 2   | socket         | BIGINT  | 0       |            | 0  |
| 3   | family         | INTEGER | 0       |            | 0  |
| 4   | protocol       | INTEGER | 0       |            | 0  |
| 5   | local_address  | TEXT    | 0       |            | 0  |
| 6   | remote_address | TEXT    | 0       |            | 0  |
| 7   | local_port     | INTEGER | 0       |            | 0  |
| 8   | remote_port    | INTEGER | 0       |            | 0  |
| 9   | path           | TEXT    | 0       |            | 0  |
| 10  | state          | TEXT    | 0       |            | 0  |
| 11  | net_namespace  | TEXT    | 0       |            | 0  |
+-----+----------------+---------+---------+------------+----+
osquery> select process_open_sockets.remote_port,processes.cmdline from process_open_sockets inner join processes on process_open_sockets.pid=processes.pid;
+-------------+------------------------------------------------+
| remote_port | cmdline                                        |
+-------------+------------------------------------------------+
| 0           | apache2 -D FOREGROUND                          |
| 0           | /opt/service                                   |
| 0           | /usr/sbin/sshd                                 |
| 0           | /usr/bin/server5                               |
| 0           | /usr/local/bin/ttyd -s SIGKILL -p 8000 osquery |
| 0           | /home/john/server1                             |
| 0           | /usr/local/bin/temp                            |
| 0           | /home/john/server1                             |
| 52372       | /opt/service                                   |
| 4000        | /root/updater                                  |
| 58944       | /usr/local/bin/ttyd -s SIGKILL -p 8000 osquery |
| 0           | /usr/sbin/vsftpd                               |
| 0           | /usr/sbin/sshd                                 |
| 0           | /home/tom/comm                                 |
| 0           | /home/john/listener1                           |
| 0           | /usr/bin/python /usr/bin/supervisord -n        |
| 0           | /usr/bin/receive                               |
| 0           | osqueryi --logger_min_status 1                 |
| 0           | osqueryi --logger_min_status 1                 |
| 0           | osqueryi --logger_min_status 1                 |
| 0           | /usr/bin/receive                               |
| 0           | osqueryi --logger_min_status 1                 |
| 0           | osqueryi --logger_min_status 1                 |
| 0           | /usr/bin/process                               |
| 0           | apache2 -D FOREGROUND                          |
| 0           | /opt/service                                   |
| 0           | /usr/sbin/sshd                                 |
| 0           | /usr/bin/server5                               |
| 0           | /usr/local/bin/ttyd -s SIGKILL -p 8000 osquery |
| 0           | /home/john/server1                             |
| 0           | /usr/local/bin/temp                            |
| 0           | /home/john/server1                             |
| 52372       | /opt/service                                   |
| 4000        | /root/updater                                  |
| 58944       | /usr/local/bin/ttyd -s SIGKILL -p 8000 osquery |
| 0           | /usr/sbin/vsftpd                               |
| 0           | /usr/sbin/sshd                                 |
| 0           | /home/tom/comm                                 |
| 0           | /home/john/listener1                           |
| 0           | /usr/bin/python /usr/bin/supervisord -n        |
| 0           | /usr/bin/receive                               |
| 0           | osqueryi --logger_min_status 1                 |
| 0           | osqueryi --logger_min_status 1                 |
| 0           | osqueryi --logger_min_status 1                 |
| 0           | /usr/bin/receive                               |
| 0           | osqueryi --logger_min_status 1                 |
| 0           | osqueryi --logger_min_status 1                 |
| 0           | /usr/bin/process                               |
+-------------+------------------------------------------------+

6. Найдите имя процесса, который использует доменный сокет '/tmp/secret.sock'.
Мы можем объединить столбец "path" таблицы "process_open_sockets" со столбцами "name" таблицы "processes".
Код:
osquery> select process_open_sockets.path,processes.name from process_open_sockets inner join processes on processes.pid=process_open_sockets.pid;
+----------------------------+-------------+
| path                       | name        |
+----------------------------+-------------+
|                            | apache2     |
|                            | service     |
|                            | sshd        |
|                            | server5     |
|                            | ttyd        |
|                            | server1     |
|                            | temp        |
|                            | server1     |
|                            | service     |
|                            | updater     |
|                            | ttyd        |
|                            | vsftpd      |
|                            | sshd        |
|                            | comm        |
|                            | listener1   |
| /var/run/supervisor.sock.1 | supervisord |
| /tmp/secret.sock           | receive     |
| /root/.osquery/shell.em    | osqueryi    |
|                            | osqueryi    |
|                            | osqueryi    |
| /tmp/secret.sock           | receive     |
|                            | osqueryi    |
|                            | osqueryi    |
|                            | process     |
|                            | apache2     |
|                            | service     |
|                            | sshd        |
|                            | server5     |
|                            | ttyd        |
|                            | server1     |
|                            | temp        |
|                            | server1     |
|                            | service     |
|                            | updater     |
|                            | ttyd        |
|                            | vsftpd      |
|                            | sshd        |
|                            | comm        |
|                            | listener1   |
| /var/run/supervisor.sock.1 | supervisord |
| /tmp/secret.sock           | receive     |
| /root/.osquery/shell.em    | osqueryi    |
|                            | osqueryi    |
|                            | osqueryi    |
| /tmp/secret.sock           | receive     | -------->Tuta
|                            | osqueryi    |
|                            | osqueryi    |
|                            | process     |
+----------------------------+-------------+

Ознакомление с Doorman и Mitre​

Что такое MITRE?​

Корпорация Mitre (MITRE) - американская некоммерческая организация, оказывающая поддержку различным правительственным учреждениям США в различных областях, одной из которых является кибербезопасность.

Что такое тактика?
Тактика - это цели, которых хакеры стремятся достичь во время кибератаки. Это просто "то, чего" на самом деле хочет достичь хакер.

Что такое техника?
Техники - это специфические методы, которые хакеры используют для достижения своих тактических целей. Это просто способ, который показывает, "как или каким образом" хакер хочет достичь своей цели.

MITRE ATT&CK® (Adversarial Tactics, Techniques, and Common Knowledge - Состязательная тактика, методы и общие знания) - это фреймворк, который предоставляет информацию о тактиках, методах и процедурах (TTP - Tactics, Techniques, Procedures), обычно используемых киберпреступниками на различных этапах кибератаки.

Что такое матрица MITRE ATT&CK?
Матрица MITRE ATT&CK это представление тактик, техник и процедур, каждая ячейка в матрице соответствует определенной технике и ее дочерним (child) тактикам.

Изображение [1]: Матрица MITRE ATT&CK

Изображение [1]: Матрица MITRE ATT&CK​

Матрица MITRE ATT&CK организована в таком виде что, на горизонтальной оси которой указаны техники, а на вертикальной тактики.

Ладно, теперь давайте разберемся во всех тактиках.

Разведка (Reconnaissance)
На этом этапе хакеры собирают информацию о целевой системе, чтобы идентифицировать потенциально ценные активы. Разведка делится на 2 части, активную и пассивную.
"А теперь давайте подумаем об этом так, как это делаю я. Как вы знаете, иногда я пишу отчеты о пентестировании веб-приложений. В этих отчетах также есть pазведка. Разведка разделена на 2 части, активную и пассивную. Пассивная разведка - это сбор информации о системе без непосредственного вмешательства в нее, тоесть мы саму систему не трогаем. Это как разузнать о ком то, через знакомого, не общаясь с самим типом. Система может быть неработоспособна, мы не знаем, наша работа заключается в сборе информации, даже не пингуя (ping) ее. При активной разведке нам разрешается вмешиваться в работу системы (можем её потрогать). Мы можем пропинговать его, выполнить активное сканирование и так далее. Обычно большая часть моих отчетов включает сбор поддоменов и информации об используемых технологиях, типа wordpress, adminer, phpmyadmin и тп." - Источник: https://xss.pro/threads/97534/

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

Первоначальный доступ
Первоначальный доступ - это этап, на котором злоумышленники получают свою первую точку входа в систему. Методы, которые здесь используются, включают в себя: фишинг, внешние удаленные сервисы, действительные учетные записи и т.д.

Исполнение
Исполнение - это когда хакер запускает вредоносный код в системе. Этa тактика может сочетаться с другими тактиками. Например, при повышении привилегий хакер может выполнить код на Python.

Постоянство
Постоянство - это сохранение доступа к скомпрометированной системе, оно позволяет хакерам входить в систему, когда они захотят. На самом деле смысл всего этого в том, чтобы сделать систему по-прежнему доступной для хакера, даже если учетные данные изменились, или система перезапустилась и т.д. Простым примером могут быть веб-оболочки, хакер может внедрить бэкдор в систему с помощью веб-оболочки для постоянного доступа.

Повышение привилегий
Повышение привилегий предполагает повышение уровня привилегий доступа, которые уже есть у хакера. Простым примером этого может быть базовое повышение привилегий в Linux. Для этого вы можете ознакомиться с моей статьей - https://xss.pro/threads/98617/

Уклонение от защиты
Тактика уклонения от защиты используется для того, чтобы избежать механизмов обнаружения, применяемых решениями безопасности. Один из примеров приведен в электронном журнале - Inception #7 - https://xss.pro/threads/99403/

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

Обнаружение
На этапе обнаружения хакеры собирают информацию о внутренней среде. Разница между обнаружением и разведкой заключается в том, что при разведке основная цель состоит в том, чтобы получить как можно больше информации о цели, которая может идентифицировать потенциальную точку входа, но при обнаружении главная цель заключается в премещении внутри системы, это позволит расширить "территорию" атакующего.

Боковое перемещение
Боковое перемещение - это процесс изучения/познования сети и получения доступа к найденным целям - Находим цели, а потом владеем ими aka pwn. По сути, они перемещаются внутри сети. Как написано в MITRE, "Достижение их цели часто включает в себя использование нескольких систем и учетных записей..."

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

Командование и контроль (К2)
Командование и контроль означают установление каналов связи между хакером и управляемыми системами.
C2 - значит Command & Control
админ центр для ботов. Схема следующая: бот делает запрос на сервер -> получает команду которую ввел оператор -> выполняет команду -> отправляет ответ обратно на ц2, и так по кругу, ботов может быть несколько, как и могут быть дополнительные модули: сокс, файловый менеджер, работа с памятью
это если в двух словах

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

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

1696683486763.png

Изображение [2] : Разведка​

Как вы можете видеть на скриншоте выше, у каждой техники и тактики есть идентификатор. Тактика "Разведка" имеет идентификатор TA0043, а техника "Поиск открытых веб-сайтов/доменов" имеет идентификатор "T1593".

Что такое Doorman?​

Doorman - это менеджер osquery, который позволяет администраторам удаленно управлять конфигурацией запросов ОС, получаемых узлами. - Источник: https://github.com/mwielgoszewski/doorman

В будущем я объединю OSQuery с Wazuh и создам "агенты", чтобы посмотреть, как это работает. Я проверил Doorman и пришел к выводу, что лучше использовать Wazuh для создания системы обнаружения вторжений на хост. Если кто-то из читателей все равно захочет, чтобы я настроил "Doorman", пожалуйста, напишите в личку или оставьте комментарий.

Лаборатории​

Эти лаборатории представляют собой комбинацию "Doorman", "MITRE" и "OSQuery".

Лаборатория №1

1. Укажите полный путь к веб-оболочке, загруженной на скомпрометированный (захваченный) сервер.
Давайте сначала познакомимся с графическим интерфейсом.

1696688108259.png

Изображение [3] : Doorman​

Можете исправить если чем то ошибусь, буду только рад! Если найдёте документацию по Doorman скиньте пожалуйста.

То, что вы видите, - это неактивные узлы. У них есть:
Идентификатор хоста - он используется, чтобы отличить один хост от другого - это псевдоним, который вы можете присвоить.
Ключ узла - насколько я понимаю, это идентификатор узла.
Последний IP-адрес / Дата регистрации / Дата последнего входа - можно понять по именам.
Теги - это теги, которые используются в MITRE, мы можем видеть теги "T1100" и "T1158". T1100- BruteForce. T1158 - "Скрытые файлы и каталоги" - Хакеры могут скрыть некоторые файлы и каталоги таким образом, что они не будут просто доступны обычным пользователям. Одним из примеров является использование "." в начале имени файла, что делает его "скрытым".

Теперь вернемся к вопросу, как следует из названия, это "веб-оболочка", поэтому мы должны проверить "веб-сервер". Корневая папка по умолчанию для веб-сервера - "/var/www/html", поэтому мы можем начать с поиска файлов, которые находятся под "/var/www/html".

1696689650978.png

Изображение [4] : Проверка последних действий


1696689660893.png

Изображение [5] : Проверка путей к файлам​

Я проверил все логи и недавние действия, единственный полный путь, который я смог найти, был "/var/www/html/3603-profile-pic.php ", так что, вероятно, это путь нашей веб-оболочки.

2. Укажите имя файла, созданного злоумышленником в скрытом каталоге.
Веб-оболочки загружаются на этапе "Постоянства", а что происходит после постоянства? Повышение привилегий. Если веб-оболочка загружена, то на сервере происходит повышение привилегий.

Здесь я вижу 2 случая: либо повышение привилегий еще не было выполнено, и хакер попытался выполнить повышение привилегий непосредственно из webshell. Или повышение привилегий уже выполнено, и хакер выполняет либо "Уклонение от защиты", либо "Доступ с использованием учетных данных".

Теперь, прежде чем впадать в паранойю и подозревать все подряд, мы можем видеть, что webshell был добавлен в "2019-12-18 10:59:55" - поэтому мы должны проверить логи, которые произошли после этого времени.

1696690684827.png

Изображение [6] : etc


1696690743099.png

Изображение [7] : root

1696690772345.png

Изображение [8] : tmp
Как мы можем видеть, есть 2 лога из "/etc", оба они с меньшей вероятностью могут быть использованы для "Повышения привилегий", "Уклонения от защиты" или "Доступa с использованием учетных данных".

В "/root" оба лога могут быть использованы злоумышленником. Опишу лог где отредактировали файл "authorized_keys".

Xакер, имеющий доступ к серверу, может сгенерировать новую пару ключей SSH, добавить открытый ключ в файл authorized_keys сервера и потенциально получить несанкционированный доступ к серверу, используя закрытый ключ.

Что ж, теперь снова возникает вопрос, чего пытается достичь хакер? На этот раз снова возникают две разные возможности.
Первый случай - это повышение привилегий - конфигурация по умолчанию в некоторых SSH позволяет пользователям создавать новые авторизованные ключи для кого угодно - в данном случае хакер сделал это, чтобы повысить привилегии.
Второй случай - до этого, хакер сохранил постоянство, добавив webshell, это позволяло хакеру сохранять доступ к серверу, но как непривилегированный пользователь. В этот раз возможно, хакер уже выполнил повышение привилегий и редактирует файл "authorized_keys", чтобы сохранить постоянство в качестве привилегированного пользователя "root". Техника: Манипулирование учетной записью: Авторизованные ключи SSH. Тактика: Постоянство.

Точный ответ не узнать, т.к. это просто лаб, но я считаю что второй случай более вероятен.

3. Укажите IP-адрес захваченного сервера.
Мы можем увидеть это, просто проверив "последний ip-адрес".

1696692320862.png

Изображение [9] : IP-адрес захваченного сервера

Лаборатория №2

1. Злоумышленник создал скрипт в скрытом каталоге на захваченном хосте. Укажите полный путь к этому скрипту.
Как уже было сказано, это.скрытый каталог, поэтому он начинается с точки, это означает, что мы должны искать "/."

1696709673122.png

Изображение [10] : Doorman

1696709532765.png

Изображение [11] : Поиск скрытого файла.
Как вы можете видеть из панели мониторинга, есть 3 пользователя, я проверил их всех на наличие скрытых каталогов и нашел только один, который выглядит подозрительно. Что я подразумеваю под подозрительным? Это файл .sh в каком-то каталоге с странным именем. Кстати, это было найдено в разделе "/etc" в узле с именем "emily".

2. Скрипт, созданный злоумышленником, был запланирован для периодического запуска. Определите полный путь к файлу cron, в который был добавлен этот скрипт.
Как мы знаем из приведенного выше, он (странный файл) был найден в узле с именем "emily", поэтому мы можем просто проверить недавнюю активность в "cron". Как мы можем видеть на скриншоте, путь в который был добавлен этот скрипт находится - /etc/crontab

1696710190190.png

Изображение [12] : Поиск файла cron.​

3. Укажите IP-адрес захваченного сервера.
Мы можем видеть это на скриншоте

1696710300979.png

Изображение [13] : IP-адрес​


Новые теги, используемые в этом случаи, следующие:
1. T1064 - Скриптинг - Этот метод устарел и заменен на "Интерпретатор команд и сценариев" - T1059. Это связано с нашими первым и вторым вопросами, где хакер уже создал скрипт и запускает его как задачу cron.
2. T1053 - Запланированная задача/задание - Это связано с нашим вторым вопросом, который касается выполнения вредоносного скрипта как задания cron.

Лаборатория №3

1.Злоумышленник искал файл(ы) закрытого ключа с определенным расширением. Как называлось это расширение? Укажите имя расширения без начальной точки (.).
Список расширений файлов с закрытыми ключами включает: .pem .key .p8 .der .p12 .keypair .pk8 .keytab .pem.key .sec
Я буду честен с вами, несмотря на то, что это хорошая идея - искать расширения файлов, которые у нас есть, выполнение этого через графический интерфейс в firefox отнимает много времени. Итак, я проверил имена пользователей и понял, что "elliot" выглядит более подозрительно, когда я проверил elliot, я увидел "private_keys_search" в недавних действиях. В "private_keys_search" мы можем увидеть команду и расширение.

1696712566475.png

Изображение [14] : Doorman

1696712587129.png

Изображение [15] : Поиск закрытого ключа​

2. Злоумышленник искал какой-то ключевой файл, специфичный для SSH. Как назывался этот файл?
Итак, где-то выполняется еще одна команда "find". Как мы можем видеть на скриншоте ниже, хакер ищет файл "id_rsa".

Изображение [16] : Поиск id_rsa

Изображение [16] : Поиск id_rsa​

3. Злоумышленник искал файлы с секретными ключами и файлы, содержащие пароли, и сохранил их в файле. Позже этот файл был удален. Укажите полный путь к этому файлу.
Чтобы найти файлы, содержащие пароли, я бы использовал команду "find" с командой "grep", как мы делали при повышении привилегий. Выполнение команд "find / -name id_rsa" и "grep --color=auto -ri password" произошло в "2019-12-19 15:22:40" и "2019-12-19 15:29:04". Итак, файлы с секретными ключами и файлы, содержащие пароли, были созданы после "2019-12-19 15:22:40" и удалены после "2019-12-19 15:29:04".

1696768607691.png

Изображение [17] : Поиск паролей и ключей

1696769072286.png

Изображение [18] : Поиск файлов
Есть 2 файла, которые были удалены после "2019-12-19 15:29:04", один из них - "key", другой - ".bash_history". У хакера есть причина удалить историю, но у него нет причин сохранять там результат выполненных команд, поэтому ответ таков "/root/key"

4. В какое время был удален файл .bash_history? Укажите ответ в следующем формате - ЧЧ:ММ:СС
Как мы можем видеть из изображения № 18, ответ - "15:30:55"

5. Укажите IP-адрес скомпрометированного сервера.
Мы можем видеть ответ на изображении № 14, нашего пользователя зовут "elliot".

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

T1081 - теперь известный как T1552.001 - Незащищенные учетные данные: Учетные данные в файлах
T1146 - теперь известен как T1070.003 - Удаление индикатора: Очистить историю команд
T1145 - теперь известный как T1552.004 - Незащищенные учетные данные: Закрытые ключи


В нашем случае сначала был осуществлен доступ по учетным данным, а затем уклонение от защиты.

Лаборатория №4

1. На захваченном хосте злоумышленник загрузил скрипт с удаленного сервера. Укажите URL-адрес, с которого был загружен этот скрипт.
Как всегда, давайте начнем с рассмотрения узлов. Мы видим 3 узла: "finance", "products" и "services". Если скрипт был загружен, вероятно, использовались такие команды, как "wget" и "curl". Вместо того, чтобы проверять все процессы, я решил проверить названия недавних событий активности, одно из них был назван "wget", и в нем хакер загрузил файл .sh.

1696775287473.png

Изображение [19] : Doorman


1696775419124.png

Изображение [20] : wget​

2. Загруженный скрипт использовался для мониторинга сетевого трафика на захваченном компьютере и отправки записи на удаленный сервер. Каков был URL-адрес, на который был отправлен записанный трафик?
Чтобы избежать постоянных подключений к серверу, вместо "живого" мониторинга трафика хакер мог бы просто сохранить часть трафика в определенном файле и затем отправить его на сервер. В вопросе у нас запрашивается URL-адрес, и мы можем видеть curl на изображении № 20, вероятно, он использовался для отправки захваченного трафика в виде файла.

1696776911669.png

Изображение [21] : curl​

Как мы можем видеть на скриншоте выше, трафик был записан в виде файла .pcap и отправлен на веб-сервер через curl.

3. Укажите IP-адрес удаленного сервера, с которого был загружен скрипт полезной нагрузки и на который был загружен перехват трафика.
Используемый домен - "data-storage.random-evil-domain.xyz", а порт - "8081", что мы можем здесь сделать, так это проверить сокеты, как мы знаем из вышесказанного, сокеты могут содержать адрес и порт.
Код:
osquery> pragma table_info(process_open_sockets);
+-----+----------------+---------+---------+------------+----+
| cid | name           | type    | notnull | dflt_value | pk |
+-----+----------------+---------+---------+------------+----+
| 0   | pid            | INTEGER | 1       |            | 1  |
| 1   | fd             | BIGINT  | 0       |            | 0  |
| 2   | socket         | BIGINT  | 0       |            | 0  |
| 3   | family         | INTEGER | 0       |            | 0  |
| 4   | protocol       | INTEGER | 0       |            | 0  |
| 5   | local_address  | TEXT    | 0       |            | 0  |
| 6   | remote_address | TEXT    | 0       |            | 0  |
| 7   | local_port     | INTEGER | 0       |            | 0  |
| 8   | remote_port    | INTEGER | 0       |            | 0  |
| 9   | path           | TEXT    | 0       |            | 0  |
| 10  | state          | TEXT    | 0       |            | 0  |
| 11  | net_namespace  | TEXT    | 0       |            | 0  |
+-----+----------------+---------+---------+------------+----+

1696777550009.png

Изображение [22] : Cокеты​

Мы можем видеть удаленный адрес и порт 8081, это наш ответ.

4. Укажите IP-адрес захваченного сервера.
Мы можем видеть это на изображении № 19

Теперь, отложив лабораторные работы, давайте проверим используемые новые методы.

T1136 - Создать учетную запись - мы видим, что файлы /etc/passwd и /etc/shadow были изменены, на этом этапе злоумышленник создал учетную запись. Это произошло в 10:27:06

T1021 - Удаленные службы - Использовались удаленные службы, такие как FTP, времена здесь следующие "10:26:21", "10:36:33", "10:36:36"- возможно, что данные T1136 были отредактированы после подключения к FTP.

T1029 - Запланированная передача - конкретных заданий cron нет.

T1105 - Передача инструмента входа - передача инструмента была осуществлена через FTP, cURL и wGET. FTP был запущен от имени пользователя root в "10:26:41", то есть после T1021, это объясняет, как были отредактированы файлы /etc/passwd и /etc/shadow. cURL
процесс начался в "10:39:10" и закончился в "10:40:04", который был использован для передачи захваченного трафика в виде файла с именем "capture-01.pcap". Команда wGET начиналась в "10:29:46" и заканчивалась в "10:30:58", файл "traffic-mon.sh " был загружен.

Из этой картины мы можем понять, что на самом деле произошло на этом этапе. Итак, хакер использовал FTP для подключения в "10:26:21", после чего хакер создал учетную запись в "10:27:06" и установил скрипт перехватчика трафика в "10:29:46", с которого он передавал загруженный трафик через cURL в "10:39:10".

T1040 - Обнюхивание сети - как мы можем видеть на скриншоте, "wireshark", "airodump-ng", "tshark" и "tcpdump" использовались для захвата трафика, хотя я не могу видеть временной интервал, в течение которого это произошло, мы можем сказать, что это происходит между временем, когда скрипт "traffic-mon.sh" был установлен, после чего трафик был захвачен и когда он был загружен на сервер хакера. Между "10:29:46" и "10:40:04"

T1169 - теперь известный как T1548.003 - Механизм контроля прав доступа: Sudo и кэширование Sudo - файл Sudoers был изменен, вероятно, это произошло после T1136, когда был создан новый пользователь.

T1222 - Изменение разрешений на доступ к файлам и каталогам - я не думаю, что изменения разрешений на доступ к файлам были сделаны хакером, потому что измененные разрешения на доступ к файлам не так важны, и изменения дают новое разрешение "0644", что означает, что владелец может читать и редактировать, другие могут читать - ложноположительный результат (false positive)

T1500 - теперь известный как T1027.004 - Запутанные файлы или информация: Скомпилировать после доставки - вероятно, это ложноположительный результат, извлечение кода было выполнено самой системой, был создан файл "eipp.log.xz", который является файлом, используемым package tool, и компиляция кода также ложноположительный результат, в /etc есть файл с именем "automake", который был логирован, вероятно, потому, что в запросе osquery был %make% - это означает, что имена, содержащие "make", должны быть логированы.

В качестве заключения я хотел бы сослаться на тематическое исследование, опубликованное MITRE о "Уютных медведях" https://attack.mitre.org/groups/G0016/, также известных как APT 29 - они были отслежены и проанализированы с использованием платформы MITRE ATT&CK. Это продемонстрировало, как ATT&CK можно использовать для "понимания хакеров".

Автор grozdniyandy

Источник https://xss.pro/​

 
Последнее редактирование модератором:


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх