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

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

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

Предварительные требования

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

Необходимые инструменты

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

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

Detailed flow of the investigation steps

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

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

Данное руководство создано с учетом того, чтобы не все клиенты или исследовательские группы Майкрософт имеют полный набор лицензий Microsoft 365 E5 или Azure AD Premium P2, доступный или настроенный в исследуемом арендаторе. Однако по мере необходимости мы будет выделять дополнительные возможности автоматизации.

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

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

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

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

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

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

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

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

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

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

Risk Detection portal

Risk Detection details

A sample of Service Principal Risk Detection Graph API

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

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

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

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

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

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

Check the Resource for Service Principal

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

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

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

Check custom roles that may be created or modified

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

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

Risk Detection portal

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

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

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

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

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

Проверка единого журнала аудита M365 (UAL) для получения сведений о фишинге за последние 7 дней

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

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

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

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

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

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

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

  • Использование журналов аудита портала Azure AD

  • Использование 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")

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

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

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

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

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

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

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

Use the Azure AD Audit Logs

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

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

Важно!

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

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

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

Toggle to disable users to sign-in

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

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

# Check if a service principal already exists for the app
$servicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$appId'"
if ($servicePrincipal) {
   # Service principal exists already, disable it
   Set-AzureADServicePrincipal -ObjectId $servicePrincipal.ObjectId -AccountEnabled $false
} else {
   # Service principal does not yet exist, create it and disable it at the same time
   $servicePrincipal = New-AzureADServicePrincipal -AppId $appId -AccountEnabled $false
}

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

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

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

    • Анализ выходных данных для учетных данных. Выходные данные могут содержать passwordCredentials или 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}

  • Поиск passwordCredentials и keyCredentials в ответе, запись всех старых идентификаторов keyId

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

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

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

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

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

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

Инструкции по azure AD SecOps по приложениям см. в руководстве по операциям безопасности Azure Active Directory для приложений.

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

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

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

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

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

DELETE /applications/{id}

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

DELETE /directory/deletedItems/{id}

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

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

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

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

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

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

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

  • IP-адрес или ASN
  • Целевой ресурс
  • Агент пользователя
  • Изменение IP-адреса размещения или без размещения
  • Страна IP
  • Тип учетных данных

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

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

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

Review risks and alerts in the Identity Protection portal

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

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

Control user access based on conditional access policy

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

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

Просмотрите параметры согласия пользователя в разделе"Согласие и разрешения>"для корпоративных приложений>Azure Active Directory>.

Select Allow user consent for apps from the options

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

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

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

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

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

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

Ссылки

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

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

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