Link-local multicast name resolution

Содержание:

Действия с захваченными хешами

NTLM Relay

Добавление нового компьютера в домен

Сбор информации о домене

CypherDog
GoFetch
ANGRYPUPPY
gt-generator

Атаки на домен

Roasting
Атака через ACL
Делегирование Kerberos
Abusing GPO Permissions

Roasting

Kerberoast
Asreproast

Kerberoast

AES256_CTS_HMAC_SHA1
AES128_CTS_HMAC_SHA1
RC4_HMAC_MD5

GetUserSPN.ps1
Find-PSServiceAccounts.ps1
Get-NetUSER -SPN
(Get-ADUser -Filter {ServicePrincipalName -ne «$null»} -Properties ServicePrincipalName).ServicePrincipalName

setspn.exe (штатная утилита Windows)
Запрос тикета через powershell
Request-SPNTicket

Invoke-Mimikatz -Command ‘«Kerberos::list /export»’
Mimikatz -Command ‘«Kerberos::list /export»’
Invioke-Kerberoast
tgsrepack.py

RiskySPN
PowerSploit
GetUserSPNs.py

Asreproast

PowerView
Модуль Active-Directory

Атака через ACL

Пользователь добавляется в необходимые группы.
Два ACE (Replicating Directory Changes и Replicating Directory Changes ALL) добавляются в ACL объекта домена.
При наличии прав на DCSync с помощью утилиты Mimikatz запрашивается хеш пароля пользователя krbtgt (настройка по умолчанию).
После завершения эксплуатации скрипт удаляет все добавленные группы и записи ACE в ACL.

ForceChangePassword. Права на изменение пароля пользователя, когда текущий пароль не известен. Эксплуатация с помощью PowerSploit — Set-DomainUserPassword.
AddMembers. Права на добавление групп, компьютеров и пользователей в группы. Эксплуатация с помощью PowerSploit — Add-DomainGroupMember.
GenericWrite. Права на изменение атрибутов объекта. Например изменить значение параметра scriptPath. При следующем входе пользователя в систему запустится указанный файл. Эксплуатация с помощью PowerSploit — Set-DomainObject.
WriteOwner. Права на изменения владельца объекта. Эксплуатация с помощью PowerSploit — Set-DomainObjectOwner.
AllExtendedRights. Права на добавление пользователей в группы, смена паролей пользователя и др. Эксплуатация с помощью PowerSploit — Set-DomainUserPassword or Add-DomainGroupMember.

Делегирование Kerberos

Неограниченное (Unconstrained delegation). Единственный вариант делегирования до Windows Server 2003
Ограниченное (Сonstrained delegation), начиная с Windows Server 2003
Ограниченное на основе ресурсов (Resource-Based Constrained Delegation). Появилось в Windows Server 2012

Пароль пользователя конвертируется в ntlm-хеш. Временная метка шифруется этим хешем и отправляется на контроллер домена для запроса TGT-тикета.
Контроллер домена проверяет информацию о пользователе (ограничение входа в систему, членство в группах и т.д.), создает TGT-тикет и отправляет пользователю. TGT-тикет зашифрован, подписан, и его данные могут быть прочитаны только krbtgt.
Пользователь запрашивает TGS-тикет для доступа на веб-сервис на веб-сервере.
Контроллер домена предоставляет TGS-тикет.
Пользователь отправляет TGT- и TGS-тикеты на веб-сервер.
Сервисная учетная запись веб-сервера использует TGT-тикет пользователя для запроса TGS-тикета для доступа к серверу БД.
Сервисная учетная запись подключается к серверу БД как пользователь.

PowerView
Active-Directory Module.

С помощью mimikatz. sekurlsa::tickets /export
Также можно выполнить атаку Pass-The-ticket

S4USelf
S4UProxy

Abusing GPO Permissions

Выполнить задачу в планировщике задач
Добавить права пользователю (SeDebugPrivilege, SeTakeOwnershipPrivilege и др.)
Добавить скрипт, выполняющийся после автозагрузки
Добавить пользователя в локальную группу

Preview Versions

From time to time, Microsoft may
publish a preview, or pre-release, version of an Open Specifications technical
document for community review and feedback. To submit feedback for a preview
version of a technical document, please follow any instructions specified for
that document. If no instructions are indicated for the document, please
provide feedback by using the Open
Specification Forums.

The preview period for a technical document varies.
Additionally, not every technical document will be published for preview.

A preview version of this document may be
available on the Windows
Protocols — Preview Documents page. After the preview period, the
most current version of the document is available on this page.

MSDP

MSDP is a protocol for MUD servers to communicate information with MUD clients in a separate channel from the one which carries all of the text that makes up the game itself. Mudlet can be configured to use MSDP by clicking on the Settings button (or Options->Preferences in the menu, or <alt>p). The option is on the General tab.

Once MSDP is enabled, you will need to reconnect to the MUD so that Mudlet can inform the server it is ready to receive GMCP information. Please note that some servers don’t both send MSDP and GMCP at the same time, so even if you enable both in Mudlet, the server will choose to send only one of them.

Receiving MSDP data

