Подозрительная активность приложения Outlook-iOS-Android через ActiveSync

Задний план: Многие из моих пользователей используют смартфоны, в основном iPhone, для доступа к своим почтовым учетным записям MS-Exchange через ActiveSync. После недавних проблем с безопасностью iOS старше 13.5 мы рекомендовали всем отключить родное почтовое приложение iPhone. В качестве замены мы предложили приложение Microsoft Outlook.

После выхода iOS 13.5 мы также предложили вернуться к родному приложению и удалить приложение MS. Параллельно мы наблюдали значительную и растущую нагрузку на наш Exchange и быстрый рост журналов транзакций между ежедневными резервными копиями (которые очищают журналы). Само по себе это не улучшилось в течение нескольких дней, и стала неизбежной опасность, что наши диски не смогут удерживать объем журнала за два дня, так что мы были бы обречены, если когда-либо ежедневное резервное копирование выйдет из строя. Следовательно, мы приняли меры для более детального анализа. Виновником было множество обращений ActiveSync, иногда по несколько тысяч на пользователя в день. Но была корреляция: все пользователи с огромным количеством обращений приходили с Outlook-iOS-Android/1.0 как пользовательский агент. В этом не было ничего удивительного во время нашего первого анализа, когда «все» использовали это приложение. Однако после того, как несколько пользователей вернулись обратно, ситуация осталась прежней. Те, кто использовали родное приложение для iPhone (снова), вызвали значительно (т.е.на порядок) меньшая нагрузка и меньший объем журнала.

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

Но мы были удивлены, когда один пользователь сообщил иметь переключился обратно, но он по-прежнему был пользователем Outlook-App (а также с другим идентификатором устройства с собственным приложением). Мы конкретно спросили пользователя, активно ли у него другое (частное) устройство. Он отрицал; единственный способ, которым он когда-либо мог получить доступ к почте со своего личного телефона, - это специальный доступ через браузер и Outlook Web Access, и это очень редко, поскольку обычно у него есть рабочий телефон с собой. С этой информацией загрузка Outlook-App доступов под его учетной записью считается как подозрительно.

Я провел дальнейшее расследование и обнаружил, что эти обращения также исходили с подозрительных IP-адресов. В то время как другие обращения ActiveSync происходят из диапазонов IP-адресов региональных (здесь: Германии) телефонных провайдеров, эти обращения к Outlook-App происходят из 52.97.x.x, который, согласно whois, принадлежит MicroSoft. Хотя это, по крайней мере, не какой-то очевидный диапазон китайских / российских хакерских IP-адресов, меня это все равно не утешает.

Q1: Это нормально, что Outlook-iOS-Android/1.0 делает крюк через сеть Microsoft? Я был бы более счастлив, если бы почту могли читать только те, кому это разрешено, а не (по крайней мере, возможно) также некоторые прокси, возможно, находящиеся под контролем США. Тогда мне, возможно, даже придется полностью запретить использование этого приложения в соответствии с GDPR.

Q2: Это нормально, что Outlook-iOS-Android/1.0 вызывает такую ​​колоссальную нагрузку? Насколько я могу судить, у клиента даже нет какой-либо опции конфигурации, которая позволяла бы пользователю запрашивать синхронизацию, скажем, каждые 30 секунд.

Q3: Это нормально, что Outlook-iOS-Android/1.0 (или указанный прокси) по-прежнему вызывает загрузку после того, как он больше не установлен ни на одном устройстве пользователя?

После удаления для некоторых пользователей сделал уменьшить нагрузку, Q3 - это то, что меня больше всего удивляет (а Q1 - это то, что заботы мне больше всего и Q2 это то, что смущает мне больше всего).

Q4: Что я должен делать? Я близок к тому, чтобы заблокировать диапазон сети MS для входящих запросов на порт 443 на брандмауэре ...