Екипите по сигурност, разчитащи на таблицата DeviceNetworkEvents в Microsoft Defender XDR за търсене на заплахи и откриване на инциденти, може да пропуснат критични външни мрежови връзки поради малко известна особеност в класификацията на IP адресите.
Проблемът е свързан с FourToSixMapping — стойност на RemoteIPType, която може да позволи на трафика към публични IP адреси да премине незабелязано покрай логиката за откриване, филтрираща строго по RemoteIPType == "Public".
Според Detect FYI пропускът е открит по време на симулация от тип Purple Team, при която атакуващ е внедрил бинарен файл за създаване на прикрит канал за командване и контрол (C2), заобикалящ контрола на уеб проксито. Въпреки че е съществувало правило за откриване точно за този етап на атаката, сигнал за тревога така и не е бил генериран.
Основната причина е свързана с едно ограничение в заявката, което тихомълком е изключило валидни връзки към публични IP адреси, регистрирани с различна стойност на RemoteIPType, а именно FourToSixMapping.
Съвременните приложения за Windows често използват двойни стекови сокети (dual-stack sockets), позволяващи едновременна комуникация по IPv4 и IPv6. Когато дадено приложение комуникира през IPv4 чрез сокет с поддръжка на IPv6, Defender XDR записва адреса като IPv4-мапиран IPv6 адрес (форматиран като ::ffff:8.8.8.8).
Този формат е дефиниран в RFC 4291. Defender XDR маркира тези събития като FourToSixMapping вместо Public, въпреки че базовият адрес е легитимен публичен IP адрес.
Анализаторите често разделят мрежовите детекции по протокол или услуга (SSH, RDP, HTTPS, DNS), за да улеснят анализа. Но заявки, които филтрират само за RemoteIPType == "Public", систематично ще пропускат всяка връзка, регистрирана като FourToSixMapping, създавайки фалшиво отрицателен резултат (False Negative) — реална атака се случва, детекция съществува, но алармата не се задейства.
Дори вградената в KQL функция ipv4_is_private() не решава проблема пряко. При тестване срещу стойност на FourToSixMapping като ::ffff:8.8.8.8 тя връща null вместо true или false, а в KQL null не е нито едно от двете.
Препоръчителната корекция е да се премахне префиксът ::ffff: от адресите с FourToSixMapping преди тяхната оценка, което нормализира адреса в стандартен IPv4 формат и позволява прецизно последващо филтриране.
Вместо да филтрирате публичните външни комуникации единствено по RemoteIPType == "Public", третирайте Public и FourToSixMapping като еднакво валидни индикатори за външна комуникация и нормализирайте IP форматите преди прилагане на логиката за детекция.