Описание инцидента: Уволенный сотрудник сохранил доступ к системе и украл данные, используя старые учетные записи.
План реагирования:
Обнаружение: Заметить подозрительную активность в логах после увольнения.
Изоляция: Отключить учетную запись сотрудника.
Оповещение: Сообщить руководству.
Проверка: Проверить логи на предмет украденных данных.
Восстановление: Сменить пароли, которые мог знать сотрудник, включая сторонние сервисы [особенно если уволился администратор]
Предотвращение: Настроить процесс деактивации всех учетных данных при увольнении и ведение реестра удаленных доступов.
Что может пойти не так:
— Логи не ведутся или удалены.
— Учетка не была отключена вовремя.
— Пароли не менялись после увольнения.
— Нет списка доступов сотрудника.
— Данные уже проданы третьим лицам.
— Нет системы предотвращения утечки данных
▰▰▰▰▰▰▰▰▰▰▰▰▰▰▰ 99%
В небольшой компании «ТехноСофт», занимавшейся разработкой ПО для автоматизации бизнеса, пятничный вечер казался обычным. Менеджер по продажам — молодая симпатичная девушка с яркими рыжими волосами и в стильных очках — объявила об уходе.
Она была звездой отдела: обаятельная улыбка и умение закрывать сделки делали её незаменимой. Конкуренты переманили её, предложив лучшие условия. В тот вечер она угостила коллег пиццей, попрощалась и ушла, унося в рюкзаке ноутбук и пачку визиток. Команда пожелала ей удачи, а утром её учётную запись в Active Directory (AD) заблокировали. Но никто не проверил доступы к серверу через Remote Desktop Protocol (RDP) — ошибку, за которую «ТехноСофт» скоро поплатился.
Сотрудники «ТехноСофт» подключались к рабочим машинам через RDP на сервере под управлением Windows Server 2019. Логи подключений фиксировались в Event Viewer, но сисадмины их не мониторили — не было ни системы оповещений, ни ресурсов для анализа. Новичкам раздавали доступы, старые сессии не проверялись, а из-за динамических IP подсети оставались открытыми.
Сисадмины активировали перенаправление локальных дисков в настройках RDP для удобства удалённой работы, но забыли ограничить права, оставив функцию доступной всем пользователям. Менеджер по продажам знала учётные данные сотрудника отдела продаж — логин и пароль "Password123", которыми тот делился в чате для работы из дома.
Сотрудник отдела продаж не менял пароль из лени, считая, что "всё и так работает", а политика GPO требовала смены раз в 180 дней. После ухода менеджер по продажам подключалась с домашнего ноутбука через RDP под этой учёткой и копировала базы клиентов и прайсы прямо на свой компьютер через перенаправление локальных дисков — доступ не ограничивался по времени, а подозрительной активности никто не замечал.
Утечка лишила фирму клиентов
Через два месяца конкуренты начали выигрывать тендеры, предлагая условия, почти идентичные «ТехноСофт». Скидки и сроки совпадали с пугающей точностью, но с чуть большим преимуществом для клиента. Аналитики забили тревогу: «Они знают наши ходы!» Сначала это списали на случайность, но после потери крупного клиента, выбравшего конкурента с чуть меньшей ценой, в офисе заговорили о проблеме. Директор отмахнулся: «Совпадение». Однако сомнения росли.
Конкуренты получили прайсы
Спустя неделю позвонил партнёр — поставщик серверов: «Ваш бывший менеджер по продажам теперь работает у конкурентов и предложила мне скидки чуть лучше ваших». Другой клиент подтвердил: «Она знает наши текущие условия и перебила их». Начальник аналитиков созвал совещание: «Как она это делает? Её же отключили от AD!» Сисадмины переглянулись, но ничего не сказали — они могли проверить активные сессии в Remote Desktop Services, но не удосужились.
Расследование утечки данных
Проверка показала: учётка менеджера по продажам в Active Directory заблокирована. «Она не могла зайти», — заявили админы, умолчав, что другие учётки оставались активными, а логи подключений пылились без внимания. После очередного отказа клиента директор рявкнул: «Проверяйте сервер!» Сисадмины сменили пароли, но не стали копаться в Event Viewer или закрывать старые сессии — это было «слишком сложно».
RDP стал причиной утечки
Ещё один партнёр заметил: "Конкуренты, где теперь работает ваша бывшая сотрудница, предложили мне сроки лучше ваших". Стало ясно: менеджер по продажам продолжала сливать свежие прайсы после ухода, укрепляя свои позиции на новом месте. Но как? Сисадмины не знали, что ответить: "RDP открыт для подсетей, мы не следили за подключениями".
Аудит показал риски ИБ
Директор сдался: «Нужны эксперты». «ТехноСофт» нанял аутсорсинговую компанию для расследования. Аудиторы начали с сканирования портов через Nmap и обнаружили, что порт 3389 (RDP) открыт на сервере компании. Затем они проверили правила брандмауэра через Windows Defender Firewall и настройки маршрутизатора, выявив, что подключения к 3389 разрешены для широкого диапазона IP — целой подсети, а не конкретных адресов. В Remote Desktop Services Manager нашли незакрытые сессии, а многофакторная аутентификация (MFA) не использовалась.
Через Group Policy Editor вскрылась слабая политика паролей: «Password123» соответствовал требованиям GPO, где нужно три из четырёх критериев (заглавная буква «P», строчные «assword», цифры «123», без спецсимволов), но GPO не включала проверку на запрещённые пароли, что позволило использовать уязвимые комбинации.
Аудиторы нажали Win+R, ввели «PowerShell» и запустили скрипт выведя список пользователей домена, не менявших пароли последние 180 дней — среди них оказался сотрудник отдела продаж.
# Поиск пользователей AD с устаревшими паролями
$maxAgeDays = [math]::Abs(
(Get-ADDefaultDomainPasswordPolicy -EA 0).MaxPasswordAge.Days ?? 180
)
$date = (Get-Date).AddDays(-$maxAgeDays)
Get-ADUser -Filter {
Enabled -eq $true -and
SamAccountName -ne 'krbtgt' -and
(PasswordLastSet -lt $date -or PasswordLastSet -eq $null)
} -Prop PasswordLastSet |
Select Name, SamAccountName,
@{N="PasswordLastSet";E={$_.PasswordLastSet ? $_ : "Never Changed"}} |
Format-Table -AutoSizeХотите разбирать реальные случаи взломов и разбираться в киберугрозах? В Telegram‑канале Security Controls я делюсь историями атак, методами защиты и разбором уязвимостей. Подписывайтесь, если тема безопасности вам интересна. |
Они также рекомендовали внедрить решения класса DLP для предотвращения утечек данных в будущем.
Форензический анализ провели с помощью Event Log Explorer, изучив системные логи Windows (Event ID 4624 для входов через RDP). Логи показали подключения с учётки сотрудника отдела продаж в нерабочее время после ухода менеджера по продажам, но точный IP установить не удалось из-за динамических адресов. Wireshark подтвердил: данные не уходили по сети, а копировались через перенаправление локальных дисков в RDP. Опрос раскрыл: сотрудник отдела продаж делился паролем в чате, а сисадмины игнорировали базовые практики — не мониторили логи и не закрывали сессии.
Защита от утечек данных
«ТехноСофт» потерял трёх ключевых клиентов, что обошлось компании в 5% годовой выручки — прямые убытки от утраты контрактов. После этого бюджет на информационную безопасность увеличили вдвое. RDP заменили на VPN с MFA, доступы стали одноразовыми и отзывались при увольнении. Внедрили менеджер паролей, чтобы сотрудники больше не хранили учётные данные в чатах, и решения DLP для контроля передачи данных, а логи настроили для активного мониторинга. Сервер обновили. Этот инцидент стал уроком: пренебрежение безопасностью дорого обходится.
#Cybersecurity #DataLeak #InsiderThreat #Кибербезопасность #УтечкаДанных #ВнутренниеУгрозы