Кампания KnockKnock атакует корпоративные email-аккаунты Office 365

Кампания KnockKnock атакует корпоративные email-аккаунты Office 365

Кампания KnockKnock атакует корпоративные email-аккаунты Office 365

Исследователи рассказали об атаке на почтовые учетные записи Office 365 Exchange Online, получившей имя KnockKnock. Целью злоумышленников являются организации в области производства, финансовых услуг, здравоохранения, потребительских товаров и государственный сектор США. В основном пострадали корпоративные email-аккаунты, которым не хватало настроенных политик безопасности.

Вредоносная кампания, о которой идет речь, основана на уникальной стратегии атаки на административные учетные записи, обычно используемые для интеграции корпоративных почтовых систем с программным обеспечением для автоматизации сбыта и продаж. Уникальность таких учетных записей в том, что они не привязаны к конкретному человеку, и требуют автоматического использования, как следствие, отличаются отсутствием защиты политиками безопасности, такими, например, как многофакторная аутентификация (MFA).

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

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

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

  • Хакеры использовали 63 сети и 83 IP-адреса для проведения своих атак.
  • Примерно 90 процентов попыток входа в систему поступали из Китая. Остальные были зафиксированы из России, Бразилии, США, Аргентины и еще 11 стран.
  • Атаковали отделы, связанные с инфраструктурой и IoT на крупных предприятиях, в таких отраслях, как производство, финансовые услуги, здравоохранение, потребительские товары, а также государственный сектор США.
  • Почти все пострадавшие учетные записи не принадлежали конкретному лицу, а были автоматизированы.

34% систем управления ЦОД работает на устаревших прошивках

Треть систем управления инженерной инфраструктурой ЦОД работает на устаревших прошивках. Специалисты «Информзащиты» изучили 66 395 BMS и выяснили, что неактуальное программное обеспечение установлено на 34% устройств. Но старая версия — лишь начало: 84% систем обмениваются данными по небезопасным протоколам, а 800 содержат известные эксплуатируемые уязвимости из каталога KEV.

Хуже всего обстоят дела с системами мониторинга электропитания: устаревшие прошивки обнаружены на 59% устройств. У OT-систем показатель составляет 48%, у BMS — 40%, у IoT-оборудования и интеллектуальных датчиков — 37%, у источников бесперебойного питания — 23%.

Обновлять такие системы сложнее, чем офисные компьютеры. Новую прошивку необходимо проверить на совместимость с контроллерами, датчиками, шлюзами и диспетчерским ПО.

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

Свежая прошивка тоже не волшебная таблетка. Около 84% BMS используют протоколы без достаточной аутентификации и шифрования, включая BACnet и MODBUS. Устройство может одновременно иметь старое ПО, известную уязвимость и принимать команды, толком не проверяя отправителя.

Напрямую из интернета доступны лишь 369 исследованных BMS — менее 1%. Однако закрытый внешний периметр не спасает: 14% систем в инфраструктуре ЦОД находились всего в одном сетевом переходе от связанного с интернетом узла. У PDU эта доля достигает 41%. Злоумышленнику достаточно взломать соседнюю ИТ-, IoT- или сетевую систему, а затем переместиться в технологический сегмент.

Эксперты рекомендуют провести инвентаризацию инженерных устройств, закрыть уязвимости KEV, изолировать BMS, контролировать подрядчиков и следить за командами в технологических протоколах. Потому что резервный контроллер с той же дырявой прошивкой — это не киберзащита, а второй шанс наступить на те же грабли.

RSS: Новости на портале Anti-Malware.ru