# 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 лет в статусе «работает — не трогай», то теперь его либо засыплют сгенерированными правками, либо просто выкинут из апстрима ради снижения шума.

В Windows Server 2025 подписание SMB-трафика (SMB Signing) включено и обязательно по умолчанию для всех исходящих и входящих клиентских подключений.

Если просто накатить новую ОС или смигрировать файловый сервер без ревизии, мгновенно отвалятся:

Старые сетевые МФУ (сканирование по SMB в сетевую папку);

Древние офисные NAS и прошивки встроенных систем;

Недоконфигурированные Linux-хосты со старыми демонами Samba, где подпись отключена ради производительности.

# 1. Инвентаризация: считаем точное количество инстансов Server 2022 в домене
Get-ADComputer -Filter 'OperatingSystem -like "*Server 2022*"' |
  Measure-Object | Select-Object Count

# 2. Проверяем текущую политику требования подписи SMB на сервере и клиенте
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature

# 3. Аудит с хоста: смотрим, какие текущие сессии висят БЕЗ цифровой подписи (Signed = False)
Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Signed

Windows Server 2022 без проблем и спешки доживёт до 2031 года в статусе надёжной «рабочей лошадки».

Но если вы уже тестируете или закупаете лицензии под Server 2025, главная задача прямо сейчас — не перенос ролей, а инвентаризация сетевых шар и легаси-оборудования без SMB signing. Иначе в первый же день после миграции техподдержка утонет в тикетах «бухгалтерия не может отсканировать документы».

# Общий статус службы времени и синхронизации
timedatectl

# Текущее смещение, стратум и активный источник (chrony)
chronyc tracking

# Детальный список апстрим-серверов и их состояние
chronyc sources -v

# Общий статус службы Windows Time и текущее смещение
w32tm /query /status

# Фактический источник синхронизации для хоста
w32tm /query /source

# Замер расхождения времени с контроллером домена в реальном времени
w32tm /stripchart /computer:dc01 /samples:5 /dataonly

Протокол Kerberos по умолчанию допускает расхождение часов не более 5 минут.

Иерархия времени в инфраструктуре должна быть строго монолитной:

Внешний доверенный NTP-пул → PDC Emulator → остальные DC домена → рядовые серверы и клиенты.

Любая самодеятельность в этой цепочке превращается в причину «плавающих» и трудноуловимых сбоев входа в домен.

Ключевой тектонический сдвиг — полноценный S3 с поддержкой Immutability прямо из коробки.

Это готовый локальный таргет под неизменяемые бэкапы для Veeam Backup & Replication и Proxmox Backup Server без необходимости городить рядом костыли, сторонние контейнеры или отдельный кластер MinIO.

Однако статус Early Access обязывает: обкатывать технологию в лабах можно уже сейчас, но в боевой прод выводить строго после релиза 27.0 и первых корректирующих сервисных сборок (U1/U2).

# 1. Проверяем здоровье текущих пулов на ошибки и ребилд
zpool status -x

# 2. Проверяем доступность и статус критических фич OpenZFS
zpool get feature@raidz_expansion,feature@block_cloning <имя_пула>

# 3. Ревизия параметров датасетов (размер блока, сжатие, аллокация места)
zfs list -o name,used,avail,compression,recordsize

Стоп-запись: аварийный накопитель немедленно перемонтируется в

либо физически выводится из системы. Никаких проверок

или

на живом диске!

Посекторный образ: сначала снимается полный RAW-образ (встроенным модулем копирования DMDE либо утилитой

).

Работа со слепком: анализ структур и вычитка файлов проводятся исключительно с полученного образа, оригинальный диск убирается на полку.

Изолированный таргет: спасённые данные выгружаются на третий, заведомо исправный накопитель.

# Эталонное снятие посекторного слепка сыплющегося диска через ddrescue:

# 1. Быстрый проход: читаем всё целое, пропуская проблемные зоны и ведя лог-карту
ddrescue -n -b 4096 /dev/sdX /mnt/backup/disk.img /mnt/backup/disk.map

# 2. Добор битых секторов: до 3 попыток вычитки проблемных кластеров по карте
ddrescue -r3 -b 4096 /dev/sdX /mnt/backup/disk.img /mnt/backup/disk.map

# 1. Проверяем валидность лицензионного ключа и активный уровень подписки
pvesubscription get

# 2. Выгружаем точные версии установленных пакетов ядра и гипервизора
pveversion -v | head -5

# 3. Контролируем репозитории: enterprise-репозиторий должен быть активен без ошибок
ls -la /etc/apt/sources.list.d/

# 4. Снятие полного диагностического слепка ноды (базовый артефакт для любого тикета)
pvereport > /root/pvereport-$(hostname).txt

Наличие контракта 24/7 снимает формальный барьер у топ-менеджмента, но не отменяет законов физики: оно не заменяет локальный кворум Corosync, кластерный High Availability и отработанный план Disaster Recovery.

Дежурный инженер вендора в Вене или США в первую очередь запросит вывод

и системные журналы. Снимите и сохраните эталонный отчет

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

# 1. Считаем общее число JAR-файлов в локальной файловой системе (без сетевых шар)
find / -xdev -name '*.jar' 2>/dev/null | wc -l

# 2. Топ каталогов с наибольшей концентрацией JAR (где прячется JVM-софт)
find / -xdev -name '*.jar' 2>/dev/null | xargs -r dirname | sort | uniq -c | sort -rn | head

# 3. Инспекция «толстых» JAR/fat-JAR (Spring Boot) без полной распаковки архива
unzip -l app.jar | grep -E 'BOOT-INF/lib/.*\.jar' | awk '{print $4}'

# 4. Сборка полного SBOM (Software Bill of Materials) на лету через Syft
syft dir:/opt -o table | grep -i java-archive

Java прячется даже там, где вы её не ждёте:

В экосистеме 1С:Предприятие (1C:EDT, Сервер взаимодействия);

В CI/CD и мониторинге (Jenkins, Elasticsearch, Logstash);

Во внутренних системах документации (Confluence, Jira);

Во встроенных веб-консолях управления СХД, KVM и ИБП.

Урок Log4Shell показал: найти уязвимый компонент на сотне серверов занимает в разы больше времени, чем накатить патч. Снятый заранее SBOM превращает неделю судорожного поиска в один моментальный

.

Драйверы стороннего оборудования — самый объемный, гетерогенный и наименее надежный пласт кодовой базы ядра.

Сегодня любая ошибка адресации или use-after-free в драйвере сетевой карты либо HBA-адаптера мгновенно приводит к Kernel Panic и падению всей ноды (либо к локальному повышению привилегий). Технология Kage локализует сбой до уровня программного отказа отдельного устройства, сохраняя работу ОС и соседних сервисов.

# 1. Считаем общее число загруженных модулей ядра
lsmod | wc -l

# 2. Проверяем статус Tainted (0 = ядро чистое и стабильное, >0 = загружены проприетарные модули/были сбои)
cat /proc/sys/kernel/tainted

# 3. Выявляем модули, собранные вне основного дерева исходников ядра (out-of-tree)
for m in $(lsmod | awk 'NR>1{print $1}'); do
  modinfo -F intree "$m" 2>/dev/null | grep -q Y || echo "Вне дерева ядра: $m"
done