В конце прошлого года в нашу лабораторию за помощью обратилась зарубежная телекоммуникационная компания, сотрудники которой обнаружили в корпоративной сети подозрительные файлы. В ходе поиска следов вредоносной активности аналитики выявили образец весьма интересного бэкдора. Его анализ показал, что мы имеем дело с очередным модульным APT-бэкдором, использующимся хакерской группой Winnti.

Последний раз деятельность Winnti попадала в наше поле зрения, когда мы анализировали модификации бэкдоров ShadowPad и PlugX в рамках расследования атак на государственные учреждения стран Центральной Азии. Оба эти семейства оказались схожи концептуально и имели примечательные пересечения в коде. Сравнительному анализу ShadowPad и PlugX был посвящен отдельный материал.

В сегодняшней статье мы разберем бэкдор Spyder — именно так окрестили найденный вредоносный модуль наши вирусные аналитики. Мы рассмотрим алгоритмы и особенности его работы и выявим его связь с другими известными инструментами APT-группы Winnti.

Разведка

Статья расскажет о подходах к анализу запакованных исполняемых файлов с помощью простых средств для обратной разработки. Будут рассмотрены некоторые пакеры, которые применяются для упаковки исполняемых файлов. Все примеры будут проведены в ОС Windows, однако изучаемые подходы можно легко портировать на любую ОС.

Привет, класс, и добро пожаловать в x86 Masochism 101. Здесь вы узнаете, как использовать коды операций непосредственно для создания исполняемого файла, даже не касаясь компилятора, ассемблера или компоновщика. Мы будем использовать только редактор, способный изменять двоичные файлы (т.е. шестнадцатеричный редактор), и «chmod», чтобы сделать файл исполняемым.

Этим постом мы начинаем двухсерийный технодетектив, в котором встретились "священная триада" доменов: putin, kremlin, crimea и "крысы" — программы удаленного доступа (RAT), а также шпион AgentTesla. Началась история с того, что в конце мая 2020 года сетевой граф Group-IB, наша автоматизированная система анализа инфраструктуры, начал детектировать домены с интересным паттерном *kremlin*.duckdns.org, к которым подключались различные вредоносные файлы. Аналитики Group-IB Threat Intelligence & Attribution исследовали эти домены и установили три кампании по распространению различных RAT. Они шли с 2019 года и были нацелены на пользователей из Польши, Турции, Италии, Украины, России, Казахстана, Болгарии, Беларуси, Греции и Чехии. В ходе расследования была установлена связь между обнаруженными доменами и остальной используемой инфраструктурой, а заодно и с конкретным человеком, который стоит за распространением AgentTesla и других вредоносных программ. Итак, обо всем по-порядку.

С ноября 2020 года участились случаи похищения аккаунтов у популярных Telegram-каналов. Недавно эксперты CERT-GIB установили тип вредоносной программы, с помощью которой хакеры пытались угнать учетку у Никиты Могутина, сооснователя популярного Telegram-канала «База» (320 тысяч подписчиков). В той атаке использовался стилер Hunter, который Могутину прислали под видом рекламы образовательной платформы. Сам стилер нацелен на устройства под управлением ОС Windows, поэтому атакующие так настойчиво просили журналиста открыть архив на рабочем компьютере, а не с iPhone, чего он — и правильно — делать не стал. Hunter "умеет" автоматически собирать учетные записи на зараженном компьютере, затем отсылает их злоумышленнику и раньше его, к примеру, часто использовали для кражи учетных данных у игроков GTA. Никита Карпов, младший вирусный аналитик CERT-GIB, провел анализ вредоносного файла и раскрывает технические детали того, как хакеры пытались угнать Telegram-канал.

Если помните, недавно у нас выходила статья про молодой, но уже подающий надежды data stealer Loki. Тогда мы подробно рассмотрели этот экземпляр (версия 1.8), получили представление о работе бота и освоили инструмент, облегчающий реагирование на события, связанные с этим ВПО. Для более полного понимания ситуации, давайте разберем еще одно шпионское ПО и сравним исследованных ботов. Сегодня мы обратим внимание на Pony — более старый, но не менее популярный экземпляр data stealer’а. Никита Карпов, аналитик CERT-GIB, расскажет, как бот проникает на компьютер жертвы и как вычислить похищенные данные, когда заражение уже произошло.

В этой статье я хочу поделиться своим опытом обхода проверки на рутованость своего устройства. Статья может рассматриваться не только как самостоятельный материал, но и как прямое продолжения моей работы из предыдущей статьи.

Будем декомпелировать .apk, копаться в обфусцированном байт-коде и редактировать его. Затем соберем .apk обратно, как обычно, словим несколько ошибок и исправим их. В общем вызов принят!

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

В данной статье копаемся в бэкапах сайта, получаем RCE в CMS LiteCraft, обходим блокировку функций в PHP, получаем пользователя mysql и реверсим бэкдор pam_unix.

Подключение к лаборатории осуществляется через VPN. Рекомендуется не подключаться с рабочего компьютера или с хоста, где имеются важные для вас данные, так как Вы попадаете в частную сеть с людьми, которые что-то да умеют в области ИБ.

Казалось бы, на первый взгляд весьма простая задача. Некоторые читатели могли еще в те бородатые времена лазить по всяким 4пда, рутить свой сенсорный самсунг, менять содержимое файла build.prop и показывать наивным ламерам свой iPhone 15+ Max Pro. Однако, как оказалось, и как оно часто бывает, не все так просто и здесь есть свои подводные камни. Статья призвана помочь простым работягам избежать все кочки да ямы на пути к своей цели!

Всем привет,

