Поделиться через

Исследование скомпрометированных и вредоносных приложений

  • Статья

В этой статье приводятся рекомендации по выявлению и расследованию вредоносных атак на одно или несколько приложений в клиенте клиента. Пошаговые инструкции помогут вам предпринять необходимые действия по исправлению для защиты информации и минимизации дополнительных рисков.

  • Предварительные требования: охватывает перечень конкретных требований, которые необходимо выполнить перед началом расследования. Например, необходимо включить ведение журнала, среди прочего, требуются роли и разрешения.
  • Рабочий процесс: отображает логический процесс, которому необходимо следовать, чтобы провести расследование.
  • Этапы расследования: включает подробное пошаговое руководство для целей конкретного расследования.
  • Этапы хранения. Содержит шаги по отключению скомпрометированных приложений.
  • Действия по восстановлению. Содержит общие инструкции по восстановлению и устранению последствий вредоносной атаки на скомпрометированные приложения.
  • Ссылки: содержит другие справочные материалы и материалы.

Необходимые компоненты

Перед началом исследования убедитесь, что у вас есть правильные средства и разрешения для сбора подробных сведений.

Необходимые средства

Для эффективного исследования установите следующий модуль PowerShell и набор средств на компьютере для исследования:

Рабочий процесс

Подробный поток действий по расследованию

Шаги для исследования

Для этого исследования предположим, что у вас есть признак потенциального компрометации приложений в виде отчета пользователя, примера журналов входа Microsoft Entra или обнаружения защиты идентификации. Обязательно выполните и включите все необходимые действия.

Эта сборник схем создается с намерением, чтобы не все клиенты Майкрософт и их команды исследования имели полный набор лицензий Microsoft 365 E5 или Microsoft Entra ID P2, доступный или настроенный. В этом сборнике схем выделены другие возможности автоматизации при необходимости.

Определение типа приложения

Важно определить тип приложения (нескольких или отдельных клиентов) на этапе исследования, чтобы получить правильную информацию, необходимую для обращения к владельцу приложения. Дополнительные сведения см. в разделе "Клиентство" в идентификаторе Microsoft Entra.

Мультитенантные приложения

Для мультитенантных приложений приложение размещается и управляется сторонним поставщиком. Определите процесс, необходимый для обращения к владельцу приложения и сообщить о проблемах.

Приложения с одним клиентом

Найдите контактные данные владельца приложения в организации. Его можно найти на вкладке "Владельцы" в разделе " Корпоративные приложения ". Кроме того, в вашей организации может быть база данных с этой информацией.

Вы также можете выполнить этот запрос Microsoft Graph:

GET https://graph.microsoft.com/v1.0/applications/{id}/owners

Проверка защиты идентификации — удостоверений рискованных рабочих нагрузок

Эта функция находится в предварительной версии во время написания этой сборника схем и требований к лицензированию, применимых к его использованию. Удостоверения рабочей нагрузки рискованно могут быть триггером для исследования субъекта-службы, но также можно использовать для дальнейшего изучения других триггеров, которые вы определили. Вы можете проверка состояние риска субъекта-службы с помощью вкладки "Защита идентификации" — удостоверений рабочих нагрузок рисков или использовать API Microsoft Graph.

Портал обнаружения рисков

Сведения об обнаружении рисков

Пример API graph обнаружения рисков субъекта-службы

Проверка необычного поведения входа

Первым шагом исследования является поиск доказательств необычных шаблонов проверки подлинности в использовании субъекта-службы. В портал Azure, Azure Monitor, Microsoft Sentinel или системы управления безопасностью и событиями (SIEM) вашей организации найдите следующее в разделе входа субъекта-службы:

  • Расположение — это проверка подлинности субъекта-службы из расположений\IP-адресов, которые вы не ожидали?
  • Сбои — существует большое количество сбоев проверки подлинности для субъекта-службы?
  • Метки времени — есть ли успешные проверки подлинности, которые происходят иногда, что вы не ожидали?
  • Частота — существует ли увеличение частоты проверки подлинности для субъекта-службы?
  • Утечка учетных данных — являются ли учетные данные приложения жестко закодированные и опубликованные в общедоступном источнике, например GitHub?

Если вы развернули защиту идентификации идентификатора записи — удостоверений рискованных рабочих нагрузок, проверка обнаружения подозрительных входов и утечки учетных данных. Дополнительные сведения см. в статье о задержании удостоверений рабочей нагрузки.

Проверка целевого ресурса

В рамках входа субъекта-службы также проверка ресурс, к которому субъект-служба обращается во время проверки подлинности. Важно получить входные данные от владельца приложения, так как они знакомы с ресурсами, к которым должен обращаться субъект-служба.

Проверка ресурса для субъекта-службы

