Да вы "эксперт"! А вот слова и тональность мнения эксперта вполне справедливы. Не прошло и полгода, как эти скрипткидди с DLS а-ля школьный реферат в PPT сгинули в никуда, сейчас о них ни слуху, ни духу
Тема совершенно не новая, статей по данной технике достаточно. Реализация и на C, и на C# с исходниками. Но за русский спасибо, конечно, только за это и плюсану :-)
Ну а теперь к фактам, о которых сказал выше: 2 июля Akira Ransomware выпустили новую версию, в которой исправлена ошибка, позволяющая декриптить файлы.
Я так и не понял, кто "плохие парни". Накосячившие спецы Аваста или также накосячившие авторы Akira? Но в итоге смекнул, что все же это я :-)
Ваш укор имел бы хоть какой то определенный смысл, если б наперед не была опубликована статья Аваста и ими же выложен декриптор, который расшифровывает файлы. И достаточно успешно.
Мой опыт говорит о том, что после публикации любой статьи или просто намека на уязвимость в шифровании вымогателя, его авторы бросаются переделывать свой продукт.
А насчет Доктор Веба и истории не сомневаюсь, я их прекрасно знаю, ну не меньше лет 20-ти :-)
Занимаюсь этой тематикой, поэтому прочитал с интересом, хотя и не люблю переводные статьи. 2 года!?!? Я даже взгрустнул за коллег-поляков.
Действительно вымогатель Dharma появился достаточно давно, был еще CrySiS. Говорят, что Dharma разработали наши умельцы. Потом другие умельцы декомпилировали и стали продавать в андеграунде исходники. Так что Phobos - это, скорее, форк, чем продолжение творчества первых. Dharma/Phobos активно работают по России, суммы выкупа невысокие, если жертва решила платить, то у нас не было случаев, чтобы ее кидали с ключами. Заходят преимущественно по уязвимому RDP. Акторы и из Германии, Ирана, и еще кому, не лень.
2 года!? Конечно, редко ресерч редко заканчивается триумфальной расшифровкой, сам эпический процесс, проделанный поляками, достоин всяческого уважения. Причем без иронии. Но эти 2 года можно было потратить на дрессировку жертв, чтобы отучить их оставлять внешний RDP с паролем "123". Причем, сколько было жертв Dharma/Phobos, всегда была одна и та же история. У вас есть RDP в интернете? Да, что вы, мы так не делаем. Потом в итоге находили, и не один. Как то делали, забыли отключить, ну и т.п. Поэтому весь подвиг в мирное время сводится к исправлению чьих то косяков.
Насколько я помню в Dharma, на один логический диск/сетевой ресурс два потока, на каждый поток свой ключ AES. То есть на хост в среднем 6-10 ключей AES. Вроде нечто похожее и в Phobos.
Мне знакома ситуация, что локоток близок. Некоторые непугливые не боятся поначалу, бросаются брутить нормально сгенерированные 32-байтные ключи. Тут генерация ключа паршивая однозначно, но все равно брут практически сложно реализуем, что и требовалось доказать. Сложно осуждать коллег, но опять же 2 года это очень много, чтобы это понять. Получился пшик, но читать занятно
Некоторые моменты и выводы удивляют. Например, не понятно зачем реверсить каждый сэмпл, можно написать ярки на пейлоады Phobos, обновлять их при необходимости. Самих пейлоадов не так много в целом, да, конфиги разные у сэмплов. Да сэмплы обфусцированы, так и это не проблема. Поэтому здесь не вижу проблем автоматизировать процесс идентификации нужного пейлоада.
Почему же!? Если речь идет об конкретной атаке с использование вымогателя, описывают ее киллчейн и TTPs. Атаку проводят конкретные атакующие, партнеры RaaS, все зависит от их квалификации. Есть еще один момент, не все хотят раскрывать подробности атаки, чтобы не раскрыть клиента.
Касательно Зеппелина начальным вектором атаки чаще выступают слабозащищенные внешние сервисы RDP и VPN.
Я - реверсер, поэтому рассказал про саму программу-вымогатель, ее функциональные возможности.
Если Вас интересует этот вопрос более широко, я могу посоветовать книгу своего друга и коллеги, она совсем недавно вышла в русском переводе.
У некоторых антивирусов есть поведенческие правила на "нездоровую" активность в файловой системе. Атаки с Зеппелином не относятся к сложным, тут только шантаж за разблокировку данных, нет схемы двойного-тройного вымогательства. В более сложных атаках, да уже и в более простых нередкость, что шифровальщик размещается в сети жертвы на "выжженную" землю, когда антивирусы и другие средства безопасности снесены. А некоторые атакующие вообще берут отключают хосты от сети :-)
Также, в дополнение к предыдущему, поясните, пожалуйста, каким образом поможет плагин, не случайно имеющий в своем названии слово shellcode, на данном конкретном примере:
Резонно и возможно будет правильнее. Это больше вопрос предпочтения. Так сложилось, что я предпочитаю в качестве отладчика x64dbg или даже древний OllyDbg, IDA Debugger мне не нравится, хотя он становится все лучше. Менять предпочтения под конкретную задачу я просто не стал. К тому же с IDA Debugger ранее плохо "дружили" плагины подобные ScyllaHide. Если что, по 1 подчасти есть схожая статья Check Point, только там еще разработали плагин для взаимодействия с отладчиком.
Вы сами ответили на свой вопрос. Вопрос гибкости. Стоит ли полагаться на чужой вспомогательный инструмент и постоянно дорабатывать его, чем разбираться в вопросе и быть готовым к любому возможному варианту. Кстати, в продолжение этой мысли, по вопросу, что только найти соль и пересчитать хеши. Вы уверены, что этого будет достаточно? Я вот нет
Всё так! Про pefile не стал писать специально, это больше вводная поп-статья, все по минимуму ) Да и признаться, не люблю я pefile ) Про unicorn писал в статье-гайде по VMProtect, отличный эмулятор, но и он имеет ограниченные возможности. Ну и для написания универсального декриптора все же придется пореверсить сначала )
Это резонный вопрос! Насколько быстро и оперативно, не могу сказать. Вот вредина, как Вы говорите, работает и никак не проявляет себя. Либо должны задетектить внешние проявления, либо Вы должны знать конкретно, где и что искать, а это не просто. Когда малварь закрепилась и закрепилась нетривиально, без повода ее найти, увы, достаточно не просто.
Сейчас современный подход строится больше на предотвращении угроз. На основе известных угроз искать подобные, предотвращать и обнаруживать их. А более продвинутый вариант, не отставать от атакующих и хантить новые угрозы, то есть стараться предвидеть их и соответственно строить свою защиту проактивно.
То есть зная про такую угрозу, если у Вас есть EDR, то, конечно, будете мониторить события, связанные с вызовами mofcomp.exe, строить какие-то правила для этого
Либо радикальный вариант, если это возможно, запретить WMI совсем.
Спасибо за хорошую статью!
Единственное, мне не понятен посыл ресёрча. В августе 2020 года появился отчет агентства кибербезопасности и безопасности инфраструктуры США (CISA) номер AR20-216A, Ваша команда решила происследовать указанные там образцы и представить более детальный анализ. Но зачем? Ваша команда выявила Taidoor вживую? Taidoor — сложный RAT, но есть сложнее и изощреннее.
Мне как вирусному аналитику интересен вектор начального доступа, какое-то описание киллчейна атаки с использованием Taidoor, сравнительный анализ со старыми образцами, а Taidoor атакует госсектор, как минимум с 2010 года, и эти образцы есть на VT. То есть мне не хватило более развернутого исследования, а не только реверс конкретных образцов, причем, как мне кажется, не выявленных вашей командой
А анализ ради анализа не очень интересен. Известный факт, что в BI.ZONE хорошие спецы.
Да вы "эксперт"! А вот слова и тональность мнения эксперта вполне справедливы. Не прошло и полгода, как эти скрипткидди с DLS а-ля школьный реферат в PPT сгинули в никуда, сейчас о них ни слуху, ни духу
Тема совершенно не новая, статей по данной технике достаточно. Реализация и на C, и на C# с исходниками. Но за русский спасибо, конечно, только за это и плюсану :-)
Я Игоря знаю с 2000-го года, как он Вас держал 12 лет вирусным аналитиком, ума не приложу :-)
Ну а теперь к фактам, о которых сказал выше: 2 июля Akira Ransomware выпустили новую версию, в которой исправлена ошибка, позволяющая декриптить файлы.
Я так и не понял, кто "плохие парни". Накосячившие спецы Аваста или также накосячившие авторы Akira? Но в итоге смекнул, что все же это я :-)
Ваш укор имел бы хоть какой то определенный смысл, если б наперед не была опубликована статья Аваста и ими же выложен декриптор, который расшифровывает файлы. И достаточно успешно.
Мой опыт говорит о том, что после публикации любой статьи или просто намека на уязвимость в шифровании вымогателя, его авторы бросаются переделывать свой продукт.
А насчет Доктор Веба и истории не сомневаюсь, я их прекрасно знаю, ну не меньше лет 20-ти :-)
Ссылка на оригинал статьи https://cert.pl/en/posts/2023/02/breaking-phobos/
Как по мне, лучше оригинал прочитать :-)
Занимаюсь этой тематикой, поэтому прочитал с интересом, хотя и не люблю переводные статьи. 2 года!?!? Я даже взгрустнул за коллег-поляков.
Действительно вымогатель Dharma появился достаточно давно, был еще CrySiS. Говорят, что Dharma разработали наши умельцы. Потом другие умельцы декомпилировали и стали продавать в андеграунде исходники. Так что Phobos - это, скорее, форк, чем продолжение творчества первых. Dharma/Phobos активно работают по России, суммы выкупа невысокие, если жертва решила платить, то у нас не было случаев, чтобы ее кидали с ключами. Заходят преимущественно по уязвимому RDP. Акторы и из Германии, Ирана, и еще кому, не лень.
2 года!? Конечно, редко ресерч редко заканчивается триумфальной расшифровкой, сам эпический процесс, проделанный поляками, достоин всяческого уважения. Причем без иронии. Но эти 2 года можно было потратить на дрессировку жертв, чтобы отучить их оставлять внешний RDP с паролем "123". Причем, сколько было жертв Dharma/Phobos, всегда была одна и та же история. У вас есть RDP в интернете? Да, что вы, мы так не делаем. Потом в итоге находили, и не один. Как то делали, забыли отключить, ну и т.п. Поэтому весь подвиг в мирное время сводится к исправлению чьих то косяков.
Насколько я помню в Dharma, на один логический диск/сетевой ресурс два потока, на каждый поток свой ключ AES. То есть на хост в среднем 6-10 ключей AES. Вроде нечто похожее и в Phobos.
Мне знакома ситуация, что локоток близок. Некоторые непугливые не боятся поначалу, бросаются брутить нормально сгенерированные 32-байтные ключи. Тут генерация ключа паршивая однозначно, но все равно брут практически сложно реализуем, что и требовалось доказать. Сложно осуждать коллег, но опять же 2 года это очень много, чтобы это понять. Получился пшик, но читать занятно
Некоторые моменты и выводы удивляют. Например, не понятно зачем реверсить каждый сэмпл, можно написать ярки на пейлоады Phobos, обновлять их при необходимости. Самих пейлоадов не так много в целом, да, конфиги разные у сэмплов. Да сэмплы обфусцированы, так и это не проблема. Поэтому здесь не вижу проблем автоматизировать процесс идентификации нужного пейлоада.
Почему же!? Если речь идет об конкретной атаке с использование вымогателя, описывают ее киллчейн и TTPs. Атаку проводят конкретные атакующие, партнеры RaaS, все зависит от их квалификации. Есть еще один момент, не все хотят раскрывать подробности атаки, чтобы не раскрыть клиента.
Касательно Зеппелина начальным вектором атаки чаще выступают слабозащищенные внешние сервисы RDP и VPN.
Я - реверсер, поэтому рассказал про саму программу-вымогатель, ее функциональные возможности.
Если Вас интересует этот вопрос более широко, я могу посоветовать книгу своего друга и коллеги, она совсем недавно вышла в русском переводе.
У некоторых антивирусов есть поведенческие правила на "нездоровую" активность в файловой системе. Атаки с Зеппелином не относятся к сложным, тут только шантаж за разблокировку данных, нет схемы двойного-тройного вымогательства. В более сложных атаках, да уже и в более простых нередкость, что шифровальщик размещается в сети жертвы на "выжженную" землю, когда антивирусы и другие средства безопасности снесены. А некоторые атакующие вообще берут отключают хосты от сети :-)
Все очень хорошо, мне лично только атрибуция и вывод не очень понравились.
А функция хеширования на рис. 16 - это Chromium SuperFastHash ;-)
Также, в дополнение к предыдущему, поясните, пожалуйста, каким образом поможет плагин, не случайно имеющий в своем названии слово shellcode, на данном конкретном примере:
Спасибо за комментарий!
Резонно и возможно будет правильнее. Это больше вопрос предпочтения. Так сложилось, что я предпочитаю в качестве отладчика x64dbg или даже древний OllyDbg, IDA Debugger мне не нравится, хотя он становится все лучше. Менять предпочтения под конкретную задачу я просто не стал. К тому же с IDA Debugger ранее плохо "дружили" плагины подобные ScyllaHide. Если что, по 1 подчасти есть схожая статья Check Point, только там еще разработали плагин для взаимодействия с отладчиком.
Вы сами ответили на свой вопрос. Вопрос гибкости. Стоит ли полагаться на чужой вспомогательный инструмент и постоянно дорабатывать его, чем разбираться в вопросе и быть готовым к любому возможному варианту. Кстати, в продолжение этой мысли, по вопросу, что только найти соль и пересчитать хеши. Вы уверены, что этого будет достаточно? Я вот нет
Обязательно передам ))
Привет! Отличная статья, не теряешь вкуса к жизни и ассемблеру. Так держать! Очень приятно встретить спустя 20 лет. Исходники, как это было давно ))
Вопрос, кто пишет сигнатуры. Если человек, то он, конечно, "зацепится" за этот код, а если робот, то не факт )
Всё так! Про pefile не стал писать специально, это больше вводная поп-статья, все по минимуму ) Да и признаться, не люблю я pefile ) Про unicorn писал в статье-гайде по VMProtect, отличный эмулятор, но и он имеет ограниченные возможности. Ну и для написания универсального декриптора все же придется пореверсить сначала )
Как вариант, можно использовать утилиту Autoruns от Sysinternals
Detecting & Removing an Attacker’s WMI Persistence
Это резонный вопрос! Насколько быстро и оперативно, не могу сказать. Вот вредина, как Вы говорите, работает и никак не проявляет себя. Либо должны задетектить внешние проявления, либо Вы должны знать конкретно, где и что искать, а это не просто. Когда малварь закрепилась и закрепилась нетривиально, без повода ее найти, увы, достаточно не просто.
Сейчас современный подход строится больше на предотвращении угроз. На основе известных угроз искать подобные, предотвращать и обнаруживать их. А более продвинутый вариант, не отставать от атакующих и хантить новые угрозы, то есть стараться предвидеть их и соответственно строить свою защиту проактивно.
То есть зная про такую угрозу, если у Вас есть EDR, то, конечно, будете мониторить события, связанные с вызовами mofcomp.exe, строить какие-то правила для этого
Либо радикальный вариант, если это возможно, запретить WMI совсем.
Спасибо большое за позитив и поддержку! ))
Единственное, мне не понятен посыл ресёрча. В августе 2020 года появился отчет агентства кибербезопасности и безопасности инфраструктуры США (CISA) номер AR20-216A, Ваша команда решила происследовать указанные там образцы и представить более детальный анализ. Но зачем? Ваша команда выявила Taidoor вживую? Taidoor — сложный RAT, но есть сложнее и изощреннее.
Мне как вирусному аналитику интересен вектор начального доступа, какое-то описание киллчейна атаки с использованием Taidoor, сравнительный анализ со старыми образцами, а Taidoor атакует госсектор, как минимум с 2010 года, и эти образцы есть на VT. То есть мне не хватило более развернутого исследования, а не только реверс конкретных образцов, причем, как мне кажется, не выявленных вашей командой
А анализ ради анализа не очень интересен. Известный факт, что в BI.ZONE хорошие спецы.