Как посмотреть имя администратора домена windows server
Обновлено: 03.07.2024
Если вы хотите, чтобы другие пользователи не могли узнать информацию о домене (например, имя администратора), подключите услугу «REG.Private».
Информация об Администраторе домена предоставляется в полном объёме на письменные запросы правоохранительных и судебных органов. Предоставление такой информации возможно исключительно на основании запросов суда и иных органов, которым законодательством РФ предоставлено такое право.
Запросы информации об Администраторе от Адвоката
В соответствии с п. 9.1.5. Правил регистрации Регистратор вправе сообщить информацию о полном наименовании (имени) администратора и его местонахождении (местожительстве) по письменному мотивированному запросу третьих лиц, содержащему обязательство использовать полученную информацию исключительно для целей предъявления судебного иска. Таким образом, адвокатский запрос должен содержать обязательство использовать полученную информацию исключительно для судебных целей, а также к нему должна быть приложена копия удостоверения адвоката, подписавшего запрос. Обращаем Ваше внимание на тот факт, что иные данные помимо ФИО/наименования и адреса по запросу адвоката не предоставляются.
Запросы информации об Администраторе от Правообладателя
В соответствии с п. 9.1.5. Правил регистрации Регистратор вправе сообщить информацию о полном наименовании (имени) администратора и его местонахождении (местожительстве) по письменному мотивированному запросу третьих лиц, содержащему обязательство использовать полученную информацию исключительно для целей предъявления судебного иска. Таким образом, запрос Правообладателя должен содержать обязательство использовать полученную информацию исключительно для судебных целей. Запрос должен быть оформлен на фирменном бланке организации-Правообладателя, иметь печать и подпись уполномоченного лица, к запросу должна быть приложена копия свидетельства на ТЗ/ТМ либо ИНН (в случае, если правообладатель обращается вследствие использования его фирменного наименования). Данные администратора по запросу Правообладателя предоставляются исключительно в случае, если само доменное имя сходно до степени смешения с ТЗ/ТМ/фирменным наименованием Правообладателя. Во всех иных случаях (в случае использования ТЗ/ТМ/фирменного наименования на контенте сайта и т.п.) данные администратора не могут быть предоставлены на основании такого запроса.
Обращаем Ваше внимание на тот факт, что иные данные помимо ФИО/наименования и адреса по запросу Правообладателя не предоставляются.
Регистратор вправе сообщить информацию о полном наименовании (имени) администратора и его местонахождении (местожительстве) по письменному мотивированному запросу третьих лиц, содержащему обязательство использовать полученную информацию исключительно для целей предъявления судебного иска.Более подробную информацию о порядке направления запросов от адвокатов и правообладателей вы можете найти в инструкции.
Используя PowerShell, как я могу получить полное имя текущего пользователя домена (не только его имя пользователя) без необходимости использования модуля ActiveDirectory?
Некоторые другие (в основном) неясные свойства также доступны. Несколько полезных:
- Homedrive UNC
- Homedrive Letter
- Описание
- Скрипт входа
Мне нравится принятый ответ, но только потому, что я хотел попробовать это сам:
или если вы не хотите иметь информацию заголовка и только результат:
Я читаю это слишком быстро, это делает запрос AD. Я устно убираю свой голос.Один лайнер с использованием Powershell 3.0:
На основании вашего комментария на принятый ответ Craig620,
Нужны ли мне права администратора домена для запуска этой команды? Или может сам пользователь домена может запустить эту команду?
Похоже, вы пытаетесь избежать установки модулей powershell на пользовательских рабочих станциях, да, но также, нет, вам не нужно быть администратором домена, чтобы искать свое собственное имя в AD. Вы можете найти практически любую информацию, которая появляется в GAL в Outlook, включая полное имя обычного пользователя.
Вы также можете посмотреть полные имена других людей как обычный пользователь в AD (используя Get-WmiObject Win32_userAccount , если вы хотите избежать модулей AD). Учетные записи служб, которые запрашивают AD (ну, прежде чем управляемые учетные записи служб ), обычно являются обычными непривилегированными пользователями AD.
Использование -match не является хорошим выбором, потому что $ env: USERNAME для "ed" будет соответствовать "fred" и "edith". Вместо этого используйте -eq для точного соответствия и добавьте в домен, если необходимо. Я использую цикл foreach в конце, чтобы убрать все начальные пробелы в качестве альтернативы «select fullname | ft -HideTableHeaders», которая печатает начальную и конечную новую строку.
Этот класс обеспечивает очень простой доступ ко всем распространенным свойствам LDAP, поэтому вам не нужно искать дважды (один раз с WinNT и снова с LDAP) или использовать [ADSISearcher] для поиска LDAP, если вам нужны некоторые расширенные свойства, которые WinNT не реализует ,
Если вы не хотите использовать модуль Active Directory, вы не можете; если вы не хотите пойти еще глубже и выполнить фактический запрос LDAP к контроллеру домена.
Любая пользовательская информация, кроме имени пользователя, хранится в Active Directory, и ее необходимо найти там.
В предыдущей статье мы описали процедуру сброса пароля стандартной учётной записи администратора домена Active Directory (учетка administrator). Данный сценарий отлично работает в «стандартной» среде Active Directory, однако в некоторых доменах подобный трюк может не сработать, т.к. при их разворачивании были использованы best practice Microsoft по обеспечению безопасности инфраструктуры AD. В реальных доменах AD для защиты учетной записи администратора домена могут применяться следующие стратегии:
- Переименование стандартной учетной записи администратора Active Directory
- Создание учетной записи-приманки. Учетная запись хоть и имеет имя Administrator, но никакими правами повышенными не обладает. Кроме того, с помощью политик аудита можно настроить оповещение служб безопасности о попытке авторизации с помощью этой учётной записи
- Отключение учетной записи Administrator и предоставление полномочий администратора домена другой учетке.
В этой статье мы попробуем разобрать методики обхода этих стратегий, позволяющих обнаружить в AD все учетные записи с правами администратора домена.
Итак, в предыдущей статье мы показывали, каким образом с помощью создания системного сервиса на контроллере домена можно сбросить пароль домен-админа. Данная команда при загрузке DC сбросит пароль доменной учетной записи administrator (администратора домена) на P@ssw0rd.
Что же делать, если под этой учетной записью авторизоваться не получается? Скорее всего, при разворачивании домена она была защищена по одной из перечисленных выше методик.
Монтируем отключенную базу Active Directory
Попробуем извлечь из базы AD информацию о реальных администраторах домена. Для этого нужно загрузиться в DSRM режиме, в котором база Active Directory (ntds.dit) находится в отключенном состоянии. Нам необходимо локально смонтировать эту базу, чтобы в дальнейшем получить возможность доступа к хранимой в ней информации.
Запустите две командные строки: в первой мы запустим процесс dsamain.exe , во второй будем вводить интерактивные команды.
Совет. При работе на Server Core вторую командную строку можно открыть, выполнив в исходной cmd команду:
Перед запуском утилиты dsamain.exe, удостоверимся, что другие сервисы и процессы в настоящий момент не используют порт 389. Сделать это можно командой:
В том случае, если команда ничего не вернула – все ОК, идем дальше (если вернула нужно найти и отключить найденный процесс).
Утилита dsamain.exe позволяет смонтировать базу AD и выполнять к ней различные запросы LDAP(по сути позволяет организовать автономный LDAP сервер). Утилита запускается со следующими параметрами:
Смонтируем базу AD командой:
Удостоверимся, что процесс dsamain.exe запущен и слушает 389 порт. Для этого во второй командной строке выполните команду:
TCP [::]:389 [::]:0 LISTENING 614
TCP 0.0.0.0:389 *:* 614
Получаем, что процесс с Process ID 614 слушает на порту TCP 389.
Проверим, что процесс с PID 604 и есть наш процесс dsamain.exe:
Session Name: Console
Mem Usage: 11,316 K
Теперь, когда база AD смонтирована, мы можем обращаться к ней с помощью утилит ds* (dsget, dsquery и т.д.). Разберем все три варианта скрытия учетной записи администратора домена.
Переименованная учетная запись администратора домена
Как можно определить, что стандартная учетная запись администратора Active Directory переименована?
Стандартный administrator AD имеет известный идентификатор SID, формат которого S-1-5-21-[ид домена]-500, соответственно, нам просто нужно найти в домене объект с таким SID. Во второй командной строке выполните команду:
В данном случае, видно, что учетная запись administrator была переименована в itpro.
Сбросить пароль этой учетной записи можно также с помощью специальной службы:
Теперь можно размонтировать базу AD (остановить процесс dsamain.exe комбинацией Ctrl+C). Убедитесь, что команда вернула строку
Active Directory Domain Services was shut down successfullyПоддельная учетная запись администратора AD
Как определить, что стандартный Administrator Active Directory не обладает необходимыми правами? Это очень просто. Зная DN (distinguished name) учетной записи administrator, мы можем получить список групп, в которых он состоит:
Как вы видите, данная учетная запись не состоит в группе администраторов домена (Domain Admins) и не подойдет для наших целей. Следующая методика поможет найти «реальных» администраторов.
Альтернативный администратор домена
Попробуем разобраться как можно получить список учетных записей, обладающих правами администратора домена? Для начала попробуем рекурсивно вывести всех членов группы Administrators (в том числе членов групп Domain Admins и Enterprise Admins).
Как вы видите, администраторскими правами обладают учетные записи Administrator и itpro. Проверим статус учётной записи Administrator:
Administrator S-1-5-21-2092397264-2003686862-3249677370-500 yes
Как вы видите, она отключена.
Проверим теперь статус учетки itpro:
itpro S-1-5-21-2092397264-2003686862-3249677370-1107 no
Эта учетная запись активна. Проверим в каких группах она состоит:
Не забудьте отмонтировать базу AD и перезагрузите сервер.
Предыдущая статья Следующая статья
Спасибо! Ту статью я тоже почитал. Можете подсказать, как в таком случае должна выглядить команда? Вот так будет корректно? sc create ResetPW binPath= «%ComSpec% /k net user itpro PA$w0rd94 /expires:never» start= auto
Именно в таком виде у меня не получилось.
Если вам нужно сбросить пароль администратора (в этом примере он называется itpro), используйте команду:
sc create ResetPW binPath= "%ComSpec% /k net user itpro P@ssw0rd" start= auto
Если нужно установить, что пароль не истекает:
sc create SetPwNotExp binPath= «%ComSpec% /k wmic useraccount WHERE Name='itpro' set PasswordExpires=false» start= auto
Большое спасибо за ответ! Сейчас попробую!
И нужно-ли останавливать второй контроллер домена?
Типичной целью пентеста внутри корпоративной сети (чаще всего построенной на ActiveDirectory) бывает компрометация контроллеров домена, то есть получение учетки с правами группы Domain Admins.
Обычно как получается с такими сетями: находим дырявые сервисы, получаем контроль над хостом, из памяти добываем учетки (креды либо хешики) и с ними идем уже на другие хосты, пока не найдем где-нибудь процессы юзера из группы Domain Admins. Если честно, то, сколько помню пентестов, проблемы найти админов не было — они обнаруживались сами собой и достаточно быстро. И как-то даже мысль не приходила в голову, что есть такая задачка — находить их.
Но вот наткнулся на интересный топик блога компании NetSPI и осознал, что «точечный удар» будет более профессиональным подходом. Самое интересное, что можно с правами обычного доменного юзера оперативно найти администраторов.
Итак, начнем. Первая подзадача — определить всех админов домена. То бишь наших жертв. Фактически не считается, что эта информация приватная, а потому доступна она всем юзерам домена по умолчанию. Узнать их можно, например, стандартной командой
Но если помнишь, с ActiveDirectory можно работать через LDAP, причем опять-таки по умолчанию для доступа к нему требуется любая доменная учетка. Как следствие, мы можем получить не только перечень админов, но и, по сути, структуру юзеров и групп, а также много другой интересной информации.
Вторая подзадачка — найти процессы, запущенные от админов домена. Это уже более специфическая тема. Методов несколько.
Есть такая штука, как Service Principle Name (SPN). Если очень примерно, то это имя сервиса, под которым он регистрируется в AD для работы Kerberos-аутентификацией. Но нас интересует здесь несколько другое. А именно то, что в LDAP’е мы можем просмотреть SPN с привязкой к аккаунту AD, под которой он запущен. То есть если какой-то сервис был запущен изначально под учетной записью администратора домена, то в LDAP’е для этой учетки будет SPN-запись с названием сервиса, а главное с именем хоста, где этот сервис запущен. Чтобы не ползать вручную по LDAP’у, NetSPI написали скрипт на PowerShell для удобного и быстрого поиска по группам.
Но у этого способа есть один минус. На практике только Microsoft’овские сервисы регистрируют себя в домене, а если учесть, что их нечасто запускают из-под доменных учеток, то шансы не очень велики. С другой стороны, если вспомнить, что каждый хост имеет учетную запись в AD, то мы можем легко найти все сервисы какого-то типа. Самый практичный пример — найти все MS SQL сервисы, которые есть в домене! И без какого-либо сканирования.
Иную возможность предоставляет нам NetBIOS. Мы с правами обычного юзера можем запросить у контроллеров домена информацию по активным сессиям. В итоге мы можем получить имя хоста с админскими процессами. Минус заключается в том, кто информация о сессиях будет за короткий промежуток времени, то есть если не было взаимодействия с контроллером, то мы не увидим админа в списке. А потому надо систематически запрашивать контроллеры — админчик когда-нибудь точно появится.
С помощью тулзы NetSess можно сделать запрос инфы, а с помощью скриптика автоматизировать поиск по выводу.
Получаем перечень сессий, используя NetSess
NetSPI в блоге предложил еще два метода: запрашивать отдельные хосты на сессии юзеров через NetBIOS или, если есть учетка локального админа (одна на многих хостах), удаленно запрашивать список запущенных процессов. Но, имхо, оба они работают в редких случаях, да и шумноваты.
Задача
Создать одну сеть для VirtualBox и VMware
Решение
Недавно нужно было в одну сеть «объединить» гостевую тачку под VirtualBox и гостевую от VMware на одной хостовой машине. Оказалось, что сделать это очень даже просто. А главное, значительно быстрее, чем конвертировать виртуалку в другой формат. Последовательность такова.
При установке VirtualBox создается дополнительный сетевой интерфейс в хостовой ОС VirtualBox Host-Only Ethernet Adapter. Его мы должны выбрать в настройках гостевой ОС VirtualBox (вкладка Network) с типом host only adapter.
Далее мы должны настроить сеть в VMware. Здесь нам понадобится Virtual Network Editor, который поставляется с VMware Workstation. В нем мы должны выбрать любую сеть (VMnet0-9), выставить для нее тип Bridged и указать в списке тот же интерфейс — VirtualBox Host-Only Ethernet Adapter. И последний шаг — в настройках гостевой ОС в VMware указать имя сети, для которой была произведена конфигурация. И все! Причем DHCP от VirtualBox’а тоже должен работать.
По идее, VMware Player тоже может подключиться к сети VirtualBox’а так же через Bridge. Но там вроде как есть проблемы с DHCP, а потому IP надо задавать вручную.
Соединяем виртуалки VMware и VirutalBox
Задача
Пробросить порт под Windows
Решение
Пробросить порт — это одна из самых типичных задач. Вот систематически с ней сталкиваюсь, когда необходимо ресерчить какую-нибудь толстенную программулину, которая по умолчанию вешается на lookback-интерфейс (127.0.0.1), но, чтобы ее перенастроить на другой интерфейс, надо побегать с бубном с пару дней. Под никсами все просто, а вот под виндой это у меня обычно решалось сторонними штуками (считай костылями), типа ncat’a. Но, спасибо Глебу за наводку, оказывается, можно пробросить порты чисто внутренними средствами — с помощью команды netsh. Возможностей у нее целая масса, но за ними отправлю тебя к мануалам, а здесь будет лишь пример для проброса:
netsh — сама тулза; interface portproxy — подклассы команд; add v4tov4 — добавить правило IPv4 на IPv4 (по идее, изначально тулза создавалась именно для решения проблем с внедрением IPv6); а далее — порт и адрес, который ОС будет слушать, и порт и адрес, куда будет перенаправлять данные. Netsh interface portproxy show all покажет все имеющиеся правила.
Тулза полезная, особенно когда надо будет поснифать локальный трафик.
Задача
Обойти lock screen для iOS
Решение
Чтобы обезопасить данные, на многих мобильных девайсах используется lock screen, который требует ввести либо код, либо графический ключ. Конечно, хуже всего то, что пользователи мобильных девайсов верят, будто их приватная информация хорошо защищена локскрином. Но нам в любом случае интересно, как можно его обойти.
Как ни странно, способы были, есть и будут. Мне хотелось бы познакомить тебя с очень занимательной ссылкой. В этом топике блога SANS Penetration Testing представлен целый пак ссылок на видео и описания уязвимостей, которые были найдены в разных версиях iOS. Очень поучительный материал.
Задача
Собрать уязвимости под Android
Решение
Еще один мини-вопрос про интересный ресурс. Вообразим, что это раздел WWW2 :). На самом деле достаточно интересная ситуация обстоит с андроидами. Платформа развивается хорошими шагами, но, в отличие от iOS, разработчиков и производителей для андроида большие кучи. И конечно, безопасность не является одним из приоритетов для них. А добавим к этому еще и геморрой с обновлениями (особенно на нетоповых моделях).
В общем, дыры появляются специфичные для вендоров и, непатченные, живут долгой жизнью. На данном ресурсе пытаются хоть как-то консолидировать и структурировать их. Есть на что посмотреть. Надеюсь, ресурс будет развиваться.
Количество уязвимых дроид-устройств. Мир в опасности!
Задача
Пробросить Meterpreter за NAT/DMZ
Решение
Для начала напомню тебе, что Meterpreter — это продвинутый динамически расширяемый шелл из Metasploit’а (MSF). Штука реально прикольная, одна из главных фишечек MSF.
Теперь к примерам по задаче. Представь себе, что есть закрытая корпоративная сеть и мы посылаем письмом наш троянчик с Meterpeter’ом, дабы захватить контроль над хостом какого-нибудь офисного сотрудника. Ты, возможно, знаешь, что в MSF есть различные виды шеллов с различными видами установления контакта между жертвой и атакующим: обычные бинды, back-connect’ы на различных протоколах, портах, через прокси-серверы или через DNS… Много-много различных вариантов.
Но что, если они нам не подходят? Что, если у жертвы есть доступ к почте? Чисто теоретически мы могли бы поломать еще какой-то хост в той же сети или в DMZ (но с которым у нас есть возможность общаться через сеть) и использовать его как транзитный. На самом деле реализовать такое можно было бы чисто за счет проброса портов, но не с Metasploit.
А вот еще один пример. У меня есть комп с виндой, но совсем нет желания ставить на него MSF (уж больно толст он стал), и я использую его из-под виртуалки с Kali. И все хорошо, когда виртуалка подключена в bridged-моде, но это не всегда возможно (port security, например), и приходится убирать ее за NAT. И вот тут начинаются трудности, когда мы что-нибудь пытаемся проэксплуатировать и получить шелл. Практическим мы опять-таки могли бы сделать просто проброс портов за NAT, но, когда мы имеем дело с MSF и reverse (back-connect) шеллами, мы должны указать свой IP, но что хуже — MSF пытается поднять на этом IP-адресе хендлер для шелла.
Возможно, и есть какие-то пути победить эту проблему чисто средствами, но, помнится, такая ситуация появлялась несколько раз и дельного решения в голову не приходило.
После такой преамбулы хотелось бы поделиться радостью — наконец-то в MSF появилась возможность общаться с жертвой (с Meterpreter) через какой-то хост. Хотя выглядит это, конечно, чем-то похожим на костыль.
В этом видео показан пример использования hop’a. Думаю, после его просмотра особых вопросов с настройкой Meterpreter’а не возникнет.
Задача
Постэксплуатация MS SQL DB links
Решение
В прошлом номере мы коснулись такой темы, как линки в базах данных и чем они нам могут помочь в пентестах на примере Oracle. Сегодня пробежимся по данной возможности для СУБД MS SQL. За основу был взят пост c NetSPI, они больше всех копались в этом деле.
Итак, линки — это возможность СУБД запрашивать данные из сторонних источников. Зачастую это другие аналогичные базы данных, но могут быть и совершенно иные. Так, MS SQL может линковаться как c MS SQL, так и с Oracle, MySQL, MS Access и даже с Excel-табличками. Но без дополнительной настройки вроде только к первому варианту.
В отличие от Оракла, в микрософтовской базе данных создание линков всегда было высокопривилегированной фичей, а потому нас больше волнует возможность, что мы можем делать с уже имеющимися линками. Так как зачем нам создавать линки, если можно сразу получить RCE на сервере? А вот уже созданными линками могут пользоваться любые юзеры базы данных, что очень удобно для нас.
Посмотреть их мы можем в табличке:
В ней мы увидим серверы (srvname), с которыми есть линки, тип подключения (providername) и доступность линка (dataaccess, доступен, если 1). Есть еще rpcout, который указывает на возможность RPC-коннектов к удаленному серверу (об этом далее).
Как и оракловой базой данных, здесь поддерживаются различные методы аутентификации при подключении к сторонним серверам. То есть мы, например, имеем доступ в базу данных А с правами обычного пользователя, но можем обратиться к линку, который подключится в базу Б с другой, привилегированной учеткой. Как ты понимаешь, в таких случаях СУБД должна хранить эту учетку. И это действительно так — в определенной табличке в зашифрованном виде (AES для 2012 и 3DES для более старых версий, с рандомным ключом). Для того чтобы расшифровать его, необходимо иметь админский доступ к ОС и в БД. NetSPI написали тулзенку для этого дела на PowerShell. Несмотря на то что нам необходимо иметь доступ на сервер, этим можно заняться, чтобы получить plain-text пароль и попробовать, не используется ли он где-то еще.
Чтобы сделать запрос к линкованной базе данных, есть два метода.
Минус второго метода заключается в том, что мы не можем делать запрос через несколько линков. Да-да-да. С openquery мы можем запросить информацию из линка в другом линке.
При этом количество «вложенностей» (то есть линков) может быть произвольно. Единственный момент тут в удвоении количества кавычек в запросах. Кроме того, документация МS говорит о невозможности выполнения хранимых процедур на линкованной БД. NetSPI это ограничение обошли, добавив произвольный запрос перед вызовом процедуры. Да, мы не получим итог процедуры, но ведь это не всегда и нужно.
Как видишь, все вполне круто и просто.
Вот только с RCE (через xp_cmdshell) на прилинкованных серверах есть трудности (не считая того, что линковка должна быть под привилегированной учеткой). Главная из них заключается в том, что хранимая процедура xp_cmdshell во всех версиях SQL-сервера после 2000 отключена по умолчанию. Конечно, в обычных условиях мы можем воспользоваться sp_configure, но только не для линкованных серверов. Используемый openquery указывает на то, что транзакция пользовательская, а потому не допускается переконфигурация сервера. Как-то так, грустно.
Теоретически имеется возможность переконфигурировать прилинкованный сервер, но он должен быть слинкован с возможностью RPC-вызовов (rpcout, упомянутый ранее), а по умолчанию это не так. Имхо, шанс найти привилегированный линк, да еще и с такой настройкой, стремится к нулю. Но в любом случае вот пример:
Как видишь, все просто, но позволяет иногда докопаться до интересных глубин.
Линки могут быть очень полезными. Примерчик от NetSPI
Читайте также: