ИБо нефиг: лучшие ИБ-разоблачения 2020-го по версии JSOC

    Подходит к концу первое полугодие, и мы решили вспомнить самые интересные кейсы из жизни 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)
    Ростелеком-Солар
    Безопасность по имени Солнце

    Комментарии 12

      0
      Никогда не открывайте наружу RDP и SSH, даже если вы прячете их за другими портами – это не помогает.


      Это касается и домашний пользователей, мамкиных хакеров типа меня. 2 раза с интвервалом в 4 года обнаруживал атаку на проброшенный на ружу shh и rdp порты. Спас только параноидальный пароль и нестандартные имена пользователей. Сейчас уже через OpenVPN ходить нужно.

      А есть какие-то хорошие ресурсы для настройки адекватной безопасности в домашней сети? Поднимать домашнюю безопасноть до корпоративно-параноидального уровня не хочется, но иметь минимальный чеклист для домашнего пользования было бы неплохо.
        0
        Я думаю, всё же имелась в виду иная угроза чем тупо брутфорс паролей. И интересно услышать у автора, кстати, какая (относительно SSH)?
          0
          Зачем вообще пароль на SSH? Какие проблемы с ключами?
          +1
          Я бы ответил следующим образом:
          1. Забрутить RDP или SSH, торчащий наружу вопрос времени и, с развитием текущих мощностей и возможностей распределенного брутфорса — это часы и дни, а не годы. Ну и помимо этого есть еще непропатченные версии, дефолтовые пароли и учетки. Буквально недавно у одной из пилотируемых компаний (крупных) обнаружили tomcat tomcat в торчащем наружу сервисе и это не редкость
          2. По безопасности домашней сети есть несколько тезисов:
          — сейчас роутеры провайдеров стали очень и очень продвинутыми. Там и DMZ можно организовать и IPSEC построить и уж VPN поднять не проблема. В любом случае VPN всегда безопасней чем RDP/SSH. Да еще и сертификат выпустить можно на поднятом CA
          — Если очень хочется открыть RDP, SSH наружу — открывайте для определенных IP, если используется статика для подключения к домашней инфраструктуре
          — Уберите в настройках публикацию интерфейса администрирования в WAN интерфейс, так как на многих роутерах по умолчанию он торчит в интернет.
          — Используйте скрытый SSID WiFi
          — Меняйте пароли WiFi хотя бы раз в месяц
          — И обязательно обновляйте прошивки железки. Взломанные микротики стали притчей воязыцех
            0
            1. Забрутить RDP или SSH, торчащий наружу вопрос времени и, с развитием текущих мощностей и возможностей распределенного брутфорса — это часы и дни, а не годы.

            Особенно, если пароли не используются. Почему вы не боитесь брута пароля на VPN, но боитесь на SSH?

            — Используйте скрытый SSID WiFi

            Напомните, пож., от чего это защищает?
              0
              По первому вопросу — VPN можно сделать с сертификатом (как я и указал в комменте) или onetimepass например, ну и брут VPN можно контролировать — рубить ip-шник или учетку при превышении количества запросов

              По второму — прежде чем подобрать пароль, нужно узнать SSID )
                +1
                SSH давно уже используется только с ключом, парольный вход выключается. Двухфакторка/вантайм к нему прикручивается ничуть не сложнее. Да и банальный fail2ban — стандарт де-факто уже с десяток лет. Причем для SSH он как раз стандарт из коробки, для VPN-ов придется настраивать. Но опять же, если вход по ключу (или сертификату в VPN) — смысла в блокировках особого нет.

                прежде чем подобрать пароль, нужно узнать SSID

                Нет. Прежде, чем подобрать пароль, вам нужно захватить хендшейк. Я не знаю ни одной утилиты для этого, которую бы смутил SSID Cloaking. То же касается и атак на WPS. Потому что «скрытый SSID» — это просто флаг, его можно игнорировать.
                Подобную практику принято относить к «вредным», на ряду с регулярной сменой системных паролей и перевешиванием сервисов на неродные порты — они не усложняют жизнь атакующим, но дают ложное чувство защищенности.
                  +1
                  ОООк) продолжим

                  По SSH — все так, только VPN дает сильно больше и сильно проще, нежели SSH. Я не спорю, что SSH можно настроить безопасно, но с VPN с точки зрения доступа к корпоративной инфраструктуры возможностей сильно больше по использованию корпоративных ресурсов. Те компании, которые приходили к нам с просьбой расследовать, расшифровать не использовали сертификаты на ssh, более того, даже root не блочили. Куча ботов ежедневно сканит интернет по 445, 22, 3389 портам. И если 22 входит и его сканят — значит «если звезды зажигаются, значит это кому-то нужно» и есть профит от этого.

                  По WiFi — речь была про безопасность ДОМАШНЕЙ сети. И от соседа мальчика 12 лет cloaking вполне норм. Хэндшейк захватить — устройство нужно, которое коннектится, а днем, когда сосед-бездельник пришел со школы и ему скучно, многие работают и не юзают точку. В корпоративных сетях использовать пароль для точки WIFI очень странно, там совершенно по-другому строится защита. Надеюсь свои «вредные» советы пояснил
            0
            Существует ли HoneyPot, имитирующий SSh-сервер, выставленный наружу без защиты? Причём такой, чтобы взломщик далеко не сразу догадался, что ему подсунули пустышку: т.е. этот HoneyPot должен как бы нормально реагировать на команды локальной работы и даже как бы позволять коннеектиться к разным сервисам локальной сети, которая тоже имитируется.
              0
              Cowrie, например
                0
                А можно просто поднять CentOS сервер, открыть ssh и настроить auditd и смотреть)
                  0
                  Можно, конечно. Иногда даже нужно. Все от задач зависит. Если просто собрать статистику и тактики ботов — то выделенный хост мне кажется излишеством. Если анализировать развитие APT — то одним хостом не обойдешься :)

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

            Самое читаемое