Déploiement de Microsoft Graph pour suivre la piste d’un attaquant

Au cours de la semaine du 20 février 2023, l’équipe Sophos X-Ops MDR a reçu deux demandes distinctes de chasse aux menaces liées à une activité inhabituelle dans les environnements Microsoft 365 (anciennement Office 365) de deux clients. Ces demandes ont déclenché une investigation portant sur des ensembles d’événements de sécurité Microsoft Graph transmis à Sophos XDR, afin d’identifier si une activité suspecte ou malveillante avait véritablement eu lieu. Microsoft Graph gère le flux de données et l’accès au niveau du Cloud de Microsoft (c’est-à-dire 365, Windows et Enterprise Mobility + Security); son API de sécurité peut connecter plusieurs fournisseurs de sécurité et cette dernière leur permet aussi de fonctionner de manière fédérée selon les besoins.

Dans cet article, nous allons vous proposer une présentation détaillée de chaque étape du flux d’attaque, ainsi que l’objectif de chaque technique d’attaque avec la requête qui permet de les identifier dans XDR. Sophos MDR a conclu que la compromission du compte de messagerie avait eu lieu dans les deux cas, en utilisant des Tactiques, Techniques et Procédures (TTP) remarquablement similaires. Le croisement des données des deux cas a montré que les deux compromissions pouvaient être liées au même acteur malveillant (inconnu).

NB : Veuillez noter que les requêtes et les exemples ci-dessous font référence à “CompromisedAdmin@example.com“, “TargetUser@example.com“, etc. Il s’agit donc uniquement de termes génériques qui doivent être remplacés dans vos requêtes par vos propres adresses email administrateur et utilisateur. À des fins d’obfuscation, nous ne ferons pas de liens dans cet article entre les occurrences “example.com” et les incidents client associés.

Matrice MITRE ATT&CK de Microsoft 365

L’environnement d’exploitation de Microsoft 365 est suffisamment unique pour qu’un sous-ensemble spécifique de TTP adverses soit nécessaire pour mener des chasses aux menaces et des investigations dans ces environnements Cloud. La figure 1 montre une capture d’écran de la matrice ATT&CK de MITRE pour Office 365 (MITRE utilise jusqu’à présent l’ancien nom de Microsoft pour son service). Cet article se concentrera sur un sous-ensemble pertinent de TTP pour la compromission des comptes de messagerie et montrera comment ces TTP ont été exploitées afin d’identifier l’activité adverse concernée par cette double chasse aux menaces (les liens vers chacune des tactiques et techniques MITRE citées sont fournis à la fin de cet article).

Figure 1 : Matrice ATT&CK modifiée de Microsoft 365. Notez qu’il y a ici 11 catégories au lieu des 14 composant la version complète d’ATT&CK (la reconnaissance, le développement des ressources et le commande et contrôle ne sont pas utilisés), et que chaque catégorie utilise un sous-ensemble de techniques dans la version complète de MITRE ATT&CK.

Accès Initial (Initial Access) : TA0001

Dans les deux cas, la compromission initiale a eu lieu environ 90 jours avant l’observation de toute action malveillante. Il est possible que ce retard soit voulu : à savoir attendre la période de journalisation par défaut de 90 jours pour que Microsoft 365 soit réinitialisé, ou peut-être en raison d’un transfert d’un courtier en accès initiaux (IAB) vers un autre acteur malveillant. Ce dernier a accédé à plusieurs comptes sur les systèmes ciblés, dans un cas en remplaçant le numéro de téléphone associé à un compte spécifique par un autre numéro de téléphone. Nous examinerons cette technique spécifique dans la section ‘Manipulation de Compte’ (Account Manipulation) ci-dessous.

Comptes Valides (Valid Accounts) : Comptes Cloud/Cloud Accounts (T1078.004)

Connexions Externes

Plusieurs adresses IP externes ont été utilisées pour se connecter à des comptes, que l’acteur a compromis ou créés après avoir obtenu un accès initial par des moyens inconnus (voir la section ‘Persistance/Persistence’ ci-dessous). Trois de ces adresses IP se sont avérées être identiques dans les deux cas.

L’analyse de ces trois adresses IP a donné les résultats suivants :

104.161.20[.]102

