Вектор эксплойта опирается на классический cBPF, который по умолчанию открыт любому пользователю системы через штатные сокет-фильтры (

).
Режим

(constant blinding) исследователи также обошли: атака замедляется, но всё равно занимает смешные 5 минут. Единственное реальное лечение — ядро с патчем.

# 1. Смотрим текущую версию ядра
uname -r

# 2. Проверяем состояние BPF и механизмов защиты
sysctl net.core.bpf_jit_enable net.core.bpf_jit_harden kernel.unprivileged_bpf_disabled

# 3. Проверяем, можно ли в теории отключить BPF JIT (если =y — флаг зашит намертво)
grep CONFIG_BPF_JIT_ALWAYS_ON /boot/config-$(uname -r)

# 4. Проверяем алгоритм хеша root в /etc/shadow:
# $y$ = yescrypt (хорошо), $6$ = SHA-512 (нормально), $1$ = MD5 (катастрофа)
awk -F: '$1=="root"{print substr($2,1,3)}' /etc/shadow

# 5. Проверяем доступность обновлений ядра в дистрибутиве
apt update && apt list --upgradable 2>/dev/null | grep -E 'linux-image|proxmox-kernel'

# 1. Поиск сервисных учеток (с SPN) без явного AES или застрявших на RC4
Get-ADUser -LDAPFilter '(&(servicePrincipalName=*)(|(!(msDS-SupportedEncryptionTypes=*))(msDS-SupportedEncryptionTypes=4)(msDS-SupportedEncryptionTypes=7)))' `
  -Properties servicePrincipalName, msDS-SupportedEncryptionTypes, PasswordLastSet |
  Select SamAccountName, msDS-SupportedEncryptionTypes, PasswordLastSet

# 2. Мониторинг запросов билетов с шифрованием RC4 (TicketEncryptionType = 0x17)
Get-WinEvent -LogName Security -MaxEvents 2000 -FilterXPath `
  "*[System[EventID=4769] and EventData[Data[@Name='TicketEncryptionType']='0x17']]" |
  ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data |
    Where-Object { $_.Name -in 'TargetUserName','ServiceName','IpAddress' } |
    ForEach-Object { "$($_.Name)=$($_.'#text')" } } | Select-Object -First 60

# 3. Проверка событий KDC в журнале System (ошибки согласования типов шифрования)
Get-WinEvent -FilterHashtable @{
    LogName      = 'System'; 
    ProviderName = 'Microsoft-Windows-Kerberos-Key-Distribution-Center'; 
    Id           = 201..209
} -MaxEvents 50 -ErrorAction SilentlyContinue

# Шаг 1. Явно разрешаем использование современных типов шифрования
Set-ADUser svc_app -KerberosEncryptionType AES128,AES256

# Шаг 2. ОБЯЗАТЕЛЬНО меняем пароль (только в этот момент генерируются хеши AES!)
Set-ADAccountPassword svc_app -Reset

# Шаг 3. Перевыпускаем keytab для Linux-хостов с поддержкой AES256
# Через ktpass:
# ktpass /princ HTTP/app.corp.local@CORP.LOCAL /pass * /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL /out app.keytab
# Либо через msktutil:
# msktutil --enctypes 0x18 --auto-update

Времени на плавную раскатку больше нет — фолбэка нет физически. Отдельный маркер при ревизии: колонка

. Если у сервисной учетки пароль не трогали с 2012 года, то помимо отсутствия AES-ключей вы получаете готовую дыру для атак Kerberoasting с мгновенным подбором слабого хеша в офлайне.

# 1. Проверяем системную версию и установленные пакеты
openssl version -a
dpkg -l | grep -E 'libssl[0-9]' || rpm -qa | grep -i openssl

# 2. Ищем слушающие UDP-порты (потенциальные сервисы DTLS)
ss -lunp

# 3. Смотрим, какие процессы держат системную библиотеку прямо сейчас
lsof -nP 2>/dev/null | grep -E 'libssl\.so' | awk '{print $1,$2}' | sort -u

# 4. Проверяем бинарники со встроенной/статической линковкой OpenSSL
strings -a /usr/sbin/ocserv 2>/dev/null | grep -m1 -E '^OpenSSL [0-9]'

Сама по себе

