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

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

image

Почему?


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

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

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


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

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

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

image

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

  • блокировать ненужные сетевые и 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, являющейся лидером мирового рынка информационной безопасности, есть целый набор технологий и решений, которые позволяют бороться с этой угрозой, на разных этапах жизненного цикла шифровальщика, — от попытки заражения до активного распространения по внутренней сети.

image

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

image

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

  • аппаратные и виртуальные межсетевые экраны 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 миллиарда долларов в год. Мы протестировали работу всех компонентов нового руководства и отвечаем за их работоспособность.

image

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


Если все-таки вернуться к истории с 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:\WINDOWS\TEMP\561D.tmp, \\.\pipe\{C1F0BF2D-8C17-4550-AF5A-65A22C61739C}

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

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

Wbem\wmic.exe /node:"w.x.y.z" /user:"username" /password:"password" "process call create "C:\Windows\System32\rundll32.exe \"C:\Windows\perfc.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:\WINDOWS\dllhost.dat \\w.x.y.z -accepteula -s -d C:\Windows\System32\rundll32.exe C:\Windows\perfc.dat,#1

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

Wbem\wmic.exe /node:"w.x.y.z" /user:"username" /password:"password" "process call create "C:\Windows\System32\rundll32.exe \"C:\Windows\perfc.dat\" #1"

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

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

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

?image

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


Есть несколько действенных мер противодействия, которые можно предпринять, чтобы обезопасить свое окружение от действий 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 и корректно аттрибуцирует их как вредоносные.
?
image

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


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


W32.Ransomware.Nyetya.Talos

SHA256


027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745
eae9771e2eeb7ea3c6059485da39e77b8c0c369232f01334954fbac1c186c998 (password stealer)

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

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

