Записки IT специалиста

Исследование атак шифровальщиков — от инцидента до вывода

📅 27–29 мая | Трёхдневный интенсив от экспертов F6 по расследованию атак шифровальщиков

Когда инфраструктура зашифрована, логи обрезаны, а следы стерты — остаётся только холодный анализ. Курс даст вам практику: как расследовать атаки, находить артефакты и делать выводы — даже в “зачищенных” инцидентах.

Что в программе:
🔍 Угрозы и тактики группировок
🔍 Атрибуция по TTP и киберразведке
🔍 Артефакты и события Windows
🔍 Три атаки: от входа до шифрования
🔍 Анализ шифровальщиков и OSINT
🔍 Финальный кейс: триаж, анализ, выводы

👨‍💻 Для кого:

✅ Специалисты ИБ и реагирования
✅ SOC-аналитики и криминалисты
✅ Те, кто хочет понимать шифровальщиков глубже

Регистрируйтесь и научитесь разбирать атаки шифровальщиков до того, как они доберутся до вашей инфраструктуры.

#реклама
О рекламодателе

​​Структура файловой системы Linux

Расположение файлов и директорий в Linux регулируется стандартом Filesystem Hierarchy Standard (FHS). Текущая версия стандарта — 3.0 от 3 июня 2015 года.

При этом следует понимать, что FHS, хоть и является основанным на POSIX, но разрабатывался исключительно для Linux и другие UNIX-системы следовать ему не обязаны.

Также далеко не все дистрибутивы полностью следуют этому стандарту, допуская различные отклонения, но, в общем и целом, основные положения соблюдаются.

Начинается файловая система с корня, который обозначается обратной косой чертой - /

Директория /bin содержит бинарные (исполняемые) файлы пользовательского уровня, для выполнения которых не нужны права суперпользователя, например, cat, find или ls.

/boot – загрузчик и все что с ним связано

В Linux все есть файл, даже устройства. Поэтому мы всегда можем их найти в директории /dev, например, блочные устройства /dev/sda или виртуальное устройство /dev/null.

/etc – конфигурационные файлы

/home – домашние директории пользователей, для каждого пользователя в данном каталоге создается собственная поддиректория: /home/Ivanov или /home/petrov

Для хранения библиотек программ предназначена директория /lib, в современных системах, в зависимости от поддерживаемых архитектур это целый набор директорий, таких как lib32, lib64 и т.п.

/lost+found, как следует из названия, хранит найденные файлы, которые не относятся ни к одной директории, но их inode не помечены как свободные. Т.е. если во время проверки файловой системы будут найдены такие файлы, то система поместит их сюда.

/media используется для автоматического монтирования съемных носителей, таких как флешки, USB или оптические диски.

/mnt – а вот сюда мы можем монтировать нужные устройства вручную. Например, можем примонтировать дополнительный диск для общего хранилища: /mnt/samba и т.д.

/opt – дополнительное программное обеспечение, чаще всего проприетарное, или имеющее большой дисковый размер.

/proc – сюда смонтирована виртуальная файловая система procfs, через «файлы» этой директории мы можем получить различную информацию от ядра системы. Скажем, cat /proc/meminfo – информация об оперативной памяти.

/root – домашняя директория суперпользователя, всегда находится в корневом каталоге.

/run – файлы состояния приложений, такие как сокеты или PID-файлы

/sbin – исполняемые файлы, которые для своего запуска требуют права суперпользователя. В первую очередь к ним относятся служебные утилиты. Здесь мы можем найти fdisk, sysctl, useradd и т.д.

/srv – стандарт предполагает хранение здесь данных сервисов, предоставляемых системой. На практике не используется.

/sys – место монтирования виртуальной файловой системы sysfs, которая позволяет не только получать различные параметры ядра, но и передавать ему настройки через «запись» нужного параметра в определенный «файл», все измененные параметры действуют до перезагрузки.

/tmp – временные файлы

/usr – достаточно интересная директория, предназначена для хранения всех установленных пользователем программ, документации, исходного кода. Предполагается, что данная директория может быть доступна по сети.

В ней также содержатся директории /usr/bin, /usr/sbin, /usr/lib и т.д.

Т.е. изначально предполагалось разделение на файлы самой системы и файлы, которые установил пользователь. Однако в большинстве современных систем директории /bin, /sbin и все /lib являются симлинками на одноименные директории в /usr.

Отдельно стоит отметить /usr/share, где располагаются различные общие ресурсы, такие как документация, примеры конфигурационных файлов, иконки и т.д.