— не повод для ночных дежурств: эксплуатация нестабильна, завязана на специфичный тайминг потери UDP-пакетов, а атак «в поле» пока нет.

Настоящий риск — неконтролируемый OpenSSL 3.0. Сейчас идеальный момент провести инвентаризацию: пока дыра относительно мягкая, нужно найти все изолированные бинарники и виртуальные аплайнсы, собранные на 3.0, и затребовать роадмап у вендоров до появления первого «дикого» zero-day.

# 1. Проверяем установленную версию Zammad (deb/rpm пакет)
zammad run rails r 'puts Version.get'

# 2. Если развернуто в контейнерах (Docker Compose)
docker compose exec zammad-railsserver rails r 'puts Version.get'

# 3. Проверяем доступность веб-интерфейса извне (отдаёт ли 200/302)
curl -sI https://helpdesk.example.ru | head -1

# 4. Форензика: подозрительные процессы и сессии от сервисного юзера zammad
ps -u zammad -o pid,lstart,cmd
last -n 50
journalctl _UID=$(id -u zammad) --since "2026-09-01" | tail -50

Helpdesk, корпоративная Wiki, CRM и внутренние трекеры, смотрящие в мир «для клиентов и подрядчиков», должны проектироваться и изолироваться с той же паранойей, что и публичный почтовый сервер.

Категория риска                         Целевой срок устранения
───────────────────────────────────────────────────────────────
CISA KEV + сервис торчит наружу         48 часов (авральный режим)
CISA KEV, изолированный внутренний узел 7 календарных дней
EPSS > 0.5 либо публичный рабочий PoC   14 дней
Critical / High общего профиля          30 дней
Medium и ниже                           Плановый цикл (спринт / релиз)
───────────────────────────────────────────────────────────────
Невозможно закрыть в срок:              Только через письменное 
                                        согласование исключения:
                                        конкретный владелец + 
                                        дедлайн пересмотра

python3 - <<'EOF'
import csv, datetime as d

now = d.date.today()
buckets = {'0-30': 0, '31-90': 0, '90+': 0}

with open('findings.csv', mode='r', encoding='utf-8') as f:
    for r in csv.DictReader(f):
        if r.get('severity', '').lower() not in ('critical', 'high'):
            continue
        try:
            first_seen = d.date.fromisoformat(r['first_seen'][:10])
            age = (now - first_seen).days
            bucket = '0-30' if age <= 30 else '31-90' if age <= 90 else '90+'
            buckets[bucket] += 1
        except (ValueError, KeyError):
            continue

print("=== ВОЗРАСТ УЯЗВИМОСТЕЙ CRITICAL / HIGH ===")
for k in ('0-30', '31-90', '90+'):
    print(f"{k:>6} дней: {buckets[k]}")
EOF

Основной ступор кроется не в нехватке времени у админов, а в размытой ответственности. У висящей месяцами дыры банально нет персонального владельца системы.

Срок без назначенного инженера превращается в пустой звук.

Инженер без жесткого дедлайна откладывает патч до первой аварии.

«Временное исключение» без зафиксированной даты пересмотра навсегда хоронит проблему в бэклоге.

# 1. Проверяем текущее значение ключа (если ключа нет — работает дефолт ОС)
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 /v BlockNtlmv1SSO

# 2. Ищем попытки NTLMv1 SSO и факты блокировок в журнале NTLM
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' `
  -FilterXPath '*[System[EventID=4024 or EventID=4025]]' -MaxEvents 50 -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Id, Message

# 3. Проверяем статус Credential Guard (наличие службы 1 = активно)
(Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard).SecurityServicesRunning

# 4. Проверяем на сервере NPS, какие сетевые политики завязаны на MS-CHAPv2 / PEAP
netsh nps show np

Это не внезапный 0-day, а планомерный вывод легаси-технологий.

Главная засада — скрытый паттерн сбоя: новенькие ноутбуки с Windows 11 24H2 в понедельник внезапно не смогут подключиться к офисному Wi-Fi, тогда как парк на Windows 10 продолжит работать штатно. Первая реакция инженеров первой линии — «сломалась точка доступа или контроллер Wi-Fi», хотя проблема сугубо в аутентификации.

PEAP-MSCHAPv2 — это по сути устаревшая парольная аутентификация, несущая в себе хвосты NTLM.

