RedTeam brazzers
Про внутряки и редтим. Пригласить друга (и красивую подружку): @RedTeambro Вступление в чат канала через кнопку «Подать заявку» в комментариях канала. Некоммерческий проект. Не одобряем блек. Выступаем против всего плохого и за все хорошее🙂
Show more📈 Analytical overview of Telegram channel RedTeam brazzers
Channel RedTeam brazzers in the Russian language segment is an active participant. Currently, the community unites 12 548 subscribers, ranking 9 726 in the Technologies & Applications category and 51 468 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 12 548 subscribers.
According to the latest data from 28 August, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -57 over the last 30 days and by 3 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 60.13%. Within the first 24 hours after publication, content typically collects N/A% reactions from the total number of subscribers.
- Post reach: On average, each post receives 0 views. Within the first day, a publication typically gains 0 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 0.
- Thematic interests: Content is focused on key topics such as хеш, привилегия, реестр, cve-2024, rpc.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Про внутряки и редтим.
Пригласить друга (и красивую подружку): @RedTeambro
Вступление в чат канала через кнопку «Подать заявку» в комментариях канала.
Некоммерческий проект. Не одобряем блек. Выступаем против всего плохого и за все хорошее🙂”
Thanks to the high frequency of updates (latest data received on 29 August, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
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-запрос вместо трех.