Комментарии (40)


  1. electronus
    30.06.2017 04:20

    ASa пропустила бы «заряженное» обновление к медку? Ну просто интересно


    1. tankistua
      30.06.2017 08:58

      Есть информация, что живые кто был за ssm и за чекпоинт фаерволлом, сама по себе аса не для этого


    1. alukatsky
      30.06.2017 10:44

      «Голая» ASA заблокировала бы внешние соединения по SMB-портам. ASA с Firepower Services заблокировала бы «заряженное» обновление с помощью функции NGIPS и (или) AMP.


  1. prostofilya
    30.06.2017 05:16

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


    1. iCpu
      30.06.2017 06:53
      +5

      «опять эти»


      1. skyblade
        30.06.2017 08:56

        … дни


    1. LoadRunner
      30.06.2017 09:21

      Или отдельный Хаб.


      1. alukatsky
        30.06.2017 10:45
        +1

        Я бы вообще «Информационную безопасность» выделил в верхний уровень хабов, а не в «Разработку». Или тогда уж в «Администрирование»


        1. LoadRunner
          30.06.2017 10:49

          Вы про Потоки? Вполне возможно, это имеет смысл.


  1. PTM
    30.06.2017 09:54

    мне интересно а много простых пользователей пострадало? просто в РФ 300усд далеко не у всех есть…


    1. alukatsky
      30.06.2017 10:46

      Я видел цифру (позавчера) — всего 12000 жертв. У WannaCry к этому моменту было уже близко к 300 тысячам


      1. teecat
        30.06.2017 13:57

        Очень мало заражений простых пользователей. Ванна край атаковал крупняк и домашников. Этот — только крупняк


        1. vilgeforce
          30.06.2017 14:42

          Существует мнение, что первичное заражение было через M.E.Doc, что объясняет заражение крупняка.


          1. teecat
            30.06.2017 14:46

            Нет. Через медок как минимум третье заражение видимо. Первое было XData — оно не шло на крупняк, поэтому ни сми ни сбу его не заметили.
            Я бы предположил, что Медок хакнули давно и его использовали все кому не лень

            А вообще всем рекомендую


            1. vilgeforce
              30.06.2017 14:48

              Третье заражение и «Нет.»? :-) Пока нет внятных доказательств о других способах первичного заражения :-( Все что про почту — туфта полная.


              1. teecat
                30.06.2017 14:52

                Первичное видимо действительно через Медок. Я сказал нет про другое. Через Медок были (видимо) и другие атаки. Но не на крупняк


                1. relia
                  30.06.2017 17:19

                  Через Медок были (видимо) и другие атаки. Но не на крупняк

                  MEdoc используется крупняком и не очень большим количеством ФОПов. Поэтому и ударять по домашним пользователям через него как-то не очень.
                  Кто(что) следующий? «Соната» с торрент-сервером раздачи обновлений, который скорее всего включен у 98% ее установивших?

                  PS
                  У себя MEdoc снес 3 недели назад за монструазность, постоянные качания каких-то обновлений и бесполезность в виду появления бесплатных альтернатив, полностью покрывающих потребности одиночного ФОП.


                  1. teecat
                    30.06.2017 17:27

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


                    1. relia
                      30.06.2017 17:40

                      Я вот лично склоняюсь к мнению, что обкатывают технологию атаки.

                      Для массовых заражений использовать говнопроги, которые вынуждены устанавливать у себя многие пользователи, и постоянно качать апдейты с говносерверов, созданных в тесной кооперации чиновников с помощниками по распилу? Тогда действительно «Соната» будет следующей скорее всего.


                      1. teecat
                        30.06.2017 17:58

                        Я не уверен, что Украина — цель следующей атаки. Данная атака совсем не выглядит политической — нет попыток доступа к данным, атак на конкретные организации, шантажа и тд. А вот как тест реакции, возможностей следственных органов — похоже
                        И сто пудов в иных странах свои Медки в наличии.
                        И интересна реакция регуляторов — озаботятся ли они приказами по мерам безопасности и их проверкой


                        1. relia
                          30.06.2017 20:53

                          Каждый говорит о том, что у него болит :)
                          Я лучше знаком с ситуацией в Украине, чем России, да и «доброжелателей» на зарплате и без у Украины хватает… Россия вводит у себя «электронные кассы» — помимо хорошего распила это тоже даст колоссальную почву для подобных атак.

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


                          1. dbond
                            01.07.2017 21:13

                            Очень даже согласен с последним утверждением. Главбух 2 раза за неделю цепляла WannaCry и оба раза после удаленного подключения СБИС (бух отчетность) через их клиента для удаленного администрирования. Оба раза восстанавливал комп из бэкапов. Локальный СБИС снес напрочь теперь работает только через облачного клиента.


            1. alukatsky
              30.06.2017 22:16

              http://www.me-doc.com.ua/1111193342 — Медок всех еще в мае предупреждал


              1. relia
                01.07.2017 21:49

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


    1. teecat
      30.06.2017 13:53

      Как и в случае в ВаннаКраем четко виден акцент на крупняке. Атаковались те, кто платить не будет, но заставит говорить об этом в СМИ. Точно так же как и ВаннаКрай имеем недоделанный троян и атак не ориентированную на выкуп. Но судя по всему и не политическую.


  1. Sinatr
    30.06.2017 10:33

    Сегодня я узнал, что страусы оказывается не прячут голову в песок. Уже за одно это открытие — большое спасибо!


    1. alukatsky
      30.06.2017 10:46

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


    1. Barafu
      30.06.2017 16:27

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


  1. vilgeforce
    30.06.2017 11:18
    -1

    «зловред шифрует файлы, используя RSA шифр с 2048-битный ключом» — нет. Шифрование файлов — AES-128-CBC, а вот уже AES ключ накрывается RSA и пишется в текстовик.


    1. RuIvanov
      30.06.2017 14:40

      Это доводно точный (дословный) перевод записи в блоге Talos. Технически, да, всё именно так — файлы шифруются AES, ключи AES закрываются RSA 2048. В любом случае, без знания приватного ключа мы не можем расшифровать данные, что гарантированно их делает недоступными.


      1. vilgeforce
        30.06.2017 14:41
        -1

        Один написал, другой перепечатал…


  1. teecat
    30.06.2017 13:56
    +2

    Что в нем такого уникального

    Две вещи:
    — атака почти исключительно на крупняк
    — большое количество сообщений о заражениях от пользователей, которые поставили все рекомендуемые обновления после Ванна Края


  1. DRDOS
    30.06.2017 19:00
    -1

    Какие все прямо наивные :(
    о «Пети» узнали многие по тому, что Журналюгам, понравилось слова ПЕТЯ!
    Все дай сложное название и никто ничего не узнал бы!
    А вы молодец, Действуете по принципу.
    Клиента-ошарашить, запугать.
    Предложить море… отличных мер по предотвращению (что бы клиент заплакал, на двадцатой строчке..).
    Потом тонко намекнуть, что вы как бы и сами можете… и тихонько ждать в сторонке!


  1. Emulyator
    30.06.2017 22:10

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


    1. alukatsky
      30.06.2017 22:13
      +1

      Админские права порезать


    1. RuIvanov
      30.06.2017 23:28

      Можно. Не совсем тривиально — там используется несколько способов, но можно. Основной — не дать утащить пароли из памяти, где они хранятся в открытом виде. https://jimshaver.net/2016/02/14/defending-against-mimikatz/


    1. RuIvanov
      30.06.2017 23:32

      Ещё можно воспользоваться советами отсюда: http://blog.gojhonny.com/2015/08/preventing-credcrack-mimikatz-pass-hash.html


      1. Emulyator
        01.07.2017 00:04

        Спасибо за ссылки. Действительно, не совсем тривиально, и пока не понятно насколько это применимо в моей печальной ситуации с локальной сетью, где в основной массе машинки с xp. (
        Прямо какая-то беда с этими легальными инструментами, и странно, что так мало информации по настройке безопасности в этом контексте.


        1. Foggy4
          04.07.2017 12:31

          Большинство рекомендаций по ссылке применимо и в вашем инвайроменте. Я бы выделил самые важные:

          1) Используйте VLANы, сегментируйте сеть. Используйте файрволл между VLAN, максимально ограничивайте взаимодействие рабочих станций между собой.
          2) Используйте возможности локальных файрволлов на рабочих станциях (появились на XP SP2). В первую очередь ограничьте SMB и NetBIOS.
          3) Ограничьте использование привилегированных учетных записей. Везде и всегда следуйте принципу предоставления лишь минимально необходимых полномочий.
          4) Устраняйте уязвимости, вовремя устанавливайте обновления безопасности.
          И от меня — не забывайте про административные меры/тренинги персонала. Об этом почему-то редко пишут в подобных статьях, хотя я бы поставил это на одно из первых мест. Регулярно доносите до сотрудников мысль, что они — важное звено в борьбе с киберугрозами, без их помощи ничего не получится. Это включает в себя как понимание того, что нельзя кликать по ссылкам без разбора, открывать подозрительные вложения, пытаться в обход ИТ отдела устанавливать или обновлять ПО, так и понимание необходимости сообщать в ИТ отдел о незнакомцах в офисе или о коллеге, который принес ноутбук на работу без разрешения и что-то на нем делает. Мы проводим тренинги раз в год со всеми сотрудниками, с экзаменом по политике информационной безопасности для каждого по итогам.


          1. Emulyator
            04.07.2017 17:25

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