Единственный стратегически верный шаг — переход на EAP-TLS. Сертификаты компьютеров выпускаются автоматически через AD CS. В этом сценарии пароли и NTLM в сетевом обмене не участвуют вовсе.

Выставить через GPO

— это временный костыль для тушения пожара, а не решение проблемы.

# 1. Поиск статичных файлов kubeconfig на раннере (их не должно быть на диске!)
find / \( -path '*/.kube/config' -o -name '*kubeconfig*' \) -type f 2>/dev/null

# 2. GitLab Runner: проверяем опасные директивы (privileged и смонтированный сокет докера)
grep -nE 'privileged|docker.sock' /etc/gitlab-runner/config.toml

# 3. Мониторинг скрытых туннелей и RMM-утилит на хосте раннера
ps -eo pid,user,lstart,cmd | grep -Ei 'chisel|ngrok|frpc|frps|atera' | grep -v grep

# 4. Проверка истории Git на случайную утечку сертификатов и ключей кластера
git log --all --oneline -S 'client-key-data'
git log --all --oneline -S 'BEGIN OPENSSH PRIVATE KEY'

# 5. Ревизия суперпользователей в Kubernetes: кто держит права cluster-admin
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") | .metadata.name + " -> " + ([.subjects[]?.name]|join(","))'

Здесь не было эксплойтов. Атакующие двигались строго по рельсам штатного функционала: сброс пароля → коммит в репозиторий → запуск пайплайна → легитимный агент техподдержки.

Права на коммит = права раннера. Раннер вслепую выполнит любой шелл-код, который прилетел в ветку. Если у сборочной ноды есть доступ к прод-кластеру, то любой разработчик с правом пуша в репозиторий (или тот, кто увел его учетку) фактически держит права уровня root на боевой инфраструктуре.

Постоянный kubeconfig — мина замедленного действия. Хранить статичный

с ролью

в переменных CI/CD или на диске раннера — грубейшая ошибка.

Смена факторов MFA — это критический инцидент. Удаление старых методов MFA или добавление нового аутентификатора должно генерировать мгновенный алерт дежурному инженеру ИБ, а не просто оседать строкой в архиве логов.

$rmmPattern = 'AnyDesk|TeamViewer|Atera|ScreenConnect|ConnectWise|Splashtop|RustDesk|' +
              'Remote Utilities|rutserv|LiteManager|Ammyy|AeroAdmin|RuDesktop|' +
              'MeshAgent|NetSupport|Radmin|ngrok|chisel'

$pcs = (Get-ADComputer -Filter 'Enabled -eq $true').Name

Invoke-Command -ComputerName $pcs -ErrorAction SilentlyContinue -ScriptBlock {
    param($pattern)
    
    # Поиск зарегистрированных служб
    $services = Get-CimInstance Win32_Service | 
        Where-Object { $_.Name -match $pattern -or $_.DisplayName -match $pattern -or $_.PathName -match $pattern }
    
    # Поиск записей в деинсталляторах (реестр 32/64-bit)
    $installed = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
                                  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' | 
        Where-Object { $_.DisplayName -match $pattern }
    
    $services | ForEach-Object { 
        [PSCustomObject]@{ Type = 'Service'; Name = $_.DisplayName; Path = $_.PathName } 
    }
    $installed | ForEach-Object { 
        [PSCustomObject]@{ Type = 'Installed'; Name = $_.DisplayName; Path = $_.InstallLocation } 
    }
} -ArgumentList $rmmPattern |
Select-Object PSComputerName, Type, Name, Path |
Export-Csv .\rmm_inventory.csv -NoTypeInformation -Encoding UTF8

# Процессы: ищем туннели, агенты и реверс-прокси
ps -eo pid,user,lstart,cmd | grep -Ei 'chisel|ngrok|frpc|gost|meshagent|rustdesk|anydesk' | grep -v grep

# Службы systemd: проверяем зарегистрированные демоны
systemctl list-units --type=service --all | grep -Ei 'chisel|ngrok|frp|mesh|rustdesk|anydesk'

# Сеть: ищем установленные наружу соединения
ss -tnp state established | grep -Ei 'chisel|ngrok|frpc'

Вопрос не в том, «хорош» или «плох» AnyDesk сам по себе. Главный вопрос: сколько утверждённых инструментов удаленного доступа разрешено регламентом вашей компании?

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