To «trigger» on MSDP messages, you’ll need to create — Mudlet will call it for you whenever relevant MSDP data is received.

As an example, lets create a script that’ll track whenever we move — that is, the room number changes. To begin with, we need to ask the game to be sending us updates whenever we move — so do:

in the command-line first to enable reporting of the room number and name. Then, create a new script and give it a name of the function you’d like to be called when the relevant MSDP message is received. Add the MSDP event you’d like the function to fire on under the registered event handlers — in our case, msdp.ROOM_VNUM. Lastly, define the function — either in this or any other script — and you’ll be done. The MSDP data received will be stored in the corresponding field of the msdp table, which your function will read from.

Example:

The test_msdp() function will be called whenever ROOM_VNUM is received from the game, and it’ll echo the latest data on the screen.

Sending MSDP data

-- ask the server to report your health changes to you. Result will be stored in msdp.HEALTH in Mudlet
sendMSDP("REPORT", "HEALTH")

-- client - IAC SB MSDP MSDP_VAR "SEND" MSDP_VAL "AREA NAME" MSDP_VAL "ROOM NAME" IAC SE in the documentation translates to the following in Mudlet:
sendMSDP("SEND", "AREA NAME", "ROOM NAME")

Аудит событий NTLM аутентификации в домене

Перед полным отключением NTLM в домене и переходе на Kerberos желательно убедиться, что в домене не осталось приложений, которые требуют и используют NTLM авторизацию.

Для отслеживания учетных записей и приложение, которые используют NTLM аутентификацию, вы можете включить политики аудита на всех компьютерах с помощью GPO. В разделе Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options найдите и включите политику Network Security: Restrict NTLM: Audit NTLM authentication in this domain, установив ее значение на Enable all.

Аналогичным образом включите политику Network Security: Restrict NTLM: Audit Incoming NTLM Traffic, установив ее значение на Enable auditing for domain accounts.

После включения данных политик события использования NTLM аутентификации записываться в журнал событий Event Viewer в секцию Application and Services Logs-> Microsoft -> Windows -> NTLM.

Можно проанализировать события на каждом сервере, или собрать все события в центральный Event Log.

Вам нужно собрать события от Microsoft-Windows-Security-Auditing c Event ID 4624 – An Account was successfully logged on

Обратите внимание на информацию в секции “Detailed Authentication Information”. Если в строке Authentication Package указано NTLM, значит для аутентификации этого пользователя использовался протокол NTLM

Теперь обратите внимание на значение Package Name (NTLM only). Здесь должно быть указано какой протокол (LM, NTLMv1 или NTLMv2) использовался для аутентификации

Таким образом вам нужно идентифицировать все сервера/приложения, которые используют устаревший протокол.

Например, для поиска всех событий аутентификации по NTLMv1 по всем контроллерам домена можно использовать такой PowerShell скрипт:

После того, как вы нашли пользователей и приложения, использующие NTLM в вашем домене, попробуйте перевести их на использование Kerberos (возможно с использованием SPN). Некоторые приложения достаточно донастроить для работы Kerberos авторизации (см. статьи Kerberos авторизация в IIS, использование Kerberos авторизация в браузерах). Из личного опыта: даже действительно большие коммерческие продукты иногда еще не перешли с использования NTLM на Kerberos, некоторые продукты требуют обновления или изменений конфигурации. Все сводится к определению того, какие приложения используют проверку подлинности NTLM, и теперь у вас есть способ для выяснения этого софта и устройств.

Для авторизации в Kerberos нужно использовать DNS имя сервера, а не IP адрес. Если вы указываете IP адрес при подключении к ресурсы, используется NTLM аутентификация.

Те приложений, которые нельзя переключить на использование NTLM можно добавить в исключения, разрешив им использовать NTLM аутентификацию, даже если она отключена на уровне домена. Для этого используется политика Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain. В список исключений нужно добавить имена серверов, для аутентификации на которых можно использовать NTLM (конечно, в идеале этот список исключений должен быть пустым). Можно использовать знак подстановки *.

Сравнение PNRP с распределенными хеш-таблицами[править | править код]

Внутренне PNRP использует архитектуру, аналогичную системам распределенных хеш-таблиц, таким как Chord или Pastry. Имя однорангового узла хешируется для создания 128-битного идентификатора, а DHT-подобный алгоритм используется для получения местоположения хоста, публикующего этот идентификатор. Но при всех сходствах, существуют и некоторые различия.

Системы DHT, такие как Chord или Pastry, хранят хеши в узлах, максимально близких к хосту, а алгоритм маршрутизации устроен так, чтобы обеспечить поиск этого узла. PNRP же, напротив, всегда хранит хеш на узле, который публикует идентификатор. Таким образом, узел будет иметь столько же записей в системе маршрутизации, сколько и идентификаторов, которые он использует. В результате складывается такая ситуация, что PNRP приходится жертвовать скоростью маршрутизации ради повышенной безопасности и надежности.

В отличие от систем DHT, PRNP разрешает нескольким хостам (например, одной группе), использовать одно и то же имя. В DHT предполагается уникальность имен. Внутренний индекс фактически состоит из 128-битного хеша имени однорангового узла и 128-битного идентификатора местоположения, полученного из IPv6-адреса узла.

