Сказ про НеПетю, а точнее не про Петю

Я не хотел писать заметку про Petya/Nyetya/NePetya и другие названия вредоносного кода, который в начале недели в очередной раз заставил содрогнуться мир по версии многих СМИ. Мое нежелание было продиктовано двумя причинами. Во-первых, именно нас, то есть компанию Cisco и ее подразделение Talos (про него я уже упоминал тут, но, видимо, придется рассказать чуть больше, что это за подразделение), пригласили участвовать в официальном расследовании происходящего в Украине, а писать о результатах следствия до его окончания мы, понятно, что не имеем возможности. Да и после окончания следствия не все его результаты будут опубликованы. Во-вторых, надо признаться, что я не разделяю того ажиотажа вокруг вредоносного кода, названного нами Nyetya, который последние дни только подогревается разными публикациями и заявлениями.

Что в нем такого уникального, что его отличает от других вредоносных программ и от того же WannaCry? Почему никто так много не пишет про Jaff или BitKangoroo, которые распространялись в то же время, что и WannaCry и использовали схожие методы? Почему никто не снимает репортажей и не обсуждает Untukmu, Shifu, Blackshades или тот же Locky, который заразил больше компьютеров чем WannaCry, Petya, Misha и Nyetya вместе взятые? Почему специалисты по ИБ с серьезным лицом обсуждают, кто раньше из них отреверсил “Петю” и кто быстрее всех распространил индикаторы компрометации? Кто-то называет 30 минут, кто-то 37 минут, кто-то “проснулся” только через несколько часов…

Почему?

Почему вообще стало возможно заражение Nyetya? Почему не сработали рекомендации, данные практически всеми специалистами полтора месяца назад, когда распоясался WannaCry? Жертвы не установили обновления на операционные системы (попутно можно было бы и браузеры с плагинами обновить)? И внешний доступ по SMB-портам тоже не закрыли? А ведь это стоило делать независимо от WannaCry. Это настолько банальные аксиомы ИБ, что про них даже на конференциях перестали говорить, погружаясь в более сложные материи — машинное обучение, искусственный интеллект, обнаружение аномалий, аналитику больших данных и т.п. Но о чем можно говорить, если даже простые вещи, не требующие никаких бюджетов, не делаются?

Когда случился (как обычно, вдруг) WannaCry, все настолько погрузились в него, что перестали смотреть вокруг и задавать более общий вопрос: “А что надо сделать, чтобы защититься от шифровальщиков?” Не от конкретного WannaCry (а их за последние полтора месяца уже большее 400 модификаций обнаружили), а от всех (или максимально возможного количества) программ-вымогателей (хотя тот же Nyetya не является вымогателем, несмотря на требование выкупа). Ведь именно в этом заключается работа специалистов информационной безопасности — не затыкать дыры после того, как их обнаружили, а уменьшить площадь возможной атаки, выстраивая систему защиты так, чтобы она изначально могла бороться с большинством угроз.

Как выстроить стратегию защиты от программ-шифровальщиков?

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

• попадание на компьютер через различные коммуникационные каналы (почта, Web, флешки, расшаренные папки, прямое сетевое соединение)
• взаимодействие с командным сервером (по нашей статистике в 92% случаев по протоколу DNS) или проверка наличия внешнего kill switch
• работа с файловой системой, включая подмену или удаление отдельных файлов, а также большое количество операций с файлами определенных типов
• работа с реестром
• работа с административными утилитами
• взаимодействие с анонимной сетью Тор
• дальнейшее распространение путем сканирования уязвимых узлов внутри сети или снаружи нее.

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

Опять же давайте рассуждать. На этапе предотвращения угрозы мы должны:

