История (не)заплаченных биткоинов
- Для кого:
- CISO, эксперты по сетевой безопасности
- Скиллы:
- Сетевая безопасность
- PT NAD

Когда ИТ- и ИБ-подразделения компании сфокусированы на безусловно важной, но одной-единственной задаче поддержания части бизнеса, которая приносит основной доход, зачастую случаются различные истории. Так произошло и с компанией «Пятница». Цепочка обстоятельств сложилась в полноценную историю (не)заплаченных биткоинов, в которой традиционно все совпадения случайны, а все персонажи вымышлены.
Знакомьтесь, компания «Пятница». Она уже достаточно давно на рынке и занимается поставками премиального кофе и кофемашин. Рынок, для которого работает «Пятница», довольно широк, клиенты разные. Есть и B2B, и B2C. География присутствия тоже обширна: 168 точек продаж расположены по всей стране. Кроме того, несколько лет назад был выход на рынки стран Ближнего Востока и СНГ.
Бизнес компании устойчиво растет и развивается. Несмотря на внушительное количество филиалов, 80% прибыли генерирует интернет-магазин. Он имеет собственное приложение, которое пользователи могут найти во всех популярных магазинах приложений. Клиенты компании им активно пользуются.
Команда, которая занимается разработкой приложения, сфокусирована на его работоспособности и удобстве. А подразделение компании, отвечающее за информационную безопасность, практически все свое рабочее время уделяет тому, чтобы это приложение было защищено от ИБ-угроз.
Вся деятельность компании сосредоточена вокруг этого генератора прибыли. Зачастую в ущерб работоспособности и безопасности других информационных систем. При этом у сотрудников, поддерживающих эти системы, всегда рядом «отвлекающие» факторы, например требования регуляторных органов. Более того, выйдя на международный рынок, компания столкнулась с многообразием нормативных документов и запутанностью требований по защите персональных данных в различных странах.
О компании «Пятница»

Как вы уже догадались, это «ж-ж-ж» неспроста — что-то должно случиться. И мы расскажем об этом «что-то», используя стадии принятия неизбежного.
Отрицание
«Во всем виноват провайдер. Ну конечно же, он»
В один понедельник поступил неприятный для службы поддержки пользователей звоночек. Первая линия поддержки столкнулась с медленной скоростью работы интернет-каналов связи. Нельзя было сказать, что информационные сервисы компании совсем перестали работать. Нет, самый важный актив — интернет-магазин —продолжал функционировать. Разработчики приложения не зря ели свой хлеб, и оно было прекрасно адаптировано к нестабильным каналам связи. По этой причине значимого внимания возникшей проблеме уделено не было.
Отрицая наличие проблем для бизнеса, ИТ-шники компании попытались решить проблему: рекомендовали не смотреть на рабочих местах HD-видео и не загружать торренты. Поняв, что советы не помогают, ИТ-служба открыла запрос в службу поддержки интернет-провайдера компании. Потому что каждый раз, когда скорость подключения к интернету падает, во всем виноват провайдер. Ну а кто же еще?
Торг
Ближе к утру пятницы компания находилась уже на стадии торга с поставщиком услуг интернет-каналов. Заявок от пользователей было очень много. Пожалуй, каждая первая заявка была с темой «Проблемы с интернетом».
Понимая, что на провайдера уже нет никакой надежды, ИТ-шники решили взять ситуацию в свои руки и стали самостоятельно и пристально изучать проблему.
Гнев
В конце пятницы, перейдя в стадию гнева, один из сетевых инженеров решил оценить состояние пограничного маршрутизатора. Инженер не делал этого раньше, потому что это казалось нелогичным. Ведь сервис по-прежнему работал, хоть и медленно, а система мониторинга не показывала ничего подозрительного.
Обратив внимание на таблицу трансляций сетевых адресов (см. рис. 1), специалист увидел, что количество запросов ко внутренним ресурсам по протоколу SSH достаточно велико. Это вызвало у него некоторые сомнения. С одной стороны, он знал, что в компании есть внутренние сервисы, которые «выставлены» наружу по разным причинам. С другой, подключений SSH было подозрительно много.

Но за окном — 18:30, окончание рабочей недели, друзья и коллеги инженера уже полчаса как сидят в ближайшем баре и опрокидывают уже не первый стакан кефира. Конечно же, инженер решил оставить уточнение причины аномалии в таблице трансляции сетевых адресов до лучших времен: разобраться на следующей неделе.
Депрессия
Увы, в ночь с пятницы на понедельник случается непоправимое. В выходные останавливается бизнес компании. Все критически важные системы, благодаря которым осуществлялись продажи, оказываются зашифрованными. Интернет-магазин «Пятницы» перестает работать. Клиенты компании при попытке заказать кофе видят на экранах своих устройств ошибку подключения. В точках офлайн-продаж не работают кассы. Клиенты не могут выполнить транзакцию и рассчитаться за заказанный кофе.
В этот момент мне позвонил CEO компании Марат Пятничный. По голосу Марата сразу стало понятно, что что-то случилось. А его первые слова: «Мы все потеряли, пожалуйста, помоги» — только подтвердили эту догадку.
Начав разбираться с проблемой, мы поняли, что зашифрованы не только бизнес-системы, но и немногочисленные бэкапы, на которые у Марата были надежды. Дела совсем плохи… Незашифрованными остались несколько серверов, хранящих копии сетевого трафика. С них мы начали расследование.
Разбор событий той недели необходимо начать с вечера пятницы, когда сетевой инженер обнаружил подозрительные NAT-трансляции на граничном маршрутизаторе. Уверен, вы прекрасно осведомлены, что инструмент просмотра таблицы трансляции сетевых адресов — это в первую очередь средство поиска неисправностей, а не что-то другое. Поэтому инженер и не смог вовремя сделать правильные выводы. Установленные сессии с большим объемом передаваемых данных — это красный флаг, требующий немедленного реагирования. Определить такие сессии позволяет PT NAD.

