- Наш профиль - продвинутые атаки!
- А почему пропустили вот эту?
- Эта атака - не продвинутая!!
В 2019 году мы принимали участие в тестировании по MITRE, базой для теста были техники, применяемые APT29. Наряду с другими участниками мероприятия, наше подразделение исследования угроз (Threat Researt) также готовило свое представление об этой группировке, что очень разумно. Результирующие сценарии тестирования являлись продуктом коллектива авторов, каждый из которых – участник тестирования.
Одной из техник, применяемой в тесте MITRE была Domain fronting (T1090.004). Техника, скажем прямо, не очень популярная, особенно сейчас, когда большинство нормальных CDN, уже исправили эту проблему (едва ли это уязвимость), поэтому, не думаю, что я сильно совру, если скажу, что Domain fronting в действии я видел только в рамках теста MITRE, в котором принимал участие в качестве аналитика MDR. Не буду в этой заметке тратить время на рассказ о том, как она работает, можно самостоятельно ознакомиться, например, здесь (см. обе части), или здесь. Техника известна где-то с 2016 года, в MDR мы ее детектируем с 2019 (насколько я вижу по нашему внутреннему трекеру). Для детектирования нужно раскрывать TLS (современные Endpoint-ы с этим справляются). На пальцах, само детектирование несложно: сравниваем SNI из рукопожатия TLS (доступно в трафике в открытом виде) c Host в заголовка HTTP или URL (закрыты TLS). Вот как SNI видно трафике (клиентский запрос TLS-рукопожатия, Client Hello):
Сетевые системы IDS не всегда раскрывают TLS (если они стоят на SPAN это сделать крайне затруднительно), поэтому, видя SNI, где атакующий подставляет какой-нибудь легитимный CDN, не срабатывают, а трафик далее идет туда, что указано в Host и скрыто от инспекции с TLS-шифрованием. Поэтому техника Domain fronting работает. И это очередной, и далеко не решающий, гвоздь в гроб сетевых систем обнаружения, не раскрывающих TLS. SSL/TLS в корпорации обязательно надо раскрывать, благо, сделать это на корпоративных АРМ не сложно.
Но в зрелых компаниях сетевые СЗИ раскрывают TLS и анализу подвергаются извлеченные из расшифрованного туннеля заголовок Host и URL ! Казалось бы, такое обнаружение вполне надежно, однако, в случае человекоуправляемой атаки, злоумышленник а) быстро понимает что его C&C обнаруживается и каким образом, б) может быстро придумать обход. Вероятно, об одной из таких попыток обхода, увиденной в реальном инциденте, и пойдет речь далее.
Мы обнаруживаем Domain fronting по событиям HttpRequest (сетевое соединение по протоколу HTTP/HTTPS). В нашей, не очень очевидной телеметрии, поле file_path в этом событии - это URL, на которое в итоге было обращение (содержимое заголовка Host - часть URL), а SNI - в поле remotecomputerfullname. Также, для понимания картинки ниже: processfilepath - процесс, инициировавший HTTPS-соединение, parentprocessfilepath - его родитель, processcmdline - его командная строка. Итак, в одном из инцидентов мы увидели вот такое событие:
Это событие инфраструктура MDR посчитала подозрительным и разметила хантами (этим жаргонизмом мы называем детектирующую логику в MDR, в EDR она именуется IoA), по которым подтянулись техники MITRE ATT&CK в поле enrich.hunts.techniques (префикс "enrich" наводит на мысль, что это обогащения события телеметрии). Среди техник видны: T1218.011, так как вредоносная DLL-ка запускается rundll32, а соответствующий хант - "сетевая активность от rundll32", что подозрительно (легитимных много, но их можно аккуратно отфильтровать); T1204.002, так как DLL (имя на картинке dinotify.dll, 14585E9BC1E9FCD3443F0E317450CEFA), предположительно, вредоносная, соответствующий хант здесь был "HTTP соединение от DLL, не имеющей репутации Good". Следует добавить, что позже файл был запрошен, проанализирован и, действительно, оказался вредоносным трояном, а, судя по его популярности в мире, разрабатывался специально для данной кампании.
Также на картинке мы видим технику T1090.004, срабатывающую, как я отмечал выше на несовпадение сайта из URL (file_path) и SNI (remotecomputerfullname), что можно видеть на картинке с событием. Однако, вместо ожидаемых легального SNI и вредоносного URL, мы видим обратное:
Немного поясню картинку: enrich.ksn_u.file_path.0.categories означает "обогащение поля телеметрии file_path репутацией KSN URL, смотрим категории сайта", соответственно, enrich.ksn_u.file_path.0.verdict - вердикт по сайту.
Т.е. атакующий открыто пытается пройти на свой C&C
а сетевые СЗИ, продвинутые, раскрывающие TLS, но детект которых построен на анализе URL, пропускают этот трафик, поскольку там легальный download.windowsupdate.com.
Мораль истории очень проста: если мы стали продвинутыми, научились раскрывать TLS, извлекать оттуда URL и анализировать его, не надо пренебрегать очевидными архаичными вещами, как анализ Destination IP и, в случае TLS, FQDN из SNI, опытный злоумышленник точно найдет эту "недоработку" и непременно воспользуется.
