Share via

Investigación de aplicaciones en peligro y malintencionadas

  • Artículo

En este artículo se proporcionan instrucciones sobre cómo identificar e investigar ataques malintencionados en una o varias aplicaciones de un inquilino de cliente. Las instrucciones paso a paso le ayudarán a tomar las medidas de corrección necesarias para proteger la información y minimizar los riesgos adicionales.

  • Requisitos previos: cubre los requisitos específicos que debe completar antes de iniciar la investigación. Por ejemplo, el registro que debe activarse, los roles y los permisos necesarios, entre otras cosas.
  • Flujo de trabajo: muestra el flujo lógico que debe seguir para realizar esta investigación.
  • Pasos de investigación: incluye una guía detallada paso a paso para esta investigación específica.
  • Pasos de contención: contiene pasos sobre cómo deshabilitar las aplicaciones en peligro.
  • Pasos de recuperación: Contiene pasos de alto nivel sobre cómo recuperarse/mitigar un ataque malicioso a aplicaciones comprometidas.
  • Referencias: contiene otros materiales de lectura y referencia adicionales.

Requisitos previos

Antes de iniciar la investigación, asegúrese de que tiene las herramientas y permisos correctos para recopilar información detallada.

Herramientas necesarias

Para una investigación eficaz, instale el siguiente módulo de PowerShell y el kit de herramientas en el equipo de investigación:

Flujo de trabajo

Detailed flow of the investigation steps

Pasos de investigación

Para esta investigación, supongamos que tiene una indicación de un posible riesgo de aplicación en forma de informe de usuario, ejemplo de registros de inicio de sesión de Microsoft Entra o una detección de protección de identidades. Asegúrese de completar y habilitar todos los pasos de requisitos previos necesarios.

Este cuaderno de estrategias se ha creado con la intención de que no todos los clientes de Microsoft y sus equipos de investigación dispongan o tengan configurado el conjunto completo de licencias Microsoft 365 E5 o Microsoft Entra ID P2. Este cuaderno de estrategias resalta otras funcionalidades de automatización cuando corresponda.

Determinar el tipo de aplicación

Es importante determinar el tipo de aplicación (multiinquilino o único) al principio de la fase de investigación para obtener la información correcta necesaria para ponerse en contacto con el propietario de la aplicación. Para más información, consulte Inquilinos en Microsoft Entra ID.

Aplicaciones multiinquilino

En el caso de las aplicaciones multiinquilino, la aplicación se hospeda y administra mediante un tercero. Identifique el proceso necesario para ponerse en contacto con el propietario de la aplicación y notificar problemas.

Aplicaciones de inquilino único

Busque los detalles de contacto del propietario de la aplicación dentro de su organización. Puede encontrarlo en la pestaña Propietarios de la sección Aplicaciones empresariales. Como alternativa, es posible que su organización tenga una base de datos que tenga esta información.

También puede ejecutar esta consulta de Microsoft Graph:

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

Comprobar la protección de la identidad: identidades con carga de trabajo de riesgo

Esta característica está en versión preliminar en el momento de escribir este cuaderno de estrategias y los requisitos de licencia se aplican a su uso. Las identidades de carga de trabajo de riesgo pueden ser el desencadenador para investigar una entidad de servicio, pero también se pueden usar para investigar más en otros desencadenadores que ha identificado. Puede comprobar el estado de riesgo de una entidad de servicio mediante la pestaña Protección de identidades: identidades de carga de trabajo de riesgo o puede usar Microsoft Graph API.

Risk Detection portal

Risk Detection details

A sample of Service Principal Risk Detection Graph API

Comprobación del comportamiento de inicio de sesión inusual

El primer paso de la investigación es buscar evidencia de patrones de autenticación inusuales en el uso de la entidad de servicio. En Azure Portal, Azure Monitor, Microsoft Sentinel o el sistema de Administración de eventos e información de seguridad (SIEM) de su organización, busque lo siguiente en la sección Inicios de sesión de entidad de servicio:

  • Ubicación: ¿la entidad de servicio se autentica desde ubicaciones\direcciones IP que no esperaría?
  • Errores: ¿hay un gran número de errores de autenticación para la entidad de servicio?
  • Marcas de tiempo: ¿hay autenticaciones correctas que se producen en ocasiones que no esperaría?
  • Frecuencia: ¿hay una mayor frecuencia de autenticación para la entidad de servicio?
  • Credenciales filtradas: ¿hay credenciales de aplicación codificadas y publicadas de forma rígida en un origen público como GitHub?