Обратите внимание на количество SSH-подключений к внутреннему адресу сети «Пятницы» (см. рис. 2). Адреса специально скрыты, но они — из блока RFC 1918. Если вы посмотрите, каким странам принадлежат сетевые адреса источников подключений, то контекст будет чуть более понятен. Прямо сейчас откройте любой WHOIS-сервис и посмотрите принадлежность адреса 211.143.255.70.
Большая часть сессий должна вызвать вопросы, потому что для управляющего соединения SSH их размер совершенно ненормальный. Размер одной из них — 11 Мбайт. На нее нужно взглянуть более внимательно (см. рис. 3).

Совсем не похожа на честный SSH. И модуль анализа PT NAD прямо об этом сообщает: клиент — FileZilla, а тип сессии — протокол передачи файлов SFTP.
А что с другими сессиями (см. рис. 4)?

Вот теперь действительно SSH. Но какой? С предустановленным паролем? Ручками нажатым? Да еще и не с первого раза? На все три вопроса ответ — да. Это говорит модуль анализа SSH и намекает, что если вы до сих пор используете парольную фразу для аутентификации SSH на серверах, доступ к которым никак иначе не контролируется, то нужно это срочно исправлять. Да и общий харденинг также необходим. Я очень люблю пользоваться для этого шпаргалкой.
https://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.htmlВернемся к расследованию и посмотрим на сессии, источниками которых является уже сам атакуемый сервер.

Увы, но утилита аудита Windows-инфраструктуры в этом случае является инструментом разведки для злоумышленника, который изучает обстановку внутри ИТ-систем «Пятницы». К сожалению, проведенный им «аудит» привел к еще более печальным последствиям.

А именно — к процессу эксфильтрации данных. Вероятнее всего, через неделю-другую эти данные можно было бы обнаружить на ближайшей торговой площадке даркнета, а новостные ленты пестрили бы заголовками об утечке. «Пятница» не только столкнулась с остановкой бизнеса, но и рисковала получить огромные репутационные потери.
Думаю, что вы уже догадываетесь. Кульминация близко. Остается понять, как это произошло.

Серия событий «Удаленное создание или изменение задач планировщика Windows» (см. рис. 7) не кажется подозрительной, на первый взгляд. Вы, пожалуй, согласитесь, что это вполне легитимное действие, до тех пор, пока не обратите внимание на время появления событий. И вот это уже странно. При клике на одно из них все тут же становится на свои места.

Принятие
Наконец, вы видите процесс шифрования активов компании. Но стало ли от этого легче Марату? Нет. Скорее всего, Марат заплатил бы вымогателям за восстановление своего бизнеса.
Почему в предыдущем абзаце — только догадки о действиях CEO компании? Пожалуй, пора раскрыть скобки и уточнить, что наша история все же о незаплаченных биткоинах.
Знакомьтесь, компания «Пятница». Она все так же успешна, и так же радует своих клиентов качественным кофе. Все, что о ней было написано в начале статьи, верно, за исключением одного. Марат, когда понял, что бизнес уверенно растет и во многом полагается на информационные системы, своевременно решил, что стратегия «предотвратить», а не «расследовать» куда более выгодная и надежная. В течение многих лет партнером «Пятницы» по информационной безопасности является Positive Technologies.
Вернемся в утро того понедельника, когда прозвенел первый звоночек и была предпринята попытка взлома компании (см. рис. 2).
Ровно в этот момент моментально отреагировали парни и девушки из ИБ-отдела «Пятницы». Заметив подозрительные события, о которых сообщил PT NAD, они написали инженерам, которые отвечают за эксплуатацию сети компании. Они попросили незамедлительно закрыть доступ к активу, на который идет атака. И затем приняли все необходимые меры, чтобы и бизнесу было удобно продолжать свою деятельность, и компания не понесла убытков.
Специалисты из отдела эксплуатации сети, имея в распоряжении не менее профессиональный NGFW, написали два простых правила, которые решили проблему, оставив грустить еще одного злоумышленника.

И напоследок. Мне нравится аналогия с лампочкой. Если взять пустую квартиру, повесить в ней люстру, вкрутить лампочку, то эта лампочка осветит проблему отсутствия дивана. Не более того. Точно так же и в информационной безопасности. Инфобез — это не про систему мониторинга, не про межсетевой экран и даже не про людей или команду. Только комплексная реализация стратегии информационной безопасности позволит рассказывать именно о НЕзаплаченных биткоинах. Опыт Positive Technologies это лишний раз подтверждает.
Я рекомендую посмотреть доклад об архитектуре центра предотвращения киберугроз. В нем Михаил Кадер, архитектор решений по информационной безопасности, Positive Technologies, рассказывает об идеях реализации комплексного подхода к ИБ.
Из других полезных ссылок, которые я храню у себя в закладках: для усиления защиты Linux-инфраструктуры, пожалуйста, используйте шпаргалку.