В данной статье я расскажу о реверс-инжиниринге ресурсов игры Twisted Metal 4 для первой Playstation. В качестве основного инструмента я буду использовать Ghidra.

Наверняка вы слышали об игровой серии Twisted Metal. А кому-то, наверное, довелось и поиграть (мне нет). По словам тех, кто играл в четвёртую часть, в игре имеются некоторые неприятные баги. Так вот, реверс-инжиниринг должен помочь исправить их. Поехали…

Система имён и паролей

Если вы используете OllyDbg не для отладки собственных приложений, для которых у вас есть отладочная информация, а для реверс-инжиниринга или исследования сторонних, типичная ваша деятельность — это вникание в машинный код чужого продукта, осознание сути происходящих вещей и расстановка большого числа меток (labels) и комментариев по всему коду, а также по секциям данных. Вы планомерно разведываете суть процедур/функций и переменных и даёте им имена, отражающие ваше понимание их предназначения.

И вот спустя несколько часов (а то и дней) работы, когда вы разобрались и подписали сотни, а то и тысячи процедур и переменных, OllyDbg внезапно зависает или вылетает, унося в небытие все ваши наработки (в которые могут входить не только labels и comments в большом числе, но и расставленные в нужных местах брекпоинты и модификации). Это потеря времени и чудовищно демотивирующий фактор, от которого опускаются руки и бледнеет лицо.

Эта статья о том, как я в такой экстренной ситуации использовал OllyDbg для того, чтобы оперативно разреверсить OllyDbg (частично), спасти висящие на волоске данные и выработать рецепт действий на случай таких катастроф.

В ходе мониторинга угроз ИБ в мае 2020 года эксперты Positive Technologies обнаружили несколько новых образцов вредоносного ПО (ВПО). На первый взгляд их следовало отнести к группе Higaisa, однако подробный анализ показал, что связывать эти вредоносы следует с группой Winnti (также известной как APT41, по данным FireEye). 

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

В предыдущей заметке «Планировщик Windows? Это очень просто» было рассказано о технологии получения дизассемблированного текста ядра операционной системы Windows XP образца 2013 года. Такой текст потребовался для анализа и корректировки кода ядра, что позволило изменить политику планирования потоков в Windows и выполнить одну конкретную задачу с уменьшением времени отклика операционной системы.

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

Поскольку Windows является, наверное, самой дорогой программой в мире по затратам на разработку и сопровождение, уровень качества кода ее ядра должен бы быть одним из самых высоких. Именно поэтому было интересно посмотреть, как устроен код с точки зрения эффективности отдельных команд. Однако я увидел не совсем то, что ожидал и поэтому решил поделиться несколькими соображениями. Для иллюстрации ниже приведены фрагменты дизассемблированного кода ядра Windows XP сборки от 4 июля 2013 года.

Хотя Windows XP и Windows 7 уже, так сказать, «сняты с вооружения», на мой взгляд, изучение даже неподдерживаемых программ имеет смысл. Ядро Windows XP сопровождалось и развивалось около 10 лет. Поэтому на основании анализа кода можно, например, даже прогнозировать пути дальнейшего развития системы. Замечу также, что различия в коде ядер различных версий Windows не так велики как различия некоторых других компонентов.

В процессе перевода своих средств программирования на платформу x86-64 потребовалось перевести и встроенный интерактивный отладчик. В отличие от подключаемых отладчиков данный отладчик находится, так сказать, непосредственно «на борту» каждой исполняемой программы. При этом он имеет сравнительно небольшие размеры (около 44 Кбайт, большую часть которых занимает дизассемблер). Я так привык к этому отладчику, что уже совершенно не могу без него обходиться, и поэтому перевод в 64-разрядную среду стал настоятельно необходимым.

Однако формальный перевод с Win32 в Win64 дал такие странные результаты, что пришлось потратить много сил и времени, чтобы разобраться, почему то, что ранее работало в Windows-XP, перестало нормально работать в Windows 7. Виной всему оказалась структурная обработка исключений, практически не задействованная ранее в среде Win32.

В процессе разбирательства я прочел множество обсуждений на эту тему на компьютерных форумах. Задаваемые вопросы (и особенно ответы) показали, что многие программисты смутно представляют конкретную реализацию структурной обработки исключений в Windows 7. Поэтому кажется полезным пояснить некоторые особенности поведения системы на примере конкретной задачи, в результате чего и появилась данная статья.

Реализация одной из ответственных задач моделирования в очередной раз привела к сложностям с операционной системой (ОС). Попытка решить задачу «под Windows», т.е. просто запустить программу, не применяя специальных средств, почти удалась, однако время от времени возникали недопустимые задержки. Эти, возникавшие случайно и редко (раз в несколько минут) задержки никак не удавалось убрать. Например, последовательное снятие всех «лишних» процессов Windows улучшало ситуацию, но, в конце концов, приводило к отказу самой ОС. Положение затрудняло и то, что проведение сравнительно долгого сеанса моделирования не позволяло на все 20-30 минут сеанса установить работающему потоку приоритет «реального времени», так как при этом нормальная работа компьютера нарушалась. Таким образом, несмотря на мощный и гибкий механизм планирования на основе приоритетов, потребовалось особое планирование, не предусмотренное в Windows, а именно: заданный поток в течение определенного периода не должен прерываться по истечению кванта времени, и на время его работы потоки с более низким приоритетом вообще не должны получать управление. Но при этом потоки с изначально более высоким приоритетом должны выполняться как обычно. Поскольку такие высоко приоритетные потоки обычно не занимают весь свой квант времени, время отклика для нужного потока в целом уменьшается и зависит от быстродействия компьютера.

Встал вопрос: можно ли настроить Windows на такой режим работы и как это сделать?