📌 Опубликовал курс на Stepik: «Белый хакер: анализ файлов в Linux»

Научитесь анализировать подозрительные файлы в Linux: определять истинный тип, находить скрытые данные, извлекать вшитые программы, перехватывать пароли и отслеживать вредоносное поведение. Все на реальных кейсах с поиском флагов.

https://stepik.org/277345

Консоль, автоматизация и Linux: что реально нужно знать, чтобы расследовать атаки

На днях задал в закрытом профильном чате три вопроса специалистам по расследованию инцидентов (в англоязычном мире это называют DFIR – Digital Forensics and Incident Response):

1) Какая доля инцидентов с Linux-машинами по вашему опыту?
2) Нужно ли DFIR-специалисту уметь работать с консольными инструментами вроде file, strings, strace или достаточно автоматизированных средств?
3) Нужно ли глубоко понимать устройство Linux?

Ответы меня удивили и обрадовали одновременно. Структурировал, собрал все воедино и теперь делюсь с вами.

https://vc.ru/dev/2928870-konsolnye-instrumenty-i-avtomatizatsiya-dlya-rassledovaniya-incidentov-v-linux

Вы когда-нибудь задумывались, что происходит внутри Linux после того, как вы вводите ./program в терминале и нажимаете Enter?

Что именно происходит дальше? Как ядро находит файл? Как загружает его в память? Кто вызывает main? И как на всё это посмотреть вживую?

Разберемся на примере пустой программы empty_sleep.

https://habr.com/ru/articles/1036444/

Логи в Linux: как перестать тонуть в хаосе

Обзорная заметка по логам в Linux.

Системные журналы (логи) – это «чёрный ящик» вашего сервера. Упал сайт, тормозит база данных, кто-то ломится по SSH? Ответы здесь. Но дьявол, как всегда, в деталях. Мир логирования в Linux многообразен: от архаичных, но всё ещё живых текстовых файлов до современных бинарных журналов. Новичок, открывший папку /var/log/, может впасть в ступор. Давайте разложим всё по полочкам и научимся читать логи.

https://vc.ru/dev/2944905-logi-v-linux-kak-effektivno-organizovat-sistemnye-zhurnaly

Планирую большую статью для Хабра по анализу логов в Linux. Думаю написать полноценное руководство по расследованию инцидента (только по логам, без анализа памяти, файловой системы и трафика): от первого осмотра /var/log/ до финального отчёта с хронологией атаки.

Моя главная цель – объяснить базу. Где и какие логи находятся, как в них ориентироваться и какие инструменты использовать, если под рукой ничего нет, кроме стандартных утилит.

Пока в черновиках есть пошаговый разбор реального кейса: bruteforce SSH, эксфильтрация базы данных, подчистка логов и попытка замести следы через touch -t. Мы пройдем весь путь руками, используя grep, awk, journalctl, stat и другие инструменты. По сути, это ручной SIEM: сбор, нормализация, агрегация, корреляция – всё то же самое, но своими руками. Без этого фундамента автоматика для вас потом превратится в чёрный ящик.

Также хочу затронуть auditd – базовую настройку и чем он принципиально отличается от syslog. И с самого начала постараюсь довести следующую мысль: глубокое понимание логов помогает объяснять технические инциденты простым языком. Когда ты видишь не абстрактный алерт, а конкретную строчку в auth.log с IP и временем, разговор с руководством становится предметным и на их языке.

Что вам как читателю было бы интереснее? Может, есть конкретная больная тема, которую стоит разобрать? Пишите в комменты 👇 Соберу обратную связь и сделаю статью максимально полезной.

Друзья, обновил статью на Хабре про загрузку программ в Linux. Добавил новый раздел "статическая загрузка на практике". Теперь с отладчиком GDB и картой памяти процесса. А ещё исправил пару неточностей, которые заметили в комментариях читатели Хабра.

Для тех, кто уже читал: самое интересное – в середине, раздел «Проверяем статическую загрузку на практике»:

https://habr.com/ru/articles/1036444/

Знания из статьи косвенно пригодятся в реверс-инжиниринге: понимание того, как программа попадает в память и что происходит до main, помогает при анализе бинарных файлов и отладке.

Есть что дополнить? Жду вас в обсуждениях!

Сисадмин пьёт чай. Вы думаете: бездельник. А я говорю: радуйтесь. Потому что если он перестал пить чай и куда-то побежал, то значит, всё уже сломалось.

Разобрал на vc, почему спокойный админ выгоднее героического, чем опасен миф «возьмём троих подешевле» и куда расти, если устал перезагружать принтеры.

По мотивам статьи Калошина из 2003 года, но с современными технологиями, историями и советами для руководителей.

