Автор admin 
Ця стаття — перша у серії «Анатомія атаки», де ми крок за кроком розбираємо реальний інцидент. Усі дані анонімізовано, але технічні деталі — справжні. Сьогодні говоримо про найважливіше: чому атака взагалі стала можливою.
Читайте также: Поліна Василина Особисте Життя: ключевые моменты биографии и карьеры
Відчинені двері: RDP назовні через маршрутизатор
Коли ми проаналізували конфігурацію периметрового маршрутизатора MikroTik, знахідка виявилась шокуючою, хоча й передбачуваною. На пристрої було налаштовано 8 правил dst-nat, які прокидали протокол RDP безпосередньо на внутрішні хости через нестандартні порти(13389, 23389, 33389 тощо). Фактично — 8 комп’ютерів компанії були доступні з будь-якої точки світу через віддалений робочий стіл.
Жодного VPN. Жодної двофакторної автентифікації. Жодного обмеження за IP-адресою джерела.
При цьому адміністратори компанії щиро вважали, що «ми за NAT-ом, нас не видно». Це поширена помилка: NAT — це механізм трансляції адрес, а не засіб захисту. Якщо ви самі налаштували прокидання портів — ви самі відчинили двері.
Контролер домену, якому 17 років
Серцем мережі був контролер домену Active Directory на базі Windows Server 2008 SP2 — операційної системи, підтримку якої Microsoft припинила ще у 2020 році. Ця система вразлива до цілої низки критичних експлойтів: Zerologon(CVE-2020−1472), EternalBlue, PrintNightmare — кожен з яких дозволяє отримати повний контроль навіть без пароля.
Ми провели аудит домену за допомогою інструменту PingCastle. Результат — 100 балів зі 100. Це не оцінка якості. Це шкала ризику, де 100 — найгірший можливий результат.
Серед знахідок: 52 облікові записи з правами адміністратора домену(при нормі 3−5), відсутність політики зміни паролів для привілейованих акаунтів, увімкнений протокол SMBv1 та десятки робочих станцій на Windows 7 і навіть Windows XP.
Ідеальний обліковий запис для зловмисника
Для горизонтального переміщення мережею зловмисник обрав сервісний обліковий запис системи 1С: Підприємство. Чому саме його? Бо цей акаунт мав права Domain Admin, за своєю природою підключався до багатьох машин одночасно(що маскує підозрілу активність) і, найголовніше, за ним не стояла жодна конкретна людина, яка могла б помітити щось незвичне.
Читайте также: Лотерейний квиток за $30 млн: як робота в OpenAI зробила сотні людей мільйонерами
Пароль цього акаунту ніколи не змінювався. Акаунт мав дозвіл на інтерактивний вхід по RDP, хоча для роботи сервісу 1С це зовсім не потрібно.
Чому жертва нічого не бачила
Централізоване збирання журналів подій(логів) у компанії не було налаштовано. Усі логи зберігались локально на кожній машині. Зловмиснику достатньо було очистити один файл на контролері домену — і вся історія автентифікацій зникла. Що він і зробив.
Без SIEM, без пересилання логів на захищене сховище, без моніторингу — компанія фактично працювала наосліп. Коли ми почали розслідування, більшість уражених систем вже були перевстановлені IT-командою. Ключовий сервер, з якого зловмисник координував усю атаку, було перевстановлено повністю — це найбільша втрата доказів в цьому кейсі.
Що з цього винести
Цей інцидент не став наслідком якоїсь витонченої хакерської операції. Зловмисники не використовували zero-day вразливостей чи спеціалізованих C2-фреймворків на кшталт Cobalt Strike. Вони просто скористались тим, що їм дали: відкритим RDP, застарілою ОС, надпривілейованим сервісним акаунтом та відсутністю моніторингу.
Перевірте просто зараз: чи є у вашій мережі прокидання RDP на зовнішній периметр? Скільки акаунтів мають права Domain Admin? Коли востаннє змінювались паролі сервісних облікових записів? Чи зберігаються ваші логи деінде, окрім самих серверів?
Якщо хоча б одна відповідь вас непокоїть — час діяти до того, як цю відповідь знайде хтось інший.
Наступна стаття серії: «48 годин усередині мережі: що робить зловмисник перед шифруванням» — покрокова хронологія дій BlackField від першого входу до запуску шифрувальника.
Читайте также: Сяйво космічного кальмара. Телескоп Джеймс Вебб зазирнув у серце галактики Мессьє 77
Автор: команда DFIR, SHERIFF Кібербезпека