Вместо таблицы маршрутизации в PNRP используется кэш записей. Каждая новая запись появляется за счет проходящего через сеть трафика. За счет этого обеспечивается актуальность информации о сети.

Intellectual Property Rights Notice for Open Specifications Documentation

Technical Documentation. Microsoft publishes Open
Specifications documentation (“this documentation”) for protocols, file
formats, data portability, computer languages, and standards support.
Additionally, overview documents cover inter-protocol relationships and
interactions.
Copyrights. This documentation is covered by Microsoft
copyrights. Regardless of any other terms that are contained in the terms of
use for the Microsoft website that hosts this documentation, you can make
copies of it in order to develop implementations of the technologies that are
described in this documentation and can distribute portions of it in your
implementations that use these technologies or in your documentation as
necessary to properly document the implementation. You can also distribute in your
implementation, with or without modification, any schemas, IDLs, or code
samples that are included in the documentation. This permission also applies to
any documents that are referenced in the Open Specifications documentation.
No Trade Secrets. Microsoft does not claim any trade
secret rights in this documentation.
Patents. Microsoft has patents that might cover your
implementations of the technologies described in the Open Specifications
documentation. Neither this notice nor Microsoft’s delivery of this
documentation grants any licenses under those patents or any other Microsoft
patents. However, a given Open Specifications document might be covered by the
Microsoft Open Specifications
Promise or the Microsoft Community
Promise. If you would prefer a written license, or if the
technologies described in this documentation are not covered by the Open
Specifications Promise or Community Promise, as applicable, patent licenses are
available by contacting iplg@microsoft.com.
License Programs. To see all of the protocols in scope
under a specific license program and the associated patents, visit the Patent Map.
Trademarks. The names of companies and products contained
in this documentation might be covered by trademarks or similar intellectual
property rights. This notice does not grant any licenses under those rights.
For a list of Microsoft trademarks, visit www.microsoft.com/trademarks.

Reservation of Rights. All other
rights are reserved, and this notice does not grant any rights other than as
specifically described above, whether by implication, estoppel, or otherwise.

Tools.
The Open Specifications documentation does not require the use of Microsoft
programming tools or programming environments in order for you to develop an
implementation. If you have access to Microsoft programming tools and
environments, you are free to take advantage of them. Certain Open
Specifications documents are intended for use in conjunction with publicly
available standards specifications and network programming art and, as such,
assume that the reader either is familiar with the aforementioned material or
has immediate access to it.

Support.
For questions and support, please contact dochelp@microsoft.com.

Выводы

Существуют два популярных семейства стандартов систем управления: стандарты Internet, описывающие системы управления на основе протокола SNMP, и международные стандарты управления открытых систем (OSI), разработанные ISO и ITU-T, опирающиеся на протокол управления CMIP. Семейство стандартов Internet специфицирует минимум аспектов и элементов системы управления, а семейство стандартов ISO/ITU-T — максимум.

Системы управления SNMP основаны на следующих концепциях, ориентированных на минимальную загрузку управляемых устройств:

агент выполняет самые простые функции и работает в основном по инициативе менеджера;
система управления состоит из одного менеджера, который периодически опрашивает всех агентов;
протокол взаимодействия между агентом и менеджером SNMP опирается на простой ненадежный транспортный протокол UDP (для разгрузки управляемого устройства) и использует два основных типа команд — get для получения данных от агента и set для передачи управляющих воздействий агенту;
агент может послать данные менеджеру по своей инициативе с помощью команды trap, но число ситуаций, в которых он применяет эту команду, очень невелико.

Базы управляющей информации MIB в стандартах Internet состоят из дерева атрибутов, называемых объектами и группами объектов.

Первые MIB Internet были ориентированы на управление маршрутизаторами:
MIB-I — только контроль, MIB-II — контроль и управление. Более поздняя разработка RMON MIB была направлена на создание интеллектуальных агентов, контролирующих нижний уровень, — интерфейсы Ethernet и Token Ring. Имена объектов стандартных MIB Internet зарегистрированы в дереве регистрации имен стандартов ISO.

Стандарты ISO/ITU-T для представления управляемых устройств используют объектно-ориентированный подход. Определено несколько суперклассов обобщенных управляемых объектов, на основании которых путем наследования свойств должны создаваться более специфические классы объектов.
Для описания управляемых объектов OSI разработаны правила GDMO, основанные на формах определенной структуры, заполняемых с помощью языка ASN.1.

Для представления знаний об управляемых объектах, агентах и менеджерах системы управления OSI используется три древовидные базы данных: дерево наследования, которое описывает отношения наследования между классами объектов, дерево включения, которое описывает отношения соподчинения между конкретными элементами системы управления, и дерево имен, которое определяет иерархические имена объектов в системе.

Протокол CMIP, который является протоколом взаимодействия между агентами и менеджерами системы управления OSI, позволяет с помощью одной команды воздействовать сразу на группу агентов, применив такие опции, как обзор и фильтрация.