Si ha implementado la protección de identidad Entra ID: identidades de carga de trabajo de riesgo, compruebe las detecciones de inicios de sesión sospechosos y de credenciales filtradas. Para más información, consulte las detenciones por riesgo de identidad de la carga de trabajo.

Compruebe el recurso de destino

En inicios de sesión de la entidad de servicio, compruebe también el recurso al que accedió la entidad de servicio durante la autenticación. Es importante obtener información del propietario de la aplicación porque están familiarizados con los recursos a los que debe acceder la entidad de servicio.

Check the Resource for Service Principal

Comprobación de cambios anómalos en las credenciales

Use los registros de auditoría para obtener información sobre los cambios de credenciales en las aplicaciones y las entidades de servicio. Filtre por categoría por administración de aplicaciones y actividad por actualización de la aplicación: certificados y administración de secretos.

  • Compruebe si hay credenciales recién creadas o inesperadas asignadas a la entidad de servicio.
  • Compruebe si hay credenciales en la entidad de servicio mediante Microsoft Graph API.
  • Compruebe tanto la aplicación como los objetos de entidad de servicio asociados.
  • Compruebe cualquier rol personalizado que haya creado o modificado. Tenga en cuenta los permisos marcados a continuación:

Check custom roles that are created or have been modified

Si ha implementado la gobernanza de aplicaciones en Microsoft Defender for Cloud Apps, consulte Azure Portal para ver las alertas relacionadas con la aplicación. Para obtener más información, consulte Introducción a la detección y corrección de amenazas de aplicaciones.

Si ha desplegado la protección de identidades, compruebe el informe "Detecciones de riesgos" y en el "historial de riesgos" de la identidad del usuario o de la carga de trabajo.

Risk Detection portal

Si ha implementado Microsoft Defender for Cloud Apps, asegúrese de que la directiva "Adición inusual de credenciales a una aplicación de OAuth" está habilitada y compruebe si hay alertas abiertas.

Para más información, consulte Adición inusual de credenciales a una aplicación OAuth.

Además, puede consultar las API servicePrincipalRiskDetections y riskDetections del usuario para recuperar estas detecciones de riesgo.

Búsqueda de cambios anómalos en la configuración de la aplicación

  • Compruebe los permisos de API asignados a la aplicación para asegurarse de que los permisos son coherentes con lo esperado para la aplicación.
  • Compruebe los registros de auditoría (filtre la actividad por la aplicación de actualización o la entidad de servicio de actualización).
  • Confirme si los cadena de conexión son coherentes y si se ha modificado la dirección URL de cierre de sesión.
  • Confirme si los dominios de la dirección URL están en línea con los registrados.
  • Determine si alguien ha agregado una dirección URL de redireccionamiento no autorizada.
  • Confirme la propiedad de su URI de redireccionamiento para asegurarse de que no haya expirado y que no lo haya reclamado un adversario.

Además, si ha implementado Microsoft Defender for Cloud Apps, consulte Azure Portal para ver las alertas relacionadas con la aplicación que está investigando actualmente. No todas las directivas de alerta están habilitadas de forma predeterminada para las aplicaciones de OAuth, por lo que debe asegurarse de que todas estas directivas están habilitadas. Para más información, consulte las directivas de la aplicación OAuth. También puede ver información sobre la prevalencia de las aplicaciones y la actividad reciente en la pestaña Investigación>Aplicaciones de OAuth.

Comprobación de roles de aplicación sospechosos

  • También puede usar los registros de auditoría. Filtrar actividad por Añadir asignación de rol de aplicación al servicio principal.
  • Confirme si los roles asignados tienen privilegios elevados.
  • Confirme si esos privilegios son necesarios.

Comprobación de aplicaciones comerciales no comprobadas

  • Compruebe si se usan aplicaciones de la galería comercial (versiones publicadas y verificadas).

Comprobación de las indicaciones de divulgación de información de propiedad keyCredential

Revise el inquilino para ver la posible divulgación de información de la propiedad keyCredential, como se describe en CVE-2021-42306.

Para identificar y corregir las aplicaciones de Microsoft Entra afectadas asociadas a cuentas de ejecución de Automation afectadas, vaya a la guía de corrección del repositorio de GitHub.

Importante

