Шокирующее открытие: Defender ошибочно объявил N‑able вредоносным – 7 способов защитить инфраструктуру

Вступление

В последние годы автоматизация управления ИТ‑инфраструктурой стала неотъемлемой частью работы большинства компаний. Инструменты удалённого мониторинга и управления (RMM) позволяют администраторам быстро реагировать на инциденты, выполнять обновления и собирать метрики без физического доступа к устройствам. Одним из лидеров рынка в этом сегменте является N‑able (ранее SolarWinds RMM). Однако даже проверенные решения могут стать причиной тревоги, если системы защиты ошибочно классифицируют их как вредоносные.

Недавно в Reddit возникла бурная дискуссия: Microsoft Defender начал помечать ncentral_softwarescanner.exe – компонент N‑able – как «malware». Пользователи заметили, что ранее файл проходил проверку без нареканий, а теперь получает сигналы тревоги, а также аналогичные сообщения от SentinelOne. Ситуация привела к росту количества тикетов в службах поддержки, обсуждениям в профессиональных сообществах и, главное, к реальному риску нарушения работы сервисов.

Японское хокку, отражающее суть проблемы:

Тень защиты падает,
Ложный крик в тишине —
Система спит.

Пересказ Reddit‑поста своими словами

Автор оригинального поста разместил ссылки на три источника: два обсуждения в Reddit (subreddit cybersecurity и msp) и анализ файла в VirusTotal. По его словам, Microsoft Defender ранее помечал файл ncentral_softwarescanner.exe как потенциально опасный, но после обновления сигнатур он перестал это делать. Тем временем SentinelOne всё ещё выдаёт предупреждения, хотя в VirusTotal текущий отчёт показывает 0 из 70 обнаружений.

В комментариях пользователи делятся своим опытом: одни считают, что это типичный «false positive» для RMM‑инструментов, другие советуют не спешить с исключениями и сначала уточнить у поставщика, а третьи указывают на необходимость обращения в поддержку N‑able и вендоров EDR.

Суть проблемы, хакерский подход и основные тенденции

Системы обнаружения угроз (EDR) работают по двум основным принципам: сигнатурный анализ и эвристика. Сигнатурный подход сравнивает файл с известными образцами вредоносного кода, а эвристика – оценивает поведение программы (доступ к реестру, сканирование сети, изменение файлов). Инструменты RMM по своей природе «делают подозрительные вещи»: они перечисляют файлы, сканируют порты, пишут в реестр, что в глазах эвристических движков выглядит как действия вредоносного ПО.

Хакеры давно используют подобные «шумные» действия для маскировки: они внедряют свои модули в легитимные RMM‑клиенты, чтобы скрыться от детекторов. Поэтому любые изменения в поведении RMM‑агентов вызывают повышенную чувствительность EDR‑систем. Текущая тенденция – рост количества ложных срабатываний именно в этом сегменте, что заставляет администраторов балансировать между безопасностью и доступностью сервисов.

Детальный разбор проблемы с разных сторон

Техническая сторона

• Эвристика Defender: После обновления сигнатур Microsoft Defender начал классифицировать ncentral_softwarescanner.exe как «Potentially Unwanted Application» (PUA). Причина – частое обращение к системным API, характерное для сканеров.
• SentinelOne: Несмотря на отсутствие обнаружений в VirusTotal, SentinelOne продолжает выдавать предупреждения, вероятно, из‑за устаревших локальных правил.
• VirusTotal: На момент написания статьи в VT 70 антивирусных движков, из которых 0 обнаружили угрозу. Исторически файл получал 3–5 положительных срабатываний, что свидетельствует о «плавающем» статусе.

Организационная сторона

• Службы поддержки получают рост количества тикетов, что увеличивает нагрузку на SOC.
• Администраторы вынуждены принимать решения: исключить директорию из сканирования или ждать обновления сигнатур.
• Неправильные исключения могут открыть путь для реального вредоносного кода, если злоумышленник получит доступ к тем же каталогам.

Поставщикская сторона

• N‑able публикует рекомендации по исключениям в официальных KB, но часто эти рекомендации приходят уже после того, как проблема всплыла в поле.
• Вендоры EDR (Microsoft, SentinelOne) обычно реагируют в течение 1–2 недель, выпуская обновления сигнатур.

Практические примеры и кейсы

Рассмотрим два типовых сценария, с которыми могут столкнуться администраторы.

Кейс 1. Малый MSP (Managed Service Provider)

Компания обслуживает 50 клиентских площадок, использует N‑able и Microsoft Defender for Endpoint. После обновления Defender в начале недели начали приходить оповещения о «malware» в папке C:\Program Files (x86)\N-able Technologies\N-central\. Администратор:

1. Проверил VirusTotal – обнаружений нет.
2. Создал исключение в политике Defender для этой директории.
3. Отправил хеш файла в Microsoft как ложный положительный результат.
4. Ожидал обновления сигнатур от Microsoft (получил через 5 дней).

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

Кейс 2. Крупный корпоративный клиент

Внутрикорпоративный SOC использует SentinelOne и Defender одновременно. После появления сигнала от SentinelOne о «malware», команда провела форензический анализ и обнаружила, что файл действительно подписан сертификатом N‑able и не содержит вредоносного кода. Было решено:

• Сразу открыть тикет в поддержке SentinelOne.
• Временно отключить автоматическое карантинирование для данного файла.
• Внести в список исключений только конкретный хеш, а не всю директорию.
• Отправить запрос в N‑able о возможных изменениях в клиенте, которые могли спровоцировать срабатывание.