• блокировать ненужные сетевые и DNS-соединения с внешним миром, в том числе с анонимными сетями (Тор и т.п.)
• сегментировать сеть для предотвращения распространения вредоносного кода, если он все-таки попал во внутреннюю сеть, например, на флешке
• устранять уязвимости
• блокировать использование уязвимостей, если их нельзя устранить (обратите внимание, я говорю не про блокирование конкретных эксплойтов, а про блокирование попыток использования конкретных уязвимостей, что позволяет блокировать любые существующие и будущие эксплойты — это отличает традиционные IPS от современных NGIPS)
• блокировать доступ пользователей к вредоносным IP-адресам, доменам и URL, в том числе и с мобильных устройств
• блокировать запуск и функционирование опасных приложений и процессов
• блокировать распространение вредоносных программ по сети (как на уровне периметра, так и внутри ЛВС)
• внедрить (предварительно проверив способность восстановления) систему резервного копирования.

Модель информационной безопасности «ДО — ВО ВРЕМЯ — ПОСЛЕ»

Но сегодня нельзя быть уверенным в 100%-м предотвращении угроз — они могут попасть на флешке, через 4G-модем, незащищенный Wi-Fi или их мог занести топ-менеджер компании, заразивший свой личный ноутбук дома и принесший его в корпоративную сеть для лечения. Поэтому несколько лет назад мы предложили следовать концепции «ДО — ВО ВРЕМЯ — ПОСЛЕ», подразумевающей, что мы должны тратить на нейтрализацию угроз не 80% усилий, как это происходит обычно, а выделить на это треть возможных ресурсов и защитных мер. Еще треть пустить на обнаружение того, что может пройти сквозь защитные преграды. На этапе обнаружения мы должны:

• идентифицировать использование известных уязвимостей (включая и попытки использования дыр)
• детектировать аномальное, нетипичное поведение пользователей (например, запуск psexec для рядового пользователя компании), узлов (например, сетевое сканирование), приложений (например, инкапсуляцию чего-то нестандартного в HTTP-трафике), процессов (например, инъекции) и сетевого трафика (например, всплески трафика определенного вида, отличающегося от нормальной картины в сети)
• анализировать на лету вложения в электронную почту и скачиваемые с Web-страниц файлы, запускаемые скрипты или отображаемые Flash- или иные мультимедиа-ролики и баннеры
• детектировать обращение к kill switch или иным узлам инфраструктуры злоумышленника в сети Интернет (например, к DGA-доменам) путем анализа DNS-запросов, Web-логов прокси, анализа Netflow и просто изучения TCP/IP-потоков.

А что с оставшейся третью усилий? Их мы должны пустить на исправление ситуации, которую неприятно признавать, но которая возможно в любой компании, — на борьбу со случившимся заражением или компрометацией. Но в этом случае мы не должны зарывать голову в песок как страусы (на самом деле страусы не зарывают голову в землю, но такая уж версия пошла с времен Плиния Старшего и мы к ней привыкли), а оперативно локализовать проблему, не дать ей распространиться по сети, «вылечить» скомпрометированные узлы и вернуть систему в предатакованное состояние. На этапе реагирования мы должны:

• ограничить сетевой трафик с зараженных или подозрительных узлов
• поместить подозреваемые или зараженные узлы в карантин (путем помещения в соответствующую VLAN или блокируя порт на коммутаторе или изменяя ACL на точек доступа или маршрутизаторе), а учетные записи пользователей временно заморозить
• провести анализ подозрительных файлов в песочнице, а также с помощью иных механизмов
• отследить траекторию движения вредоносных или подозрительных файлов по сети
• восстановить данные из резервной копии
• запустить в отдельных случаях сложные процессы Threat Hunting, позволяющие подтвердить или опровергнуть гипотезу о наличии шифровальщика, выдвинутую аналитиком ИБ.

Решения Cisco для борьбы с шифровальщиками

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

Но это не просто красивая картинка. Мы подготовили (кстати, еще до всяких WannaCry и Nyetya) детальное техническое руководство по дизайну инфраструктуры для борьбы с данной угрозой. Оно разработано нами в соответствие с нашей архитектурой Cisco SAFE (Security Architecture for Enterprise), но в деталях рассматривает и способы проникновения программ-вымогателей в сети заказчиков, и методы предотвращения, обнаружения и реагирования в соответствие с жизненным циклом современной угрозы “ДО-ВО ВРЕМЯ-ПОСЛЕ“.

