У админов атакованных компаний не было шансов заметить аномалию

Расследование нашумевшей кибератаки продолжается. Руководитель команды реагирования на компьютерные инциденты CyS Centrum Николай Коваль, привлеченный к анализу инцидента, поделился промежуточными итогами.

Николай ранее возглавлял CERT-UA при Госспецсвязи. Видимо, устав бороться с ветрянными мельницами за мизерную зарплату, специалист покинул ряды госчиновников и основал частную киберлабораторию.   

- В статьях о кибератаке стали появляться утверждения, что хакеры получили удаленный доступ к данным компаний. Есть ли риск, что на удаленке они скачивали конфиденциальные данные компаний перед  активацией вируса? 

- В результате проведенного нами исследования установлено, что сервера M.E.Doc в организациях (с DLLкой, содержащей бекдор), помимо направленной на саботаж атаки 27.06.2017, были также использованы как PIVOT-point ("позиция", например, вз) для компрометации корпоратиломанный компьютер сотрудника, служащая отправной точкой для дальнейшего развития атакивных информационных систем ряда организаций. Причем, это было еще в апреле. Именно поэтому некоторые компании пострадали намного больше, чем другие. И именно поэтому помимо бекдора в DLLке M.E.Doc, в сетях таких организаций было найдено другое вредоносное программное обеспечение, являющееся инструментарием, используемым совершенно конкретной группой атакующих.

Если в большинстве организаций атака ограничилась серверами/компьютерами с M.E.Doc, то, потенциально, могла быть нарушена конфиденциальность обрабатываемых только на них данных. Не могу сказать, насколько это критично и как именно классифицируется информация, циркулирующая в M.E.Doc.

Наличие несанкционированного доступа злоумышленников к сети/системам следует рассматривать как подтвержденный факт нарушения конфиденциальности той или иной части информации. В связи с этим следует предпринимать адекватные меры, основанные на таком допущении. Объем скомпрометированной информации, что логично, зависит от того, насколько "глубоко" злоумышленники смогли пробраться. Чтобы это понять, надо производить исследование инцидента. Если бы данные клиентов были скомпрометированы (подтверждено или с высокой долей вероятности), распорядители этих данных, например, банки, в первую очередь, предпринимали бы соответствующие меры. Потому как, если решить умолчать об инциденте, потом может быть намного хуже. 

- По логике, системные администраторы компаний могли регулярно мониторить исходящий трафик и заметить  выкачку или…? 

 - В качестве серверов управления бекдором использовались сервера самого M.E.Doc'а (другой вопрос, что трафик перенаправлялся на реальный управляющий сервер). Так вот, в таком случае у "админов компаний" было не много шансов заметить аномалию. Мы, к примеру, смогли ее определить на основе нештатного размера HTTP-ответа.

Конечно, заметить аномалию можно, но для этого надо два фактора. Во-первых, четко и в тонкостях представлять, как выглядят штатные запросы и ответы к/от серверу M.E.Doc. Например, штатные запросы к M.E.Doc (их всего 4 вида) могут иметь совершенно конкретные значения/диапазоны значений размеров HTTP-ответов. Во-вторых, осуществлять постоянный детальный мониторинг аномалий по набору параметров. Вместе с тем, это трудновыполнимо.

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

- Говорят, в наших сетях «сидят» еще как минимум два вируса на инкубации…. 

- Если рассуждать о том, как учитывать и обрабатывать такие риски с точки зрения ИБ, то тут необходимо пересмотреть подход в отношениях с поставщиками услуг (как уже неоднократно отмечалось, данная угроза относится к категории supply-chain threat).

Строить информационные системы надо на основе "нулевого" доверия к продуктам поставщика услуг (его оборудованию и программному обеспечению). Кроме того, модель угроз должна допускать возможность компрометации того или иного узла сети, таковы реалии. Исходя из этого, ответственным за ИБ надо думать не о невзламываемости их сети/систем, а о том, как сделать так, чтобы, в случае "затопления отсека", не пострадала вся "подводная лодка".