Через неделю SentinelOne выпустил патч, и проблема исчезла без необходимости длительного исключения.

Экспертные мнения из комментариев

"RMM false positive situation. These tools do sketchy‑looking things by design (enumerate files, scan networks, touch registry) so EDR heuristics lose their minds periodically."

— This_Cardiologist242

"Yeah I'd reach out to n-able and s1 support independently. Ask if something changes to cause this. I'd be very wary of just throwing exclusions in for a known working service. I understand what others are saying about how it does things that can seem malicious, but if this service has been working in the environment without issues and now is causing alerts, treat it as a real threat."

— tacticalAlmonds

"Any update's regarding this issue? N-able stays on investigating [Status Dashboard]"

— CompetitiveAnalyst40

"Seeing this in our org as well. Got a call from our SOC about it. S1 detecting NAble as malware"

— Technickelback

"Issue is the RMM vendor requires the exclusions as part of onboarding/setup and will then point to that KB the moment you have any issues as a get out."

— Thet4nk1983

Ключевые выводы из комментариев:

• Ложные срабатывания – типичная проблема для RMM‑инструментов.
• Не стоит сразу добавлять широкие исключения; лучше уточнить у поставщика.
• Поддержка N‑able уже работает над проблемой, но процесс может занять время.
• Важно документировать любые изменения в политике EDR.

Возможные решения и рекомендации

1. Проверка репутации файла: Сначала отправьте хеш в VirusTotal и в консоль EDR. Если большинство движков считают файл чистым – это первый сигнал о ложном срабатывании.
2. Создание целевых исключений: Вместо исключения всей папки, добавьте исключение только для конкретного хеша и только в тех политиках, где он действительно нужен.
3. Отправка FP‑отчёта: В Microsoft Defender и SentinelOne есть возможность отправить «false positive». Это ускорит обновление сигнатур.
4. Контакт с поставщиком: Откройте тикет в N‑able, укажите детали (версия клиента, хеш, логи EDR). Часто в KB уже есть готовый набор исключений.
5. Мониторинг статуса: Подпишитесь на статус‑дашборд N‑able (https://uptime.n-able.com/) и на каналы обновлений Microsoft.
6. Тестовое окружение: Перед массовым внедрением новых политик EDR протестируйте их в лаборатории, где можно безопасно воспроизвести поведение RMM‑клиента.
7. Обучение персонала: Проведите инструктаж SOC о характерных «шумных» действиях легитимных RMM‑инструментов, чтобы снизить уровень тревожности.

Заключение с прогнозом развития

С ростом количества облачных сервисов и удалённого управления спрос на RMM‑решения будет только расти. Одновременно усиливается давление со стороны EDR‑производителей, которые стремятся уменьшить количество ложных срабатываний. Ожидается, что в ближайшие 12–18 месяцев появятся более «контекстно‑осведомлённые» модели машинного обучения, способные различать легитимные действия RMM‑клиентов от действительно вредоносных. Тем не менее, пока такие технологии не станут массовыми, администраторы будут вынуждены балансировать между исключениями и реактивным реагированием.

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

Практический пример (Python) – автоматическое отправление FP‑отчёта в Microsoft Defender

import requests
import json
import hashlib
import os
import datetime

# Константы – замените на свои значения
API_ENDPOINT = "https://api.securitycenter.microsoft.com/api/alerts/submitfalsepositive"
TENANT_ID = "your-tenant-id"
CLIENT_ID = "your-client-id"
CLIENT_SECRET = "your-client-secret"

def get_access_token():
    """Получаем токен доступа к Microsoft Graph API."""
    url = f"https://login.microsoftonline.com/{TENANT_ID}/oauth2/v2.0/token"
    payload = {
        "client_id": CLIENT_ID,
        "scope": "https://api.securitycenter.microsoft.com/.default",
        "client_secret": CLIENT_SECRET,
        "grant_type": "client_credentials"
    }
    response = requests.post(url, data=payload)
    response.raise_for_status()
    return response.json()["access_token"]

def calculate_sha256(file_path):
    """Вычисляем SHA‑256 хеш файла."""
    sha256 = hashlib.sha256()
    with open(file_path, "rb") as f:
        for chunk in iter(lambda: f.read(8192), b""):
            sha256.update(chunk)
    return sha256.hexdigest()

def submit_false_positive(file_hash, file_name):
    """Отправляем запрос о ложном срабатывании."""
    token = get_access_token()
    headers = {
        "Authorization": f"Bearer {token}",
        "Content-Type": "application/json"
    }
    payload = {
        "fileHash": file_hash,
        "fileName": file_name,
        "comment": "False positive detected by internal analysis – N‑able scanner.",
        "timestamp": datetime.datetime.utcnow().isoformat() + "Z"
    }
    response = requests.post(API_ENDPOINT, headers=headers, data=json.dumps(payload))
    if response.status_code == 202:
        print("Отчёт успешно отправлен.")
    else:
        print(f"Ошибка отправки: {response.status_code} – {response.text}")

if __name__ == "__main__":
    # Путь к файлу, который вызвал срабатывание
    target_file = r"C:\Program Files (x86)\N-able Technologies\N-central\ncentral_softwarescanner.exe"
    if os.path.isfile(target_file):
        file_hash = calculate_sha256(target_file)
        submit_false_positive(file_hash, os.path.basename(target_file))
    else:
        print("Файл не найден, проверьте путь.")

Скрипт автоматически вычисляет SHA‑256 хеш подозрительного файла и отправляет запрос в Microsoft Defender, помечая его как ложный положительный результат. Это ускоряет процесс обновления сигнатур и снижает количество повторных срабатываний.