Kerberos

Rubeus это инструмент, совместимый с С# версии 3.0 (.NET 3.5), предназначенный для проведения атак на компоненты Kerberos на уровне трафика и хоста. Может успешно работать как с внешней машины (хостовой), так и внутри доменной сети (клиентского доменного хоста).

С помощью данного инструмента можно реализовать следующие атаки:

1. Kerberos User Enumeration and Brute Force
2. Kerberoast
3. AS-REP Roasting
4. Silver Ticket
5. Golden Ticket
6. Overpass The Hash/Pass The Key (PTK)
7. Pass-The-Ticket / Ticket Dump
8. Unconstrained Delegation
9. Constrained Delegation

О том, почему возможны эти атаки, а также о механизмах их реализации и принципах работы Kerberos написано уже достаточное количество публикаций (например, коллеги из Инфосистемы Джет писали хороший материал с разбором), поэтому в данной статье я сделаю упор на то, как реализовать первые пять атак из списка выше с помощью Rubeus (остальные четыре в следующей части).

А пока немного терминологии:

Kerberos сетевой протокол аутентификации, который предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними.
Клиентский компьютер компьютер, которому требуется доступ к службе, поддерживающей аутентификацию Kerberos.
Сервисный компьютер сервер/компьютер, на котором размещается Сервис, поддерживающий аутентификацию Kerberos KDC (Центр распространения ключей).
SPN (имя участника службы) это имя службы, связанной с учетной записью пользователя, в которой будет работать служба. Эта привязка выполняется в LDAP путем установки значения для атрибута servicePrincipalName. SPN имеет формат вида SERVICE/hostname
Ticket (билет) зашифрованный пакет данных, который выдается доверенным центром аутентификации KDC.

Когда пользователь выполняет первичную аутентификацию, после успешного подтверждения его подлинности, KDC выдает первичное удостоверение пользователя для доступа к сетевым ресурсам Ticket Granting Ticket (TGT).



В дальнейшем, при обращении к отдельным ресурсам сети пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу Service Ticket (TGS).



Итак, смоделируем ситуацию, когда нам удалось получить доступ к домену AD, но по каким-либо причинам нет возможности для тестирования использовать собственную хостовую ОС (Kali, BackTrack и т.п.), поэтому тестировать наш домен MEOW.LOCAL мы будем изнутри с доменной клиентской машины Windows 10. Использовать будем уже скомпилированную версию Rubeus из состава Ghostpack-CompiledBinaries.

С помощью VMware создадим виртуальные машины на операционных системах Windows Server 2016 (контроллер домена), Windows 10 (доменная машина), развернем домен meow.local и присвоим статичные IP-адреса машинам:

контроллер домена DC-16 (192.168.0.201);
доменная машина Barscomp (192.168.0.202).

В Active Directory создадим доменных пользователей ADadmin, Barsik, User1, User2.

В принципе, на этом пока всё, давайте проверим.

KERBEROS BRUTE-FORCE

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

Следующая команда выполнит перебор пользователей по словарю users.txt и выполнит брутфорс паролей по словарю pass.txt



В результате мы получили существующих пользователей и пароли, так же Rubeus любезно получил тикеты (TGT) и сохранил их на нашем компьютере. Перейдём к более продвинутым техникам атак на протокол Kerberos.

KERBEROASTING

Для проведения данной атаки необходимо создать учётную запись у нас это будет iis_svc, отвечающая за взаимодействие с IIS-сервисом на сервере DC-16.meow.local (наш КД). Ей нужно присвоить ей атрибут SPN.

• Cоздаём сервисную учетную запись IIS
  New-ADUser -Name "IIS Service Account `
-SamAccountName iis_svc -UserPrincipalName iis_svc@meow.local `
-ServicePrincipalNames "HTTP/dc-16.meow.local `
-AccountPassword (convertto-securestring "S3rv1ce!" -asplaintext -force) `
-PasswordNeverExpires $True `
-PassThru | Enable-ADAccount
  
• Hастроим конфигурацию IIS сервера
  Import-Module WebAdministration
  
• Удаляем дефолтный вебсайт
  Remove-Item 'IIS:\Sites\Default Web Site' -Confirm:$false -Recurse

• Cоздаём новый пул приложений с использованием учётной записи IIS
  $appPool = New-WebAppPool -Name dc-16.meow.local
$appPool.processModel.identityType = 3
$appPool.processModel.userName = MEOW\iis_svc
$appPool.processModel.password = S3rv1ce!
$appPool | Set-Item


• Создаём новый вебсайт и включаем проверку подлинности Windows
  $WebSite = New-Website -Name dc-16.meow.local -PhysicalPath C:\InetPub\WWWRoot -ApplicationPool ($appPool.Name) -HostHeader dc-16.meow.local

