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-запрос вместо трех.