• Sept occurrences apparaissent au niveau du signalement d’abus d’adresse IP (IP abuse report) sur AbuseIPDB.
• Nom de domaine de ioflood[.]com, qui est un fournisseur d’hébergement de serveurs dédiés.
• Ports exposés : FTP (21/TCP), RPC (135/TCP), SMB (445/TCP), RDP (3389/TCP)

20.232.202[.]245

• Hébergée dans Microsoft Azure Cloud (région Est des États-Unis)
• Ports exposés : RDP (3389/TCP)

185.241.149[.]122

• 25 occurrences apparaissent au niveau du signalement d’abus d’adresse IP (IP abuse report) sur AbuseIPDB.
• Nom de domaine de ipxo[.]com, qui est une marketplace d’adresses IP louant des ressources IP.
• Ports exposés : RPC (135/TCP), SMB (445/TCP), RDP (3389/TCP)

ioflood.com et ipxo.com, deux sociétés légitimes, ont été contactées par MDR dans le cadre de cet abus observé au niveau de leurs services.

Requête Sophos XDR

SELECT creation_time, user_id, operation, client_ip
FROM xdr_identity_o365
WHERE lower(user_id) IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com)
AND operation IN ('UserLoggedIn', 'UserLoginFailed')

Persistance/Persistence : TA0003

Création de Compte/Create Account : Compte Cloud/Cloud Account (T1136.003)

Au cours des premiers jours de la compromission, l’acteur malveillant a créé un compte ou des comptes sur le système ciblé pour établir la persistance, puis (comme mentionné) a attendu des mois avant d’aller plus loin afin de poursuivre ses objectifs.

Un de ces comptes au niveau administrateur a été créé au cours de la première semaine de décembre ; il a ensuite été utilisé pour créer un autre compte fin février, près de quatre-vingts jours plus tard et quelques jours avant que Sophos ne soit appelé pour porter assistance (les logs avant la création du compte administrateur global n’étaient pas disponibles pour les enquêteurs).

Requête Sophos XDR

SELECT creation_time, user_id, operation, object_id, modified_properties
FROM xdr_identity_o365
WHERE operation LIKE 'Add user.'

Manipulation de Compte/Account Manipulation (T1098)

Mises à Jour Utilisateur

L’acteur malveillant a ajouté un nouveau numéro de téléphone à un compte utilisateur compromis, susceptible d’effectuer et d’intercepter des appels téléphoniques directement ou via Microsoft Teams. L’attaquant peut avoir agi ainsi pour diverses raisons, notamment à des fins d’ingénierie sociale, de dissimulation (masquerading) ou de violation du MFA. Fait intéressant, ce changement de numéro de téléphone s’est produit près de trois semaines avant que de nouvelles activités malveillantes ne soient lancées par l’attaquant.

Opération Exchange : ’Update User’.

Requête Sophos XDR

SELECT creation_time, user_id, operation, client_ip, target, modified_properties
FROM xdr_identity_o365
WHERE lower(user_id)
IN (‘CompromisedAdmin@example.com’, ‘CompromisedAdmin@example.com’) 
AND operation LIKE ‘Update user.’

Manipulation de Compte/Account Manipulation : Autorisations Supplémentaires de Délégation de Messagerie/Additional Email Delegate Permissions (T1098.002)

L’acteur malveillant a tiré parti de son compte privilégié pour s’accorder un accès complet aux boîtes de réception des autres utilisateurs. Il a également utilisé ce privilège pour “envoyer en tant que/send as” (c’est-à-dire envoyer des emails à partir des comptes d’autres utilisateurs), ce qui pourrait conduire à de nouvelles attaques contre les entreprises avec lesquelles ces deux clients travaillent. Les emails ont également été supprimés.

Opérations Exchange : ‘Add-MailboxPermission’, ‘Add-RecipientPermission’

Le tableau suivant donne un exemple de modification d’autorisation pour un accès complet, comme observé à ce stade.

Figure 2 : Extension des autorisations concernant un compte abusé

Requête Sophos XDR

SELECT creation_time, user_id, operation, object_id,
JSON_EXTRACT(parameters, ‘$[2].Value’) AS Access,
JSON_EXTRACT(parameters, ‘$[2].Name’) AS Name,
JSON_EXTRACT(parameters, ‘$[1].Value’) AS Source, parameters
FROM xdr_identity_o365
WHERE lower(user_id) 
IN (‘CompromisedAdmin@example.com’, ‘CompromisedAdmin@example.com’)
AND operation LIKE ‘%Permission%’