Данное руководство описывает весь стек технологий, которые позволяют бороться с вымогательским ПО:

• аппаратные и виртуальные межсетевые экраны Cisco ASA и Cisco Firepower
• системы предотвращения вторжений Cisco NGIPS и Cisco wIPS
• системы борьбы с вредоносным ПО Cisco Advanced Malware Protection
• средства мониторинга DNS Cisco OpenDNS
• средства сегментации корпоративной сети Cisco Identity Service Engine
• системы анализа аномалий во внутренней сети предприятия Cisco Stealthwatch
• аппаратный, виртуальный или облачный контроль доступа к Web-ресурсам Cisco Web Security
• аппаратную, виртуальную или облачную защиту входящей и исходящей электронной почты Cisco Email Security
• песочница Cisco AMP ThreatGrid
• и т.д.

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

А как же все-таки быть с НеПетей?

Если все-таки вернуться к истории с Nyetya (он же Petya.A, он же Petya.C, он же PetrWrap, он же PetyaCry, он же GoldenEye, он же ExPetr), то что известно нам на сегодняшний день?

Начиная с атак шифровальщика SamSam, основными жертвами которого стали органы здравоохранения в США в марте 2016 года, Talos предупреждал об опасности размножения вредоносного ПО, использующего незакрытые доступные по сети уязвимости. В мае 2017 WannaCry заставил плакать многих, воспользовавшись уязвимостями реализации протокола SMBv1 и широко распространился по множеству систем по всему миру. 27 июня был обнаружен новый образец вредоносного ПО, достаточно сильно отличающийся от оригинального Petya, чтобы люди начали давать ему новые имена, такие как Petrwrap и GoldenEye. Talos идентифицирует данный образец ВПО как Nyetya. Наше текущее расследование (оригинальная и постоянно обновляемая запись в блоге Cisco Talos на английском доступна тут) показало, что данный образец также использует EternalBlue и EternalRomance в комбинации с psexec и WMI-инструментарием для распространения и заражения новых жерт внутри сети. Мы подробно рассмотрим это ниже в разделе «функциональность вредоноса Nyetya». По сравнению с WannaCry отсутствует сканирующий внешнюю сеть компонент.

Идентификация начального вектора в настоящий момент затруднена. Ранние отчёты об использовании почтового вектора пока не подтвердились. Основываясь на наблюдениях над поведением образцов “в диком мире”, мы видим, что отсутствуют явные, видимые внешние механизмы размножения данного образца ВПО. Мы подозреваем, что часть инфекций, возможно, использовала механизм обновления бухгалтерского ПО, известного в Украине, под названием MeDoc, что косвенно подтверждается самим производителем MeDoc и коллегами-исследователями. Talos продолжает поиск изначального вектора атаки.

Как и с любым вредоносным ПО, Talos не рекомендует выплачивать выкуп. Имейте в виду, что для данного конкретного образца вредоносного кода это ещё и бессмысленно, так как почтовый ящик, который предполагалось использовать для обмена информацией о платежах и получения ключей расшифровки был заблокирован почтовым провайдером posteo.de. Это был единственный способ коммуникации, использованный злоумышленниками для получения информации о платежах и для получения ключей расшифровки. Не существует других методов для подключения вредоносного ПО к удалённым серверам управления и получения от них ключей расшифровки (в виду отсутствия таковых). Таким образом Nyetya не является шифровальщиком, который работает ради выкупа, а просто является образцом вредоносного ПО, которое уничтожает данные и системы, до которых может дотянуться.

Метод получения пользовательских паролей

Perfc.dat, ответственный за распространение зловреда, содержит встроенный исполняемый модуль в секции ресурсов. Данный исполняемый модуль создаётся как временный файл в пользовательском %TEMP% каталоге и запускает named pipe с параметром, содержащим GUID. В дальнейшем основной исполняемый модуль Perfc.dat взаимодействует с этим исполняемым модулём через данный named pipe. Например:

C:WINDOWSTEMP561D.tmp, \.pipe{C1F0BF2D-8C17-4550-AF5A-65A22C61739C}

