RedTeam brazzers
Про внутряки и редтим. Пригласить друга (и красивую подружку): @RedTeambro Вступление в чат канала через кнопку «Подать заявку» в комментариях канала. Некоммерческий проект. Не одобряем блек. Выступаем против всего плохого и за все хорошее🙂
Больше📈 Аналитический обзор Telegram-канала RedTeam brazzers
Канал RedTeam brazzers языкового сегмента Русский является активным участником. Сейчас сообщество объединяет 12 548 подписчиков, занимая 9 731 место в категории Технологии и приложения и 51 456 место в регионе Россия.
📊 Показатели аудитории и динамика
С момента создания невідомо проект демонстрирует стремительный рост, собрав аудиторию из 12 548 подписчиков.
Согласно последним данным от 27 августа, 2026, канал показывает стабильную активность. За последние 30 дней изменение числа участников составило -66, а за последние 24 часа — -6, при этом общий охват остаётся высоким.
- Статус верификации: Не верифицирован
- Уровень вовлечённости (ER): Средний показатель вовлечённости аудитории составляет 63.74%. В первые 24 часа после публикации контент обычно набирает N/A% реакций от общего числа подписчиков.
- Охват публикаций: В среднем каждый пост получает 7 997 просмотров. В течение первых суток публикация набирает 0 просмотров.
- Реакции и взаимодействия: Аудитория активно поддерживает контент: среднее количество реакций на один пост — 47.
- Тематические интересы: Контент сосредоточен на ключевых темах, таких как хеш, привилегия, реестр, cve-2024, rpc.
📝 Описание и контентная политика
Автор описывает ресурс как площадку для выражения субъективного мнения:
“Про внутряки и редтим.
Пригласить друга (и красивую подружку): @RedTeambro
Вступление в чат канала через кнопку «Подать заявку» в комментариях канала.
Некоммерческий проект. Не одобряем блек. Выступаем против всего плохого и за все хорошее🙂”
Благодаря высокой частоте обновлений (последние данные получены 28 августа, 2026) канал поддерживает актуальность и высокий уровень охвата публикаций. Аналитика показывает, что аудитория активно взаимодействует с контентом, что делает его важной точкой влияния в категории Технологии и приложения.
cwd_user / cwd_group / cwd_membership / cwd_directory. Скрипт умеет автоматически определять нужную базу для вставки данных
https://github.com/CICADA8-Research/Penetration/blob/main/Atlassian/Jira/create_admin.py\svcctl поверх установленного SMB-соединения с последующей попыткой открытия менеджера управления службами с SC_MANAGER_ALL_ACCESS, что, само собой, разрешено только высокопривилегированной УЗ, ведь это право дает полный доступ до управления службами на конечном устройстве.
Для подключения используются функции из протокола MS-SCMR, а именно OpenScManager(). Отмечу, что подключение к svcctl может оказаться роковым в вопросах уклонения от обнаружения (ведь его используют и psexec.py и smbexec.py), поэтому алгоритм следует поменять.
Мы поверх SMB соединения можем подключиться к любому другому пайпу, который имеет какой-нибудь контроль доступа. Можно попробовать и более экзотичные варианты по типу попытки дропа файла на C$. Но мой выбор остановился на протоколе MS-EVEN6. Причем именно его шестой версии потому, что обычный MS-EVEN, который я использовал тут подключается поверх пайпа \pipe\eventlog, а некоторые детектят таким образом коерс через Coercer. Поэтому я переделал функцию под MS-EVEN6, который поддерживает подключение через обычный TCP-коннект. Можно увидеть мой код тут
А как бы меняли логику Вы?
@RedTeambroPwn3d!) поверх разных протоколов. Начнем с протокола LDAP. Логика взаимодействия с протоколами находится внутри папки ./nxc/protocols:
- smb.py/ldap.py/ftp.py/... - обвязки под протоколы;
- Папки smb/ldap/ftp/... - дополнительный функционал протокола (не путать с модулями). Например, исполнение команд поверх SMB через -X whoami --exec-method atexec, в ./nxc/protocols/smb/atexec.py будет лежать логика atexec.py, либо --bloodhound поверх протокола LDAP.
Каждый протокол NXC сделан достаточно шаблонно, он должен реализовывать следующие функции:
- create_conn_obj() - осуществляет подключение к целевому протоколу нужного компьютера;
- enum_host_info() - позволяет получить информацию поверх этого протокола об устройстве, например, имя хоста и домена;
- print_host_info() - отображает данные из enum_host_info();
- check_if_admin() - решает, выводить или нет надпись Pwn3d!;
- *_login() - реализация аутентификации поверх различных протоколов.
Посмотрим подробнее, что делает NXC для определения привилегированной УЗ поверх LDAP. Для этого проваливаемся в ./nxc/protocols/ldap.py. С целью наглядности, а также чтобы подсветить потенциальные детекты LDAP-запросов, которые отправляет «стоковый» NXC, добавил логирование в функцию search().
1. Сначала отправляется следующий запрос
(userAccountControl:1.2.840.113556.1.4.803:=8192), base_dn=DC=example,DC=local, attributes=['objectSid']
этот запрос позволяет обнаружить контроллеры домена (UF_TRUST_ACCOUNT), чтобы по их SID получить SID домена. Пример ответа:
[{'objectSid': 'S-1-5-21-1234567890-1234567890-1234567890-1001'}]
2. Затем по найденному ObjectSid идет получение названий привилегированных групп по типу Domain Admins, Enterprise Admins:
Запрос: (|(objectSid=S-1-5-21-1234567890-1234567890-1234567890-512)(objectSid=S-1-5-21-1234567890-1234567890-1234567890-519)(objectSid=S-1-5-21-1234567890-1234567890-1234567890-544)(objectSid=S-1-5-32-549)(objectSid=S-1-5-32-551)), base_dn=DC=example,DC=local, attributes=['distinguishedName']
Ответ: [{'distinguishedName': 'CN=Server Operators,CN=Builtin,DC=example,DC=local'}, {'distinguishedName': 'CN=Backup Operators,CN=Builtin,DC=example,DC=local'}, {'distinguishedName': 'CN=Domain Admins,CN=Users,DC=example,DC=local'}, {'distinguishedName': 'CN=Enterprise Admins,CN=Users,DC=example,DC=local'}]
3. Наконец, NXC получает членов этих групп и проверяет, нет ли нашей УЗ в них. Если есть, значит, у нас Pwn3d! (в данном случае УЗ попадает в поле sAMAccountName):
Запрос: (&(objectCategory=user)(sAMAccountName=administrator)(|(memberOf:1.2.840.113556.1.4.1941:=CN=Server Operators,CN=Builtin,DC=example,DC=local)(memberOf:1.2.840.113556.1.4.1941:=CN=Backup Operators,CN=Builtin,DC=example,DC=local)(memberOf:1.2.840.113556.1.4.1941:=CN=Domain Admins,CN=Users,DC=example,DC=local)(memberOf:1.2.840.113556.1.4.1941:=CN=Enterprise Admins,CN=Users,DC=example,DC=local)(primaryGroupID=512)(primaryGroupID=519)(primaryGroupID=544)(primaryGroupID=549)(primaryGroupID=551))), base_dn=DC=example,DC=local, attributes=[]
Ответ: [{'objectClass': ['top', 'person', 'organizationalPerson', 'user'], 'cn': 'Administrator', ......
Полный текст ответа: https://gist.github.com/MzHmO/c9f5206112f09801b4478c725f1df2a4
Наконец, если на отправленный третий запрос поступал ответ, значит, пользователь привилегированный.
Отсюда у нас вылезает три потенциально интересных IOC'а в LDAP-запросах, которые можно отслеживать и детектировать.
Отмечу, что алгоритм не самый идеальный и его можно упростить, запрашивая сразу memberOf текущего пользователя, после чего извлекать objectSid полученных групп и по RID проверять их на привилегированность - будет два запроса LDAP. Пойдем еще дальше и исключим из этой цепочки objectSid, забив в NXC строки "Domain Admins"/"Администраторы домена" и проверять их, в таком случае будет всего один LDAP-запрос вместо трех.