А также /usr/local, куда по умолчанию устанавливаются файлы программ, которые собраны из исходных кодов или получены иными путями в обход менеджера пакетов.

/var – файлы, которые изменяются при работе системы, например, логи - /var/log, базы данных - /var/lib, файлы обслуживаемые веб сервером - /var/www.

​​Мифы и легенды Active Directory – откуда ноги растут

Как мы уже неоднократно говорили, администраторы Active Directory очень часто подвержены множественным заблуждениям, из которых уже сформировался устойчивый набор мифов и легенд.

Как водится, происхождение всего этого мифотворчества уходит своими корнями в далекие времена Windows NT, т.е. до 2000 года. Фактически уже выросло второе поколение специалистов, которые эту самую NT в глаза не видели, но тем не менее подвержены распространенным заблуждениям.

Поэтому предлагаем вам немного окунуться в историю и понять, чем являлся домен NT и что изменилось с приходом Active Directory.

Домен NT (NTDS) являлся реализаций службы каталогов от Microsoft доступный в серверной операционной системе Windows NT Server. И состоял из одного первичного контроллера домена – PDC (Primary Domain Controller) и неограниченного количества резервных – BDC (Backup Domain Controllers).

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

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

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

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

А при появлении нового сервера приходилось крепко думать, будет ли он контроллером домена или нет. Так как изменить его назначение без переустановки было невозможно.
Также схема один PDC – много BDC имела серьезные проблемы с репликацией, особенно для удаленных филиалов с учетом скоростей и качества каналов связи того времени. При том, что удаленный филиал сам не мог внести необходимые данные в домен, так как для этого требовался первичный контроллер.

Поэтому с приходом Windows 2000 и Active Directory от данной схемы отказались, с этого момента все контроллеры домена стали равнозначны и каждый из них мог вносить изменения в базу домена, потом обмениваясь измененными данными. А для контроля целостности и уникальности данных были созданы хозяева операций.

Также теперь любой сервер мог стать контроллером домена или перестать им быть без переустановки, что значительно облегчило администрирование и планирование инфраструктуры.

Но несмотря на то, что Active Directory скоро разменяет четверть века многие коллеги все еще продолжают оперировать устаревшими терминами и понятиями системы, которую никогда в глаза не видели.

▶️ БЕСПЛАТНЫЙ МАСТЕР-КЛАСС «Linux: от основ к профессиональному использованию»

14 мая в 19:00 (МСК) | Онлайн | Бесплатно
✔️Регистрация

Linux уже давно перестал быть инструментом исключительно для системных администраторов. Сегодня это необходимый навык для DevOps-инженеров, специалистов по кибербезопасности и всех, кто работает с IT-инфраструктурой.  

На нашем вебинаре мы:
▪️ Развеем мифы о сложности Linux и покажем, как начать работать с ним уверенно
▪️ Продемонстрируем практическое применение в реальных рабочих задачах
▪️ Расскажем о карьерных перспективах для специалистов, владеющих Linux
▪️ Дадим пошаговый алгоритм освоения системы

Особое внимание уделим:
✔ Работе с терминалом (основные команды и их применение)
✔ Решению типовых задач системного администрирования
✔ Возможностям для профессионального роста
 
Ведущий: Дмитрий Семьянов — действующий специалист по пентесту, куратор курса «Основы Linux».

Не пропустите! Регистрация здесь.
🚀 Трудности с регистрацией? Пишите @Codeby_Academy

Мифы и легенды Active Directory. Миф 2 - хозяева операций (роли FSMO)

У этого мифа очень много разновидностей, но все они сводятся к тому, что хозяева операций - некая священная корова. Почему? Да потому что так исторически сложилось.

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

На самом деле хозяева выполняют очень важные роли, но в повседневной жизни AD участвуют мало. Отсутствия некоторых вы можете никогда и не заметить.

Всего хозяев пять. Два - уровня леса, по одному в каждом лесу. И три уровня домена, по одном в каждом домене.

Начнем с леса:

1️⃣ Хозяин именования домена. - как часто вы переименовываете домен или заводите новый в текущем лесу? Многие делают это один раз при установке AD.

2️⃣ Хозяин схемы - нужен немного чаще, раз в несколько лет, когда вы захотите ввести в домен контроллер на новой версии ОС или поставить что-то типа Exchange.

Уровень домена:

1️⃣ Хозяин инфраструктуры - самый бесполезный хозяин. Если домен один - он не нужен. Если все контроллеры являются Глобальными каталогами (как рекомендуется ныне) - он не нужен.