Evidencia de peligro: si detecta evidencia de peligro, es importante seguir los pasos resaltados en las secciones de contención y recuperación. Estos pasos ayudan a abordar el riesgo, pero realizan una investigación más detallada para comprender el origen del riesgo para evitar un mayor impacto y garantizar que se quiten los actores incorrectos.

Hay dos métodos principales para obtener acceso a los sistemas mediante el uso de aplicaciones. La primera implica que un administrador o usuario dé su consentimiento a una aplicación, normalmente a través de un ataque de suplantación de identidad (phishing). Este método forma parte del acceso inicial a un sistema y a menudo se conoce como "suplantación de identidad de consentimiento".

El segundo método implica una cuenta de administrador ya comprometida que crea una nueva aplicación con fines de persistencia, recopilación de datos y permanecer bajo el radar. Por ejemplo, un administrador en peligro podría crear una aplicación de OAuth con un nombre aparentemente inocuo, evitando la detección y permitiendo el acceso a largo plazo a los datos sin necesidad de una cuenta. Este método se ve a menudo en ataques de estado nacional.

Estos son algunos de los pasos que se pueden realizar para investigar más adelante.

Compruebe el registro de auditoría unificado (UAL) de Microsoft 365 para ver las indicaciones de suplantación de identidad (phishing) de los últimos siete días.

A veces, cuando los atacantes usan aplicaciones malintencionadas o comprometidas como medio de persistencia o para filtrar datos, una campaña de suplantación de identidad está implicada. En función de los resultados de los pasos anteriores, debe revisar las identidades de:

  • Propietarios de la aplicación
  • Administración de consentimiento

Revise las identidades para obtener indicaciones de ataques de suplantación de identidad en las últimas 24 horas. Aumente este intervalo de tiempo si es necesario a 7, 14 y 30 días si no hay indicaciones inmediatas. Para obtener un cuaderno de estrategias detallado de investigación de suplantación de identidad (phishing), consulte el cuaderno de estrategias de investigación de suplantación de identidad (phishing).

Búsqueda de consentimientos de aplicaciones malintencionadas durante los últimos siete días

Para agregar una aplicación a un inquilino, los atacantes suplantan a los usuarios o administradores para dar su consentimiento a las aplicaciones. Para obtener más información sobre los signos de un ataque, consulte el cuaderno de estrategias de investigación de concesión de consentimiento de la aplicación.

Comprobación de los registros de auditoría

Para ver todas las concesiones de consentimiento para esa solicitud, filtre Actividad por Consentimiento para la aplicación.

  • Use el centro de administración de Microsoft Entra del registro de auditoría

  • Uso de Microsoft Graph para consultar los registros de auditoría

    a) Filtre por un período de tiempo específico:

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

b) Filtre los registros de auditoría para las entradas del registro de auditoría "Consentimiento para aplicaciones":

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) Uso de Log Analytics

AuditLogs
| where ActivityDisplayName == "Consent to application"

Para obtener más información, consulte el cuaderno de estrategias de investigación de concesión de consentimiento de la aplicación.

Un usuario puede autorizar a una aplicación a acceder a algunos datos en el recurso protegido, mientras actúa como ese usuario. Los permisos que permiten este tipo de acceso se denominan "permisos delegados" o consentimiento del usuario.

Para buscar aplicaciones que los usuarios consienten, use LogAnalytics para buscar en los registros de auditoría:

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

Compruebe los registros de auditoría para averiguar si los permisos concedidos son demasiado amplios (en todo el inquilino o con consentimiento del administrador).

Revisar los permisos concedidos a una aplicación o entidad de servicio puede ser una tarea que consume mucho tiempo. Comience con la comprensión de los permisos potencialmente peligrosos en Microsoft Entra ID.

Ahora, siga las instrucciones sobre cómo enumerar y revisar los permisos en la investigación de concesión de consentimiento de la aplicación.

Compruebe si las identidades de usuario han concedido los permisos que no deben tener la capacidad de hacerlo, o si las acciones se realizaron en fechas y horas extrañas.

Revisión mediante registros de auditoría:

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

También puede usar los registros de auditoría de Microsoft Entra, filtrar por consentimiento a la aplicación. En la sección Detalles del registro de auditoría, haga clic en Propiedades modificadas y, a continuación, revise ConsentAction.Permissions:

Use the Microsoft Entra audit logs

Pasos de contención