Проверка ненормальных изменений учетных данных

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

  • Проверьте, были ли недавно созданы или непредвиденные учетные данные, назначенные субъекту-службе.
  • Проверьте учетные данные субъекта-службы с помощью API Microsoft Graph.
  • Проверьте как приложение, так и связанные объекты субъекта-службы.
  • Проверьте любую пользовательскую роль , созданную или измененную. Обратите внимание на указанные ниже разрешения.

Проверка настраиваемых ролей, созданных или измененных

Если вы развернули управление приложениями в приложениях Microsoft Defender для облака, проверка портал Azure для оповещений, связанных с приложением. Дополнительные сведения см. в статье "Начало работы с обнаружением угроз и исправлением угроз приложения".

Если вы развернули защиту идентификации, проверка отчет "Обнаружение рисков" и удостоверение пользователя или рабочей нагрузки "журнал рисков".

Портал обнаружения рисков

Если вы развернули Microsoft Defender для облака Приложения, убедитесь, что включена политика "Необычное добавление учетных данных в приложение OAuth" и проверка для открытых оповещений.

Дополнительные сведения см. в статье о необычном добавлении учетных данных в приложение OAuth.

Кроме того, вы можете запросить API-интерфейсы servicePrincipalRiskDetections и API-интерфейсы рисков пользователя, чтобы получить эти обнаружения рисков.

Поиск изменений конфигурации аномальных приложений

  • Проверьте разрешения API, назначенные приложению, чтобы убедиться, что разрешения соответствуют ожидаемым для приложения.
  • Проверьте журналы аудита (действие фильтра по обновлению приложения или субъекту-службе обновления).
  • Убедитесь, что строка подключения согласованы и изменен ли URL-адрес выхода.
  • Убедитесь, что домены в URL-адресе находятся в строке зарегистрированных.
  • Определите, добавил ли любой пользователь URL-адрес несанкционированного перенаправления.
  • Подтвердите владение URI перенаправления, который вы владеете, чтобы убедиться, что срок действия не истек и был заявлен злоумышленником.

Кроме того, если вы развернули Microsoft Defender для облака Приложения, проверка портал Azure для оповещений, связанных с приложением, которое вы изучаете. Не все политики оповещений включены по умолчанию для приложений OAuth, поэтому убедитесь, что эти политики включены. Дополнительные сведения см. в политиках приложений OAuth. Вы также можете просмотреть сведения о распространенности приложений и последних действиях на вкладке "Исследование> Приложение OAuth s".

Проверка подозрительных ролей приложения

  • Журналы аудита также можно использовать. Фильтрация действий путем добавления назначения роли приложения субъекту-службе.
  • Убедитесь, что назначенные роли имеют высокий уровень привилегий.
  • Убедитесь, необходимы ли эти привилегии.

Проверка наличия непроверенных коммерческих приложений

  • Проверьте, используются ли приложения коммерческой коллекции (опубликованные и проверенные версии).

Проверка сведений о раскрытии сведений о свойстве keyCredential

Просмотрите клиент для потенциального раскрытия информации о свойстве keyCredential, как описано в CVE-2021-42306.

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

Внимание

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

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

Второй метод включает в себя уже скомпрометированную учетную запись администратора, создав новое приложение для целей сохраняемости, сбора данных и пребывания под радаром. Например, скомпрометированный администратор может создать приложение OAuth с казалось бы безобидным именем, избегая обнаружения и разрешая долгосрочный доступ к данным без необходимости учетной записи. Этот метод часто встречается в нападениях государства страны.

Ниже приведены некоторые шаги, которые можно предпринять для дальнейшего изучения.

Проверьте единый журнал аудита Microsoft 365 (UAL) для фишинговых показаний за последние семь дней

Иногда, когда злоумышленники используют вредоносные или скомпрометированные приложения в качестве средства сохраняемости или для получения данных, используется фишинговая кампания. Основываясь на результатах предыдущих шагов, необходимо просмотреть удостоверения:

  • Владельцы приложения
  • Администратор согласия

Просмотрите удостоверения для указания фишинговых атак за последние 24 часа. Увеличьте этот интервал времени при необходимости до 7, 14 и 30 дней, если нет непосредственных признаков. Подробный сборник схем исследования фишинга см. в сборнике схем исследования фишинга.

Поиск согласия вредоносных приложений за последние семь дней

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

Проверка журналов аудита

Чтобы просмотреть все предоставления согласия для этого приложения, отфильтруйте действие по согласию на приложение.

  • Использование журналов аудита Центра администрирования Microsoft Entra

  • Использование Microsoft Graph для запроса журналов аудита

    a) Фильтрация для определенного интервала времени:

GET https://graph.microsoft.com/v1.0/auditLogs/auditLogs/directoryAudits?&$filter=activityDateTime le 2022-01-24