2️⃣ Хозяин RID - выдает идентификаторы безопасности для новых объектов, пачками по 500 штук. Если они кончатся, а хозяин будет недоступен - вы не сможете создавать новые объекты.

3️⃣ Эмулятор PDC - его отсутствие вы заметите раньше всего, так как эта роль отвечает за синхронизацию времени в домене. Также перестанут работать некоторые политики при неправильном вводе пароля, но кто на это обращает внимание?

Как видим, ничего сакрального в хозяевах нет и домен может спокойно жить без них некоторое время.

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

А захват ролей делаем только тогда, когда контроллер окончательно вышел из строя.

Ниже статья как сделать это средствами старого доброго ntdsutil.

https://interface31.ru/tech_it/2013/08/upravlenie-rolyami-fsmo-pri-pomoshhi-ntdsutil.html

Мифы и легенды Active Directory. Миф 1 - PDC.

Читаем официальную документацию:

Роль FSMO эмулятора PDC

Эмулятор PDC необходим для синхронизации времени на предприятии. Windows включает службу времени W32Time (Windows время), требуемую протоколом проверки подлинности Kerberos. Все Windows компьютеры на предприятии используют общее время. Цель службы времени — убедиться, что служба Windows времени использует иерархическую связь, контролируемую полномочиями. Это не позволяет циклам обеспечить надлежащее общее использование времени.

Эмулятор PDC домена является авторитетным для домена. Эмулятор PDC в корне леса становится авторитетным для предприятия и должен быть настроен для сбора времени из внешнего источника. Все держатели ролей PDC FSMO следуют иерархии доменов при выборе своего связанного партнера по времени.

В домене Windows роль эмулятора PDC сохраняет следующие функции:

Изменения пароля, внесенные другими DCs в домене, реплицированы преимущественно в эмулятор PDC.
При сбоях проверки подлинности в том или ином dc из-за неправильного пароля сбои перенаправляются в эмулятор PDC перед сообщением о сбое неправильного пароля пользователю.
Блокировка учетной записи обрабатывается в эмуляторе PDC.
Эмулятор PDC выполняет все функции, которые Windows NT 4.0 Серверный PDC или более ранний PDC выполняет для Windows NT 4.0 или более ранних клиентов.
Эта часть роли эмулятора PDC становится ненужной в следующей ситуации:
Все рабочие станции, серверы членов и контроллеры доменов, работающие Windows NT 4.0 или более ранних, обновлены до 2000 Windows 2000.

Эмулятор PDC по-прежнему выполняет другие функции, описанные в Windows 2000.

В следующих сведениях описываются изменения, которые происходят в процессе обновления:

Windows клиенты (рабочие станции и серверы-члены) и клиенты на уровне ниже уровня, которые установили клиентский пакет распределенных служб, не выполняют каталог записей (например, изменения паролей) в dc, рекламируемом как PDC. Они используют любой DC для домена.
После обновления контроллеров доменов резервного копирования (BDCs) в доменах с Windows 2000 г. эмулятор PDC не получает запросов на реплику на уровне ниже уровня.
Windows (рабочие станции и серверы-члены) и клиенты на уровне, которые установили клиентский пакет распределенных служб, используют Active Directory для поиска сетевых ресурсов. Они не требуют службы Windows NT браузера.

https://docs.microsoft.com/ru-ru/troubleshoot/windows-server/identity/fsmo-roles

Основной вывод: в Active Directory нет никаких первичных контроллеров, все контроллеры равнозначны. Эмулятор PDC нужен для совместимости с NT4 ( у кого-то есть?) и для ряда вспомогательных, но важных функций, например, синхронизации времени.

Все ведь любят допиливать 1С, так? Прямо хочется открыть конфигуратор и повспоминать, как же тут написать цикл, правда ведь?

Шутка, конечно. На самом деле мы всё понимаем. Именно поэтому мы подготовили инструмент, который позволит вам поручить написание кода под 1С нейросетью. Предлагаем его попробовать, и надеемся что вам понравится!

#реклама
О рекламодателе

Все ведь любят допиливать 1С, так? Прямо хочется открыть конфигуратор и повспоминать, как же тут написать цикл, правда ведь?

Шутка, конечно. На самом деле мы всё понимаем. Именно поэтому мы подготовили инструмент, который позволит вам поручить написание кода под 1С нейросетью. Предлагаем его попробовать, и надеемся что вам понравится!

#реклама
О рекламодателе

​​Родина слышит