Похоже что .tmp-исполняемый код основывается на Mimikatz, известном open source инструментарии для получения пользовательских паролей и логинов из памяти системы и использует для этого несколько методов.Тем не менее, Talos подтверждает, что данный код не является точной копией Mimikatz.

Полученные пары логин/пароль используются для заражения удалённых систем через WMIC и PsExec. Например:

Wbemwmic.exe /node:"w.x.y.z" /user:"username" /password:"password" "process call create "C:WindowsSystem32rundll32.exe "C:Windowsperfc.dat" #1

Функциональность вредоноса Nyetya

В своём расследовании, команда Talos обнаружила, что на скомпрометированных системах имеется файл «Perfc.dat». Perfc.dat содержит функциональность, необходимую для дальнейшей компрометации системы, и содержит одну неименнованную экспортируемую функцию, #1. Библиотека пытается получить привилегии администратора системы, используя вызовы SeShutdowPrivilege и SeDebugPrivilege, от имени текущего пользователя через вызов Windows API AdjustTokenPrivileges. В случае успеха, вредонос перезаписывает master boot record (MBR) на дисковом устройстве, обозначаемом как PhysicalDrive 0 внутри Windows. Независимо от того, успешно это действие или нет, вредонос переходит к созданию отложенной задачи через schtasks, для того, чтобы перегрузить систему через час после первоначальной инфекции.

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

Вредонос использует три возможных механизма для размножения:

1. EternalBlue — тот же эксплойт, что и для WannaCry.
2. EternalRomance — SMBv1 exploit, ставший доступным в результате утечки «ShadowBrokers»
3. Psexec — легальный инструмент администраторов Windows.
4. WMI — Windows Management Instrumentation, легальный компонент Microsoft Windows.

Данные механизмы используются для установки и запуска на исполнение perfc.dat.

Для систем, на которых не установлен патч MS17-010, используется EternalBlue или EternalRomance эксплойты для компрометации системы. Тип эксплойта зависит от того, какую операционную систему использует жертва.

• EternalBlue
  • Windows Server 2008 R2
  • Windows Server 2008
  • Windows 7
• EternalRomance
  • Windows XP
  • Windows Server 2003
  • Windows Vista

Psexeс используется для запуска следующей команды (где w.x.y.z это IP-адрес), используя токен текущего пользователя для установки вредоноса на сетевом устройстве. Talos всё ещё расследует метод, с помощью которого «current user's windows token» вытаскивается вредоносом на текущей машине.

C:WINDOWSdllhost.dat \w.x.y.z -accepteula -s -d C:WindowsSystem32rundll32.exe C:Windowsperfc.dat,#1

WMI импользуется для выполнения следующих команд, которые делают функционально тоже самое, что и psexec, но использует при этом логин и пароль текущего пользователя(username и password). Talos всё ещё исследует метод, которым вредоносу становятся известны логин и пароль текущего пользователя.

Wbemwmic.exe /node:"w.x.y.z" /user:"username" /password:"password" "process call create "C:WindowsSystem32rundll32.exe "C:Windowsperfc.dat" #1"

Как только система скомпрометирована, зловред шифрует файлы, используя RSA шифр с 2048-битный ключом. Дополнительно вредонос пытается очистить текущие системные журналы на скомпрометированной системе, используя для этого следующие команды:

wevtutil cl Setup & wevtutil cl System & wevtutil cl Security & wevtutil cl Application & fsutil usn deletejournal /D %c:

Системы с перезаписанным MBR после рестарта показывают следующее сообщение:



Рекомендуемые меры противодействия

Есть несколько действенных мер противодействия, которые можно предпринять, чтобы обезопасить свое окружение от действий Nyetya:

• Первое и самое главное, мы настоятельно рекомендуем клиентам, которые ещё не установили патч MS17-010 сделать это немедленно. Учитывая масштаб угрозы и её распространение, иметь непропатченные системы крайне неразумно.
• Использовать ПО, способное обнаруживать и блокировать запуск известных образцов вредоносного кода.
• Разработать и внедрить план действий в случае подобных нештатных ситуаций, включающий в себя не только регулярное резервное копирование, но и регулярную проверку восстановления данных из резервных копий. Резервные копии не должны быть доступны из сети и храниться отдельно.
• Полностью отключить SMBv1, если это возможно, и перейти на использование более продвинутых версий SMB. (SMBv2 впервые появился в Microsoft Vista).