b) Фильтрация журналов аудита для записей журнала аудита "Согласие на приложения":

https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?directoryAudits?$filter=ActivityType eq 'Consent to application'


"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#auditLogs/directoryAudits",
"value": [
    {
        "id": "Directory_0da73d01-0b6d-4c6c-a083-afc8c968e655_78XJB_266233526",
        "category": "ApplicationManagement",
        "correlationId": "0da73d01-0b6d-4c6c-a083-afc8c968e655",
        "result": "success",
        "resultReason": "",
        "activityDisplayName": "Consent to application",
        "activityDateTime": "2022-03-25T21:21:37.9452149Z",
        "loggedByService": "Core Directory",
        "operationType": "Assign",
       "initiatedBy": {
            "app": null,
            "user": {
                "id": "8b3f927e-4d89-490b-aaa3-e5d4577f1234",
                "displayName": null,
                "userPrincipalName": "admin@contoso.com",
                "ipAddress": "55.154.250.91",
                "userType": null,
                "homeTenantId": null,
                "homeTenantName": null
            }
        },
        "targetResources": [
            {
                "id": "d23d38a1-02ae-409d-884c-60b03cadc989",
                "displayName": "Graph explorer (official site)",
                "type": "ServicePrincipal",
                "userPrincipalName": null,
                "groupType": null,
                "modifiedProperties": [
                    {
                        "displayName": "ConsentContext.IsAdminConsent",
                        "oldValue": null,
                        "newValue": "\"True\""
                    },

c) Использование Log Analytics

AuditLogs
| where ActivityDisplayName == "Consent to application"

Дополнительные сведения см. в сборнике схем исследования предоставления согласия приложения.

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

Чтобы найти приложения, предоставленные пользователями, используйте LogAnalytics для поиска журналов аудита:

AuditLogs
| where ActivityDisplayName == "Consent to application" and (parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)) <> "True")

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

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

Теперь следуйте инструкциям по перечислению и просмотру разрешений в расследовании предоставления согласия приложения.

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

Проверка с помощью журналов аудита:

AuditLogs
| where OperationName == "Consent to application" 
//| where parse_json(tostring(TargetResources[0].modifiedProperties))[4].displayName == "ConsentAction.Permissions"

Вы также можете использовать журналы аудита Microsoft Entra, фильтруя по согласию на приложение. В разделе сведений журнала аудита щелкните "Изменить свойства", а затем просмотрите раздел ConsentAction.Permissions:

Использование журналов аудита Microsoft Entra

Действия по сдерживанию

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

Внимание

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

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

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

Переключение для отключения входа пользователей

Для отключения входа в приложение можно также использовать следующий код Microsoft Graph PowerShell :

# The AppId of the app to be disabled
$appId = "{AppId}"

# Check if a service principal already exists for the app
$servicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$appId'"

if ($servicePrincipal) {
   # Service principal exists already, disable it

  $ServicePrincipalUpdate =@{
    "accountEnabled" = "false"
  }
   Update-MgServicePrincipal -ServicePrincipalId $servicePrincipal.Id -BodyParameter $ServicePrincipalUpdate
   
} else {
   # Service principal does not yet exist, create it and disable it at the same time
   
   $ServicePrincipalID=@{
	"AppId" = $appId
	"accountEnabled" = "false"
   }
   
   $servicePrincipal = New-MgServicePrincipal -BodyParameter $ServicePrincipalId
   
}

Действия по восстановлению

Исправление субъектов-служб

  1. Перечислить все учетные данные, назначенные субъекту-службе Risky. Лучший способ сделать это — выполнить вызов Microsoft Graph с помощью GET ~/application/{id}, где идентификатор, переданный, является идентификатором объекта приложения.

    • Анализ выходных данных для учетных данных. Выходные данные могут содержать парольCredentials или keyCredentials. Запишите ключи для всех.

      "keyCredentials": [],
     "parentalControlSettings": {
         "countriesBlockedForMinors": [],
         "legalAgeGroupRule": "Allow"
     },
     "passwordCredentials": [
         {
             "customKeyIdentifier": null,
             "displayName": "Test",
             "endDateTime": "2021-12-16T19:19:36.997Z",
             "hint": "7~-",
             "keyId": "9f92041c-46b9-4ebc-95fd-e45745734bef",
             "secretText": null,
             "startDateTime": "2021-06-16T18:19:36.997Z"
         }
     ],

  2. Добавьте новые учетные данные сертификата (x509) в объект приложения с помощью API addKey приложения.

    POST ~/applications/{id}/addKey

  3. Немедленно удалите все старые учетные данные. Для каждого старого пароля удалите его с помощью:

    POST ~/applications/{id}/removePassword

    Для каждого старого ключа удалите его с помощью:

    POST ~/applications/{id}/removeKey

  4. Исправьте все субъекты-службы, связанные с приложением. Выполните этот шаг, если клиент размещает или регистрирует мультитенантное приложение и (или) регистрирует несколько субъектов-служб, связанных с приложением. Выполните аналогичные действия, описанные ранее:

  • GET ~/servicePrincipals/{id}

  • Поиск паролейCredentials и keyCredentials в ответе, запись всех старых идентификаторов ключей

  • Удалите все старые учетные данные пароля и ключа. Используйте:

    POST ~/servicePrincipals/{id}/removePassword and POST ~/servicePrincipals/{id}/removeKey for this, respectively.

Исправление затронутых ресурсов субъекта-службы

Исправьте секреты KeyVault, к которым субъект-служба имеет доступ, сменив их в следующем приоритете:

  • Секреты, предоставляемые непосредственно с помощью вызовов GetSecret .
  • Остальные секреты в предоставленных KeyVaults.
  • Остальные секреты в предоставленных подписках.

Дополнительные сведения см. в статье "Интерактивное удаление и перемещение сертификатов и секретов субъекта-службы или приложения".

Инструкции microsoft Entra SecOps по приложениям см . в руководстве по операциям безопасности Microsoft Entra для приложений.

В порядке приоритета этот сценарий будет следующим:

  • Обновите командлеты Graph PowerShell (Добавление и удаление ApplicationKey + ApplicationPassword), чтобы включить примеры для переката учетных данных.
  • Добавьте пользовательские командлеты в Microsoft Graph PowerShell, упрощающий этот сценарий.

Отключение или удаление вредоносных приложений

Приложение можно отключить или удалить. Чтобы отключить приложение, в разделе "Включено" для входа пользователей переместите переключатель в "Нет".

Вы можете удалить приложение либо временно, либо окончательно, в портал Azure или через API Microsoft Graph. При обратимом удалении приложение можно восстановить до 30 дней после удаления.

DELETE /applications/{id}

Чтобы окончательно удалить приложение, используйте этот вызов API Microsoft Graph:

DELETE /directory/deletedItems/{id}

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

Ведение журнала для включения:

  • Служба — основной каталог
  • Тип действия — обновление субъекта-службы
  • Категория — управление приложениями
  • Инициировано субъектом (субъектом) — имя участника-пользователя
  • Целевые объекты — идентификатор приложения и отображаемое имя
  • Измененные свойства — имя свойства = включена учетная запись, новое значение = true

Ведение журнала для восстановленного:

  • Служба — основной каталог
  • Тип действия — добавление субъекта-службы
  • Категория — управление приложениями
  • Инициировано субъектом (субъектом) — имя участника-пользователя
  • Целевые объекты — идентификатор приложения и отображаемое имя
  • Измененные свойства — имя свойства = включена учетная запись, новое значение = true

Примечание. Корпорация Майкрософт глобально отключает приложения, которые нарушают условия обслуживания. В этих случаях эти приложения отображаются DisabledDueToViolationOfServicesAgreement в свойстве disabledByMicrosoftStatus связанных типов ресурсов приложения и субъекта-службы в Microsoft Graph. Чтобы предотвратить создание экземпляров в организации в будущем, вы не сможете удалить эти объекты.

Реализация защиты идентификации для удостоверений рабочей нагрузки

Корпорация Майкрософт обнаруживает риск для удостоверений рабочей нагрузки в поведении входа и автономных индикаторах компрометации.

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

Эти оповещения отображаются на портале защиты идентификации и могут быть экспортированы в средства SIEM с помощью диагностических Параметры или API защиты идентификации.

Проверка рисков и оповещений на портале защиты идентификации

Условный доступ для удостоверений рискованных рабочих нагрузок

Условный доступ позволяет блокировать доступ для определенных учетных записей, назначенных, когда защита идентификации помечает их как "под угрозой". Обратите внимание, что принудительное применение через условный доступ в настоящее время ограничено только однотенантными приложениями.

Управление доступом пользователей на основе политики условного доступа

Дополнительные сведения см. в разделе "Условный доступ" для удостоверений рабочей нагрузки.

Реализация политик риска приложений

Просмотрите параметры согласия пользователя в разделе "Согласие и разрешения пользователей" в разделе "Согласие пользователей" и ">Корпоративные разрешения" для приложений>Microsoft Entra ID>Enterprise.

Выберите

Сведения о параметрах конфигурации см. в статье "Настройка согласия пользователей на приложения".

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

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

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

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

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

Ссылки

Дополнительные инструкции по реагированию на инциденты

Изучите руководство по выявлению и расследованию этих дополнительных типов атак:

Ресурсы по реагированию на инциденты