PowerWare новый вымогатель использующий PowerShell

    Black Carbon Threat Research Team недавно обнаружили новое семейство вымогателей, получившее название PowerWare. Они нацелены на структуры использующее Microsoft Word и PowerShell. PowerShell является языком сценариев для операционных систем Microsoft.



    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.
    ua-hosting.company
    Хостинг-провайдер: серверы в NL до 300 Гбит/с

    Comments 38

    • UFO just landed and posted this here
        0
        авторы PowerWare изначально просят $500 выкупа

        Дешевле выпустить внутренний документ, запрещающий понижать безопасность макросов.
        Если макросы нужны, то создать пользователю сертификат в ветке "Доверенные корневые центры сертификации" (да хоть в ГОСТ Р 34.11/34.10-2001, которых в каждой конторе навалом), а к нему привязать сертификат для подписи макросов — поместить в ветку "Доверенные издатели". Устанавливаем безопасность макросов "Отключить все макросы кроме макросов с цифровой подписью".
        –2
        Печально.
        До этого времени в моей практике от вымогателей удавалось успешно спасаться используя локальные политики безопасности запрещающие запуск приложений и скриптов из пользовательских папок…
        Но если начнут лезть через ворд… то даже и не знаю, что делать тогда. Запуск макросов не отключить, он многим нужен в работе. Сам ворд тоже нужен.
          +1
          Вредоносные документы пока что легко определяются в почте (я пока что не встречал других способов распространения таких штук) — в письме используются общие фразы "высылаем вам акт" и тому подобные, а при запуске такого ворда (если всё правильно настроено) появится окошко "документ содержит макросы, отключить?" — и всё, закрываете документ и shift+delete. Главное научить пользователей не тыкать "включить макросы" при загрузке такого документа и, конечно же, всегда иметь актуальные резервные копии для всего парка машин.
            +1
            Создаем сертификат для подписывания кода. Добавляем этот сертификат в доверенные издатели. Подписываем нужные нам макросы и скрипты PS этим сертификатом. Не подписанное содержимое запрещаем выполнять.
              –1
              Осталось всего ничего, найти деньги на сертификат.
                +1
                Самоподписанный сертификат, на домашнем компьютере. Или выданный центром сертификации в корпоративной инфраструктуре. Все это бесплатно.
            +5
            Мои глаза болеть гугл транслейт нет пожалуйста просить.
            Вычитывайте пожалуйста текст перед тем как запостить.
              +1
              — Эй, антивирус! Ворд создал экзешник и они вместе что-то скачивают!
              — Всё ок, сигнатур таких нет.
              — О! А вот ещё. Тут в радиусе 100км никто никогда js файлы вручную не запускал, а тут вдруг запустили и оно меняет все подряд файлы!
              — Не, не, всё в порядке…
                0
                Не создал, а запустил.
                Ну скачивает, повершеллу не запрещено скачивать, как и любым другим программам. Это проблема не антивируса, а фаерволла.
                Не если вы не видите суслика, то не значит, что его нет. Сигнатуры на все js не создашь, а ограничивать разработчиков в полете их фантазии не совсем верно. Я в колледже, когда админил было такое, что студенты прибегали и ругались что Kaspersky Gold не дает им файлы компилить в дельфи на безобидных программах. Тоже ничего хорошего.
                А вдруг я захотел зашифровать все свои файлы. По-быстрому. В дверь то уже ломятся. Почему честно купленный антивирус меня должен ограничивать?
                  0
                  Антивирус, как и фаервол, не должны блокировать угрозу, насколько бы опасной она не была. Они должны спрашивать решения у пользователя. Но тот же ворд при активации макроса, или та же винда при запуске js файла, спросят, а действительно ли пользователь хочет выполнить это действие, ведь оно потенциально опасно, но пользователь соглашается. Если антивирус не заметил угрозу — проблема в антивирусе, а если пользователь пропустил угрозу, которую заметил антивирус — то пользователю уже ничего не поможет, он найдёт способ как затащить угрозу в систему. Ну а то, что антивирусные базы содержат сигнатуру, которую можно встретить в болванке приложения на Delphi — это косяк антивирусов, некоторые из которых даже эту страницу могут посчитать опасной, если разметить на ней "вредоносный код" из их базы.
                    0
                    |Антивирус, как и фаервол, не должны блокировать угрозу, насколько бы опасной она не была. Они должны спрашивать решения у пользователя.
                    Оу. У Вас нет на поддержке 3к+ пользователей. Иначе такие глупые мысли Вам бы в голову даже не пришли.
                    У пользователя по умолчанию ничего спрашивать не нужно, нужно выбирать самое безопасное действие на своё усмотрение.
                    Тем кто по опытнее дать возможность на свой страх и риск залезть в настройки и выставить галочки на своё усмотрение.
                    Вы слишком много хотите от антивирусов и от пользователей. Что первые, что и вторые — не совершенны.
                      0
                      Вместо того, чтобы объяснить пользователю суть проблемы, вы предлагаете не разрешать ему включать компьютер. Наверное это идеальное решение проблемы взаимодействия пользователя и компьютера, но скорее всего пользователь так же не сможет решать поставленные задачи.
                        0
                        | вы предлагаете не разрешать ему включать компьютер
                        Где? =)
                      0
                      «Антивирус, как и фаервол, не должны блокировать угрозу, насколько бы опасной она не была. Они должны спрашивать решения у пользователя.»

                      WAT?????
                        0
                        NTG!!!!11
                        Я хотел сказать лишь о том, что у пользователя должен быть выбор, а не просто окошко с уведомлением о том, что угроза была заблокирована. Например на случай, если антивирус ругается на то, что в тхт файле содержится особо опасный вирус и поэтому его нельзя открывать.
                          0
                          Если это домашний компьютер, я согласен, что у пользователя должен быть выбор, поскольку за свои действия он отвечает сам. В случае компьютера в компании, наверное все таки лучшим способом будет автоматическая блокировка в любом случае.
                            0
                            Так в большинстве случаев и делают. Вместо того, чтобы объяснить пользователям банальные правила безопасного поведения в сети, им ограничивают доступ, закрывают фаерволами и групповыми политиками. И всё замечательно работает ровно до тех пор, пока какое-нибудь из средств защиты не даёт сбой: антиспам пропустит письмо, антивирус не заметит новую сборку или пользователь скачает свежих котиков с расширением ps1. Это, блин, как закрывать фаерволом порт сервиса, который поддерживает авторизацию, но настроить её нормально лень. Но конечно же, вместо того, чтобы потратить час на написание инструкции с описанием типичных векторов атак или день на съёмки обучающего ролика, проще сказать что пользователи тупые и сами о себе позаботиться не смогут, тем более что их много, а я один. Конечно же не у всех всё настолько плохо, но большинство тех компаний, которых мне довелось проаудировать, полагались или на защиту софта или ещё хуже, на защиту того же софта установленного на отдельную железку и купленную за какие то сказочные деньги. И защита иногда даже работает, особенно если атаки имеют массовый характер, но стоит провести таргетированную атаку и софт лажает, атака доходит до пользователей, и если атакующий знает какие именно возможности у пользователя на ПК заблокированы, он подберёт такой вектор, что защитить пользователя сможет только он сам.
                  0
                  Почему microsoft не сделают так, чтобы пользователи могли настроить ограничения макросов или вовсе их выключить, но с возможностью редактирования файла? Кто знает, как ситуация обстоит с другими офисными программами?
                    0
                    А с каких пор блокировка макросов мешает работе с документами? Просто макросы не будут запускаться, и всё.
                    А что угодно в документе творить можно и дальше.
                    Да и блокировка макросов возможна как полная, так и частичная — блокировать только неподписанные.
                    0
                    Похоже, пришло время запрещать: Запретить использование командной строки(Конфигурация пользователя — Административные шаблоны — Система в gpedit.msc)
                    0
                    Не нашел, как решен вопрос PowerShell Execution Policy?
                      0
                      powershell.exe запускается с ключем -executionplicy bypass. На втором скриншоте это видно
                      0
                      А вот тут большая пребольшая дыра походу.
                      И так — имеется ПК в домене + учетка которой через GPO запрещено выполнение любых программ кроме списка явно обозначенных (cmd в нем есть а вот powershell нету).
                      Попытка запуска powershell через ярлык или как-то еще ни к чему не приводит.
                      Но вот если мы запустим cmd и там набирем "powershell -executionpolicy bypass" — то мы окажемся в среде powershell и выполнив "Get-executionPolicy" убедимся что режим реально стал bypass, хотя по умолчанию выполнение скриптов было запрещено.
                      Вот такая вот фигня.
                        0
                        Никакой дыры, если у нас есть возможность заставить cmd выполнять произвольные команды, почему выполнение powershell скриптов это что-то более опасное?
                          0
                          Я правильно его запускаю?

                          0
                          Тут на днях случайно наткнулся на ещё один вариант "вируса на powershell" на StackOwerflow. Способ заражения неизестен, но механизм работы занятный.
                            0
                            То есть тот факт, что в описанном мной примере изначально пользователю запрещен запуск powershell в принципе, но из cmd оно таки запускается и в дополнение к этому совершенно спокойно происходит смена политики выполнения этих самых скриптов это нормальная ситуация?
                              +1
                              Отвечу на оба каммента сразу:
                              происходит смена политик
                              Нет, не просиходит. Запускается отдельно взятый инстанс процесса powershell в обход политики. Вы можете это воспринимать это как одно и то же, но на самом деле это не так. Кроме того, много раз Майкрософтом было сказано, что execution policy — метод защиты от случайных запусков скриптов, с безопасностью он имеет мало общего
                              запрещено выполнение любых программ кроме списка явно обозначенных (cmd в нем есть а вот powershell нету).
                              Откройте cmd и вызовите из него любую программу не из "списка явно обозначенных". Удивление гарантирую :) Скажу даже больше: почти все утилиты (ping, ipconfig, netsh) — точно такие же экзешники, как и powershell.exe. Можете легко найти их поиском в системной папке.
                              А вот тут большая пребольшая дыра походу.
                              В вызове powershell через cmd нет какой-то секретной магии. Он запустится в контексте тех прав, с которыми выполнялся cmd. А значит сможет сделать ровно то же, что и так можно сделать через cmd и bat-файлы.
                              0
                              А как бороться-то? В гугле пока пусто.

                              — запрещать вообще (или только неподписанные) макросы
                              — запрещать 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-clients
                                0
                                Дырка же в том, что пользователь может включить макросы. Какая разница, будет зловредный код написан на VBA или на powershell?
                                  0
                                  С CMD как бороться не в курсе, а с PowerShell довольно просто. Назначать ExecutionPolicy в 'AllSigned' через GPO. В таком случае '-ExecutionPolicy Bypass' не сработает.
                                  Пример

                                    0
                                    Не помню навскидку — режит AllSigned требует только своих внутренних сертификатов, или скрипт может быть подписан левой подписью и таки отработать???
                                      0
                                      Должно быть подписано доверенным валидным сертификатом.
                                        0
                                        Отлично, действительно работает.
                                        Капец конечно, запуск через CMD даже спокойно обходит ограничение в прямом виде через SRP )))

                                        Интересно, это не повлияет на запуск всяких встроенных maintenance скриптов в task sheduler на новых системах, там вроде было что-то встроенное, с запуском по расписанию??
                                      0
                                      Это не работает для однострочников, да и подписывать свои скрипты ленится даже Microsoft (последний абзац).
                                        0

                                        Это работает для любых *.ps1 файлов.
                                        Для powershell.exe -command "<command here>" оно, действительно, не сработает. Впрочем, даже в EncodedCommand особо много не запихнуть (функция шифрования, например, не влезет), так что я бы не переживал сильно на этот счёт.


                                        Я говорю про защиту от выполнения именно сторонних неподписанных файлов-скриптов.
                                        Ну а то, что кто-то не подписывает какие-то конкретные скрипты — так кто мешает подписать внутренним сертификатом, если уверен в скрипте? <paranoia mode>Я вот, например, никогда не уверен в левых скриптах и перепроверяю сам, кто бы их ни написал.</paranoia mode>

                                  Only users with full accounts can post comments. Log in, please.