Manipulation de Compte/Account Manipulation : Rôles Cloud Additionnels/Additional Cloud Roles (T1098.003)

Modifications SharePoint

L’acteur malveillant a ajouté le compte administrateur compromis au SharePoint de l’entreprise ciblée avec le rôle “administrateur du site (site admin)“. De plus, il a également activé le “partage via des liens anonymes“, permettant à l’acteur de créer des liens vers des fichiers qui ne nécessitaient pas d’authentification pour y accéder.

Opérations Exchange : ‘SiteLocksChanged’, ‘SiteCollectionCreated’, ‘SiteCollectionAdminAdded’

Le tableau suivant donne des exemples de rôles Cloud modifiés pour accorder un accès complet, comme observé à ce stade.

Figure 3 : Modification des rôles pour donner un accès complet au compte contrôlé par l’attaquant

Requête Sophos XDR

SELECT creation_time, user_id, operation, client_ip, object_id, modified_properties
FROM xdr_identity_o365 WHERE lower(user_id)
IN (‘CompromisedAdmin@example.com’, ‘CompromisedAdmin@example.com’)
AND operation IN (‘SiteLocksChanged’, ‘SiteCollectionCreated’,’ SiteCollectionAdminAdded’)

Collecte/Collection : TA0009

Collecte d’Email/Email Collection : Collecte d’Email à Distance/Remote Email Collection (T1114.002)

Après s’être donné des autorisations complètes au niveau des boîtes de réception des autres utilisateurs, l’acteur malveillant a commencé à lire les emails des utilisateurs pour en savoir plus sur ces derniers et l’entreprise concernée. Ce niveau d’accès peut également être utilisé pour obtenir des données personnelles et sensibles concernant les opérations bancaires, les activités commerciales, la vérification de la configuration MFA, et bien plus encore, notamment l’activité liée au changement de numéro de téléphone mentionné dans la section ‘Manipulation de Compte’. Les emails de cet utilisateur ont alors été consultés environ 20 jours avant cette phase, probablement pour une reconnaissance plus approfondie du réseau.

L’acteur malveillant pouvait également accéder, créer, répondre et envoyer des emails à partir du compte administrateur compromis, se faisant alors passer pour l’utilisateur ciblé avec un accès à sa boîte de réception et aux diverses interactions. Il est également possible que le numéro de téléphone ajouté au compte mentionné dans ‘Manipulation de Compte’ ait été utilisé pour se faire passer pour le propriétaire du compte, suite à l’accès aux emails de l’utilisateur à partir d’un autre compte appartenant à ce dernier.

Certains en-têtes et créations d’email intéressants comprenaient des réponses aux demandes de code d’accès, des emails liés aux opérations bancaires (comme indiqué dans le tableau ci-dessous) et des réponses aux emails internes concernant des projets.

Opérations Exchange : ‘Update’, ‘Create’, ‘SendAs’.

Le tableau suivant donne un exemple du compte contrôlé par l’attaque se faisant passer pour un autre compte, comme observé à ce stade.

Figure 4 : Le compte contrôlé par l’attaquant est modifié pour se faire passer pour un autre utilisateur

Requête Sophos XDR

SELECT creation_time, user_id, operation, client_ip, mailbox_owner_upn, modified_properties, JSON_EXTRACT(item, '$.Subject') AS Subject, item
FROM xdr_identity_o365
WHERE lower(user_id)
IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com’)
AND operation IN ('SendAs', 'Create', 'Update')

Collecte d’Email/Email Collection : Règle de Transfert d’Email/Email Forwarding Rule (T1114.003)

Règles de Transport

Dans les deux cas, l’acteur malveillant a mis en œuvre des règles de transport ou modifié des règles existantes. Ces règles de transport suivent des termes liés au blocage des activités suspectes telles que “Block Spoofing” ou “[REDACTED] Compromise”.

Ces règles ont été utilisées pour rediriger les emails contenant certains en-têtes liés à “admin” ou “OnlineBanking” vers la boîte de réception de l’utilisateur compromis.

D’autres règles ont été ajoutées pour supprimer les emails dans ces règles de transport (Suppression de l’indicateur/Indicator Removal : Supprimer les données de la boîte de réception/Clear Mailbox Data : T1070.008) afin que l’email en question soit transféré vers le compte compromis et supprimé instantanément de la boîte de réception de l’utilisateur.

