Злоумышленники взламывают «бухгалтерские» сервера с программой 1С

Сложно представить себе предприятие или физическое лицо-предпринимателя, которые, при осуществлении своей хозяйственной деятельности, не прибегают к использованию средств автоматизации финансовой деятельности или процесса управления предприятием в целом. По большому счету, самыми распространенными инструментами бухгалтера являются системы дистанционного банковского обслуживания (сфера ответственности банка) и специальные программы, например 1С. Последние, являющиеся очень «интимным» местом, устанавливают на серверное оборудование, размещенное где-нибудь за пределами своей страны, предоставляя удаленный доступ пользователям по RDP (!). Кто знает, тот не даст соврать, что уровень критичности информации, обрабатываемой на таких серверах с 1С, достаточно высок. Волей-неволей как раз эти активы и оказались под прицелом злоумышленников. Понимая, что шифровальщики-вымогатели (ransomware) в данном случае как раз то, что нужно, атакующие решили атаковать сервера с 1С, шифровать данные и требовать за них выкуп.

Но на этом проблемы не заканчиваются. Так как плохие хакеры – народ хозяйственный, они не могли допустить, чтобы хоть какая-то частичка скомпрометированной информации, оказавшаяся в их распоряжении, пропадала зря. Безусловно, если рассмотреть мошенничество в системах дистанционного банковского обслуживания, операторам таких бот-сетей как, например, ZeuS, в первую очередь интересны компьютеры, на которых установлено программное обеспечение «клиент-банк», так как с них можно украсть деньги и получить выгоду. А что же делать с зараженными компьютерами тех бухгалтеров, которые только то и делают, что работают удаленно в 1С? Выход был найден! Почему бы скомпрометированные аутентификационные данные для доступа к серверу 1C по протоколу RDP, не передавать «партнерам» для точечной проработки по линии шифрования и вымогательства?!

Примеры того как глазами злоумышленников выглядели ранее не перспективные компьютеры с доступом к 1С, а также, снимки экранов с зараженных компьютеров в момент доступа к 1С по RDP, приведены на рис. 1-3.

Рис. 1

Рис. 2

Рис. 3

Но не все могут себе позволить бот-сеть. Часть злоумышленников направили свои «исследования» на поиск серверов, предусматривающих подключения по RDP, и принялись подбирать аутентификационные данные для получения доступа к последним. Иными словами – «брут-форсить».

Совсем недавно в сети начали появляться сообщения о том, что данные 1С подвергаются шифрованию [1], а для получения инструкции/ключа для расшифровки следует обращаться по указанной электронной почте. С одной стороны ничего технически сложного в подобных атаках нет, но, в то же время, методы и подходы злоумышленников оказались действенными (сделан упор на качество, а не на количество).

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

По одному из таких обращений мы провели базовое изучение файлов регистрации событий (Event Logs) и смогли сделать вывод о том, что и как происходило. В первую очередь стало понятно, что для организации подбора паролей злоумышленники используют распределенную инфраструктуру. В исследованном нами случае подбор логинов и паролей осуществлялся 11 дней с 68 разных IP-адресов расположенных в 21 стране мира. Перечень IP-адресов, с которых производилась атака, отображен ниже.

Общее количество логинов, к которым пытались подобрать пароль, составило 973. ТОП-30 логинов и соответствующее число попыток их подбора, отображены ниже.

Основным инструментом для анализа логов (а именно – Security.evtx) был «Log Parser 2.2». Для изучения процессов, связанных с удаленным подключением к серверу по RDP, мы обращали внимание на такие события:

• Successful User Account Login (EventID=4624)
• Failed User Account Login (EventID=4625)

Пример одного из вариантов применения «Log Parser 2.2» отображен ниже.

LogParser.exe -i:EVT -o:CSV "SELECT
TimeGenerated,
EXTRACT_TOKEN(Strings,5,'|') AS TargetUserName, 
EXTRACT_TOKEN(Strings,10,'|') AS LogonType,
EXTRACT_TOKEN(Strings,19,'|') AS IpAddress, 
EXTRACT_TOKEN(Strings,20,'|') AS IpPort, 
EventID 
INTO 4625-query.txt 
FROM Security.evtx 
WHERE EventID=4625"

Если задействовать один из доступных в «Log Parser 2.2» способов отображения данных (-o:DATAGRID), полученный результат будет иметь следующий вид (Рис. 4). Отметим, что из 31878 записей в логе Security.evtx, 30266 записей были посвящены событию «Failed User Account Login» (что очень ярко характеризует проведенную на сервер «брут-форс» атаку.).

Рис. 4

Вследствие удачно подобранного пароля злоумышленники осуществляют удаленный доступ к серверу и выборочно шифруют важные данные, оставляя «сообщения» пострадавшим (рис. 5-7).

Рис. 5

Рис. 6

Рис. 7

Некоторые злоумышленники оказываются настолько максималистами, что, помимо зашифровывания данных 1С, не упускают возможности установить на сервер дополнительное программное обеспечение, скажем, для автоматизированного поиска уязвимостей в движках разных сайтов (например, WordPress). Те, кто исследовал подобный инцидент с шифрованием баз данных 1С, вероятно, удивлялись, почему на сервер с 1С дополнительно устанавливается Python (рис. 8-9)

Рис. 8

Рис. 9

Цель данной статьи – обратить внимание на описанную угрозу. В первую очередь, материал является релевантным для тех, чья «финансовая информация» обрабатывается на удаленных серверах с RDP-доступом. Несколько рекомендаций, направленных на минимизацию вероятности реализации угрозы, а также – возможных негативных последствий, приведены ниже.

1. Регулярное резервное копирование данных.
2. Ограничение доступа к RDP с помощью межсетевого экрана: разрешить доступ только с конкретных IP-адресов/подсетей.
3. Использование RDP-шлюзов [2].
4. Обеспечение доступа к терминальному серверу посредством шифрованных тоннелей (IPSec).
5. Использование механизма Network Level Authentication (NLA) [3].
6. Усложнение задачи подбора пароля с помощью политики блокировки учетной записи после введения определенного количества (3-5) неверных комбинаций логин-пароль.
7. Использование не типичных названий учетных записей.
8. Смена стандартного номера сетевого порта (3389/tcp) на котором функционирует RDP, на не типичный.
9. Регулярный мониторинг событий информационной безопасности.

Отдел реагирования на инциденты CyS Centrum

Использованные материалы:
[1] https://forum.esetnod32.ru/forum35/topic12795/
[2] https://security.berkeley.edu/resources/best-pract...
[3] https://technet.microsoft.com/en-us/library/cc7327...