Después de identificar una o varias aplicaciones o identidades de carga de trabajo como malintencionadas o en peligro, es posible que no desee implementar inmediatamente las credenciales de esta aplicación, ni desea eliminar inmediatamente la aplicación.

Importante

Antes de realizar el siguiente paso, la organización debe ponderar el impacto en la seguridad y el impacto empresarial de deshabilitar una aplicación. Si el impacto empresarial de deshabilitar una aplicación es demasiado grande, considere la posibilidad de preparar y pasar a la fase de recuperación de este proceso.

Deshabilitación de la aplicación en peligro

Una estrategia de contención típica implica la deshabilitación de inicios de sesión en la aplicación identificada, para proporcionar al equipo de respuesta a incidentes o el tiempo de unidad de negocio afectado para evaluar el impacto de la eliminación o la rotación de claves. Si la investigación le lleva a creer que las credenciales de la cuenta de administrador también están en peligro, este tipo de actividad debe coordinarse con un evento de expulsión para asegurarse de que todas las rutas para acceder al inquilino se cortan simultáneamente.

Toggle to disable users to sign-in

También puede usar el siguiente código de PowerShell de Microsoft Graph para deshabilitar el inicio de sesión en la aplicación:

# 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
   
}

Pasos de la recuperación

Corrección de entidades de servicio

  1. Enumere todas las credenciales asignadas al principal del servicio de riesgo. La mejor manera de hacerlo es realizar una llamada de Microsoft Graph mediante GET ~/application/{id} donde id pasado es el identificador de objeto de aplicación.

    • Analice la salida de las credenciales. La salida puede contener passwordCredentials o keyCredentials. Registre los keyIds para todos.

      "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. Agregue una nueva credencial de certificado (x509) al objeto de aplicación mediante la API addKey de la aplicación.

    POST ~/applications/{id}/addKey

  3. Quite inmediatamente todas las credenciales antiguas. Para cada credencial de contraseña antigua, quítela mediante:

    POST ~/applications/{id}/removePassword

    Para cada credencial de clave antigua, quítela mediante:

    POST ~/applications/{id}/removeKey

  4. Corrija todas las entidades de servicio asociadas a la aplicación. Siga este paso si el inquilino hospeda o registra una aplicación multiinquilino o registra varias entidades de servicio asociadas a la aplicación. Realice pasos similares a los que se enumeran anteriormente:

  • GET ~/servicePrincipals/{id}

  • Busque passwordCredentials y keyCredentials en la respuesta, registre todos los keyIds antiguos.

  • Quite todas las credenciales de clave y contraseña antiguas. Uso:

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

Corrección de los recursos de entidad de servicio afectados

Corrija los secretos de KeyVault a los que la entidad de servicio tiene acceso rotándolos, en la siguiente prioridad:

  • Secretos expuestos directamente con llamadas GetSecret.
  • El resto de los secretos en KeyVaults expuestos.
  • El resto de los secretos en las suscripciones expuestas.

Para obtener más información, consulte Eliminación e implementación interactiva de los certificados y secretos de una entidad de servicio o una aplicación.

Para obtener instrucciones de Microsoft Entra SecOps sobre las aplicaciones, consulte Guía de operaciones de seguridad de Microsoft Entra para aplicaciones.

En orden de prioridad, este escenario sería:

  • Actualice el documento cmdlets de PowerShell de Graph (Add/Remove ApplicationKey + ApplicationPassword) para incluir ejemplos de sustitución de credenciales.
  • Agregue cmdlets personalizados a Microsoft Graph PowerShell que simplifica este escenario.

Deshabilitar o eliminar aplicaciones malintencionadas

Una aplicación se puede deshabilitar o eliminar. Para deshabilitar la aplicación, en Habilitado para que los usuarios inicien sesión, mueva el botón de alternancia a No.

Puede eliminar la aplicación, ya sea temporalmente o permanentemente, en Azure Portal o a través de Microsoft Graph API. Al eliminar temporalmente, la aplicación se puede recuperar hasta 30 días después de la eliminación.

DELETE /applications/{id}

Para eliminar permanentemente la aplicación, use esta llamada a Microsoft Graph API:

DELETE /directory/deletedItems/{id}

Si deshabilita o elimina temporalmente la aplicación, configure la supervisión en los registros de auditoría de Microsoft Entra para obtener información sobre si el estado cambia de nuevo a habilitado o recuperado.