Так как Nyetya пытается перезаписать MBR на заражённой машине, Talos протестировал применимость разработанного нами ПО MBRFilter для защиты системного MBR. Тесты показали применимость этого ПО для защиты системного MBR. Для тех пользователей и компаний, для которых это актуально, мы рекомендуем MBRFilter в качестве одной из мер защиты. Тем не менее, MBRFilter это open source проект Talos и мы не можем предоставить каких либо гарантий или оказать поддержку при его использовании.

Текущее покрытие системами безопасности Cisco

Клиенты Cisco могут защищаться от Nyetya с помощью следующих продуктов:

• Advanced Malware Protection (AMP) идеально подходит для блокировки исполнения вредоносного ПО. При этом стоит отметить, что обнаружение вредоносного кода осуществляется не по сигнатурам, а по поведению, то есть AMP не зависит от частоты обновления антивирусных баз как у традиционных антивирусов.
• Сетевые устройства защиты, такие как NGFW, NGIPS, и Meraki MX могут обнаруживать сетевую активность, ассоциированную с угрозой. Стоит заметить, что использование уязвимостей EternalBlue и EternalRomance мы обнаруживаем еще с апреля этого года, задолго до начала эпидемий WannaCry и Nyetya.
• AMP Threat Grid успешно идентифицирует бинарные файлы вредоносного ПО.
• Email и Web пока не подтверждены как используемый в атаке вектор в настоящий момент. В дополнение, не существует известных элементов внешнего управления данным вредоносом в настоящее время.
• Свежие сигнатуры Snort доступны на официальном сайте проекта Snort.org.

Правила NGIPS / Snort

Следующие правила NGIPS / Snort обнаруживают данную угрозу:

• 42944 — OS-WINDOWS Microsoft Windows SMB remote code execution attempt
• 42340 — OS-WINDOWS Microsoft Windows SMB anonymous session IPC share access attempt
• 41984 — OS-WINDOWS Microsoft Windows SMBv1 identical MID and FID type confusion attempt

Следующие правила NGIPS / Snort также обнаруживают деятельность вредоносного ПО в трафике:

• 5718 — OS-WINDOWS Microsoft Windows SMB-DS Trans unicode Max Param/Count OS-WINDOWS attempt
• 1917 — INDICATOR-SCAN UPnP service discover attempt
• 5730 — OS-WINDOWS Microsoft Windows SMB-DS Trans Max Param OS-WINDOWS attempt
• 26385 — FILE-EXECUTABLE Microsoft Windows executable file save onto SMB share attempt
• 43370 — NETBIOS DCERPC possible wmi remote process launch

Threat Grid

Threat Grid успешно обнаруживает сэмплы вредоноса Nyetya и корректно аттрибуцирует их как вредоносные.


Индикаторы компрометации (IOCs)

Детектирование в AMP

W32.Ransomware.Nyetya.Talos

SHA256

027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745
eae9771e2eeb7ea3c6059485da39e77b8c0c369232f01334954fbac1c186c998 (password stealer)

Дополнительная информация:

• видео-запись вебинара Cisco «Не дай зашифровать себя» о программе-шифровальшике WannaCry
• руководство Cisco по дизайну инфраструктуры для борьбы с программами-вымогателями (на английском языке)
• раздел на сайте Cisco (на английском языке), посвященной борьбе с программами-вымогателями
• рекомендации Cisco по борьбе с WannaCry (на русском языке)
• детальное описание возможностей по сегментации сети (на русском языке)
• годовой отчет по кибербезопасности (на русском языке)
• детальное и регулярно обновляемое описание Nyetya от Cisco Talos (на английском языке)
• видео-презентация по нашему подходу в борьбе с программами-вымогателями (на русском языке)

Автор: alukatsky

Источник