https://vc.ru/hr/2973435-sisadmin-mify-i-realnost-professii-sistemnogo-administratora

Случайно наткнулся на фрагмент из «Чёрного лебедя» Н. Талеба и поймал себя на мысли, что это идеальное описание духа «Хакерской кузницы». Инженеры творят не ради доказательства теорий, а из любви к процессу.

Вот этот фрагмент:

«Инженеры изобретают технологические новинки, потому что им нравится сам процесс изобретательства, а не отнюдь не ради познания тайн природы. Получается так, что только некоторые из этих изобретений открывают перед нами новые перспективы.

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

Но у наших изобретений редко бывает судьба, которую мы им пророчим; лишь благодаря любви инженеров к созданию всяческих игрушек и машинок происходит очередной прорыв в познании мира. Просвещению нашему способствует совсем не те инструменты, что предназначены для подтверждения и доказательства тех или иных теорий, а как раз те, что поначалу не имеют ни малейшего отношения к интересующему нас предмету исследования.»

Так и живём. Добро пожаловать в кузницу.

#ХКузница #ХакерскаяКузница

Вышла моя статья «Статический анализ бинарных файлов стандартными консольными средствами Linux. Часть 1» в журнале «Системный администратор» № 281 (№4, 2026).

О чём: как без запуска и сторонних инструментов, используя file, strings, xxd и dd, определить истинный тип подозрительного файла, найти скрытые строки и сигнатуры, извлечь вшитые программы. Ровно то, о чём мы говорим в этом сообществе – глубокое понимание системы подручными средствами.

Это первая часть. В следующих номерах – продолжение.

Для тех, кому тема зашла и хочется копнуть глубже: на основе этих же подходов построен мой бесплатный курс «Белый хакер: анализ файлов в Linux» – от первичного осмотра до динамической трассировки, с практикумами и флагами. Ссылка на курс: https://stepik.org/277345

https://samag.ru/archive/article/5320

Добро пожаловать в кузницу.

#ХКузница #ХакерскаяКузница

Когда писал статью про путь программы от execve до main, случайно заметил пробел: мы не разобрались в том, как бинарь находит функции в памяти, адреса которых он не может знать заранее из-за ASLR. В новой статье для «Хакера» разбираем PLT, GOT и релокации, глядя на первый и повторный вызовы через призму objdump, readelf и GDB. Ссылки на свежий материал и первую часть оставлю ниже, добро пожаловать в кузницу.

🔗 Статья в «Хакере»: https://xakep.ru/2026/07/08/linux-relocation/
🔗 Первая часть на Хабре: https://habr.com/ru/articles/1036444/

#ХКузница #ХакерскаяКузница

[Кузница изнутри]

Почему реверс-инженеру нужно знать про релокации и ленивое связывание?

Пишу статью по гибридному анализу (Ghidra + GDB). Нужно было показать читателю, как элегантно работает std::string::_M_dispose() и как на низком уровне определяется, где лежит строка: в куче или на стеке (SSO).

Решил заодно красиво продемонстрировать работу команды stepi в GDB. Ставлю точку останова перед первым вызовом _M_dispose(), делаю шаг внутрь... и попадаю в PLT-заглушку.

Начинается ленивое связывание (lazy binding). Отладчик ныряет в _dl_runtime_resolve, потом в другие функции и мы начинаем тонуть. Я трачу время, теряю нить повествования, раздуваю раздел и увожу читателя от главной сути. Все в минусе.

Нужно было просто поставить точку останова на второй вызов _M_dispose! К тому моменту динамический компоновщик уже разрешит все адреса и я попаду прямиком внутрь нужной мне функции, без лишних посредников.

В динамически слинкованных бинарниках внешние функции не всегда связываются сразу при запуске. Если реверс-инженер не понимает, как работают PLT/GOT и ленивое связывание, его отладка превратится в бесконечное блуждание по заглушкам и отнимет драгоценное время.

Подробнее о релокациях в Linux написал в журнале «Хакер»:

https://xakep.ru/2026/07/08/linux-relocation/

#ХКузница #ХакерскаяКузница #КузницаИзнутри #Linux #ELF #reverse #безопасность

Прекрасно понимаю, что иногда лень читать технические лонгриды и хочется просто полистать ленту в Инстаграм*. Поэтому решил его завести и публиковать шпаргалки из своих статей – схемы, картинки, выжимки. Для быстрого чтения и без погружения в портянку деталей.

А если зацепит – полный текст материала всегда найдете по ссылке в описании к записи.

Профиль: https://www.instagram.com/mosesutulin/

*Деятельность организации Meta Platforms Inc, ее продуктов Instagram и Facebook запрещена в Российской Федерации.