Cидим в офисе, пьём кофе и неспешно осваиваем новое ПО для анализа логов. Вдруг звонок от партнёра «Перспективного мониторинга» в одном из регионов: «Ребята, нашего заказчика, похоже, взломали. Тут вроде всё и очевидно, и как-то странно. Помогите разобраться». Заказываем билеты и в путь!
В любом расследовании инцидента информационной безопасности в первую очередь важно понять и выяснить кто, когда и как заметил, что инцидент произошёл или мог произойти. С этого человека и начинается расследования: как правило, если кто-то регулярно работает с информационным ресурсом, то лучше всех и понимает, как тот устроен и как должен нормально функционировать. Иногда заметить атаку очень просто — например, изменяется главная страница корпоративного сайта, или IDS фиксирует регулярные попытки перебора паролей, или пользователь получает «весёлое» сообщение криптолокера с требованием заплатить выкуп за данные. Иногда сложнее — компьютер внезапно стал тормозить, или вырос объём сетевого трафика.
На первый взгляд в нашем случае было как раз всё просто — сайт заказчика поменялся, хотя все редакторы и администраторы клялись, что не трогали его. Простейшая логика подсказывала — если у нас есть предыдущее состояние информационной системы (Ура! Они делали бекапы!) и есть текущее состояние, то ответ на все наши вопросы хранится где-то в изменениях.
Важно понимать, что киберпреступления совершают люди. И они всегда оставляют следы своего присутствия в информационной системе — как бы они ни старались их уничтожить или замаскировать. И обычно эти следы находятся в логах, дампах памяти, результатах работы специального программного обеспечения форензики.
Мы сформировали поверхность атаки со всеми возможными векторами атак и гипотезами, начиная от уязвимостей CMS (системы управления контентом) сайта и заканчивая осознанными вредоносными действиями администратора сайта. Чтобы понять, что происходит в ИТ-инфраструктуре организации, надо самому ненадолго стать системным администратором. Мы на практике выяснили, что сисадмины пострадавшей организации могут подробно ответить на 4 листа наших вопросов всего за каких-то пару часов. Это существенно дольше одной пиццы или трубки, но ведь и Ш. Холмс — персонал вымышленный, в отличие от сердитого руководства.
Благодаря этой сессии вопросов и ответов, мы смогли сократить число возможных гипотез в несколько раз. В данном случае мы могли проверить оставшиеся предположения прямо на «боевой» системе без особого риска что-то поломать и повлиять на доступность сайта и сервисов, хотя, конечно, так бывает далеко не всегда и приходится воспроизводить узлы инфраструктуры на стендах. Так мы отбросили ещё несколько гипотез.
Оставшиеся варианты атаки имели одну общую черту — действия совершались от имени легитимного редактора сайта. Логи CMS и сервера также говорили нам, что сама платформа не подвергалась атакам в период, непосредственно предшествовавший взлому сайта. Пароли администраторов и редакторов сайта были сложные и длинные, не поддающиеся перебору. На сервере хранились только хеши с «солью». Следов использования рабочих эксплойтов на CMS мы также не смогли обнаружить. Сложив эти факты, мы пришли к выводу, что злоумышленник знал логин и пароль администратора сайта, и приняли эту версию как наиболее вероятную.
И тут мы попали в ситуацию, которую не любит никто — ни ИТ- и ИБ-службы, ни сами исследователи — нужно было осмотреться вокруг, потому что сайт стремительно переставал быть главной нашей проблемой. Профессиональная паранойя подсказывала, что атаке подвергся не только он.
На второй итерации, когда мы уже могли уточнять вопросы сисадминам и администратору сайта согласно нашей рабочей версии, мы выяснили, что учётные данные однажды пересылались электронным письмом. Похоже, кроме сотрудников организации, кто-то ещё читал их почту. Не очень хорошая новость для ИТ и безопасников, правда?
В логах почтового сервера мы смогли отыскать доказательства компрометации около 30 учётных записей. Каждую неделю на протяжении почти полугода сервер отдавал почту по запросу легитимного (с точки зрения сервера) пользователя на определённый IP-адрес. Таких IP-адресов было около десятка, и каждый использовался для получения писем 3-4 пользователей. По этому списку мы и стали копать дальше.
И в этот момент нам невероятно повезло! В логах прокси-сервера мы нашли один из этих «плохих» IP-адресов, к которому шли непонятные регулярные обращения по протоколу http. Если перевести с машинного языка на человеческий, то кто-то регулярно маячил наружу «я тут», «я тут», «я тут».
Следы привели нас на рабочее место системного администратора, на нём мы нашли троян, который и обращался к своему командному серверу. Что заставило злоумышленников получать почту на IP-адрес командного сервера мы никогда не узнаем, но только благодаря этому просчёту мы смогли найти первопричину всех бед.
Исследователи «Перспективного мониторинга» в Москве провели реверс-инжиниринг вредоносного кода и смогли выяснить, что троян собирал метаинформацию обо всех офисных файлах, до которых мог дотянуться, упаковывал данные в зашифрованный архив и регулярно отсылал наружу. Анализ операционной и файловой систем компьютера показал, что троян попал на рабочую станцию через заражённый сайт.
Все логины и пароли почтовых учётных записей хранились в зашифрованном excel-файле на компьютере системного администратора. Мы предположили, что троян с помощью кейлогера получил пароль от этого файла и отослал злоумышленникам, поскольку видели взаимодействие троянского ПО и управляющего сервера в логах сетевого оборудования. Теперь мы точно знали, что искать на других машинах.
После того, как мы собрали информацию об инциденте, заказчик расследования запустил процессы восстановления. Мы помогли вернуть работоспособность затронутых атакой информационных систем и ресурсов. После анализа результатов расследования мы порекомендовали поменять настройку и состав средств защиты информации, чтобы предотвратить повторение инцидента в будущем или закрыть наиболее критичный вектор атак.
В данном конкретном случае мы не нашли виноватых внутри организации, да перед нами и не стояло такой задачи — нас позвали установить, что произошло, обнаружить затронутые ресурсы и выяснить, какие данные были скомпрометированы. ИТ- и ИБ-службы сделали то, что от них зависело — внедрили средства защиты информации и соблюдали базовые правила информационной безопасности. Просто иногда случаются успешные атаки. Мы обнаружили новый вектор и помогли его ликвидировать. То же самое мы делаем и при комплексных тестах на проникновение в информационные системы, когда исследуем сайты и веб-приложения, СУБД, сетевые службы и сервисы (электронная почта, прокси, VoIP, FTP и пр.), сетевое оборудование, беспроводные технологии, средства защиты информации, серверные и пользовательские операционные системы, прикладное ПО.
Часто бывает ситуация, когда нужно понять долговременную логику действий нарушителя внутри информационной системы, выявить определённые закономерности поведения. Тогда мы устанавливаем у заказчика сенсоры IDS и подключаем их к нашему коммерческому Центру мониторинга, где аналитики уже могут спокойно наблюдать за развитием событий, разобраться, что происходит, и «разобрать» вредоносный код. Инцидент информационной безопасности может обнаружить дежурная смена центра мониторинга или к нам может обратиться непосредственно владелец ресурса, как было в описанном случае, если в его информационной системе есть подозрительная активность, при которой внедрённые ранее средства защиты информации «молчат». При этом в атакованной организации может не быть подготовленных и свободных ресурсов или опыта для расследования инцидента. И тогда «Перспективный мониторинг» может помочь — amonitoring.ru.