Специалисты из Лаборатории Касперского в рамках проекта Kaspersky Security Bulletin продолжают моделировать и пытаться предвидеть развитие финансовых угроз и crimeware, ежегодно анонсируя свои прогнозы по возможным трендам на будущий год с оценкой заявленных в предыдущем периоде.

В целом большинство прогнозов на 2023 год оказались верными: развитие новых угроз в мире Web3 и криптовалют, рост популярности загрузчиков вредоносного ПО на теневом рынке и изменение мотивов вымогателей, которые сосредоточатся на разрушительных (в частности, политически мотивированных) атаках.

Прогноз об активном использовании новых средств для тестирования на проникновение в преступных целях в целом не оправдался — ресерчеры не наблюдали в атаках новых популярных фреймворков, отличных от Cobalt Strike и Brute Ratel C4.

Вопреки ожиданиям ЛК, операторы ransomware остались верны битку, при этом они полагаются миксеры для маскировки своих транзакций.

А в 2024 году исследователям придется решать множество сложных задач и противостоять все более изощренным TTPs злоумышленников, эксплуатирующих уязвимости финансовых систем. Ожидается, что:

- Стремительно возрастет количество кибератак с использованием технологий машинного обучения. Такой подход приведет к росту числа непрофессиональных атак — порог вхождения в эту нишу снизится, при этом возрастут шансы обмануть жертву.

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

- Системы автоматического перевода (ATS), при котором банковский зловред совершает транцзакции, как только пользователь входит в банковское приложение, будут использоваться хакерами по всему миру.

- Многие киберпреступники из Восточной Европы переключились на шифровальщики, отказавшись от зловредов для онлайн-банкинга. Освободившуюся нишу могут занять бразильские банковские троянцы. Эти и другие семейства будут активно распространяться по миру, претендуя на звание нового ZeuS.

- Вымогатели будут тщательнее выбирать цели, делая атаки на финансовые организации более целенаправленными и разрушительными.

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

- Атак с использованием 0-day станет меньше, а количество уязвимостей первого дня возрастет. Преступники также будут чаще обращать внимание на ошибки в конфигурации устройств и сервисов.

- Экосистема киберпреступных групп станет более гибкой — ее участники будут переходить из одной группы в другую или работать на несколько групп одновременно.

- Для создания вредоносного ПО и эксплуатации уязвимостей будут применяться менее распространенные кроссплатформенные языки программирования, такие как Golang и Rust, что усложнит обнаружение угроз и противодействие им.

- На фоне социально-политических конфликтов возрастет активность хактивистов, чья цель — вывести из строя критическую инфраструктуру и службы.

https://ruler-project.github.io/ruler-project/

Проект направленный на документирование какие именно логи полезно собирать для расследования.

Так как нашей команде Luntry часто приходится участвовать в различных проектах по безопасности Kubernetes систем: аудиты, пентесты, архитектурные проекты. То приходится порой думать о некоторых моментах, к которым просто так не придешь, никогда об этом не задумываясь. Одним из таких последних моментов был момент, когда требовалось понять стоит ли определенные высокопривелигерованные микросервисы (там хороший SA) располагать в одном Namespace или расселить на разные. При решении этой задачи как раз и пригодился наш атакующий опыт.

Смысл заключается в том, что если у злоумышленника на Node есть возможность создать Pod в таком Namespace (где и эти высокопривелигерованные сервисы), даже с учетом того что стоит множества правильных политик PolicyEnginе (против Bad Pods и тд), то у него все равно остаётся возможность смонтировать внутрь такого Pod интересующий его SA из того же самого Namespace! Далее когда он смонтируется туда, то можно смело забирать его с Node ...

Как митигейшены можно сделать следующее:
1) Чтобы уменьшить риск компрометации, критичные сервисы разделать по Namespaces
2) Namespaces c критичными/инфраструктурными сервисами привязывать только к определенным инфраструктурным Nodes
3) Писать политики PolicyEngine, которые проверяют использование критичных SA, только в определенных сервисах

P.S. Еще была крутая идея для атаки - все это провернуть через StaticPod, но там нельзя ссылать на другие ресурсы (на тот же SA)…

P.S.S. Ближайшие дни мы на HighLoad++ 2023 Msk и будем рады пообщаться лично =)

Моя первая презентация с вчерашнего #soctech про мониторинг угроз от|на подрядчиков. Я специально сделал disclaimer во время выступления, что, во-первых, вариантов угроз на цепочку поставок достаточно много (от аппаратных имплантов до несанкционированных действий сотрудников подрядчиков), а во-вторых, по каждой из них можно отдельно говорить не менее 20 минут, а у меня на все было 20 минут. Так что в презентации некоторые мысли о том, на что стоит обратить внимание...