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

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

Злоумышленники взламывают сервера с 1С, шифруют данные и требуют выкуп. Об одной из таких историй, а также о том, как повысить безопасность финансовой информации, мы и расскажем в данном исследовании.

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

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

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

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

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

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

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

94.23.170.170 45.32.83.236 89.184.84.84 195.154.209.174 190.10.9.246 212.83.168.145 193.34.8.158 178.22.50.250 109.237.89.107 46.175.191.254 104.45.28.180 96.11.19.194 12.139.34.20 97.65.80.4 94.136.45.239 46.98.123.93 74.208.153.91 62.205.128.83 76.79.234.170 212.48.66.50 195.138.198.199 94.158.46.227 178.238.92.22 212.57.114.159 109.107.232.75 89.179.244.173 78.37.97.102 91.223.180.250 78.85.33.136 89.151.134.231 163.158.144.184 77.232.25.22 172.245.123.14 188.247.66.213 92.253.126.26 134.249.149.96 176.36.19.10 5.53.117.49 113.160.199.25 74.208.112.162 83.110.216.111 80.82.64.117 91.218.19.12 85.238.100.202 64.38.204.98 61.182.72.16 185.28.110.35 199.189.254.245 179.111.212.254 37.152.8.236 39.109.19.1 37.122.210.243 91.243.29.89 195.70.37.67 211.141.150.55 198.74.113.208 217.73.91.183 24.97.22.154 195.175.104.78 81.176.239.250 14.147.145.218 78.63.234.219 93.75.39.135 190.10.8.29 5.134.114.154 103.24.92.220 136.243.121.218 185.125.217.76 190.10.8.209

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

Admin 3424 Administrador 492 user2 161 Админ 2900 administrateur 436 user3 157 Administrator 2544 user1 354 User1 157 administrator 2315 adm 336 manager 149 Администратор 2114 кассир 298 Владимир 130 admin 921 guest 226 alina 113 user 780 бухгалтер 189 kassa 107 test 770 Таня 185 director 95 Administrateur1 522 User 168 sys 87 Administrateur 495 Наталья 164 test1 86

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

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

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

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

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

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

адрес

CyS Centrum LLCул. Никольско-Слободская 2-Бподъезд 5(1)этаж 15, офис 177Киев, 02002Украина

📎📎📎📎📎📎📎📎📎📎