PowerWare — новый экземпляр вымогателей, использующий собственные инструменты операционных систем, такие как PowerShell. Как правило, “традиционные” варианты вымогателей устанавливают новые вредоносные файлы в системе, которые в некоторых случаях проще обнаружить. PowerWare использует PowerShell, базовую утилиту текущих систем Windows, чтобы сделал всю грязную работу. Используя PowerShell данный вымогатель пытается избежать создания новых файлов на диске и замаскировать свои действия под действия уже установленных, легальных скриптов.
Обманчиво простой код PowerWare — это новый подход к вымогателям, отражающий растущую тенденцию среди авторов вредоносных программ, которые выходят за рамки стандартных вредоносных решений.
Распространенность и популярность вымогателей в последнее время была ошеломляющей, тысячи организаций пришлось заплатить выкуп, чтобы разблокировать свои зашифрованные файлы. За последние несколько дней были выявлены успешные и громкие атаки вымогателей в трех американских больницах. Исследовательская группа Carbon Black Threat Research обнаружила PowerWare после безуспешной атаки, нацеленной на организацию здравоохранения, что находилась в клиентской базе Carbon Black. При этом использовалась фишинг-кампания по электронной почте.
Исследование показало, что PowerWare загружается с помощью Microsoft Word документом с макрос-включениями. Документ Word использует макросы, чтобы создать cmd.exe, который поочередно вызывает PowerShell с необходимыми опциями. Опции загружают и распространяют вредоносный код PowerWare. Довольно интересный момент — авторы PowerWare изначально просят $500 выкупа, который увеличивается до $1000 в течение двух недель.
PowerWare — как это происходит
Для испытательного образца PowerWare используется “вредоносный” документ Word.
В этом примере, когда пользователь включает макросы, создается cmd.exe, который сразу запускает пару экземпляров PowerShell. Один из них загружает сценарий вымогателя, другой запускает PowerShell со сценарием в качестве входных данных.
Процесс выполнения PowerWare в командной строке Вы сможете увидеть на скриншоте ниже.
Ниже приведен фрагмент из PowerWare сценария. В первых строках генерируется несколько случайных чисел, которые будут использоваться для вычисления ключа шифрования, а также для UUID, присвоенного этой конечной точке. Затем URL, чтобы отправить определен ключ. Эта информация в виде обычного текста отправляется на управляющий хоста атакующего с помощью HTTP.
(Примечание: есть хорошие новости для тех кто уже подвергся такой атаке — Вы можете самостоятельного устранить вредоносный скрипт, когда он отправляет запрос домой. Скрипт делает это с помощью простого текстового протокола, что позволяет легко отследить перемещение трафика. Тут возникает простой вопрос идентификации правильного домена и IP от сетевого трафика, чтобы получить ключ шифрования. Для своих пользователей Carbon Black предоставляет информацию как защититься от такого рода вымогателя.)
Далее идет команда для создания фактического ключа, который будет использоваться в шифровании, векторе инициализации и других crypto-параметрах.
Наконец, скрипт проходит через файловую систему, шифруя каждый файл с указанным расширением (расширения указаны ниже).
Атакующие также включали файл HTML в каждую папку, в которой есть зашифрованные файлы с именем FILES_ENCRYPTED-READ_ME.HTML. В файлах детализировано все то, как жертва может вернуть свои данные обратно.
Ключевой фразой является:
Вы бы лучше поторопились! Цена увеличится в два раза спустя пару недель!
Обнаружение PowerWare
Пользователи Carbon Black Enterprise Protection могут блокировать первоначальный исполняемый файл cmd.exe от Word. Действует правило, которое блокирует cmd.exe от выполнения при запуске с помощью winword.exe. Сделать такие же правила для остальных офисных приложений, вроде excel.exe, powerpnt.exe и outlook.exe может стать хорошим решением. Как всегда при создании правил, рекомендуется сначала создать их, как правила отчетов и следить за консолью, чтобы оценить любые потенциальные воздействия. Как только Вы удостоверитесь, что правила не принесут вреда работе Вашей среды — можете установить его действие в режим «Блокировать».
Аналогичное правило для браузеров, чтобы блокировать приложения от запуска PowerShell. Это также должно помочь уберечь от других типов вредоносного программного обеспечения, использующего документы Office.
Для обнаружения следующие запросы Carbon Black Enterprise Protection должны идентифицировать действие, а также (другие типы вредоносного программного обеспечения):
process_name: cmd.exe PARENT_NAME: winword.exe chilproc_name: powershell.exe:
process_name: powershell.exe filemod_count: [1000 *]
В то время как данная выборка использует cmd.exe в качестве посредника, Вам следует наблюдать за PowerShell, который был создан непосредственно – process_name: powershell.exe PARENT_NAME: winword.exe.
И даже файл cmd.exe, созданный от офисных приложений для более общего обнаружения:
Process_name: cmd.exe и (PARENT_NAME: winword.exe или PARENT_NAME: excel.exe или PARENT_NAME: Powerpnt.exe или PARENT_NAME: outlook.exe).
Детали по файлу
Сетевые детали
PowerWare шифрует следующие форматы:
Оригинал статьи Вы можете найти на официальном сайте Carbon Black.
Комментарии (35)
Sublustris
29.03.2016 21:07-2Печально.
До этого времени в моей практике от вымогателей удавалось успешно спасаться используя локальные политики безопасности запрещающие запуск приложений и скриптов из пользовательских папок…
Но если начнут лезть через ворд… то даже и не знаю, что делать тогда. Запуск макросов не отключить, он многим нужен в работе. Сам ворд тоже нужен.morgreek
29.03.2016 21:46+1Вредоносные документы пока что легко определяются в почте (я пока что не встречал других способов распространения таких штук) — в письме используются общие фразы "высылаем вам акт" и тому подобные, а при запуске такого ворда (если всё правильно настроено) появится окошко "документ содержит макросы, отключить?" — и всё, закрываете документ и shift+delete. Главное научить пользователей не тыкать "включить макросы" при загрузке такого документа и, конечно же, всегда иметь актуальные резервные копии для всего парка машин.
alex-khv
30.03.2016 09:26+1Создаем сертификат для подписывания кода. Добавляем этот сертификат в доверенные издатели. Подписываем нужные нам макросы и скрипты PS этим сертификатом. Не подписанное содержимое запрещаем выполнять.
Sublustris
30.03.2016 09:35-1Осталось всего ничего, найти деньги на сертификат.
alex-khv
30.03.2016 09:37+1Самоподписанный сертификат, на домашнем компьютере. Или выданный центром сертификации в корпоративной инфраструктуре. Все это бесплатно.
korobkinn
29.03.2016 23:10+5Мои глаза болеть гугл транслейт нет пожалуйста просить.
Вычитывайте пожалуйста текст перед тем как запостить.
ProstoTyoma
30.03.2016 01:09+1— Эй, антивирус! Ворд создал экзешник и они вместе что-то скачивают!
— Всё ок, сигнатур таких нет.
— О! А вот ещё. Тут в радиусе 100км никто никогда js файлы вручную не запускал, а тут вдруг запустили и оно меняет все подряд файлы!
— Не, не, всё в порядке…Sergey-S-Kovalev
30.03.2016 06:46Не создал, а запустил.
Ну скачивает, повершеллу не запрещено скачивать, как и любым другим программам. Это проблема не антивируса, а фаерволла.
Не если вы не видите суслика, то не значит, что его нет. Сигнатуры на все js не создашь, а ограничивать разработчиков в полете их фантазии не совсем верно. Я в колледже, когда админил было такое, что студенты прибегали и ругались что Kaspersky Gold не дает им файлы компилить в дельфи на безобидных программах. Тоже ничего хорошего.
А вдруг я захотел зашифровать все свои файлы. По-быстрому. В дверь то уже ломятся. Почему честно купленный антивирус меня должен ограничивать?DarkByte
30.03.2016 09:00Антивирус, как и фаервол, не должны блокировать угрозу, насколько бы опасной она не была. Они должны спрашивать решения у пользователя. Но тот же ворд при активации макроса, или та же винда при запуске js файла, спросят, а действительно ли пользователь хочет выполнить это действие, ведь оно потенциально опасно, но пользователь соглашается. Если антивирус не заметил угрозу — проблема в антивирусе, а если пользователь пропустил угрозу, которую заметил антивирус — то пользователю уже ничего не поможет, он найдёт способ как затащить угрозу в систему. Ну а то, что антивирусные базы содержат сигнатуру, которую можно встретить в болванке приложения на Delphi — это косяк антивирусов, некоторые из которых даже эту страницу могут посчитать опасной, если разметить на ней "вредоносный код" из их базы.
Sergey-S-Kovalev
30.03.2016 11:40|Антивирус, как и фаервол, не должны блокировать угрозу, насколько бы опасной она не была. Они должны спрашивать решения у пользователя.
Оу. У Вас нет на поддержке 3к+ пользователей. Иначе такие глупые мысли Вам бы в голову даже не пришли.
У пользователя по умолчанию ничего спрашивать не нужно, нужно выбирать самое безопасное действие на своё усмотрение.
Тем кто по опытнее дать возможность на свой страх и риск залезть в настройки и выставить галочки на своё усмотрение.
Вы слишком много хотите от антивирусов и от пользователей. Что первые, что и вторые — не совершенны.DarkByte
30.03.2016 11:50Вместо того, чтобы объяснить пользователю суть проблемы, вы предлагаете не разрешать ему включать компьютер. Наверное это идеальное решение проблемы взаимодействия пользователя и компьютера, но скорее всего пользователь так же не сможет решать поставленные задачи.
whiplash
30.03.2016 14:09«Антивирус, как и фаервол, не должны блокировать угрозу, насколько бы опасной она не была. Они должны спрашивать решения у пользователя.»
WAT?????DarkByte
30.03.2016 14:20NTG!!!!11
Я хотел сказать лишь о том, что у пользователя должен быть выбор, а не просто окошко с уведомлением о том, что угроза была заблокирована. Например на случай, если антивирус ругается на то, что в тхт файле содержится особо опасный вирус и поэтому его нельзя открывать.dimka11
30.03.2016 18:46Если это домашний компьютер, я согласен, что у пользователя должен быть выбор, поскольку за свои действия он отвечает сам. В случае компьютера в компании, наверное все таки лучшим способом будет автоматическая блокировка в любом случае.
DarkByte
30.03.2016 19:20Так в большинстве случаев и делают. Вместо того, чтобы объяснить пользователям банальные правила безопасного поведения в сети, им ограничивают доступ, закрывают фаерволами и групповыми политиками. И всё замечательно работает ровно до тех пор, пока какое-нибудь из средств защиты не даёт сбой: антиспам пропустит письмо, антивирус не заметит новую сборку или пользователь скачает свежих котиков с расширением ps1. Это, блин, как закрывать фаерволом порт сервиса, который поддерживает авторизацию, но настроить её нормально лень. Но конечно же, вместо того, чтобы потратить час на написание инструкции с описанием типичных векторов атак или день на съёмки обучающего ролика, проще сказать что пользователи тупые и сами о себе позаботиться не смогут, тем более что их много, а я один. Конечно же не у всех всё настолько плохо, но большинство тех компаний, которых мне довелось проаудировать, полагались или на защиту софта или ещё хуже, на защиту того же софта установленного на отдельную железку и купленную за какие то сказочные деньги. И защита иногда даже работает, особенно если атаки имеют массовый характер, но стоит провести таргетированную атаку и софт лажает, атака доходит до пользователей, и если атакующий знает какие именно возможности у пользователя на ПК заблокированы, он подберёт такой вектор, что защитить пользователя сможет только он сам.
Oplkill
30.03.2016 09:26Почему microsoft не сделают так, чтобы пользователи могли настроить ограничения макросов или вовсе их выключить, но с возможностью редактирования файла? Кто знает, как ситуация обстоит с другими офисными программами?
LoadRunner
30.03.2016 11:52А с каких пор блокировка макросов мешает работе с документами? Просто макросы не будут запускаться, и всё.
А что угодно в документе творить можно и дальше.
Да и блокировка макросов возможна как полная, так и частичная — блокировать только неподписанные.
Zven
30.03.2016 09:26Похоже, пришло время запрещать: Запретить использование командной строки(Конфигурация пользователя — Административные шаблоны — Система в gpedit.msc)
Shaz
30.03.2016 10:37А вот тут большая пребольшая дыра походу.
И так — имеется ПК в домене + учетка которой через GPO запрещено выполнение любых программ кроме списка явно обозначенных (cmd в нем есть а вот powershell нету).
Попытка запуска powershell через ярлык или как-то еще ни к чему не приводит.
Но вот если мы запустим cmd и там набирем "powershell -executionpolicy bypass" — то мы окажемся в среде powershell и выполнив "Get-executionPolicy" убедимся что режим реально стал bypass, хотя по умолчанию выполнение скриптов было запрещено.
Вот такая вот фигня.ApeCoder
30.03.2016 12:58Никакой дыры, если у нас есть возможность заставить cmd выполнять произвольные команды, почему выполнение powershell скриптов это что-то более опасное?
n01d
30.03.2016 13:05Тут на днях случайно наткнулся на ещё один вариант "вируса на powershell" на StackOwerflow. Способ заражения неизестен, но механизм работы занятный.
Shaz
30.03.2016 13:12То есть тот факт, что в описанном мной примере изначально пользователю запрещен запуск powershell в принципе, но из cmd оно таки запускается и в дополнение к этому совершенно спокойно происходит смена политики выполнения этих самых скриптов это нормальная ситуация?
totoro042
30.03.2016 14:50+1Отвечу на оба каммента сразу:
происходит смена политик
Нет, не просиходит. Запускается отдельно взятый инстанс процесса powershell в обход политики. Вы можете это воспринимать это как одно и то же, но на самом деле это не так. Кроме того, много раз Майкрософтом было сказано, что execution policy — метод защиты от случайных запусков скриптов, с безопасностью он имеет мало общего
запрещено выполнение любых программ кроме списка явно обозначенных (cmd в нем есть а вот powershell нету).
Откройте cmd и вызовите из него любую программу не из "списка явно обозначенных". Удивление гарантирую :) Скажу даже больше: почти все утилиты (ping, ipconfig, netsh) — точно такие же экзешники, как и powershell.exe. Можете легко найти их поиском в системной папке.
А вот тут большая пребольшая дыра походу.
В вызове powershell через cmd нет какой-то секретной магии. Он запустится в контексте тех прав, с которыми выполнялся cmd. А значит сможет сделать ровно то же, что и так можно сделать через cmd и bat-файлы.
whiplash
30.03.2016 21:19А как бороться-то? В гугле пока пусто.
— запрещать вообще (или только неподписанные) макросы
— запрещать cmd для всех без прав админа — Как это отразится на логон/логофф скриптах
https://community.spiceworks.com/topic/430295-disable-cmd-for-all-users-but-administrators
http://stackoverflow.com/questions/29699337/disable-cmd-and-powershell-on-windows-server-2012-for-clientsApeCoder
31.03.2016 07:28Дырка же в том, что пользователь может включить макросы. Какая разница, будет зловредный код написан на VBA или на powershell?
n01d
31.03.2016 11:54С CMD как бороться не в курсе, а с PowerShell довольно просто. Назначать ExecutionPolicy в 'AllSigned' через GPO. В таком случае '-ExecutionPolicy Bypass' не сработает.
Примерwhiplash
31.03.2016 12:09Не помню навскидку — режит AllSigned требует только своих внутренних сертификатов, или скрипт может быть подписан левой подписью и таки отработать???
n01d
31.03.2016 12:23Должно быть подписано доверенным валидным сертификатом.
whiplash
31.03.2016 13:53Отлично, действительно работает.
Капец конечно, запуск через CMD даже спокойно обходит ограничение в прямом виде через SRP )))
Интересно, это не повлияет на запуск всяких встроенных maintenance скриптов в task sheduler на новых системах, там вроде было что-то встроенное, с запуском по расписанию??
SyavaSyava
Забавная идея.
Но ничего нового — те же макросы в офисных файлах, которые включают сами пользователи, те же скрипты/бинарники во временных папках. Только вместо js теперь ps1.
Нормально настроенная политика ограничения использования программ всё так же эффективно отправляет все эти потуги в нужном направлении, без всяких там «XXX Enterprise Protection». Кстати, для интереса заглянул на сайт производителя этого чудесного продукта — судя по всему ценник у них конский, т.к. даже постеснялись указать его на сайте.
Переводчик статьи ко второй половине видать совсем выдохся, и оставил продукт гуглоперевода как есть. Но ценного там ничего нет, так что пускай…
bopoh13
Дешевле выпустить внутренний документ, запрещающий понижать безопасность макросов.
Если макросы нужны, то создать пользователю сертификат в ветке "Доверенные корневые центры сертификации" (да хоть в ГОСТ Р 34.11/34.10-2001, которых в каждой конторе навалом), а к нему привязать сертификат для подписи макросов — поместить в ветку "Доверенные издатели". Устанавливаем безопасность макросов "Отключить все макросы кроме макросов с цифровой подписью".