Команда киберкриминалистов Angara SOC подготовила материал с реконструкцией хакерской атаки, которая длилась несколько дней и серьезно угрожала бизнесу заказчика.
Отметим сразу, что точкой входа стала учетная запись сотрудника, который не имел никакого отношения к IT - и ИБ-инфраструктуре, поэтому этот кейс еще раз подтверждает, как важна киберграмотность не только сотрудников компании, но и подрядчиков, и даже субподрядчиков.
Атака. Первые улики
Изначально и далее преступники подключались напрямую через Citrix ADC/NetScaler под доменной учетной записью сотрудника отдела продаж. Citrix часто используется для организации удаленного доступа к корпоративной сети, в том числе для доступа к сети через веб-интерфейс. Ниже приводим выявленные VPN-сессии первично скомпрометированного пользователя.
На протяжении всего периода атаки, при помощи корреляции установленных сессий и событий соединений сетевого оборудования Palo Alto, установлено, что в качестве источника подключения выступали IP-адреса, принадлежащие одному VPN-провайдеру ‒ ProtonVPN:
149.102.244.66,
146.70.161.198,
146.70.161.171
Атака. День первый
В первый же день расследования был получен доступ к промежуточному серверу и в рамках установленной сессии приступили к изучению доступных локальных и удаленных файлов. Для этого использовали графический интерфейс и веб-ресурсы, которые были отмечены в закладках браузера у скомпрометированного пользователя.
Ниже приводим часть истории посещений веб-страниц в браузере Internet Explorer. Как видно из этих скриншотов, злоумышленников в первую очередь интересовали внутренние ресурсы организации, такие как Confluence, Jira и другие доступные приложения.
Более того, опираясь на журналы доступа Confluence, можно заключить, что при доступе со скомпрометированного сервера преступники также попытались получить доступ с других учетных записей, но без последующих переходов на какие-либо страницы в рамках поиска информации.
Атака. День второй
Подключившись с использованием VPN на следующий день в 07:10, хакеры продолжили изучение хоста, чтобы найти чувствительную информацию. Об этом свидетельствуют большое количество имеющихся LNK-файлов, которые автоматически создаются операционной системой при открытии локальных или удаленных файлов, а также история Internet Explorer, содержащая сведения о доступе как к веб-, так и локальным ресурсам.
На протяжении всего период атаки злоумышленники получили доступ ко множеству файлов, исходным кодам отдельных приложений, приватным ключам, файлам конфигураций, а также файлам .bash_history, содержащим чувствительную информацию.
Спустя непродолжительное время после подключения и просмотра отдельных файлов, был загружен архивом один из первых инструментов – EmEditor (emed64_22.3.0_portable.zip). Это гибкий текстовый редактор с широким функционалом, в том числе с возможностью просмотра файлов очень большого размера и манипуляции с ними через графический интерфейс. Архив был распакован в директорию C:/Users/<victim>/Downloads, активно использующуюся злоумышленниками и в дальнейшем.
В продолжение исследования сетевых каталогов в тот же день аналогичным образом были загружены еще три инструмента:
HeidiSQL, инструмент администрирования с открытым исходным кодом для сразу нескольких баз данных, таких как MariaDB, MySQL, а также Microsoft SQL Server, PostgreSQL и SQLite
WinSCP, клиент протоколов FTP, FTPS, SCP, SFTP, предназначенный для Windows
dbeaver, инструмент администрирования базы данных с возможностью взаимодействия с базами данных через драйвер JDBC
И хотя все используемое хакерами программное обеспечение относится к portable-версиям, то есть не требует полноценной установки, в системе частично остаются следы их работы. Так, сразу после загрузки dbeaver на целевую систему, программа была запущена и с ее помощью были предприняты попытки подключения к отдельным серверам баз данных. Часть структурированных логов приводим далее. Внимание, очень длинная таблица :)
Время |
Адрес подключения в соответствующем формате |
Тип ответа |
08:27:23.612 |
jdbc:oracle:thin:@//<serverName1>:1535/LFDWH |
ORA-17002: Ошибка ввода-вывода |
08:27:34.487 |
jdbc:oracle:thin:@//:1521/LFDWH |
ORA-17002: Ошибка ввода-вывода |
08:28:00.130 |
jdbc:oracle:thin:@//<serverIp2>:1525/LFDWH |
ORA-17002: Ошибка ввода-вывода |
08:28:06.974 |
jdbc:oracle:thin:@//<serverIp2>:1535/LFDWH |
ORA-17002: Ошибка ввода-вывода |
09:06:03.836 |
jdbc:oracle:thin:@//<serverName3>:1533/LFDWH |
ORA-12514: Невозможно подключиться к базе данных. Сервис %s |
09:06:14.166 |
jdbc:oracle:thin:@//<serverName3>:1533/UNC10G |
ORA-01017: invalid username/password; logon denied |
09:06:29.526 |
jdbc:oracle:thin:@//<serverName3>:1533/UNC10G |
ORA-01017: invalid username/password; logon denied |
09:53:46.006 |
jdbc:oracle:thin:@//<serverName3>:1533/UNC10G |
ORA-01017: invalid username/password; logon denied |
10:07:30.714 |
jdbc:oracle:thin:@//<serverName3>:1533/UNC10G |
ORA-01017: invalid username/password; logon denied |
10:11:15.990 |
jdbc:oracle:thin:@//<serverName3>:1533/LFDWH |
Connected |
10:38:29.002 |
jdbc:oracle:thin:@//<serverName4>:1566/uncunc |
Connected |
10:53:31.832 |
jdbc:oracle:thin:@//<serverName5>:1566/uncunc |
ORA-01013: пользователем запрошена отмена текущей операции |
15:47:46.670 |
jdbc:oracle:thin:@//<serverName5>:1566/SAPTDS |
ORA-12514: Невозможно подключиться |
15:47:57.842 |
jdbc:oracle:thin:@<serverName5>:1566:SAPTDS |
ORA-12505: Невозможно подключиться |
15:50:10.292 |
jdbc:oracle:thin:@//<serverName5>:1566/UNC |
ORA-12514: Невозможно подключиться |
15:50:17.792 |
jdbc:oracle:thin:@//p260unc4:1566/UCN |
ORA-12514: Невозможно подключиться |
15:53:38.925 |
jdbc:oracle:thin:@//<serverName3>:1533/UCN |
ORA-12514: |
15:53:57.396 |
jdbc:oracle:thin:@//<serverName3>:1533/SAPTDS |
ORA-12514: |
15:54:13.164 |
jdbc:oracle:thin:@//<serverName3>:1533/ALAL |
ORA-12514: |
15:54:30.044 |
jdbc:oracle:thin:@//<serverName3>:1533/UNC10G |
ORA-01017: |
15:54:45.310 |
jdbc:oracle:thin:@//<serverName3>:1533/UNC10G |
ORA-01017: |
15:59:09.384 |
jdbc:oracle:thin:@//<serverName7>:1537/PBUH_F |
ORA-01017: |
15:59:13.056 |
jdbc:oracle:thin:@//<serverName7>:1537/PBUH_F |
ORA-01017: |
15:59:31.075 |
jdbc:oracle:thin:@//<serverName7>:1537/PBUH_F |
ORA-01017: |
16:00:12.404 |
jdbc:oracle:thin:@//<serverName7>:1537/PBUH_F |
ORA-01017: |
16:01:21.081 |
jdbc:oracle:thin:@//<serverName7>:1537/PBUH_F |
ORA-01017: |
16:01:26.223 |
jdbc:oracle:thin:@//<serverName7>:1537/PBUH |
ORA-12514: |
|
… |
|
19:22:35.898 |
jdbc:oracle:thin:@ <serverIp3>::1522:insisdb |
Connected |
12:54:16.305 (следующий день) |
jdbc:oracle:thin:@// <serverName6>:1533/UNC10G |
Connection reset. |
13:05:57.551 |
jdbc:sqlserver://;serverName=<serverIp2>;port=50449;databaseName=master |
Не удалось установить соединение TCP/IP |
17:12:48.986 |
jdbc:sqlserver://;serverName=<serverIp3>;databaseName=master |
Connection failed. |
17:27:59.297 |
jdbc:sqlserver://;serverName=<serverIp2>;port=53688;databaseName=master |
Connection failed. |
17:55:07.860 |
jdbc:oracle:thin:@// <serverName8>:1566/uncunc |
ORA-12541: |
17:55:37.572 |
jdbc:oracle:thin:@//<serverName8>:1566/uncunc |
Connected |
17:59:55.532 |
jdbc:oracle:thin:@//<serverName8>:1566/uncunc |
ORA-01017: |
18:00:03.970 |
jdbc:oracle:thin:@//<serverName8>:1566/uncunc |
Connected |
Как видно из приведенной выше таблицы, несмотря на множественные неудачные попытки подключения, в выделенных случаях подключение было успешно установлено. Более того, дополнительно лог-файл приложения содержит ошибки на уровне базы данных, то есть при выполнении запросов, что подтверждает возможность манипуляций с данными атакующими на указанных серверах. Так как журналов выполненных запросов не ведется, достоверно восстановить содержание запросов не представляется возможным.
Стоит отметить, что параллельно событиям этого же дня, в 10:15:20 в файловой системе скомпрометированного ранее хоста появились первые файлы, именования которых схожи стандартному формату при выгрузке базы данных. При это восстановить эти файлы невозможно из-за технических особенностей логического пространства виртуального диска.
Кроме того, мы зафиксировали значительный рост исходящего трафика, общим объемом около 850 МБ, что может свидетельствовать об первом этапе эксфильтрации данных.
В рамках фазы пост-эксплуатации злоумышленники использовали исключительно системные инструменты и легитимное ПО, предназначенное для администрирования. Так, в 18:37:45 была загружена, распакована и запущена утилита LDAP Admin (LdapAdminExe-w64-1.8.3.zip), расположенная в том же каталоге C:\Users\<victim>\Downloads\, для выполнения LDAP-запросов к целевому серверу. После анализа полученных данных, поиск чувствительной информации продолжился.
В ряде случаев, к отдельным серверам пробовали подключиться через WinSCP или через RDP-подключение (на основании событий системного журнала TerminalServices RDPClient\Operational).
Дополнительно, по ходу атаки атакующие загрузили веб-браузеры qtweb, opera и PortableGit. Последнее решение используется для работы с системой управления версиями Git для просмотра найденных git-файлов репозиториев.
На основании лог-файлов системы управления репозиториями программного кода GitLab, доступного по адресу https://gitlab.<companyname>.ru/, хакеры в 16:31:43 выполнили доступ удаленного адреса, который относится к подсети туннеля, настроенного для подрядчика. Информация об используемой учетной записи для подключения в явном виде отсутствует. По событиям с контроллеров домена, аутентификация на ресурсе производилась в том числе при помощи одной из привилегированных учетных записей. Но однозначно утверждать, что использовалась только эта учетная запись ─ невозможно.
При детальном анализе запрашиваемых URI выявлено, что выполнялся поиск по отдельным ключевым словам, в том числе: «bitrix», «password», «mysql», «postgres», «ms-auth», «sftp», «ssh», «oracle», «jdbc», «postgresql», «password prod», «bitrix», «sk2239», «sftp-prod.autoins.ru», «ftp», «password admin», «password basic», «basic auth admin», «aws secret backup», «password username jdbc», «password mysql», «storage.yandexcloud.net», «CLO_STORAGE_YANDEX», «BEGIN RSA PRIVATE KEY», «ssh private rsa», «10.255.1», несколько других внутренних и внешних адресов, и последующий перебор найденных веток.
Позднее, в 18:10:35 и 18:53:59 того же дня был зафиксирован первый вход из-под этой же привилегированной учетной записи с промежуточного сервера на веб-интерфейсы пространств Confluence и Jira.
В 20:04:50, в журнале auth.log зафиксировано подключение при помощи протокола ssh
к другому серверу (уже на операционной системе GNU/Linux) с использованием учетных данных привилегированной локальной учетной записи, состоящей в группе sudo, и имеющей аналогичный логину пароль. Многократных ошибок при входе на сервер не наблюдалось, вероятнее всего, аутентификационный материал был получен ранее в открытом виде из ранее изученных файлов.
Так как история вводимых команд пользователем .bash_history ведется без указания временных меток, достоверно определить команды, введенные злоумышленниками на серверах, не представляется возможным, явных признаков вредоносной активности не обнаружено. Так, вероятно, хакеры установили файловый менеджер Midnight Commander для более удобного взаимодействия с файловой системой:
sudo apt install mc
mc
Тем не менее, в 22:03:58 с данного сервера был выполнен первый запрос к базе данных MySQL от имени сервисной учетной записи, вероятно, также полученной аналогичным способом на этапе изучения.
SELECT * FROM <prodTable> WHERE ID > 12427356;
Предположительно, в целях выгрузки был построен туннель с использованием клиентов Putty и WinSCP для создания SFTP (FTP over SSH) /SCP сессии. Тогда же были выгружены на изначально скомпрометированный сервер файлы-ответы, полученные после выполнения первого запроса - user.sql и user2023.sql, после чего файл был разбит на RAR-архивы. Примечательно, что ряд команд злоумышленником выполнялся напрямую через WinSCP, а именно проверка сетевого доступа на сервер:
nc -zv -w1 10.255.1.6 3306
nc -zv -w1 10.255.1.6 22
ping -c 1 10.255.1.6
Атака. День третий
На третий и финальный день, в 09:53:06 (создание пользовательской сессии – в 08:49:37), был осуществлен второй запрос:
SELECT ID,TIMESTAMP_X,LOGIN,’PASSWORD’,NAME,LAST_NAME,EMAIL,LAST_LOGIN,PERSONAL_PHONE,PERSONAL_BIRTHDAY,SECOND_NAME FROM <prodTable>
При выгрузке результатов отработанных запросов во внешнюю сеть, аналогично отслеживается рост исходящего трафика (итого за предыдущий день ≈ 2517 МБ, текущий ≈ 1078 МБ). Выгрузив результаты, после удаления части следов и созданных в процессе файлов, сессия была завершена. В дальнейшем, недопустимых событий реализовано не было.
Выводы? Рекомендации
Злоумышленники далеко не всегда используют сложные техники или вредоносный код. Иногда они достигают своей цели, используя исключительно легитимные инструменты, а нужную информацию находят, просто внимательно изучая доступные ресурсы.
Такое поведение хакеров довольно сложно отличить от действий обычного пользователя или прикладного администратора. Как раз этим и пользуются Leak Wolf. Возможно, этих ребят знают больше по Telegram-каналу NLB, куда они размещают данные некоторых из своих жертв.
Поэтому приводим наши практические рекомендации, чтобы на дальних подступах пресекать такие кибератаки "на грани":
Поставьте на контроль обращения к адресам, которые относятся к VPN-провайдерам, прокси, анонимайзерам
Внедрите многофакторную аутентификацию на всех публично доступных, а также критических ресурсах для обеспечения дополнительного уровня верификации внутренних пользователей и повышения их безопасности с целью защиты от взлома
Контролируйте и проводите регулярную инвентаризацию ваших IT-активов, в том числе внешних, чтобы исключить создание теневой инфраструктуры
Строгая парольная политика: не менее 14 символов для пользовательских учетных записей, использование букв разных регистров, а также спецсимволов. Всегда ведите журнал паролей (количество старых паролей, которые хранятся в Active Directory, запрещая пользователю повторно использовать старый пароль, который настраивается аналогично через политику паролей
Исключите возможность использовать одинаковые пароли от локальных привилегированных учетных записей как для Windows-, так и для Linux-систем
Киберграмотность и цифровая гигиена сотрудников - ваше все
Следите за тем, чтобы пароли не хранились в легкодоступных файлах в открытом виде, а при использовании терминала не вводились явно для недопущения их сохранения в истории команд
Используйте для защиты конечных устройств решения класса EDR. Важно обеспечить максимальную полноту покрытия сети для предотвращения появления "слепых" зон
При разграничении доступа применяйте принцип минимальных привилегий в системе, уделяя особое внимание учетным записям, использующимся для автоматизированных процессов и удаленного доступа
Подключите журнал запросов баз данных для контроля запросов с ответами, содержащими большое количество строк.
Бонус: индикаторы компрометации
IP-адреса:
IP-адрес |
AS*, диапазон |
Геолокация |
Краткое описание |
149.102.244.66 |
212238, 149.102.244.0/24 |
Варшава, Польша |
ProtonVPN |
146.70.161.198 |
9009, 146.70.161.0/24 |
Варшава, Польша |
ProtonVPN |
146.70.161.171 |
9009, 146.70.161.0/24 |
Варшава, Польша |
ProtonVPN |
*autonomous system, AS — система IP-сетей и маршрутизаторов, управляемых одним или несколькими операторами, имеющими единую политику маршрутизации с Интернетом |
Мы всегда на связи, Angara SOC!
Комментарии (7)
0mogol0
05.10.2023 20:14Строгая парольная политика: не менее 14 символов для пользовательских учетных записей, использование букв разных регистров, а также спецсимволов.
И бумажки с паролями на мониторе / фото паролей в телефоне итп... Потому что заполнить случайный текст на 14 символов не реально.
ИМХО, пароли надо или дополнять двух-факторной аутентификацией, или биометрией.
Cruz_Castillo
05.10.2023 20:14Зачем случайный, парольные фразы же!
0mogol0
05.10.2023 20:14ИМХО это всё же уже вчерашний день... Можно хоть первую страницу Войны и мира заставить набивать, но человек слишком ленив, и будет обходить эти требования при возможности. Поэтому лучше оставить 8-9 символов + (обязательно!) какой-то доп. механизм.
3ycb
И опять винда. Почему я не удивлен?