Opérations Exchange : ‘New-TransportRule’, ‘Set-TransportRule’, ‘Enable-TransportRule’.

Règle de Transport : Exemple n°1

Cette règle a permis à l’acteur de contrôler les emails qui seraient véritablement envoyés vers la boîte de réception d’un utilisateur cible en abusant de la fonctionnalité.

[
    {   "Name": "Name",
        "Value": "Block Phishing"
    },
    {.  
        "Name": "ModerateMessageByUser",
        "Value": "CompromisedAdmin@example.com"
    },

    {
        "Name": "SubjectOrBodyContainsWords",
        "Value": "Exchange admin privilege;Global Administrator;AddMailboxPermission;Add Mailbox Permissions;Add-MailboxPermission;User at risk detected;Risky sign-in;Mailbox Permission Changed;High-severity alert;[REDACTED BANKING SUBJECT LINE]"
    },
    {
        "Name": "DeleteMessage",
        "Value": "False"
    }
]

Règle de Transport : Exemple n°2

Cette règle permettait à l’acteur de supprimer les emails avec un sujet ou un corps de message spécifique afin d’éviter d’éveiller les soupçons des administrateurs et des utilisateurs de l’entreprise cible.

[
	{
		"Name": "Name",
		"Value": "Display name spoofing"
	},
	{
		"Name":"SubjectOrBodyContainsWords"
		"Value":"Exchange admin privilege;A user account has been created or modified;Suspicious Inbox Rule;AddMailboxPermission;Add Mailbox Permissions;Add-MailboxPermission;High-severity alert;InsightIDR Incident Alert;Granted mailbox permission;New-InboxRule;CompromisedAdmin@example.com ",
	},
	{
		"Name":"DeleteMessage"
		"Value":"True",
	},
	{
		"Name":"RedirectMessageTo"
		"Value":"",
	},
	{
		"Name":"ExceptIfFrom"
		"Value":"",
	},
	{
		"Name":"HeaderMatchesMessageHeader"
		"Value":"",
	},
	{
		"Name":"HeaderMatchesPatterns"
		"Value":"",
	}
]

Le tableau suivant fournit une liste des noms de règle de transport observés à ce stade, avec quelques adaptations pour protéger l’identité du client.

Figure 5 : Une sélection d’indicateurs confirmant la conclusion émise par les chasseurs selon laquelle il s’agit bien de T1114.003 en action

Requête Sophos XDR

SELECT creation_time, user_id, operation, client_ip, object_id, parameters
FROM xdr_identity_o365
WHERE lower(user_id)
IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com’)
AND operation LIKE '%Transport%'

Évasion de Défense/Defense Evasion : TA0005

Altération des Défenses/Impair Defenses : Désactivation ou Modification des Outils/Disable or Modify Tools (T1562.001)

TenantAllowBlockListSpoofItems

Dans les deux cas, l’acteur malveillant a exploité la fonction Online Exchange “TenantAllowBlockListSpoofItems” pour ajouter des entrées d’expéditeurs usurpés à la liste d’autorisation des locataires (Tenant), leur permettant de contourner les règles d’expéditeurs usurpés et d’envoyer des emails à des cibles à partir de domaines usurpés.

Dans l’un des cas, l’acteur malveillant est allé plus loin et a ajouté quelques domaines supplémentaires ainsi qu’une adresse IP à la liste des locataires (Tenant) autorisés/bloqués :

• iad3a.emailsrvr[.]com
• continental-database[.]com
• “104.161.20[.]102”

Notez que l’adresse IP de cette règle a été utilisée dans les deux cas pour se connecter à des comptes compromis.

Opération Exchange : ‘New-TenantAllowBlockListSpoofItems’.

Exemples de TenantAllowBlockListSpoofItems

[
    {
        "Name": "Identity"
        "Value": "default",
    },
    {
        "Name": "SpoofType"
        "Value": "External",
    },
    {
        "Name": "Action"
        "Value": "Allow",
    },
    {
        "Name": "SpoofedUser"
        "Value": "impersonated-email-account.com",
    },
    {
        "Name": "SendingInfrastructure"
        "Value": "botasso.cl",
    }
]

Requête Sophos XDR

SELECT creation_time, user_id, operation, client_ip, object_id, parameters
FROM xdr_identity_o365
WHERE lower(user_id)
IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com’)
AND operation LIKE '%Spoof%'

