RedTeam brazzers
Про внутряки и редтим. Пригласить друга (и красивую подружку): @RedTeambro Вступление в чат канала через кнопку «Подать заявку» в комментариях канала. Некоммерческий проект. Не одобряем блек. Выступаем против всего плохого и за все хорошее🙂
Ko'proq ko'rsatish📈 Telegram kanali RedTeam brazzers analitikasi
RedTeam brazzers Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 12 548 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 9 731-o'rinni va Rossiya mintaqasida 51 456-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 12 548 obunachiga ega bo‘ldi.
27 Avgust, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni -66 ga, so‘nggi 24 soatda esa -6 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 63.74% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining N/A% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 7 997 marta ko‘riladi; birinchi sutkada odatda 0 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 47 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent хеш, привилегия, реестр, cve-2024, rpc kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Про внутряки и редтим.
Пригласить друга (и красивую подружку): @RedTeambro
Вступление в чат канала через кнопку «Подать заявку» в комментариях канала.
Некоммерческий проект. Не одобряем блек. Выступаем против всего плохого и за все хорошее🙂”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 28 Avgust, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
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-запрос вместо трех.