Set-WebConfigurationProperty -Filter /system.WebServer/security/authentication/anonymousAuthentication `
-Name enabled -Value $false -Location $Fqdn

Set-WebConfigurationProperty -Filter /system.WebServer/security/authentication/windowsAuthentication `
-Name enabled -Value $true -Location $Fqdn

Set-WebConfigurationProperty -Filter /system.webServer/security/authentication/windowsAuthentication `
-Name useAppPoolCredentials -Value $true -Location $Fqdn


Следующая команда выведет список всех SPNов в домене


Как видно из скриншота, пользователь iis_svc (IIS Service Account) имеет SPN HTTP/dc-16.meow.local.

Продолжаем наш эксперимент. Что же происходит, когда пользователь со своей доменной машины обращается к вебсайту IIS сервиса:
на доменной машине Barscomp запустим захват пакетов в Wireshark и через любой бразуер обратимся по адресу dc-16.meow.local;
так как мы включили проверку подлинности Windows, то появится такое окно, где требуется ввести данные доменной учётной записи пользователя:



проходим аутентификацию, попадаем на вебсайт, но это нас не интересует, посмотрим, что за это время успел поймать Wireshark:



первые два пакета AS-REQ и AS-REP являются способом, которым пользователь аутентифицируется с помощью KDC и извлекает TGT. Наибольший интерес представляют пакеты TGS-REQ и TGS-REP.

Рассмотрим содержимое пакета TGS-REQ:



Здесь мы видим, что посылается запрос для имени участника службы (SPN) HTTP/dc-16.meow.local, связанного с учетной записью iis_svc.

В пакете TGS-REP возвращается билет TGS, который зашифрован с использованием пароля учетной записи meow.local\iis_svc. Соответственно, расшифровав данный билет, мы получим пароль сервисной учетной записи. Попробуем на практике.



Давайте воспользуемся инструментом, которому посвящена данная статья (если кто забыл это Rubeus).

Итак, для проведения этой атаки используется экшн kerberoast, добавив флаг /stats, мы можем выполнить проверку на наличие пользователей с установленным SPN, уязвимых к атаке данного типа.



Теперь произведем атаку на учётную запись, использующую RC4 шифрование, а затем установим для неё AES-128/AES-256 шифрование и попробуем ещё раз.

Итак, под учетной записью meow.local/Barsik (шифрование RC4) запускаем рубеус командой Rubeus.exe kerberoast:



В результате мы получили хэш TGS (зашифрованный по алгоритму RC4) для учетной записи iis_svc.

Включим AES шифрование:



Повторим:



Мы также получили TGS, только зашифрованный по алгоритму AES-128/AES-256

Оба эти хэша ломаются одинаково хорошо утилитами hashcat и JohnTheRipper







Обратите внимание на тип хэша в данной атаке Kerberos 5 TGS-REP etype 23

ASREPRoast

Для начала немного поговорим о предварительной аутентификации Kerberos. При обычных операциях в среде Windows Kerberos клиент отправляет в KDC запрос (пакет AS-REQ), содержащий временную метку (timestamp), зашифрованную хэшем пароля пользователя. Эта структура в пакете называется PA-ENC-TIMESTAMP и встроена в PA-DATA (данные предварительной авторизации), более подробно описано на странице 60 RFC4120 и используется в Kerberos версии 5. Затем KDC расшифровывает временную метку, что бы проверить валидность пользователя, отправившего AS-REQ, а затем возвращает AS-REP и продолжает обычные процедуры аутентификации.

В AS-REP сам билет зашифрован сервисным ключом (в данном случае хэшем krbtgt), зашифрованная часть подписывается паролем пользователя, для которого мы отправляем AS-REQ.

В современных средах Windows все учетные записи пользователей требуют предварительной проверки подлинности Kerberos, но, что интересно, по умолчанию, Windows сначала пытается выполнить обмен AS-REQ/AS-REP без предварительной проверки подлинности (не отправляя зашифрованную метку времени):



Это происходит из-за того, что клиент заранее не знает поддерживаемые типы шифрования (etypes), подробно описано в разделе 2.2 RFC6113.

Данная атака возможна, если учетной записи пользователя разрешена аутентификация без предварительной проверки подлинности Kerberos. Мы можем отправить AS-REQ для пользователя, у которого отключена предварительная проверка подлинности, и сразу получить AS-REP хэш, расшифровав который получим пароль пользователя.

Здесь важно то, что атакующему для проведения данной атаки, в отличии от Kerberoasting, пароль учетной записи не требуется, только валидные имена пользователей домена.



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





Есть! Мы получили AS-REP хэш, сломаем его через hashcat и JTR.







Обратите внимание, здесь я указываю хэшкату тип хэша 18200 (в Kerberoast был 13100), который означает что ломать надо хэш Kerberos 5 AS-REP etype 23.

SILVER TICKET

Суть данной атаки в том, чтобы подделать TGS для скомпрометированной службы и получить максимальные права на этом сервисе, при этом KDC здесь не принимает никакого участия. Для реализации данной атаки необходимо знать NTLM-хэш пароля учетной службы (в нашем примере meow.local\iis_svc из примера с Kerberoasting). Атакующий может создать блок данных, соответствующий TGT-REP, вот упрощенный пример поддельного билета:

realm: meow.local
sname: http\dc-16.meow.local
enc-part: Зашифровано скомпрометированным NTLM-хэшем
key: 0x379DC4FA152BA1C Произвольный ключ сеанса
crealm: meow.local
cname: BadCat
authtime: 2050/01/01 00:00:00 Срок действия билета
authorization-data: поддельный PAC, с необходимыми правами доступа к сервису

Стоит учитывать, что PAC имеет двойную подпись: первая подпись использует секрет учетной записи службы, а вторая использует секрет контроллера домена (секрет учетной записи krbtgt). Атакующий знает только секрет учетной записи службы, поэтому вторую подпись он подделать не может. Однако когда сервис получает этот билет, он обычно проверяет только первую подпись. Это связано с тем, что некоторым учетным записям служб предоставлена привилегия действовать как часть операционной системы (подробнее тут ). Для таких служб Silver Ticket будет работать, даже если пароль krbtgt будет изменен, но пока не изменится пароль учетной записи самой службы.

Непосредственно с помощью Rubeus создать Silver Ticket не получится, но это можно сделать с помощью Mimikatz.



SID идентификатор пользователя (получен командой whoami /user);
Domain наш домен meow.local;
ID желаемый идентификатор безопасности (1001 в нашем случае соответствует для учетной записи Adadmin, имеющей права администратора);
Target атакуемый хост с запущенным скомпрометированным сервисом;
Service атакуемый сервис (у нас HTTP);
RC4 NTLM-хэш пароля учётной записи meow.local\iis_svc (учетная запись службы);
User имя пользователя (может быть любым).
Mimikatz сохранит поддельный TGS в файл. Далее, командой klist.exe проверим наличие действующих билетов, с помощью Rubeus подгрузим поддельный билет (в примере файл silver.kirbi) в текущую сессию пользователя, ещё раз проверим klist и наконец отправим веб-запрос на dc-16.meow.local.



Авторизация прошла успешно и мы получили двухсотый ответ, заглянем в логи на dc-16.



Видим, что был произведен вход в систему под учетной записью BadCat (в домене такой учетки нет) с привилегиями доменного администратора Adadmin, о чем свидетельствует ИД безопасности, а точнее последние 4 цифры 1001.

GOLDEN TICKET

Эта атака напоминает серебряный билет, только атакующий создает TGT с использованием NTLM-хэша учетной записи krbtgt. Преимущества золотого билета в том, что он даёт возможность получения доступа к любому сервису или любому хосту внутри домена.

NTLM-хэш учетной записи krbtgt можно получить из процесса lsass, файла NTDS.dit или через атаку DCSync, но потребуются административные права.

С помощью Mimikatz создадим Golden ticket:



Здесь я использовал идентификатор безопасности (id) 500, чтобы получить права администратора системы (можно указать любой другой), NTLM-хэш (rc4) учетной записи krbtgt и пользователя VeryBadCat.

Проверим список действующих тикетов в сессии, добавим золотой, проверим и подключимся к КД, используя PsExec.







С таким билетом открыты любые доменные двери =)

На этом заканчиваю первую часть статьи, посвященную инструменту Rubeus. В целом, инструмент с большинством задач справляется и определенно найдет своих поклонников, но лично мне всё-таки удобнее использовать утилиты из состава Impacket, хотя пополнить свой арсенал и уметь им грамотно работать никогда лишним не будет =).

А в следующей части разберем ещё несколько техник захвата и продвижения по AD с помощью Rubeus.

Всем добра, не болейте)

Всем привет!

Это вторая часть статьи про возможности инструмента проведения атак на протокол Kerberos Rubeus. Первую можно прочитать тут. В этот раз мы рассмотрим, как с помощью данного инструмента возможно реализовать следующие атаки:

Overpass The Hash/Pass The Key (PTK);
Pass The Ticket;
Unconstrained Delegation;
Constrained Delegation.

О том, почему возможны эти атаки, какие механизмы их реализации существуют, какой принцип лежит в основе работы Kerberos, написано уже много (например, коллеги из Инфосистемы Джет опубликовали хорошую статью с разбором), поэтому в своем материале я сделаю упор на реализацию атак с помощью Rubeus.

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



На этом небольшое лирическое отступление закончено, вернемся к основной части.
Тестовый стенд для проведения атак остался без изменений с момента выхода первой части статьи .

Overpass The Hash/Pass The Key (PTK)

Материал из Википедии свободной энциклопедии

Атака Pass-the-hash один из видов атаки повторного воспроизведения. Она позволяет атакующему авторизоваться на удалённом сервере, аутентификация на котором осуществляется с использованием протокола NTLM или LM.

Но что делать, если в сети отключена аутентификация по протоколам NTLM или LM и используется только аутентификация Kerberos, а у вас есть хэш пароля? Здесь в игру вступает Overpass-the-hash с помощью имеющегося хэша пароля пользователя Rubeus может запросить билет TGT для данной учетной записи.

Вот доменный пользователь Barsik решил изучить вопросы информационной безопасности, где-то раздобыл хэш пароля администратора домена ADadmin, скачал Rubeus, прочитал умных статей и пробует применить это на практике.



Видим, что кэшированных билетов у него нет, как и нет доступа к контроллеру домена DC-16.meow.local, но дальше Barsik запускает Rubeus с экшеном asktgt и аргументами /domain, /user, /rc4, /ptt, чтобы на основании имеющегося хэша пароля учетной записи ADadmin получить валидный TGT билет, аргумент /ptt сразу подгрузит полученный билет в текущую сессию пользователя Barsik.



Билет получен и загружен, Barsik пробует ещё раз авторизоваться на контроллере домена как Adadmin.



И на этот раз у него это успешно получается.

Pass The Ticket (PTT)

Данная атака похожа на Overpass-the-hash/Pass-the-key, атакующий старается получить билет доменного пользователя (желательно имеющего максимальные привилегии в домене) и загрузить его в текущую сессию. Один из способов получения TGT билетов дамп билетов локально на текущей доменной машине из процесса lsass.exe (Local Security Authentication Server). Чтобы это сделать, необходимо иметь привилегии локального администратора, а лучше NT AUTHORITY/SYSTEM. Rubeus может выгрузить билеты, хранящиеся в lsass, с помощью экшена dump, а экшн triage покажет, какие билеты хранятся в системе на данный момент.





Rubeus выгружает билеты из lsass в кодировке base64, при этом в самом инструменте есть заметка, как сохранить полученный base64 билет в формате .kirbi.



Сохраним и импортируем билет в текущую сессию пользователя.



Как видно из скриншота, тикет ADadmin успешно загружен и мы можем посмотреть содержимое диска C на контроллере домена DC-16.meow.local от имени ADadmin.

Unconstrained Delegation

Unconstrained Delegation (неограниченное делегирование) это привилегия в домене, которая может быть предоставлена учетным записям пользователей или компьютеров. Она позволяет учетной записи проходить проверку подлинности на сервисе в сети от имени другой учетной записи.

Вот теперь пришло время немного подкрутить тестовый стенд и включить неограниченное делегирование: дадим привилегию неограниченного делегирования компьютеру BARSCOMP.



Один из этапов проведения тестирования безопасности домена Active Directory поиск учетных записей с включенным делегированием, обычно для этих целей используют Powerview, но можно и вручную, используя стандартный модуль ActiveDirectory.



Для проведения данной атаки я воспользуюсь Printer Bug, который подробно описал Lee Christensen из SpecterOps. Любой прошедший проверку пользователь может удаленно подключиться к серверу печати контроллера домена и запросить обновление новых заданий на печать, сказав ему отправить уведомление учетной записи с неограниченным делегированием. Lee Christensen написал приложение SpoolSample, которое производит обращение к службе печати на КД по протоколу MS-RPRN.

На компьютере, с которого будет проводится атака (BARSCOMP.meow.local), необходимо запустить Rubeus в режиме мониторинга, используя экшн monitoring. Данный режим требует привилегий NT ATHORITY/SYSTEM и слушает новые билеты TGT/TGS в процессе lsass. Я установлю аргументом /interval:1 (в секундах) интервал опроса lsass на наличие новых билетов, и аргументом /filteruser:DC-16$ установлю фильтр отображения только билетов пользователя DC-16$.



Rubeus запущен, параллельно в другой сессии запускаю SpoolSample.exe с аргументами dc-16.meow.local (атакуемая машина) и barscomp.meow.local (наш слушающий хост).



Посмотрим, что намониторил Rubeus.



Пойман TGT билет учетной записи контроллера домена. Теперь можно, используя уже известную Pass-the-ticket атаку, импортировать билет и с помощью mimikatz провести атаку DCSync, чтобы получить NTLM-хэш учетной записи krbtgt (а как вы уже знаете из первой части статьи, хэш этой учетной записи можно использовать для создания Golden Ticket и полного захвата домена AD).

Обратите внимание, что Rubeus понимает билеты как в виде .kirbi файла, так и в строке закодированной base64.

Сonstrained Delegation

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

Создадим нового доменного пользователя Backup с паролем B@ckup1234, присвоим ему SPN для службы cifs на контроллере домена.



Теперь можно установить для этой учетной записи возможность делегирования служб ldap и cifs на контроллере домена DC-16.meow.local.



Определить учетные записи, которым разрешено ограниченное делегирование, можно также с помощью Powerview или модуля ActiveDirectory.



Зная пароль или NTLM-хэш учетной записи meow.local\Backup, с помощью Rubeus можно запросить билет TGT для неё.



Теперь, используя экшн s4u в Rubeus можно запросить TGS для пользователя, которому разрешена аутентификация на сервисе cifs\dc-16.meow.local (например, администратору домена ADadmin).



Здесь я указываю полученный ранее билет учетной записи Backup; /impersonateuser пользователя, права которого хочу получить; /domain домен, в котором всё происходит; /msdsspn /asltservice сервис, для которого нужен TGS; /ptt сразу импортировать полученный билет в текущую сессию.

Вот что происходит в Rubeus:



Здесь можно заметить, что при ограниченном делегировании включаются 2 расширения Kerberos: это S4U2self и S4U2proxy.

S4U2self позволяет участникам службы запросить специальный TGS с флагом FORWARDABLE к себе от имени конкретного пользователя. Это нужно для того, чтобы данный билет в дальнейшем мог использоваться расширением S4U2proxy.

S4U2proxy позволяет вызывающей стороне использовать этот специальный билет, чтобы запросить TGS пользователя для службы, к которой разрешено делегирование (в данном случае cifs\dc-16.meow.local). Более подробно об этом можно прочитать здесь и здесь.

В это время Rubeus уже получил финальный тикет и импортировал его в текущую сессию.



Проверим, получится ли посмотреть диск C на контроллере домена с полученным билетом.



Да, всё прошло успешно.

На этом я заканчиваю обзор на данный инструмент, в целом мне он понравился, приятный и простой в использовании, с хорошим функционалом. Надеюсь, и вы после прочтения данных статей возьмёте его на вооружение.

Спасибо за внимание, всем добра, не болейте!

Бенджамин Делпи изначально создал Mimikatz в качестве доказательства концепции, чтобы продемонстрировать Microsoft уязвимость для атак их протоколов аутентификации. Вместо этого он непреднамеренно создал один из самых широко используемых и загружаемых хакерских инструментов за последние 20 лет.
Джейк Уильямс из Rendition Infosec говорит: Mimikatz сделал для повышения безопасности больше, чем любой другой известный мне инструмент. Если защита сетей Windows ваша работа, важно быть в курсе последних обновлений Mimikatz, чтобы понимать методы, которые хакеры будут использовать для проникновения в ваши сети, и оставаться на шаг впереди.

Что такое Mimikatz?

Mimikatz это приложение с открытым исходным кодом, которое позволяет пользователям просматривать и сохранять учетные данные аутентификации, такие как тикеты Kerberos. Бенджамин Делпи продолжает руководить разработкой Mimikatz, поэтому набор инструментов работает с текущей версией Windows и включает самые современные виды атак.

Злоумышленники обычно используют Mimikatz для кражи учетных данных и повышения привилегий: в большинстве случаев программное обеспечение для защиты конечных точек и антивирусные системы обнаруживают и удаляют его. И наоборот, специалисты по тестированию на проникновение используют Mimikatz для обнаружения и тестирования уязвимостей в ваших сетях, чтобы вы могли их исправить.

Возможности Mimikatz

Первоначально Mimikatz демонстрировал, как использовать одну уязвимость в системе аутентификации Windows. Теперь же этот инструмент охватывает несколько различных видов уязвимостей. Mimikatz может выполнять следующие методы сбора учетных данных:

• Pass-the-Hash (перехват хеша): ранее Windows хранил данные аутентификации в хэше NTLM. Злоумышленники используют Mimikatz для передачи точной строки хеша на целевой компьютер для входа в систему. Злоумышленникам даже не нужно взламывать пароль, им просто нужно перехватить хеш и использовать его без какой-либо обработки. Это то же самое, что найти ключ от всех дверей дома на полу. Вам нужен один ключ, чтобы открыть любую дверь.
• Pass-the-Ticket (перехват тикета): новые версии Windows хранят данные аутентификации в конструкции, называемой тикетом (Ticket). Mimikatz предоставляет пользователю возможность передать тикет Kerberos на другой компьютер и войти в систему с помощью этого тикета. В остальном это то же самое, что и перехват и передача хеша.
• Over-Pass the Hash (Pass the Key): еще одна разновидность атаки pass-the-hash, но этот метод передает уникальный ключ для выдачи себя за пользователя, данные которого можно получить от контроллера домена.
• Kerberos Golden Ticket): это вид атаки с перехватом тикета (pass-the-ticket), но в данном случае целью является конкретный тикет для скрытой учетной записи под названием KRBTGT. Эта учетная запись шифрует все остальные тикеты.Золотой билет дает вам учетные данные администратора домена для любого компьютера в сети без срока истечения.
• Kerberos Silver Ticket: еще одна атака типа pass-the-ticket, но серебряный тикетиспользует для своих целей функцию Windows, которая упрощает использование служб в сети. Kerberos предоставляет пользователю тикет сервера выдачи разрешений (TGS), и пользователь может использовать этот тикет для входа в любые службы в сети. Microsoft не всегда проверяет тикет сервера выдачи разрешений (TGS) после его выпуска, поэтому с его помощью можно легко обойти любые меры безопасности.
• Pass-the-Cache): единственная атака, не использующая уязвимости Windows! Атака с перехватом кэша обычно аналогична атаке с перехватом билета, но в этой атаке используются сохраненные и зашифрованные данные для входа в систему Mac/UNIX/Linux.

Как скачать Mimikatz

Вы можете скачать Mimikatz с GitHub Бенджамина Делпи. Он предлагает несколько вариантов загрузки, от исполняемого файла до исходного кода, который вам нужно будет скомпилировать с Visual Studio 2010 или более новой версии.

Как использовать Mimikatz

После запуска исполняемого файла Mimikatz появится интерактивная консоль Mimikatz, в которой вы сможете запускать команды в реальном времени.

Запустите Mimikatz от имени администратора: для полноценной работы Mimikatz выберите Запуск от имени администратора, даже если вы используете учетную запись администратора.

Проверка версии Mimikatz
Существует 2 версии Mimikatz: 32-битная и 64-битная. Убедитесь, что вы используете версию, соответствующую разрядности вашей Windows. Выполните команду version из командной строки Mimikatz, чтобы получить информацию об исполняемом файле Mimikatz, версии Windows и о наличии каких-либо настроек Windows, которые могут помешать корректной работе Mimikatz.

Извлечение из памяти паролей в виде открытого текста
Модуль sekurlsa в Mimikatz позволяет выгружать пароли из памяти. Чтобы использовать команды в модуле sekurlsa, у вас должны быть права на уровне администратора или системы.

Сначала выполните команду:

mimikatz # privilege::debug 

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

mimikatz # log nameoflog.log

И, наконец, выведите все хранящиеся на этом компьютере пароли в виде незашифрованного текста:

mimikatz # sekurlsa::logonpasswords

Использование других модулей Mimikatz

Модуль шифрования открывает доступ к CryptoAPI в Windows, который позволяет перечислять и экспортировать сертификаты и их закрытые ключи, даже если они отмечены как неэкспортируемые.
Модуль Kerberos обращается к API Kerberos, поэтому вы можете поэкспериментировать с этой функциональностью, извлекая тикеты Kerberos и управляя ими.
Модуль служб позволяет запускать, останавливать, отключать и выполнять другие операции со службами Windows.
И, наконец, команда coffee выводит ASCII-изображение кофе, ведь кофе нужен всем. :)

Mimikatz способен на гораздо большее Если вы интересуетесь тестированием на проникновение или просто хотите покопаться во внутреннем устройстве проверки подлинности Windows, ознакомьтесь со ссылками ниже.

• Руководство по тестированию на проникновение в средах Active Directory
• Неофициальное руководство по Mimikatz и справочник команд
• Koadic: вредоносная программа LOL и сервер контроля и управления на Python
• Официальная энциклопедия Mimikatz

Хотите увидеть Mimikatz в действии и узнать, как Varonis защищает вас от проникновения? Присоединяйтесь к нашему бесплатному интерактивному практическому семинару по кибератакам и посмотрите, как инженеры Varonis проводят кибератаку в нашей лаборатории безопасности.

Что такое single sign-on?

Технология единого входа (Single sign-on SSO) метод аутентификации, который позволяет пользователям безопасно аутентифицироваться сразу в нескольких приложениях и сайтах, используя один набор учетных данных.

Как работает SSO?

SSO базируется на настройке доверительных отношений между приложением, известным как провайдер услуг, и системой управления доступами, например, OneLogin. Такие доверительные отношения часто базируются на обмене сертификатом между системой управления доступами и провайдером услуг. Такой сертификат может использоваться, чтобы обозначить идентификационную информацию, которая отправляется от системы управления доступами провайдеру услуг, таким образом провайдер услуг будет знать, что информация поступает из надежного источника. В SSO идентификационные данные принимают форму токенов, содержащих идентификационные значения информации о пользователе такие, как email или имя пользователя.

Порядок авторизации обычно выглядит следующим образом:

1. Пользователь заходит в приложение или на сайт, доступ к которому он хочет получить, то есть к провайдеру услуг.
2. Провайдер услуг отправляет токен, содержащий информацию о пользователе (такую как email адрес) системе SSO (так же известной, как система управления доступами), как часть запроса на аутентификацию пользователя.
3. В первую очередь система управления доступами проверяет был ли пользователь аутентифицирован до этого момента. Если да, она предоставляет пользователю доступ к приложению провайдера услуг, сразу приступая к шагу 5.
4. Если пользователь не авторизовался, ему будет необходимо это сделать, предоставив идентификационные данные, требуемые системой управления доступами. Это может быть просто логин и пароль или же другие виды аутентификации, например одноразовый пароль (OTP One-Time Password).
5. Как только система управления доступами одобрит идентификационные данные, она вернет токен провайдеру услуг, подтверждая успешную аутентификацию.
6. Этот токен проходит сквозь браузер пользователя провайдеру услуг.
7. Токен, полученный провайдером услуг, подтверждается согласно доверительным отношениям, установленным между провайдером услуг и системой управления доступами во время первоначальной настройки.
8. Пользователю предоставляется доступ к провайдеру услуг.

Если пользователь попробует получить доступ к другому сайту, то понадобится настройка подобных доверительных отношений в соответствии с методом SSO. Порядок аутентификации в этом случае будет состоять также из вышеизложенных шагов.

Что такое токен в контексте SSO?

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

Является ли технология SSO безопасной?

Ответом на этот вопрос будет "в зависимости от ситуации".

Есть несколько причин, по которым стоит внедрить SSO. Метод единого входа может упростить работу с логином и паролем, как для пользователя, так и для администратора. Пользователям больше не придется держать в голове все учетные данные, теперь можно просто запомнить один более сложный пароль. SSO позволяет пользователям намного быстрее получить доступ к приложениям.

SSO также сокращает количество времени, потраченного на восстановление пароля с помощью службы поддержки. Администраторы могут централизованно контролировать такие факторы, как сложность пароля и многофакторную аутентификацию (MFA). Администраторы также могут быстрее отозвать привилегии на вход в систему, если пользователь покинул организацию.

Однако, у SSO есть некоторые недостатки. Например, вероятно, вам захочется, чтобы определенные приложения оставались заблокированы/менее открыты к доступу. По этой причине важно выбрать то решение SSO, которое, к примеру, даст вам возможность запросить дополнительный фактор проверки аутентификации прежде, чем пользователь авторизуется или оградит пользователей от доступа к определенным приложениям пока не обеспечено безопасное соединение.

Как внедрить SSO?

Особенности внедрения SSO могут отличаться с учетом того, с каким именно решением SSO вы работаете. Но вне зависимости от способа, вам нужно точно знать какие цели вы преследуете. Убедитесь, что вы ответили на следующие вопросы:

• С какими типами пользователей вы работаете и какие у них требования?
• Вы ищете локальное или облачное решение?
• Возможен ли дальнейший рост выбранной программной платформы вместе с вашей компанией и ее запросами?
• Какие функции вам необходимы, чтобы убедиться в том, что процесс авторизации проходят только проверенные пользователи? MFA, Adaptive Authentication, Device Trust, IP Address Whitelisting, и т.д?
• С какими системами вам необходимо интегрироваться?
• Нужен ли вам доступ к программному интерфейсу приложения (API)?

Что отличает настоящую SSO от хранилища или менеджера паролей?

Важно понимать разницу между SSO (Технологией единого входа) и хранилищем или менеджерами паролей, которые периодически путают с SSO, но в контексте Same Sign-On что означает такой же/одинаковый вход, а не единый вход (Single Sign-On). Говоря о хранилище паролей, у вас может быть один логин и пароль, но их нужно будет вводить каждый раз при переходе в новое приложение или на новый сайт. Такая система попросту хранит ваши идентификационные данные для других приложений и вводит их когда это необходимо. В данном случае между приложением и хранилищем паролей не установлены доверительные отношения.

С SSO, после того, как вы вошли в систему, вы можете получить доступ ко всем одобренным компанией сайтам и приложениям без необходимости авторизовываться снова. Это включает в себя как облачные, так и локально установленные приложения, часто доступные через сам сервис SSO (также известный, как сервис авторизации).

В чем разница между программным обеспечением единого входа и решением SSO?

Изучая доступные варианты единого входа, вы можете увидеть, что их иногда называют программным обеспечением единого входа, а не решением единого входа или провайдером единого входа. Часто разница состоит лишь в том, как позиционируют себя компании. Фрагмент программного обеспечения предполагает локальную установку. Обычно это то, что разработано для определенного набора задач и ничего более. Программный продукт предполагает, что есть возможность расширяться и кастомизировать потенциальные возможности исходного варианта. Провайдер будет отличным вариантом, чтобы обратиться к компании, которая производит или пользуется программным продуктом. Например, OneLogin в качестве провайдера SSO.

Бывают ли разные типы SSO?

Когда мы говорим о едином входе (SSO), используется множество терминов:

• Federated Identity Management (FIM)
• OAuth (OAuth 2.0 в настоящее время)
• OpenID Connect (OIDC)
• Security Access Markup Language (SAML)
• Same Sign On (SSO)

На самом деле, SSO это часть более крупной концепции под названием Federated Identity Management, поэтому иногда SSO обозначается, как федеративная SSO. FIM просто относится к доверительным отношениям, созданным между двумя или более доменами или системами управления идентификацией. Система единого входа (SSO) это характеристика/фича, доступная внутри архитектуры FIM.

OAuth 2.0 это особая программная платформа, которая также может считаться частью архитектуры FIM. OAuth фокусируется на доверительных отношениях, предоставляя доменам идентификационную информацию пользователя.

OpenID Connect (OIDC) это уровень аутентификации, наложенный на базу OAuth 2.0, чтобы обеспечить фунциональность SSO.

Security Access Markup Language (SAML) это открытый стандарт, который также разработан для обеспечения функциональности SSO.

Система Same Sign On, которую часто обозначают, как SSO, на самом деле, не похожа Single Sign-on, т.к не предполагает наличие доверительных отношений между сторонами, которые проходят аутентификацию. Она более привязана к идентификационным данным, которые дублируются и передаются в другие системы когда это необходимо. Это не так безопасно, как любое из решений единого входа.

Также существуют несколько конкретных систем, которые стоит упомянуть, говоря о платформе SSO: Active Directory, Active Directory Federation Services (ADFS) и Lightweight Directory Access Protocol (LDAP).

Active Directory, который в настоящее время именуется, как Active Directory Directory Services (ADDS) это централизованная служба каталогов Microsoft. Пользователи и ресурсы добавляются в службу каталогов для централизованного управления, а ADDS работает с такими аутентификационными протоколами, как NTLM и Kerberos. Таким образом, пользователи, относящиеся к ADDS могут аутентифицироваться с их устройств и получить доступ к другим системам, интегрированным с ADDS. Это и есть форма SSO.

Active Directory Federation Services (ADFS) это тип управления федеративной идентификацией (Federated Identity Management system), которая также предполагает возможность Single Sign-on. Он также поддерживает SAML и OIDC. ADFS преимущественно используется для установления доверительных отношений между ADDS и другими системами, такими как Azure AD или других служб ADDS.

Протокол LDAP (Lightweight Directory Service Protocol) это стандарт, определяющий способ запроса и организации информационной базы. LDAP позволяет вам централизованно управлять такими ресурсами, как пользователи и системы. LDAP, однако, не определяет порядок авторизации, это означает, что он не устанавливает непосредственный протокол, используемый для аутентификации. Но он часто применяется как часть процесса аутентификации и контроля доступа. Например, прежде, чем пользователь получит доступ к определенному ресурсу, LDAP сможет запросить информацию о пользователе и группах, в которых он состоит, чтобы удостовериться, что у пользователя есть доступ к данному ресурсу. LDAP платформа на подобие OpenLDAP обеспечивает аутентификацию с помощью аутентификационных протоколов (например, Simple Authentication и Security Layer SASL).

Как работает система единого входа как услуга?

SSO функционирует также, как и многие другие приложения, работающие через интернет. Подобные OneLogin платформы, функционирующие через облако, можно отнести к категории решений единого входа Software as a Service (SaaS).

Что такое App-to-App (приложение-приложение) SSO?

В заключение, возможно вы слышали о App-to-App SSO. Пока еще такой подход не является стандартным. Такое понятие больше используется SAPCloud для обозначения процесса передачи идентификационных данных пользователя из одного приложения в любое из других, состоящих в их экосистеме. В какой-то степени такой метод присущ OAuth 2.0, но хочется снова подчеркнуть, что это не стандартный протокол или метод. В настоящее время он является характерным только для SAPCloud.