[Информационная безопасность] ИБо нефиг: лучшие ИБ-разоблачения 2020-го по версии JSOC
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Подходит к концу первое полугодие, и мы решили вспомнить самые интересные кейсы из жизни JSOC, с которыми столкнулись в этом году. Встреча со «старым знакомым» киберпреступником в новом заказчике, вредоносный скрипт в Task Scheduler и загадка кривой настройки балансировщика – читаем и проникаемся под катом.
Кадр из сериала South Park
Мы узнали его по почерку
За время существования JSOC мы сталкивались с разными ИТ-инфраструктурами и различными желаниями заказчика по покрытию мониторингом своего ИТ-ландшафта. Часто бывает, например, что заказчик хочет следить только за серверами, лишая себя возможности увидеть происходящее около контролируемого сегмента. Такой подход может вылиться в поздний детект атаки, когда скомпрометирована уже бОльшая часть инфраструктуры. И если у наших действующих заказчиков таких ситуаций не бывает, то на пилотных проектах это обычная история.
Так, во время одного из пилотов заказчик находился в процессе перестройки собственного ИТ-ландшафта и хотел посмотреть, как SOC будет сочетаться с его новой инфраструктурой и процессами. В силу различных, не зависящих от нас обстоятельств у нас не было подключено ни одного сетевого источника, что капец как сильно ограничивало нас в детекте различных инцидентов. Были подключены только контроллер доменов, пара виндовых серверов, почтовый сервер и антивирус. Пилот проходил довольно спокойно и для нас стандартно: обнаружилось несколько вредоносов в инфраструктуре, использование TOR'a и запрещенных RAT'ов. Но в один прекрасный день начало срабатывать огромное количество наших правил, среди них были правила из категории Threat Hunting, которые автоматизируют процесс выявления следов злоумышленника. Ответственный аналитик быстро понял, что дело пахнет керосином, и даже понял, с кем имеет дело.
Что же произошло? Первым делом мы увидели добавление новых учетных записей в группу доменных админов. Но сработало еще одно правило, а именно подозрительное наименование учетных записей, с которым мы уже сталкивались. Один наш старый знакомый злоумышленник при проведении атак создает две учетки, которые прописаны в его скрипте: эти два имени «кочуют» у него от одной жертвы к другой – небольшое изменение может быть вызвано только правилами именования учетных записей атакуемой организации. Мы встречали его уже много раз при расследовании инцидентов. Он атакует организации любого размера и отрасли одним и тем же методом, и, как правило, все заканчивается шифрованием ключевых серверов компании.
К сожалению, первая скомпрометированная машина была вне скоупа подключенных источников, поэтому момент запуска самого скрипта зафиксировать не удалось. Следом за созданием учетных записей мы зафиксировали изменение правил на локальном файерволе, которое разрешало использование определенного средства удаленного администрирования, а затем была создана служба агента этого самого средства. Кстати, антивирус, который использует заказчик, не распознает эту тулзу, поэтому мы контролируем ее по созданию соответствующей службы и запуску процесса.
Вишенкой на торте стало распространение на скомпрометированные хосты легальной утилиты для шифрования. Залить ее на все хосты он не успел. Злоумышленника «выгнали» из инфраструктуры спустя 23 минуты после первой сработки по этому инциденту.
Конечно, мы с заказчиком хотели получить полную картину инцидента и найти точку входа злоумышленника. Опираясь на наш опыт, мы запросили логи с сетевого оборудования, но, к сожалению, уровень логирования на нем не позволял сделать какие-либо выводы. Однако, получив от администраторов конфиг пограничного сетевого оборудования, мы увидели следующее:
ip nat inside source static tcp «серый адрес» 22 «белый адрес» 9922
ip nat inside source static tcp «серый адрес» 3389 «белый адрес» 33899
Из чего был сделан вывод, что, скорее всего, точкой входа стал один из серверов, где был настроен такой NAT. Проанализировали логи этих серверов и увидели успешную аутентификацию под админской учеткой, запуск Mimikatz и последующий запуск скрипта, который создавал доменных администраторов. Благодаря этому случаю заказчик провел полную ревизию правил межсетевых экранов, паролей и политик безопасности и выявил еще несколько недостатков своей инфраструктуры. А еще получил более системное понимание, зачем нужен SOC в его организации.
Удалёнка и домашние роутеры – рай для хакера
Очевидно, что в условиях перехода компаний на удаленку стало существенно сложнее мониторить события на конечных устройствах. Ключевых причин две:
1) большое количество сотрудников используют для работы личные устройства;
2) даже при наличии рабочих ноутбуков сотрудники не всегда подключены к VPN компании, и логи поступают с существенной задержкой.
Также очевидный факт, что даже опытным злоумышленникам стали интересны домашние сети, так как это теперь идеальная точка проникновения в корпоративный периметр.
У одного из наших заказчиков 90% сотрудников перешли на удаленный режим работы, и у всех были доменные ноутбуки – соответственно, мы могли продолжать мониторинг конечных устройств – конечно, с учетом пункта 2 выше. И именно этот пункт сыграл против нас.
Один из пользователей во время самоизоляции не подключался к VPN практически целый день. В конце рабочего дня ему все-таки понадобился доступ к корпоративным ресурсам. Он воспользовался VPN, мы получили логи с его рабочей машинки и увидели странное. В Task Scheduler’e была создана подозрительная задача: она запускала некий файл каждую среду в 17:00. Начали разбираться.
Следы привели к двум doc-файлам: один из них создал задачу, второй был запускаемым файлом в задаче. Пользователь скачал их с Google Drive.
На этом этапе наших поисков подключилась уже служба безопасности заказчика и начала внутреннее расследование. Выяснилось, что пользователь получил на свою личную почту письмо, которое содержало ссылку на Google Drive, откуда и были скачаны документы. Постепенно добрались до роутера пользователя – естественно, логин\пароль к нему были admin\admin (как будто бывает иначе?). Но самое интересное обнаружилось в настройках DNS-сервера роутера: там был указан IP-адрес одной из европейских стран. Загнали этот адрес в VirusTotal – большинство источников засветились красным цветом. После окончания расследования, заказчик направил нам два файла на исследование, и мы увидели, что запускаемый задачей файл начинал «ходить» по всевозможным директориям и выгружать оттуда данные.
Хронология инцидента получилась следующая: злоумышленник получил доступ к роутеру пользователя, поменял в нем настройки, указав в качестве DNS-сервера свой собственный сервер. Какое-то время наблюдал за своей «жертвой» и отправил письмо на личную почту пользователя. На этом шаге мы его и обнаружили, не дав пробраться вглубь корпоративной инфраструктуры.
Свои тоже нарушают
На начальном этапе работы с аутсорсинговым SOC мы всегда рекомендуем подключать источники событий поэтапно, для того чтобы заказчик на своей стороне отладил процессы, четко определил зоны ответственности и в целом привык к этому формату. Так, у одного из наших новых заказчиков мы подключили сначала базовые источники, такие как контроллеры доменов, межсетевые экраны, прокси, различные СЗИ, почту, DNS- и DHCP-серверы и еще несколько различных серверов. Также мы предложили подключить на уровне локальных логов машины администраторов головного офиса, но заказчик сказал, что пока это лишнее и он своим админам доверяет. Тут, собственно, и начинается наша история.
В один из дней к нам перестали поступать события. От заказчика узнали, что якобы из-за масштабной DDoS-атаки у него «упал» ЦОД и сейчас он занимается восстановлением. Это сразу вызвало много вопросов – ведь система защиты от DDoS-атак была подключена к нам.
Аналитик сразу же начал копаться в ее логах, но ничего подозрительного там не нашел – все было в штатном режиме. Тогда посмотрел на сетевые логи и обратил внимание на странную работу балансировщика, который распределял нагрузку между двумя серверами, обрабатывающими входящий трафик. Балансировщик нагрузку не распределял, а наоборот направлял ее только на один сервер, пока тот не «захлёбывался», и только потом перенаправлял поток на второй узел. Но гораздо интереснее, что, как только упали оба сервера, этот трафик пошел дальше и «положил» вообще все. Пока велись работы по восстановлению, заказчик выяснил, кто накосячил. На этом, казалось бы, инцидент исчерпан: к информационной безопасности он не имеет никакого отношения и просто связан с кривыми руками ошибкой администратора. Но заказчик решил расследовать до конца. Проверив АРМ-ы админов, он обнаружил, что у того самого горе-умельца почищены все журналы ОС, и тогда попросил нас проверить его действия за последнюю неделю.
Интересно, что этот администратор за пару недель до произошедшего несколько раз был объектом наших расследований. Он обращался из локальной сети к внешнему хосту по 22 порту. Тогда данный инцидент был отмечен как легитимный, т.к. админам не запрещено пользоваться внешними ресурсами для автоматизации собственной работы или тестирования каких-либо новых настроек оборудования. Возможно, эту связь между падением ЦОДа и обращением к внешнему хосту никогда бы и не заметили, но был еще один инцидент: обращения с одного из серверов тестового сегмента к тому же хосту в интернете, к которому ранее обращался админ – этот инцидент тоже был отмечен заказчиком как легитимный. Посмотрев активность администратора, мы увидели постоянные обращения к этому серверу из тестового сегмента и попросили заказчика проверить его.
И вот она развязка – на том сервере был развернут веб-сервер, реализующий частичный функционал основного веб-сайта заказчика. Выяснилось, что админ планировал перенаправлять часть входящего трафика на свой поддельный сайт, чтобы таким образом собрать для своих целей данные пользователей.
Итог
Несмотря на то, что на дворе уже 2020 год, во многих организациях до сих пор не соблюдаются прописные истины информационной безопасности, а безответственность собственного персонала может приводить к катастрофическим последствиям.
В связи с этим вот несколько советов:
1. Никогда не открывайте наружу RDP и SSH, даже если вы прячете их за другими портами – это не помогает.
2. Настраивайте максимально возможный уровень логирования для ускорения детекта злоумышленников.
3. Развивайте направление Threat Hunting в своей организации. Изучайте TTPs и тулзы, которые используют злоумышленники. Такие знания существенно усложняют им жизнь и увеличивают ваши шансы на обнаружение атаки.
4. Доверяй, но проверяй. Необходимо контролировать даже самых доверенных сотрудников, особенно если у них есть повышенные права, с которыми они могут нанести вред организации.
Артем Кильдюшев, аналитик отдела экспертного пресэйла продуктов и сервисов Solar JSOC (artkild)
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-компании, Информационная безопасность, Карьера в IT-индустрии, Развитие стартапа] Бизнес-хакеры Кремниевой долины
- [Информационная безопасность] Google Dorking или используем Гугл на максимум
- [PHP, Symfony] Управление секретами в Symfony (перевод)
- [Информационная безопасность] Security Week 29: системная реклама в Android
- [Growth Hacking, Гаджеты, Интервью, Информационная безопасность] Телефон, как личное пространство современной жизни
- [Браузеры, Информационная безопасность, Серверное администрирование] Почему удостоверяющие центры не соблюдают требование CA/Browser к сертификатам
- [Информационная безопасность, Сетевые технологии, Системное администрирование] NGFW для малого бизнеса. Новая линейка CheckPoint 1500 Security Gateway
- [Cisco, Информационная безопасность, Сетевые технологии, Системное администрирование] StealthWatch: анализ и расследование инцидентов. Часть 3
- [Информационная безопасность, Разработка для интернета вещей, Сетевые технологии] Простой UDP hole punching на примере IPIP-туннеля
- [Информационная безопасность, Тестирование веб-сервисов, Тестирование мобильных приложений] Burp Suite Tips
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_security, #_soc, #_udalenka (удалёнка), #_vredonosnoe_po (вредоносное по), #_kiberbezopasnost (кибербезопасность), #_kiberintsedenty (киберинцеденты), #_blog_kompanii_rostelekomsolar (
Блог компании Ростелеком-Солар
), #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:55
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Подходит к концу первое полугодие, и мы решили вспомнить самые интересные кейсы из жизни JSOC, с которыми столкнулись в этом году. Встреча со «старым знакомым» киберпреступником в новом заказчике, вредоносный скрипт в Task Scheduler и загадка кривой настройки балансировщика – читаем и проникаемся под катом.  Кадр из сериала South Park Мы узнали его по почерку За время существования JSOC мы сталкивались с разными ИТ-инфраструктурами и различными желаниями заказчика по покрытию мониторингом своего ИТ-ландшафта. Часто бывает, например, что заказчик хочет следить только за серверами, лишая себя возможности увидеть происходящее около контролируемого сегмента. Такой подход может вылиться в поздний детект атаки, когда скомпрометирована уже бОльшая часть инфраструктуры. И если у наших действующих заказчиков таких ситуаций не бывает, то на пилотных проектах это обычная история. Так, во время одного из пилотов заказчик находился в процессе перестройки собственного ИТ-ландшафта и хотел посмотреть, как SOC будет сочетаться с его новой инфраструктурой и процессами. В силу различных, не зависящих от нас обстоятельств у нас не было подключено ни одного сетевого источника, что капец как сильно ограничивало нас в детекте различных инцидентов. Были подключены только контроллер доменов, пара виндовых серверов, почтовый сервер и антивирус. Пилот проходил довольно спокойно и для нас стандартно: обнаружилось несколько вредоносов в инфраструктуре, использование TOR'a и запрещенных RAT'ов. Но в один прекрасный день начало срабатывать огромное количество наших правил, среди них были правила из категории Threat Hunting, которые автоматизируют процесс выявления следов злоумышленника. Ответственный аналитик быстро понял, что дело пахнет керосином, и даже понял, с кем имеет дело. Что же произошло? Первым делом мы увидели добавление новых учетных записей в группу доменных админов. Но сработало еще одно правило, а именно подозрительное наименование учетных записей, с которым мы уже сталкивались. Один наш старый знакомый злоумышленник при проведении атак создает две учетки, которые прописаны в его скрипте: эти два имени «кочуют» у него от одной жертвы к другой – небольшое изменение может быть вызвано только правилами именования учетных записей атакуемой организации. Мы встречали его уже много раз при расследовании инцидентов. Он атакует организации любого размера и отрасли одним и тем же методом, и, как правило, все заканчивается шифрованием ключевых серверов компании. К сожалению, первая скомпрометированная машина была вне скоупа подключенных источников, поэтому момент запуска самого скрипта зафиксировать не удалось. Следом за созданием учетных записей мы зафиксировали изменение правил на локальном файерволе, которое разрешало использование определенного средства удаленного администрирования, а затем была создана служба агента этого самого средства. Кстати, антивирус, который использует заказчик, не распознает эту тулзу, поэтому мы контролируем ее по созданию соответствующей службы и запуску процесса.  Вишенкой на торте стало распространение на скомпрометированные хосты легальной утилиты для шифрования. Залить ее на все хосты он не успел. Злоумышленника «выгнали» из инфраструктуры спустя 23 минуты после первой сработки по этому инциденту. Конечно, мы с заказчиком хотели получить полную картину инцидента и найти точку входа злоумышленника. Опираясь на наш опыт, мы запросили логи с сетевого оборудования, но, к сожалению, уровень логирования на нем не позволял сделать какие-либо выводы. Однако, получив от администраторов конфиг пограничного сетевого оборудования, мы увидели следующее: ip nat inside source static tcp «серый адрес» 22 «белый адрес» 9922 ip nat inside source static tcp «серый адрес» 3389 «белый адрес» 33899 Из чего был сделан вывод, что, скорее всего, точкой входа стал один из серверов, где был настроен такой NAT. Проанализировали логи этих серверов и увидели успешную аутентификацию под админской учеткой, запуск Mimikatz и последующий запуск скрипта, который создавал доменных администраторов. Благодаря этому случаю заказчик провел полную ревизию правил межсетевых экранов, паролей и политик безопасности и выявил еще несколько недостатков своей инфраструктуры. А еще получил более системное понимание, зачем нужен SOC в его организации. Удалёнка и домашние роутеры – рай для хакера Очевидно, что в условиях перехода компаний на удаленку стало существенно сложнее мониторить события на конечных устройствах. Ключевых причин две: 1) большое количество сотрудников используют для работы личные устройства; 2) даже при наличии рабочих ноутбуков сотрудники не всегда подключены к VPN компании, и логи поступают с существенной задержкой. Также очевидный факт, что даже опытным злоумышленникам стали интересны домашние сети, так как это теперь идеальная точка проникновения в корпоративный периметр. У одного из наших заказчиков 90% сотрудников перешли на удаленный режим работы, и у всех были доменные ноутбуки – соответственно, мы могли продолжать мониторинг конечных устройств – конечно, с учетом пункта 2 выше. И именно этот пункт сыграл против нас. Один из пользователей во время самоизоляции не подключался к VPN практически целый день. В конце рабочего дня ему все-таки понадобился доступ к корпоративным ресурсам. Он воспользовался VPN, мы получили логи с его рабочей машинки и увидели странное. В Task Scheduler’e была создана подозрительная задача: она запускала некий файл каждую среду в 17:00. Начали разбираться.  Следы привели к двум doc-файлам: один из них создал задачу, второй был запускаемым файлом в задаче. Пользователь скачал их с Google Drive. На этом этапе наших поисков подключилась уже служба безопасности заказчика и начала внутреннее расследование. Выяснилось, что пользователь получил на свою личную почту письмо, которое содержало ссылку на Google Drive, откуда и были скачаны документы. Постепенно добрались до роутера пользователя – естественно, логин\пароль к нему были admin\admin (как будто бывает иначе?). Но самое интересное обнаружилось в настройках DNS-сервера роутера: там был указан IP-адрес одной из европейских стран. Загнали этот адрес в VirusTotal – большинство источников засветились красным цветом. После окончания расследования, заказчик направил нам два файла на исследование, и мы увидели, что запускаемый задачей файл начинал «ходить» по всевозможным директориям и выгружать оттуда данные. Хронология инцидента получилась следующая: злоумышленник получил доступ к роутеру пользователя, поменял в нем настройки, указав в качестве DNS-сервера свой собственный сервер. Какое-то время наблюдал за своей «жертвой» и отправил письмо на личную почту пользователя. На этом шаге мы его и обнаружили, не дав пробраться вглубь корпоративной инфраструктуры. Свои тоже нарушают На начальном этапе работы с аутсорсинговым SOC мы всегда рекомендуем подключать источники событий поэтапно, для того чтобы заказчик на своей стороне отладил процессы, четко определил зоны ответственности и в целом привык к этому формату. Так, у одного из наших новых заказчиков мы подключили сначала базовые источники, такие как контроллеры доменов, межсетевые экраны, прокси, различные СЗИ, почту, DNS- и DHCP-серверы и еще несколько различных серверов. Также мы предложили подключить на уровне локальных логов машины администраторов головного офиса, но заказчик сказал, что пока это лишнее и он своим админам доверяет. Тут, собственно, и начинается наша история. В один из дней к нам перестали поступать события. От заказчика узнали, что якобы из-за масштабной DDoS-атаки у него «упал» ЦОД и сейчас он занимается восстановлением. Это сразу вызвало много вопросов – ведь система защиты от DDoS-атак была подключена к нам. Аналитик сразу же начал копаться в ее логах, но ничего подозрительного там не нашел – все было в штатном режиме. Тогда посмотрел на сетевые логи и обратил внимание на странную работу балансировщика, который распределял нагрузку между двумя серверами, обрабатывающими входящий трафик. Балансировщик нагрузку не распределял, а наоборот направлял ее только на один сервер, пока тот не «захлёбывался», и только потом перенаправлял поток на второй узел. Но гораздо интереснее, что, как только упали оба сервера, этот трафик пошел дальше и «положил» вообще все. Пока велись работы по восстановлению, заказчик выяснил, кто накосячил. На этом, казалось бы, инцидент исчерпан: к информационной безопасности он не имеет никакого отношения и просто связан с кривыми руками ошибкой администратора. Но заказчик решил расследовать до конца. Проверив АРМ-ы админов, он обнаружил, что у того самого горе-умельца почищены все журналы ОС, и тогда попросил нас проверить его действия за последнюю неделю. Интересно, что этот администратор за пару недель до произошедшего несколько раз был объектом наших расследований. Он обращался из локальной сети к внешнему хосту по 22 порту. Тогда данный инцидент был отмечен как легитимный, т.к. админам не запрещено пользоваться внешними ресурсами для автоматизации собственной работы или тестирования каких-либо новых настроек оборудования. Возможно, эту связь между падением ЦОДа и обращением к внешнему хосту никогда бы и не заметили, но был еще один инцидент: обращения с одного из серверов тестового сегмента к тому же хосту в интернете, к которому ранее обращался админ – этот инцидент тоже был отмечен заказчиком как легитимный. Посмотрев активность администратора, мы увидели постоянные обращения к этому серверу из тестового сегмента и попросили заказчика проверить его. И вот она развязка – на том сервере был развернут веб-сервер, реализующий частичный функционал основного веб-сайта заказчика. Выяснилось, что админ планировал перенаправлять часть входящего трафика на свой поддельный сайт, чтобы таким образом собрать для своих целей данные пользователей. Итог Несмотря на то, что на дворе уже 2020 год, во многих организациях до сих пор не соблюдаются прописные истины информационной безопасности, а безответственность собственного персонала может приводить к катастрофическим последствиям. В связи с этим вот несколько советов: 1. Никогда не открывайте наружу RDP и SSH, даже если вы прячете их за другими портами – это не помогает. 2. Настраивайте максимально возможный уровень логирования для ускорения детекта злоумышленников. 3. Развивайте направление Threat Hunting в своей организации. Изучайте TTPs и тулзы, которые используют злоумышленники. Такие знания существенно усложняют им жизнь и увеличивают ваши шансы на обнаружение атаки. 4. Доверяй, но проверяй. Необходимо контролировать даже самых доверенных сотрудников, особенно если у них есть повышенные права, с которыми они могут нанести вред организации. Артем Кильдюшев, аналитик отдела экспертного пресэйла продуктов и сервисов Solar JSOC (artkild) =========== Источник: habr.com =========== Похожие новости:
Блог компании Ростелеком-Солар ), #_informatsionnaja_bezopasnost ( Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:55
Часовой пояс: UTC + 5