# 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 сам по себе. Главный вопрос: сколько утверждённых инструментов удаленного доступа разрешено регламентом вашей компании?

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

Созданные файлы:  /data/lib/liblog.so
                  /data/bin/webconsole
                  /data/etc/ld.so.preload
Модифицирован:    /bin/smit
Вредоносные IP:   79.141.169.187
                  45.129.0.192

Опасность: связка

+ инжектируемая библиотека

гарантирует перехват системных вызовов каждым процессом в ОС. Закрепление наглухо переживает штатные ребуты устройства.

# 1. Проверяем текущий билд
get system status

# 2. Включаем официальный Workaround: тушим IBE
config system encryption ibe
    set status disable
end

# 3. Ревизия открытых портов управления на внешних интерфейсах
show system interface

# Ищем следы контактов с известной инфраструктурой атаки
grep -E '79\.141\.169\.187|45\.129\.0\.192' /var/log/firewall/*.log

Почтовый ретранслятор обязан принимать SMTP-трафик снаружи (порты 25/587). Однако веб-интерфейс шифрования IBE и панель администрирования часто выставляются в интернет автоматически вместе с интерфейсом приёма почты.

Если IBE не используется в рабочих регламентах компании — отключите модуль немедленно.

Если функционал шифрованных писем необходим внешним адресатам — заворачивайте его строго за WAF / Reverse Proxy с белыми списками и жесткой валидацией URL.

Важно: хост с внедрённым

бессмысленно просто обновлять после выхода патча. Устройство подлежит полному вайпу, накату чистого образа «с нуля» и перевыпуску всех ключей и секретов.

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

# 1. Отключаем Windows Script Host (режет wscript/cscript, .wsf, .vbs, .js)
$wshPath = 'HKLM:\SOFTWARE\Microsoft\Windows Script Host\Settings'
New-Item $wshPath -Force | Out-Null
New-ItemProperty -Path $wshPath -Name Enabled -Value 0 -PropertyType DWord -Force

# 2. Переназначаем ассоциацию .hta на Блокнот вместо mshta.exe
cmd /c 'ftype htafile="%SystemRoot%\System32\notepad.exe" "%1"'

# 3. Включаем правила ASR (Attack Surface Reduction) в аудит-режим:
# - Блокировка запуска обфусцированных скриптов (5BEB7EFE-FD9A-4556-801D-275E5FFC04CC)
# - Запрет JS/VBS запускать исполняемый контент из сети (D3E037E1-3EB8-44C8-A917-57927947596D)
Add-MpPreference -AttackSurfaceReductionRules_Ids `
  D3E037E1-3EB8-44C8-A917-57927947596D, 5BEB7EFE-FD9A-4556-801D-275E5FFC04CC `
  -AttackSurfaceReductionRules_Actions AuditMode, AuditMode

# 4. Проверяем в Sysmon (Event ID 1) подозрительные вызовы mshta и GatherOsState
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1} -MaxEvents 5000 -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'mshta\.exe|GatherOsState\.exe' } |
  Select-Object -First 50 TimeCreated, Message

В этой атаке нет ни одной CVE. Стейджеры HTA/WSF, DLL sideloading легитимного бинарника и Scripted Diagnostics — это штатный инструментарий Windows, который 99% сотрудников компании не требуется для работы ни при каких обстоятельствах.

Утилиты

,

,

на машинах бухгалтерии, логистов или отдела кадров — это не инструмент, а готовый вектор компрометации.

Появление подписанного софта Microsoft (вроде

) во временных каталогах пользователя — верный признак инцидента.

Ветка       Исправленный релиз      Ветка       Исправленный релиз
──────────────────────────────────────────────────────────────────
20.9        20.9.10.1               20.18       20.18.4.1
20.12       20.12.8.2               26.1        26.1.2.1
20.15       20.15.6.1               26.2        26.2.1
──────────────────────────────────────────────────────────────────
Ветки < 20.9 — официальный EOL (только плановая миграция на 20.9+)

# 1. Поиск URL-encoded паттернов в логах реверс-прокси
grep -E 'POST /%[0-9a-fA-F]{2}_security_check' \
  /var/log/nms/containers/service-proxy/serviceproxy-access.log*

# 2. Аудит вызовов j_security_check и аномалий под служебными учетками viptela-reserved-*
grep -E 'j_security_check|viptela-reserved-' /var/log/nms/vmanage-server.log* | tail -100

# Сравниваем HTTP-коды ответа на прямой и URL-encoded запросы
curl -sk -o /dev/null -w 'Декодированный путь: %{http_code}\n' https://<host>/j_security_check
curl -sk -o /dev/null -w 'Экранированный путь (%6a): %{http_code}\n' https://<host>/%6a_security_check

Корень проблемы — CWE-177 (URL Parsing/Discrepancy). Это фундаментальная проблема многослойных архитектур: когда фронтенд-фильтр (WAF, Envoy, Nginx, внутренний контейнер-прокси) и целевой бэкенд (Spring/Tomcat) нормализуют URL по разным стандартам.

Золотое правило: валидатор прав и обработчик бизнес-логики обязаны работать с одинаково канонизированным представлением строки запроса.

Четыре критических обхода авторизации подряд на одном продукте за год — четкий сигнал: консоль управления SD-WAN Manager нельзя считать доверенной по умолчанию, даже если на нее накачены прошлые обновления.

# 1. Какие типы хешей фактически задействованы в ваших текущих InRelease
grep -hoE '^(MD5Sum|SHA1|SHA256|SHA512|SHA3-[0-9]+):' \
  /var/lib/apt/lists/*InRelease 2>/dev/null | sort | uniq -c

# 2. Поиск устаревших GPG-ключей репозиториев (RSA 1024, DSA и legacy-форматы)
for k in /etc/apt/trusted.gpg.d/* /usr/share/keyrings/*; do
  [ -f "$k" ] || continue
  echo "== Файл: $k"
  gpg --show-keys "$k" 2>/dev/null | grep -E '^pub'
done

В криптографии это называется crypto-agility (криптографическая гибкость) — способность инфраструктуры переключиться на новые криптопримитивы без необходимости менять сам софт и переустанавливать ОС на клиентах.

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

# 1. Только ошибки (от err и выше) с момента текущего старта системы
journalctl -p err -b

# 2. Логи конкретного сервиса за последний час
journalctl -u nginx --since "1 hour ago"

# 3. Режим live-мониторинга (аналог tail -f) по конкретной службе
journalctl -u ssh -f

# 4. Список всех зафиксированных загрузок ОС (с их ID и временными метками)
journalctl --list-boots

# 5. Сообщения ядра (dmesg) за ПРЕДЫДУЩУЮ загрузку (ключевое при анализе падений)
journalctl -k -b -1

# 6. Фильтр по исполняемому файлу в чистом текстовом выводе
journalctl _COMM=sshd -o cat | grep -i 'failed'

# 7. Выборка событий в жестком временном окне
journalctl --since "2026-10-05 09:00" --until "2026-10-05 10:00"

# 8. Просмотр структуры записи со всеми служебными метаполями (для построения точных фильтров)
journalctl -o json-pretty -n 1

# 9. Проверка дискового пространства, занятого журналами прямо сейчас
journalctl --disk-usage

# 10. Ротация и очистка архивов старше 30 дней
journalctl --vacuum-time=30d

# Проверка наличия каталога постоянного хранения
ls -d /var/log/journal 2>/dev/null && echo "Логи пишутся на диск" || echo "ВНИМАНИЕ: логи живут только в RAM до ребута!"

# Проверка конфигурации лимитов
grep -E '^(Storage|SystemMaxUse)' /etc/systemd/journald.conf

# Включение постоянного хранения логов на диске
mkdir -p /var/log/journal && systemctl restart systemd-journald

Связка флагов

и

закрывает 80% всех типовых инцидентов из серии «почему сервер упал ночью».

Персистентное хранилище на диске с жестко зафиксированным лимитом

в

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

Нейросети драматически удешевили поиск и генерацию отчетов, но валидация и исправление по-прежнему требуют дефицитного ресурса — внимания живого сеньор-инженера.

Патч-менеджмент ускорится в разы: AI выгребает пыльные углы кодовой базы, поэтому поток минорных CVE и обновлений ядра будет нарастать лавинообразно.

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

Внутренний саппорт ждёт то же самое: службы Helpdesk и Security-команды скоро захлебнутся во входящих баг-репортах и сканах уязвимостей, сгенерированных пользователями через локальные AI-агенты.

# 1. Физические сетевые контроллеры и активные модули ядра
lspci -k | grep -A2 -i ethernet

# 2. Быстрая привязка: сетевой интерфейс -> загруженный драйвер
for i in /sys/class/net/*; do 
  [ -e "$i/device/driver" ] && echo "$(basename "$i"): $(basename "$(readlink "$i/device/driver")")"
done

Если раньше драйвер мог тихо и стабильно работать 15 лет в статусе «работает — не трогай», то теперь его либо засыплют сгенерированными правками, либо просто выкинут из апстрима ради снижения шума.