Registro para habilitado:

  • Servicio: Directorio principal
  • Tipo de actividad: Actualizar el servicio Principal
  • Categoría: Administración de aplicaciones
  • Iniciado por (actor): UPN del actor
  • Destinos: id. de aplicación y nombre para mostrar
  • Propiedades modificadas: nombre de propiedad = cuenta habilitada, nuevo valor = true

Registro para recuperado:

  • Servicio: Directorio principal
  • Tipo de actividad: agregar entidad de servicio
  • Categoría: Administración de aplicaciones
  • Iniciado por (actor): UPN del actor
  • Destinos: id. de aplicación y nombre para mostrar
  • Propiedades modificadas: nombre de propiedad = cuenta habilitada, nuevo valor = true

Nota: Microsoft deshabilita globalmente las aplicaciones que se han detectado que infringen sus Términos de servicio. En esos casos, estas aplicaciones DisabledDueToViolationOfServicesAgreement aparecen en la propiedad disabledByMicrosoftStatus sobre los tipos de recursos principales de aplicaciones y servicios relacionados en Microsoft Graph. Para evitar que se vuelvan a crear instancias en la organización en el futuro, estos objetos no se pueden eliminar.

Implemente Identity Protection para identidades de carga de trabajo

Microsoft detecta el riesgo en las identidades de carga de trabajo a través del comportamiento de inicio de sesión y los indicadores sin conexión de riesgo.

Para más información, consulte Proteger las identidades de la carga de trabajo con Identity Protection.

Estas alertas aparecen en el portal de Identity Protection y se pueden exportar a herramientas de SIEM mediante diagnóstico Configuración o las API de Identity Protection.

Review risks and alerts in the Identity Protection portal

Acceso condicional para las identidades de carga de trabajo de riesgo

El acceso condicional le permite bloquear el acceso a cuentas específicas que designa cuando Identity Protection los marca como "en riesgo". Tenga en cuenta que el cumplimiento a través del acceso condicional está limitado actualmente solo a las aplicaciones de un solo inquilino.

Control user access based on conditional access policy

Para más información, consulte Acceso condicional para las identidades de carga de trabajo.

Implementación de directivas de riesgo de aplicaciones

Revise la configuración del consentimiento del usuario en Microsoft Entra ID>Aplicaciones empresariales>Consentimiento y permisos>Configuración del consentimiento de los usuarios.

Select Allow user consent for apps from the options

Para revisar las opciones de configuración, consulte Configuración de cómo los usuarios dan su consentimiento a las aplicaciones.

Cuando un desarrollador de aplicaciones dirige a los usuarios al punto de conexión de consentimiento del administrador con la intención de otorgar consentimiento para todo el inquilino, esto se conoce como flujo de consentimiento del administrador. Para asegurarse de que el flujo de consentimiento del administrador funcione correctamente, los desarrolladores de aplicaciones deben enumerar todos los permisos en la propiedad RequiredResourceAccess del manifiesto de aplicación.

La mayoría de las organizaciones deshabilitan la capacidad de los usuarios de dar su consentimiento a las aplicaciones. Para proporcionar a los usuarios la capacidad de seguir solicitando consentimiento para las aplicaciones y tener la funcionalidad de revisión administrativa, se recomienda implementar el flujo de trabajo de consentimiento del administrador. Siga los pasos del flujo de trabajo de consentimiento del administrador para configurarlo en el inquilino.

Para las operaciones con privilegios elevados, como el consentimiento del administrador, tiene una estrategia de acceso con privilegios definida en nuestra guía.

El consentimiento escalonado basado en el riesgo ayuda a reducir la exposición de los usuarios a las aplicaciones maliciosas. Por ejemplo, las solicitudes de consentimiento de aplicaciones multiinquilino recién registradas que no están comprobadas por el editor y requieren permisos no básicos se consideran de riesgo. Si se detecta una solicitud de consentimiento de usuario de riesgo, la solicitud requiere un "paso activo" para el consentimiento de administrador. Esta funcionalidad de paso activo está habilitada de manera predeterminada, pero solo produce un cambio de comportamiento cuando está habilitado el consentimiento del usuario.

Asegúrese de que esté habilitado en el inquilino y revise las opciones de configuración que se describen aquí.

Referencias

Cuadernos de estrategias de respuesta ante incidentes adicionales

Examine las instrucciones para identificar e investigar estos tipos de ataques adicionales:

Recursos de respuesta a incidentes