DFIR and Malware Analysis
Фаззинг — очень популярная методика тестирования программного обеспечения случайными входными данными. В сети огромное количество материалов о том, как находить дефекты ПО с его помощью. При этом в публичном пространстве почти нет статей и выступлений о том, как искать уязвимости с помощью фаззинга. Возможно, исследователи безопасности не хотят делиться своими секретами. Тем интереснее рассмотреть эту тему в данной статье.
Давайте в общих чертах рассмотрим вопросы взлома и защиты Android-приложений.
В рамках статьи нас интересуют сами процессы взлома и защиты, а не конкретные методики работы с конкретными инструментами. Поэтому разберёмся с этими процессами и постараемся сделать выводы. Чтобы читать было интереснее, я решил попеременно ставить себя и на место нападающего, и на место защищающего приложение человека. Что-то вроде шахмат: сначала ход делает нападающий, а затем защищающийся. Пока кто-то не победит. Пройдём путь, постепенно наращивая сложность, от простого вроде HTTPS — к более сложному, вроде обфускации и деобфускации, изменению поведения. И под конец перейдём к C++ и просмотру его Assembler кода.
Расследование инцидентов в области информационной безопасности не такая горячая тема, как пентесты, но эта научная и практическая дисциплина продолжает развиваться, во многом, благодаря Open Source-сообществу.
Давайте пройдемся по просторам GitHub и посмотрим, какие инструменты для сбора и анализа цифровых доказательств доступны всем желающим.
Под катом утилиты для разбора содержимого оперативной памяти, исследования докер-образов, анализа журналов, извлечения информации из кеша браузеров и многое другое.
Как ни крути, хардкорные статьи — соль Хабра. Они вдохновляют, обучают, информируют, разъясняют и задают высокую планку уровня публикаций. Их пишут легенды (как по значку в профиле, так и по жизни), известные тимлиды, уверенные мидлы и круто въехавшие в тему джуны (которые порой и не джуны вовсе). Их читают не все. А ещё к ним очень страшно подступиться. Попробуем разобраться, как писать супер сложную статью, чтобы она осталась в анналах истории, Хабра и в закладках самых строгих читателей.
Анализируя отчеты по разбору вредоносного ПО приходишь к выводу, что одним из популярных методов для закрепления в системе является COM Hijacking (T1546.015). Примером такого вредоносного ПО является Fancy Bear или Jumplump. Таким образом, становится очень важно команде Blue Team уметь детектировать данный вид атаки. Поэтому было принято решение выпустить серию статей, посвященных технологии Component Object Model, разбору атаки COM Hijacking и ее детектированию.
Rust как язык программирования только набирает обороты и находит своих почитателей. Он не только предлагает множество надстроек для безопасности кода, но с недавнего времени еще и появился в ядре Linux.
В этой статье мы посмотрим на него с "обратной" стороны, а именно попробуем пореверсить программу, написанную на Rust, и выяснить, что можно сделать, чтобы сделать ее анализ проще. Рассмотрим утилиты, приложения и плагины, а также напишем свой плагин для IDA Pro, Cutter и rizin, чтобы автоматически создать сигнатуры для исполняемого файла без отладочных символов. Поговорим о FLIRT-сигнатурах, их преимуществах и недостатках и о том, можно ли автоматизировать их создание.
Вообще-то, третья статья данного цикла должна была рассказывать о конкретных оптимизациях. Но пока я прикидывал её план, стало ясно, что без освещения некоторых аспектов неопределённого поведения многое из дальнейших описаний будет непонятно. Поэтому сделаем ещё один осторожный шаг, прежде, чем окунаться в омут с головой.
Наверное, многие слышали, что неопределённое поведение (undefined behavior, UB) -- постоянный источник разнообразных багов, иногда очень забавных, иногда довольно жутких. Тема также неоднократно освещалась и на Хабре, навскидку раз, два, три (и даже целый тег есть). Однако чаще всего статьи по данной теме посвящены тому, как можно отстрелить себе ногу, голову или случайно сжечь свой жёсткий диск, исполнив какой-нибудь опасный код. Я же намерен сделать акцент на том, зачем авторы языков программирования надобавляли всей этой красоты, и как оптимизатор может её эксплуатировать. Всё будет проиллюстрировано наглядными примерами из LLVM и присыпано байками из собственного опыта, так что наливайте себе чай, располагайтесь поудобнее, и погнали.
Приветствую вас, дорогие читатели! Сегодня я хочу рассказать о том, как с помощью уязвимого драйвера получить NTLM hash пользователя. NTLM hash находится в памяти процесса lsass.exe операционной системы Windows. Процесс lsass.exe отвечает за авторизацию локального пользователя компьютера.
По этой теме я нашел несколько статей:
1. A physical graffiti of LSASS: getting credentials from physical memory for fun and learning.
2. [EX007] How playing CS: GO helped you bypass security products.
Разобрав эти статьи, у меня появилось желание объединить их для лучшего понимания метода извлечения NTLM hash’а из памяти процесса lsass.exe.
Важные замечания:
• Все действия будут проводится на Windows 10 версии 1909 сборка 18363.1556.
• Название разработанного приложения для этой статьи будет shor.exe.
Привет. В этом посте мы рассмотрим простую модель фильтрации спама с помощью наивного байесовского классификатора с размытием по Лапласу, напишем несколько строк кода на R, и, наконец, протестируем на англоязычной базе данных смс спама. Вообще, на хабре я нашел две статьи посвященные данной теме, но ни в одной не было наглядного примера, чтобы можно было скачать код и посмотреть результат. Также не было упоминания про размытие, что существенно увеличивает качество модели, без особых затрат усилий, в отличие, скажем, от сложной предобработки текста. Но вообще, запилить очередной пост про наивного байеса меня побудило то, что я пишу методичку для студентов с примерами кода на R, вот и решил поделиться инфой.