Данная заметка написана на злобу дня, в противовес расхожему мнению, что через отечественные сертификаты нас всех расшифруют и… В общем, отправят пилить лобзиком ангарскую сосну на свежем морозном воздухе.

На самом деле никто никогда не скрывал, что отечественный УЦ предназначен в первую очередь для крупных игроков: финтех, госы, электронные сервисы, которые в 2022 чуть было не остались без валидных сертификатов.

Но неокрепшие умы и примкнувшие к ним лица старательно разгоняют тему, что мол отечественный УЦ — это первый шаг к государственному MitM, когда весь трафик расшифруют и никому потом мало не покажется.

Но никто так и не потрудился обосновать – зачем? Какая цель всего этого действа? И кто будет всем этим заниматься?

Ведь расшифровать трафик – это только начало. Его надо проанализировать и выявить… Что выявить? Да пес его знает. Адепты данной теории заговора не склонны к логике, они просто эмоционально нагнетают – могут, значит сделают!

А теперь я предлагаю каждому тупо собрать трафик домашней сети за сутки и вдумчиво его проанализировать. Когда вы скажете – нафиг нужно? Через полчаса? Час? А там еще этого трафика вагон и маленькая тележка. И, самое главное, что это даст?

По факту занятие это чудовищно дорогое и столь же чудовищно неэффективное. Ибо 99,5% трафика – это хлеб и зрелища, крайне далекие от интересов «товарища Майора».

А теперь подумаем, если некто Имярек засветился у т. Майора, то он явно засветился в публичном поле и если его личность неизвестна, то какой смысл в расшифровке трафика? И даже если мы смогли локализовать его до города, то все равно объем информации будет фактически неподъемным для любого регионального отдела хоть МВД, хоть ФСБ, нет там столько людей.

Но если наш Имярек засветился в соцсети, форуме или ином ресурсе, владелец которого гражданин РФ, то органы просто пошлют к нему запрос, в котором попросят выдать всю информацию по Имяреку.

И это не только IP, но и временная активность, социальная активность и т.д. Т.е. когда Имярек заходит на ресурс, кого он лайкает, кто лайкает его, на кого он подписан, кто подписан на него и т.д. и т.п.

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

Эта методика давно отработана оффлайн, проста, дешева и привычна. А слабое звено найдется всегда. Особенно если утром вас выдернут из постели хмурые мужики в штатском.

И к чему тут расшифровка трафика? Совсем ни к чему. Это сложно и дорого. А тут простая и понятная любому оперу отработка социальных связей.

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

После чего снимаем с ТСПУ данные, а кто именно в это время обменивался трафиком с этим ресурсом. Выборка будет большая. Но это не страшно. Берем следующий момент времени и накладываем выборки друг на друга.

И уже через несколько итераций мы фактически получит данного пассажира на блюдечке. А если у него свой VPN-сервер, то срисуют его фактически мгновенно.

А дальше что? Перехватим и расшифруем его трафик? Зачем? Проще просто прийти рано утром, вытащить пассажира из теплой постельки, положить лицом в пол, устроить маски-шоу, дать проникнуться и поговорить по душам.

Если пассажир попался непонятливый, то всегда есть рядом слабое звено – родители, супруга, любовница, кореша и собутыльники. Хороший опер умеет работать с этим материалом.

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

Поэтому не надо искать черную кошку в темной комнате, особенно если ее там нет.

​​Упоминание российских сертификатов вызывает у многих бурную реакцию, вплоть до того, что это мол узаконенный MitM и все мы теперь под колпаком у товарища майора.

Слышать такие вещи довольно странно, тем более от специалистов. При выпуске сертификата закрытый ключ генерируется и остается у клиента, а удостоверяющий центр только подписывает сертификат своей подписью.

Доступ к закрытому ключу CA сразу лишает все сертификаты доверия, но не дает возможности расшифровать клиентский трафик.

Но даже если мы получим доступ к закрытому ключу клиента, то тоже вряд ли сможем расшифровать сеанс. Почему?

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

Подробнее об этом можно почитать в нашей статье: Введение в криптографию. Общие вопросы, проблемы и решения

А пока посмотрим на скриншот ниже, Сбер, сертификат от Минцифры, это видно в самом верху. Теперь смотрим ниже, там есть буквы ECDHE, это означает что для формирования сеансового ключа был использован алгоритм Диффи-Хеллмана на эллиптических кривых. При применении этого алгоритма параметры шифрования не сохраняются, чем достигается совершенная прямая секретность (PFS).

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