Проверь себя: сможете ли вы защитить компанию от кибератаки?

    Недавно в Самаре прошли международные открытые соревнования по информационной безопасности VolgaCTF. Владимир Дрюков, директор центра мониторинга и реагирования на кибератаки Solar JSOC, рассказал участникам соревнований о трех реальных атаках и спросил, как можно было их выявить. Проверьте, сможете ли вы ответить правильно.

    Ниже расшифровка выступления Владимира, но для желающих посмотреть uncensored and uncut version (включая ответы слушателей) — вот видео:


    Итак, слово Владимиру:



    Хочется рассказать несколько историй из нашей жизни. Большую часть их них я буду рассказывать с конца – то есть начиная с того, что это был за инцидент. А вы попробуйте придумать, как эту атаку можно было увидеть на старте, что бы вы, как защитник компании, сделали, чтобы действия злоумышленников попали на ваш радар.

    Надеюсь, это поможет вам в будущем, когда вы станете профессиональными пентестерами и будете работать в Positive Technologies, Digital Security или у нас. Вы будете знать, как центр мониторинга видит такие атаки, как он на них реагирует, и – кто знает – может быть, это поможет вам обойти защиту, добиться своей цели и показать заказчику, что он не так неуязвим, как ему казалось. Ну что, поехали?

    Задача №1. Эта служба и опасна, и трудна, и на первый взгляд как будто не видна...


    Началась история с того, что к нам пришел руководитель службы информационной безопасности одной компании и говорит:

    «Ребята, у меня творится какая-то странная ерунда. Есть четыре машины, которые начинают спонтанно перезагружаться, вываливаться в синий экран – в общем, происходит какая-то чушь. Давайте поразбираемся».

    Когда ребята из группы форензики приехали на площадку, оказалось, что security логи на всех машинах почищены – активностей так много, что журнал security быстро ротируется (перезаписывается). В Master File Table тоже не удалось найти ничего интересного – фрагментация сильная, данные быстро перезатираются. Тем не менее, удалось найти кое-что в журнале system: примерно раз в сутки на этих четырех машинах появляется служба it_helpdesk, делает что-то неизвестное (security логов нет, как мы помним) и исчезает.

    У нашего главы форензики появилось примерно такое выражение лица:



    Стали разбираться дальше, и оказалось, что служба it_helpdesk – на самом деле переименованный PSExec.
    Служебные программы, такие как Telnet, и программы удаленного управления, такие как PC Anywhere компании Symantec, позволяют выполнять программы в удаленных системах, однако их не так просто установить, поскольку требуется устанавливать еще и клиентское программное обеспечение в тех удаленных системах, к которым необходимо получить доступ.

    Программа PsExec — это облегченный вариант Telnet. Она позволяет выполнять процессы в удаленных системах, используя для этого все возможности интерактивного интерфейса консольных приложений, и при этом нет необходимости вручную устанавливать клиентское программное обеспечение. Основное достоинство PsExec — это возможность вызывать в интерактивном режиме интерфейс командной строки в удаленных системах и удаленно запускать такие инструменты как IpConfig. Это единственный способ вывести на экран локального компьютера данные об удаленной системе.

    technet.microsoft.com

    Проверив журналы system на других машинах, мы увидели, что задействованы не 4 рабочих станции, а 20, плюс еще 19 серверов, в том числе один критичный сервер. Пообщались с айтишниками и выяснили, что они к этому отношения не имеют, такой подсистемы у них нет. Стали копать дело дальше, и тогда обнаружилась довольно любопытная и редко встречающаяся вещь – DNS-tunneling, которое использовал модуль ВПО, отвечающий за связь с центром управления ботнетом.
    DNS-tunneling — техника, позволяющая передавать произвольный трафик (фактически, поднять туннель) поверх DNS-протокола. Может применяться, например, для того чтобы получить полноценный доступ к Интернет из точки, где разрешено преобразование DNS-имён.

    DNS-туннелирование нельзя запретить простыми правилами брандмауэра, разрешив при этом остальной DNS-трафик. Это связано с тем, что трафик DNS-туннеля и легитимные DNS-запросы неразличимы. Обнаруживать DNS-туннелирование можно по интенсивности запросов (если трафик по туннелю велик), а также более сложными методами, используя системы обнаружения вторжений.

    xgu.ru

    Вредоносный код попал в организацию через почту, распространялся по инфраструктуре и взаимодействовал с C&C-сервером через DNS-туннель. Поэтому запреты на взаимодействие с интернетом, которые стояли в серверном сегменте, не работали.

    На одном из критичных серверов стоял кейлоггер, который автоматически считывал пароли, и вредонос пытался ползти дальше, получая новые учетные данные пользователей, в том числе роняя машины в BSOD и считывая пароли администраторов, которые его поднимали.

    К чему это привело? За то время, пока вредонос жил в инфраструктуре, было скомпрометировано много учеток и, помимо этого, большой объем других потенциально чувствительных данных. В ходе расследования мы локализовали область действия злоумышленников и «выгнали» их из сети. Заказчик же получил еще четыре месяца муки – потребовалось перезалить половину машин и перевыпустить все пароли – от баз данных, учеток и так далее. Людям с ИТ-опытом не надо объяснять, какая это непростая история. Но, тем не менее, все закончилось хорошо.

    Итак, вопрос: как можно было выявить эту атаку и поймать за руку киберпреступника?

    Ответ на первую задачу
    Во-первых, как вы помните, заражение затронуло критичный сервер. Если на таком хосте запускается новая, неизвестная ранее служба, это инцидент очень высокой степени критичности. Такого происходить не должно. Если вы хотя бы мониторите службы, которые запускаются на критичных серверах, одно это поможет выявить подобную атаку на ранней стадии и не дать ей развиться.

    Во-вторых, не стоит пренебрегать и информацией с самых базовых средств защиты. PSExec неплохо детектируется антивирусами, но маркируется не как вредоносное ПО, а как Remote Admin Tool или Hacking Tool. Если внимательно смотреть в логи антивируса, можно вовремя увидеть срабатывание и принять соответствующие меры.


    Задача №2. Страшные сказки


    Большой банк, женщина работает в финансовой службе и имеет доступ к АРМ КБР.
    АРМ КБР – автоматизированное рабочее место клиента Банка России. Представляет собой программное решение для защищенного информационного обмена с Банком России, в том числе отправки платежных поручений, банковских рейсов и т.д.

    Эта сотрудница финансовой службы принесла на работу флешку с файлом под названием Skazki_dlya_bolshih_i_malenkih.pdf.exe. У нее была маленькая дочка, и женщина хотела распечатать на работе детскую книжку, которую скачала из интернета. Расширение файла .pdf.exe не показалось ей подозрительным, да и потом, когда она запустила файл, открылась обычная pdf.



    Женщина распечатала книгу и ушла домой. Но расширение .exe, конечно, было не случайным. За ним скрывался Remo Admin Tool, который сел на рабочую станцию и окопался там в системных процессах больше чем на год.

    Как работают такие вредоносы? Прежде всего, делают скришоты экрана около 15 раз в минуту. В отдельный файл они складывают полученные с кейлоггера данные – логины и пароли, переписку в почте, мессенджерах и много где еще. Подключив клиента, мы быстро заметили зараженный хост и вычистили вирус из сети.

    Вопрос: как можно было выявить «незаметный» вредонос, не детектируемый антивирусом?

    Ответ на вторую задачу
    Во-первых, вредоносное ПО, как правило, что-то делает в файловой системе, меняет записи реестра – словом, как-то загружается в систему. Это можно отследить, если мониторить хост на уровне логов, которые пишет сама операционная система, – security логи, запуск процессов, изменение реестра.

    Во-вторых, важно помнить, что такой вредонос не живет автономно, он обязательно куда-то стучится. Часто у рабочих станций в сети доступ в интернет идет только через прокси, поэтому если машина пытается стучаться куда-то напрямую, это серьезный инцидент, с которым надо разбираться.


    Задача №3. «Кровавый warez»


    Системному администратору надо было сравнить и «склеить» воедино 2 .xml-файла. Он пошел простым путем – набрал в поисковике «скачать xml merger без регистрации и sms». Официальный сайт разработчика этой утилиты был на 3 месте в выдаче, а на первых двух – файлообменники. Там администратор и скачал программу.

    Как вы, наверное, уже догадались, в «бесплатную» утилиту был встроен хороший, качественный модуль повышения привилегий. Он снес антивирусного агента на машине и создал вместо него файл с таким же названием. Так вредонос и висел на машине, периодически связываясь с центром управления.



    Самое плохое было в том, что ИТ-администратор – это король замка, у него есть доступ везде. С его машины вирус может добраться до любого хоста или сервера. Вредонос пополз по сети через доменные sharepoint, пытаясь добраться до машины главного финансиста. В этот момент ее поймали за хвост, и история была погашена.

    Вопрос: как выявить такую атаку на машину привилегированного пользователя?

    Ответ на третью задачу
    Опять-таки, можно слушать трафик, пытаясь поймать вредонос «с поличным» – в момент запроса к C&C-серверу. Однако если в компании нет NGFW, IDS, системы анализа сетевого трафика или SIEM, которая выловит из трафика хоть что-то ценное, слушать его можно до бесконечности.

    Эффективнее смотреть логи операционной системы, отправляя их в какую-то внешнюю систему. Пока вредоносное ПО удаляло антивирусный агент, оно не могло очистить файл аудита, поэтому в логах, переданных на внешней системе, точно останется информация об удалении антивирусного агента или как минимум о самом факте очистки аудита. После этого логи на самой машине будут пустыми, и следов уже не найти.
    • +26
    • 7,9k
    • 9

    Ростелеком-Solar

    214,00

    Безопасность по имени Солнце

    Поделиться публикацией

    Похожие публикации

    Комментарии 9
      0
      Действительно, нельзя исключить возможность заражения. Вот поэтому в компании руководствуются главным правилом системного администратора «Разделяй и властвуй»: работать только с учетной записью с правами пользователя. Для администрирования у администраторов существует отдельная учетная запись с повышенными правами.
        0
        Это конечно все хорошо, но большинство проблем возникает просто из за халатности пользователей, из личного опыта, пришел в компанию, изменил на контроллере домена GPO чтобы пароли менялись каждые 42 дня и чтобы пароль был минимально сложным (8 символов, буквы в разных регистрах, плюс цифры), вы не поверите, но буквально через несколько дней звонит финансовый директор и в довольно не вежливой форме просит вернуть все как было, следом вызвали на ковер к генеральному директору, он тоже возмущается почему как раньше нельзя использовать пароль 25102015, тоже самое и главный бухгалтер у нее везде пароль дата рождения мужа, вы подумаете наверное какая то мелкая фирма, но нет это крупный холдинг, при чем есть разработанная политика безопасности компании подписанная и утвержденная этим самым руководством, некоторые пользователи просят дать права локального администратора, мол типа не бойся я опытный почти как программист, мне можно или те же самые руководители требуют открыть запрещенные сайты, видеохостинги, сайты женской одежды и т.д.

        Теперь об инструментах безопасности, не все они удобны, а зачастую мешают пользователям работать, например ИБ специалист попросил развернуть везде DLP систему, развернул и побежали жаловатья пользователи, так как эта DLP (решение от MCafee) жрет ресурсы компьютера как не в себя, компы виснут, работать невозможно.

        Я за ИБ в компаниях, но все же нужно учитывать наш «совковый» опыт.
          0
          Отчего же, очень верим. По нашему опыту, многие атаки происходят потому, что кому-то в компании «на минутку» открыли доступ в интернет в обход прокси, а потом забыли закрыть, пользователь обладал правами администратора на машине, но не знал азов ИБ и т.д.
          Безопасность часто конфликтует с удобством пользователей, и здесь очень помогают две вещи: внутренние обучения пользователей и умение обосновать руководству необходимость в ИБ с точки зрения выгоды для бизнеса.
            0
            Вы не поверите, но сложность и ротируемость пароля к обеспечению ИБ почти не имеют отношения. Пруф.
            +1
            К третьей истории можно добавить ещё один совет:
            Нужно регулярно (хотя бы раз в квартал, а лучше — в месяц) отслеживать состояние антивируса на хостах и при отсутствии «пинга» до сервера управления в течение какого-то времени — либо выявлять и решать проблему, либо хотя бы переустанавливать антивирус / агент.
              +1
              Это очень хороший совет, но, к сожалению, не для этого инцидента. Тут нюанс истории был ровно в том, что созданный fake агент антивируса действительно периодически стучался в центр управления и демонстрировал собственную «живость». Наверняка его можно было бы «обмануть», послав какую-то нестандартную команду из центра управления, и он бы отреагировал неадекватно, но до этого дело при расследовании не дошло :)
                0
                Ух, жесть какая. Хорошо так загнались разработчики)
              +1
              >Системному администратору надо было сравнить 2 .xml-файла.
              Не понял. А «сравнить по содержимому» из тотал коммандер не катит?
                0
                Да, тут не совсем корректная формулировка в тексте (в аудио вроде все так). Задача была не просто сравнить а еще и «склеить» воедино. Поэтому банальные способы типа total commander и notepad++ не работали.

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

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