Microsoft призналась, что потеряла часть клиентских логов безопасности

Microsoft призналась, что потеряла часть клиентских логов безопасности

Microsoft призналась, что потеряла часть клиентских логов безопасности

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

Первым на проблему указало издание Business Insider, сославшееся на официальное уведомление Microsoft.

Судя по всему, баг затронул логи безопасности в период со 2 по 19 сентября. В них содержалась информация о мониторинге подозрительного трафика, странного поведения и попыток аутентификации в сети.

По словам самой Microsoft, инцидент затронул следующие сервисы:

  • Microsoft Entra: логи, в которые записывались попытки входа и активность, оказались неполными.
  • Приложения Azure Logic: провалы в данных телеметрии, затрагивающие настройки Log Analytics, Resource Logs и Diagnostic.
  • API Azure Healthcare: частично обрывистые логи диагностики.
  • Microsoft Sentinel: провалы в логах, связанных с безопасностью системы. Могут затруднить анализ данных и детектирование киберугроз.
  • Azure Monitor: неполные результаты при выполнении запросов, основанных на данных логов.
  • Azure Trusted Signing: частично обрывистые логи SignTransaction и SignHistory.
  • Azure Virtual Desktop: неполные записи в Application Insights.
  • Power Platform: частично пропали отчёты порталов Analytics, Admin и Maker.

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

Бесплатные VPN начали умирать за пару дней, IP уже ни при чём

Бесплатный VPN из Telegram бодро запускается, а через несколько дней Reels замирают, YouTube уходит в бесконечную загрузку, а Gemini встречает ошибкой 403. Современные системы фильтрации научились распознавать туннели даже без расшифровки трафика.

По версии пользователя Хабра Djin22, теперь одного нового IP-адреса может быть недостаточно.

Анализаторы изучают размеры пакетов, интервалы между ними, структуру TLS-соединения и другие косвенные признаки. Если трафик ведёт себя как прокси, маскировка под обычный HTTPS уже не всегда спасает.

Один из характерных сценариев автор называет «проблемой 16 КБ»: соединение успешно устанавливается, передаёт первые данные, а затем резко замедляется или обрывается. Для борьбы с этим используют фрагментацию пакетов, уменьшение размера TCP-сегментов и десинхронизацию DPI с помощью zapret. Идея проста: сервер должен получить нормальный поток, а анализатор — головоломку.

Отдельная история — сервисы Google. Они могут учитывать TLS-отпечаток клиента и замечать, когда программа притворяется Chrome не слишком убедительно. В sing-box для более правдоподобной имитации браузера применяют uTLS.

Если Telegram не работает даже через VLESS Reality, автор предлагает ShadowTLS v3: протокол маскирует соединение под обычную TLS-сессию с разрешённым ресурсом. Ещё один приём — padding, то есть добавление случайных данных для изменения размеров пакетов и усложнения статистического анализа.

В качестве готовых вариантов Djin22 перечисляет hynet.cloud, AmneziaVPN, Red Shield VPN, Cloudflare WARP и собственные серверы на Xray или sing-box. Однако часть текста о hynet.cloud выглядит рекламно, а заявления об «эмуляции JA4», residential-маршрутизации и автоматическом переключении протоколов приводятся без независимого подтверждения.

RSS: Новости на портале Anti-Malware.ru