Трудно е да се отговори на следния въпрос: „Колко акаунта за услуги имате във вашата среда?“. Още по-труден е въпросът: „Знаете ли какво правят тези акаунти?“. А най-трудният вероятно е: „Ако някой от вашите служебни акаунти бъде компрометиран и използван за достъп до ресурси, ще можете ли да откриете и спрете това в реално време?“.

Тъй като повечето екипи за идентификация и сигурност биха дали отрицателен отговор, не е чудно, че едно от непосредствените действия, които днешните нападатели извършват след първоначалното компрометиране на крайната точка, е издирването на неподозирани служебни акаунти. И още по-малко е чудно, че в повечето случаи те успяват да намерят такъв и да го използват, за да се разпространят в цялата среда, като се забелязват едва когато е твърде късно – след като работните станции и сървърът са криптирани от рансъмуер или чувствителните данни са откраднати.

В тази статия разгръщаме причините, които са довели до превръщането на служебните акаунти в една от най-опасните слабости в средата на Active Directory, обясняваме как силата на тази слабост подхранва атаките с ransomware.

Акаунти за услуги: Потребителски акаунти, които не са свързани с реално лице и се използват за комуникация между машини

Потребителските акаунти са един от основните градивни елементи в корпоративната среда. Интуитивно ние свързваме потребителските акаунти с реални хора. Съществуват обаче и потребителски акаунти, които не са свързани с нито едно човешко същество. Тези акаунти се създават за комуникация между машини, автоматизиране на повтарящи се задачи и други задачи, които трябва да се извършват във фонов режим без човешка намеса. Те обикновено са известни като „служебни акаунти“ и освен че не са свързани с реален човек, са идентични във всички аспекти с другите, „свързани с хора“ потребителски акаунти.

Тези служебни акаунти се създават по два основни начина. Първият е ИТ персонал, който определя, че определена хигиена, мониторинг или друга задача би било по-добре да се извърши по автоматизиран начин, отколкото ръчно. Вторият начин е в хода на инсталиране на корпоративен софтуер на място. В този случай някои служебни акаунти се създават съгласно инструкциите на конкретния софтуер – в хода на самата инсталация – и имат за задача да сканират, да разпространяват актуализации и други подобни задачи за поддръжка.

Предизвикателства пред сигурността на акаунта за услуги: Невидими, високопривилегировани и изключително трудни за защита

Нека разберем какво прави акаунтите за услуги и  ненаблюдавана повърхност за атаки:

• Липсата на видимост: Колкото и странно да звучи, в рамките на инфраструктурата за идентификация няма инструмент, който автоматично да филтрира служебните акаунти от общия брой потребители. Не съществува и автоматизиран процес на документиране, който да показва създаването на служебен акаунт.
• Високи привилегии за достъп: Тъй като сервизните акаунти се създават за комуникация между машините, от само себе си се разбира, че те трябва да притежават необходимите привилегии за достъп до всички тези машини, което означава, че те са административен потребител, не по-различен от всеки ИТ администратор.
• Липса на PAM защита: Обичайната практика е административните акаунти да бъдат защитени, като се поставят в хранилището на PAM решение и се редуват паролите им. Този подход обаче не може да се приложи към служебните акаунти, тъй като техните пароли са твърдо кодирани в скриптовете, които изпълняват техните задачи. По този начин всяко завъртане на паролата би обезсилило паролата в скриптовете, което би попречило на служебния акаунт да получи достъп до целевия ресурс и впоследствие би прекъснало всеки процес, който разчита на задачата на служебния акаунт.

Как атакуващите използват  акаунтите за услуги за странично придвижване и разпространение на рансъмуер

Нека приемем, че атакуващият ransomware е компрометирал успешно крайна точка (работната станция или сървърът са същите в този случай). Това, разбира се, е само първата стъпка. Следващата стъпка е да започне да сканира средата, за да открие потребителски акаунти за компрометиране, които биха позволили на противника да се придвижи странично в средата и да заложи полезния товар на ransomware във възможно най-много машини.

Но какъв акаунт да изберете? Противникът се нуждае от акаунт, който е достатъчно привилегирован, за да има достъп до други сървъри и работни станции. Но това трябва да бъде и акаунт, който може да се използва под радара, без да привлича нежелано внимание.

Ето защо служебните акаунти са най-добрата цел за компрометиране. Атакуващите знаят, че има голяма вероятност никой да не търси този акаунт, или още по-добре – никой дори да не знае, че този акаунт съществува. Възможно е да е бил създаден преди години от администратор, който междувременно е напуснал компанията, без да си направи труда да изтрие създадените от него служебни акаунти.

Пример за атака с акаунт за услуги № 1: Модел на атака с рансъмуер, използващ компрометиран акаунт за услуги на Microsoft Exchange Server

Диаграмата по-долу показва примерна атака – една от многото, които сме анализирали през последната година – в която противникът е използвал компрометиран акаунт за услуги на Exchange Server за първата част от страничното си придвижване, последвано от допълнително компрометиране на администраторски пълномощия.

Вижте подробности за всеки етап по-долу:

• Първоначален достъп: Компрометиране на Exchange Server чрез използване на уязвимостта Proxyshell
• Компрометиране на пълномощията: получаване на пълномощията на потребител от домейна
• Странично придвижване 1: използване на служебните акаунти за достъп до допълнителни машини
• Компрометиране на пълномощия 2: получаване на пълномощия на потребител администратор
• Странично движение 2: Използване на идентификационните данни на администратора за масово разпространение в множество машини
• Изпълнение на зловреден софтуер: Поставяне и изпълнение на ransomware на машините

Пример за атака на акаунт за услуги № 2: странично движение в хибридната среда на Uber

Известната атака срещу Uber, която се проведе преди няколко месеца, включваше значително използване на компрометиране и използване на акаунт за услуги. В този случай ставаше въпрос за служебен акаунт, който има достъп до наличния PAM. Нападателите намериха скрипта с данните за служебния акаунт в споделен мрежов диск и го използваха, за да извлекат паролите на множество ресурси от хранилището на PAM.

Вижте подробности за всеки етап по-долу:

• Първоначален достъп: Бомбардиране на MFA за получаване на достъп чрез VPN.
• Компрометиране на пълномощията 1: Кражба на пълномощията на акаунта за услуги от споделена папка.
• Компрометиране на удостоверения 2: Кражба на тайни от секретния сървър на PAM.
• Странично придвижване: Използване на тайни за достъп до различни чувствителни ресурси