Suppression de l’Indicateur/Indicator Removal: Supprimer les données de la boîte de réception/Clear Mailbox Data (T1070.008)

Suppression d’Email

La suppression des emails a été utilisée comme tactique dans les deux cas. Certaines suppressions se sont produites en raison des règles de transport ajoutées par l’attaquant (Collecte d’Email/Email Collection : Règle de Transfert d’Email/Email Forwarding Rule – T1114.003).

Les emails supprimés peuvent fournir un contexte dans le but de l’attaque. Dans l’un des cas, nous avons observé des emails créés concernant des codes d’accès (notamment pour les services bancaires en ligne), ainsi que des emails supprimés révélant qu’un code d’accès avait été réinitialisé. D’autres activités ont été observées, telles que des “verrouillages” et des “réinitialisations de mot de passe”, indiquant clairement que l’acteur avait probablement compromis le processus d’authentification des utilisateurs ciblés.

L’acteur a également supprimé les emails reçus de la part de Microsoft 365 Security, susceptibles d’empêcher les contrôles de sécurité tiers d’informer la victime au sujet de la menace.

Opérations Exchange : ‘MoveToDeletedItems’, ‘HardDelete’, ‘SoftDelete’.

Le tableau suivant fournit une liste des règles de suppression d’email observées à ce stade, avec quelques adaptations pour protéger l’identité du client.

Figure 6 : Manipulation des règles pour rediriger les emails susceptibles d’alerter l’utilisateur ciblé sur la présence de l’attaquant

Requête Sophos XDR

SELECT creation_time, user_id, operation, client_ip, mailbox_owner_upn,

JSON_EXTRACT(affected_items, '$[0].Subject') AS Subject, affected_items
FROM xdr_identity_o365
WHERE lower(user_id)
IN (‘CompromisedAdmin@example.com', ‘CompromisedAdmin@example.com’)
AND operation IN ('MoveToDeletedItems', 'HardDelete', 'SoftDelete')

Recommandations

Il existe de nombreuses options disponibles pour lutter contre la compromission de compte de messagerie tels que celles présentées dans cet article. Votre meilleur choix dépendra des activités de votre entreprise, des coûts, de votre modèle de risque et de vos besoins.

Nous présenterons ici quelques suggestions de base. Cependant, nous vous recommandons fortement d’opter pour des mécanismes de prévention et de détection, adaptés à votre environnement et basés sur les tactiques et techniques détaillées dans cet article (c’est-à-dire les détections XDR et les chasses aux menaces régulières).

1. Activez le MFA pour les utilisateurs privilégiés (ou tous les utilisateurs, si possible).
2. Effectuez régulièrement des audits au niveau des créations de compte utilisateur et administrateur.
3. Ajoutez les adresses IP d’une plage approuvée pour l’authentification (par exemple, votre sous-réseau VPN) et bloquez les plages non approuvées.
4. Choisissez une conservation de données prolongée pour votre produit XDR afin de maintenir la journalisation au-delà de la période de rétention par défaut de 90 jours (ou envisagez des solutions de transfert/journalisation d’événements).

Indicateurs de compromission (IOC)

Une liste d’indicateurs de compromission associée à cette investigation est disponible sur notre GitHub.

Toutes les techniques et sous-techniques ATT&CK décrites ci-dessus sont documentées sur le site de MITRE. Des liens vers chaque description sont fournis ci-dessous pour faciliter la navigation.

• Initial Access: TA0001
  • Valid Accounts: Cloud Accounts (T1078.004)
• Persistence: TA0003
  • Create Account: Cloud Account (T1136.003)
  • Account Manipulation (T1098)
  • Account Manipulation: Additional Email Delegate Permissions (T1098.002)
  • Account Manipulation: Additional Cloud Roles (T1098.003)
• Collection: TA0009
  • Email Collection: Remote Email Collection (T1114.002)
  • Email Collection: Email Forwarding Rule (T1114.003)
• Defense Evasion: TA0005
  • Impair Defenses: Disable or Modify Tools (T1562.001)
  • Indicator Removal: Clear Mailbox Data (T1070.008)

Remerciements

Imane Ismail a joué un rôle déterminant dans l’investigation menée sur ces 2 cas.

Billet inspiré de Investigator, API Yourself: Deploying Microsoft Graph on the trail of an attacker, sur le Blog Sophos.