{"id":22353,"date":"2023-06-30T11:21:16","date_gmt":"2023-06-30T19:21:16","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2023\/06\/30\/news-16083\/"},"modified":"2023-06-30T11:21:16","modified_gmt":"2023-06-30T19:21:16","slug":"news-16083","status":"publish","type":"post","link":"https:\/\/www.palada.net\/index.php\/2023\/06\/30\/news-16083\/","title":{"rendered":"Investigator, API Yourself: Deploying Microsoft Graph on the trail of an attacker"},"content":{"rendered":"

Credit to Author: gallagherseanm| Date: Fri, 30 Jun 2023 17:47:14 +0000<\/strong><\/p>\n

\n

During the week of February 20, 2023, Sophos X-Ops MDR team received two separate requests for threat hunts related to unusual activity in two customers\u2019 Microsoft 365 (formerly Office 365) environments. This prompted an investigation into sets of Microsoft Graph security events forwarded to Sophos XDR, to identify whether suspicious or malicious activity occurred. Microsoft Graph handles dataflow and access in Microsoft\u2019s cloud (ie., 365, Windows, and Enterprise Mobility + Security); its Security API can connect multiple security providers and lets them operate in a federated fashion as needed.<\/p>\n

In this article, we will provide a detailed walkthrough of each step in the attack flow, along with the purpose of each attack technique and the query by which each is identified in XDR. Sophos MDR concluded that email account compromise took place in both cases, using remarkably similar tactics, techniques, and procedures (TTPs). Cross-referencing data from both cases showed that the two compromises may be related to the same (unknown) threat actor.<\/p>\n

(Please note that the queries and examples below refer to ‘CompromisedAdmin@example.com’, \u2018TargetUser@example.com\u2019, and so forth. These are placeholders and should be replaced in your queries with your own admin and user email addresses. As an obfuscation measure, we do not differentiate in this writeup which appearances of \u201cexample.com\u201d are connected to which customer\u2019s incident.)<\/p>\n

Microsoft 365\u2019s MITRE ATT&CK Matrix<\/h2>\n

The operating environment of Microsoft 365 is unique enough that a specific subset of adversarial TTPs are required to conduct threat hunts and investigations within these cloud environments. Figure 1 shows a screenshot of MITRE\u2019s ATT&CK Matrix for Office 365<\/a>. (MITRE is so far using Microsoft\u2019s previous name for the service.) This article will focus on a subset of these TTPs relevant to email account compromise, and show how they were leveraged to identify the adversarial activity exposed in this double threat hunt. (Links to each of the MITRE tactics and techniques cited are provided at the end of this article.)<\/p>\n

\"Figure<\/a>
Figure 1: Microsoft 365\u2019s modified ATT&CK matrix. Note that there are 11 categories instead of the full ATT&CK\u2019s 14 (Reconnaissance, Resource Development, and Command and Control are not used), and that each category uses a subset of techniques in the MITRE\u2019s full version of ATT&CK<\/figcaption><\/figure>\n

Initial Access: TA0001<\/h2>\n

In both cases, the initial compromise took place approximately 90 days prior to any observed malicious execution. It is possible this delay was purposeful — to wait out the default 90-day logging period for Microsoft 365 to roll over, or perhaps due to a handover from an Initial Access Broker (IAB) to another threat actor. The threat actor accessed multiple accounts on the targeted systems, in one case changing the phone number associated with a specific account to a different phone number. We\u2019ll examine this specific technique in the Account Manipulation section below.<\/p>\n

 <\/p>\n

Valid Accounts: Cloud Accounts (T1078.004)<\/h3>\n

External Logins<\/h3>\n

Multiple external IP addresses were used to log into accounts, which the actor compromised or created after gaining initial access by unknown means (see Persistence section below). Three of these IP addresses were observed to be identical in both cases.<\/p>\n

Analysis of these three IP addresses produced the following results:<\/p>\n

104.161.20[.]102<\/strong><\/p>\n

    \n
  • Seven counts of IP abuse reports on AbuseIPDB<\/li>\n
  • Domain name of ioflood[.]com, which is a dedicated-server hosting provider<\/li>\n
  • Exposed ports: FTP (21\/TCP), RPC (135\/TCP), SMB (445\/TCP), RDP (3389\/TCP)<\/li>\n<\/ul>\n

    20.232.202[.]245<\/strong><\/p>\n

      \n
    • Hosted in Microsoft Azure Cloud (EastUS region)<\/li>\n
    • Exposed ports: RDP (3389\/TCP)<\/li>\n<\/ul>\n

      185.241.149[.]122<\/strong><\/p>\n

        \n
      • 25 counts of IP abuse reports on AbuseIPDB<\/li>\n
      • Domain name of ipxo[.]com, which is an IP-address marketplace leasing IP resources<\/li>\n
      • Exposed ports: RPC (135\/TCP), SMB (445\/TCP), RDP (3389\/TCP)<\/li>\n<\/ul>\n

        ioflood.com and ipxo.com, both legitimate companies, were contacted by MDR in connection with this observed abuse of their services.<\/p>\n

         <\/p>\n

        Sophos XDR Query<\/h3>\n
        SELECT creation_time, user_id, operation, client_ip  FROM xdr_identity_o365  WHERE lower(user_id) IN (\u2018CompromisedAdmin@example.com', \u2018CompromisedAdmin@example.com)  AND operation IN ('UserLoggedIn', 'UserLoginFailed')<\/pre>\n
        Persistence: TA0003<\/h2>\n
        Create Account: Cloud Account (T1136.003)<\/h3>\n
        During the early days of the compromise, the threat actor created an account or accounts on the targeted system to establish persistence, and then (as mentioned) waited months before acting further on their objectives.<\/p>\n
        One such admin-level account was created during the first week of December; it was then used to create another account in late February, nearly eighty days later and a few days before Sophos was called in on the case. (Logs before the creation of the global admin account were not available to investigators.)<\/p>\n
        Sophos XDR Query<\/h3>\n
        SELECT creation_time, user_id, operation, object_id, modified_properties  FROM xdr_identity_o365  WHERE operation LIKE 'Add user.'<\/pre>\n
         <\/p>\n
        Account Manipulation (T1098)<\/h2>\n
        User Updates<\/h3>\n
        The threat actor added a new phone number to a compromised user account, likely to perform and intercept phone calls directly or via Microsoft Teams. There are various reasons the attacker might have done this, including social-engineering purposes, masquerading, or MFA subversion. Interestingly, this phone-number change happened nearly three weeks prior to further attacker activity.<\/p>\n
        Exchange Operation:<\/strong> \u2018Update User\u2019.<\/p>\n
        Sophos XDR Query<\/h3>\n
        SELECT creation_time, user_id, operation, client_ip, target, modified_properties  FROM xdr_identity_o365  WHERE lower(user_id)  IN (\u2018CompromisedAdmin@example.com\u2019, \u2018CompromisedAdmin@example.com\u2019)   AND operation LIKE \u2018Update user.\u2019<\/pre>\n
        Account Manipulation: Additional Email Delegate Permissions (T1098.002)<\/h3>\n
        The threat actor leveraged their privileged account to grant themself full access to other users\u2019 mailboxes. They also used this privilege to \u201csend as\u201d (i.e., send email from other users\u2019 accounts) \u2013 potentially leading to further attack efforts at companies with which these two customers do business. Emails were also deleted.<\/p>\n
        Exchange Operations:<\/strong> \u2018Add-MailboxPermission\u2019, \u2018Add-RecipientPermission\u2019<\/p>\n
        The following table gives an example of permission modification for full access as seen at this stage.<\/p>\n
        Figure 2: Expanding permissions for an abused account<\/em><\/p>\n
        Sophos XDR Query<\/h3>\n
        SELECT creation_time, user_id, operation, object_id,  JSON_EXTRACT(parameters, \u2018$[2].Value\u2019) AS Access,  JSON_EXTRACT(parameters, \u2018$[2].Name\u2019) AS Name,  JSON_EXTRACT(parameters, \u2018$[1].Value\u2019) AS Source, parameters  FROM xdr_identity_o365  WHERE lower(user_id)   IN (\u2018CompromisedAdmin@example.com\u2019, \u2018CompromisedAdmin@example.com\u2019)  AND operation LIKE \u2018%Permission%\u2019<\/pre>\n
         <\/p>\n
        Account Manipulation: Additional Cloud Roles (T1098.003)<\/h3>\n
        SharePoint Modifications<\/h3>\n
        The threat actor added the compromised administrator account to the target organization\u2019s SharePoint with the \u201csite admin\u201d role. In addition, they also enabled \u201cshare using anonymous links,\u201d allowing the actor to create links to files that did not require authentication to access.<\/p>\n
        Exchange Operations:<\/strong> \u2018SiteLocksChanged\u2019, \u2018SiteCollectionCreated\u2019, \u2018SiteCollectionAdminAdded\u2019<\/p>\n
        The following table gives examples of cloud roles changed to grant full access as seen at this stage<\/p>\n\n\n\n\n\n\n\n
        User<\/strong><\/th>\nOperation<\/strong><\/th>\nObject ID<\/strong><\/th>\nModified Properties<\/strong><\/th>\n<\/tr>\n
        CompromisedAdmin@example.com<\/td>\nSiteLocksChanged<\/td>\nhttps:\/\/sharepoint.com\/<user_page><\/td>\n[{“OldValue”:”True”,”NewValue”:”False”,”Name”:
         “SiteAccess”}]<\/td>\n<\/tr>\n
        CompromisedAdmin@example.com<\/td>\nSiteCollectionAdminAdded<\/td>\nhttps:\/\/sharepoint.com\/<user_page><\/td>\n[{“OldValue”:””,”NewValue”:”CompromisedAdmin@example.com”,
         “Name”:”SiteAdmin”}]<\/td>\n<\/tr>\n
        CompromisedAdmin@example.com<\/td>\nSharingPolicyChanged<\/td>\nhttps:\/\/sharepoint.com\/<user_page><\/td>\n[{“OldValue”:”False”,”NewValue”:”True”,”Name”:
         “ShareUsingAnonymousLinks”}]<\/td>\n<\/tr>\n
        CompromisedAdmin@example.com<\/td>\nSharingPolicyChanged<\/td>\nhttps:\/\/sharepoint.com\/<user_page><\/td>\n[{“OldValue”:”Disabled”,”NewValue”:”Enabled”,
         “Name”:”ShareUsingAnonymousLinks”}]<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        Figure 3: Altering roles to give the attacker-controlled account full access<\/em><\/p>\n
        Sophos XDR Query<\/h3>\n
        SELECT creation_time, user_id, operation, client_ip, object_id, modified_properties  FROM xdr_identity_o365 WHERE lower(user_id)  IN (\u2018CompromisedAdmin@example.com\u2019, \u2018CompromisedAdmin@example.com\u2019)  AND operation IN (\u2018SiteLocksChanged\u2019, \u2018SiteCollectionCreated\u2019,\u2019 SiteCollectionAdminAdded\u2019)<\/pre>\n
         <\/p>\n
        Collection: TA0009<\/h2>\n
        Email Collection: Remote Email Collection (T1114.002)<\/h3>\n
        After giving themselves full permissions to other users\u2019 mailboxes, the threat actor proceeded to read users\u2019 emails to learn more about the users and the organization. This level of access may also be used to gain personal and sensitive data surrounding banking, business operations, verifying MFA configuration, and much more, including activity related to the phone-number change mentioned in the Account Manipulation section. That user\u2019s emails were at this point accessed approximately 20 days prior to this phase, likely for further in-network reconnaissance.<\/p>\n
        The threat actor could also access, create, respond, and send emails from the compromised admin account, masquerading as the targeted user whose mailbox they were interacting with. It\u2019s also possible that the phone number added to the account mentioned in Account Manipulation was used to masquerade as the account owner, following access of the user’s emails from another account owned by that user.<\/p>\n
        Some interesting headers and email creations included responses to passcode requests, banking-related emails (as shown in the table below), and responding to internal project emails.<\/p>\n
        Exchange Operations:<\/strong> \u2018Update\u2019, \u2018Create\u2019, \u2018SendAs\u2019.<\/p>\n
        The following table gives an example of the attack-controlled account masquerading as another account as seen at this stage.<\/p>\n\n\n\n\n
        user<\/strong><\/td>\noperation<\/strong><\/td>\nmailbox_owner<\/strong><\/td>\nsubject<\/strong><\/td>\n<\/tr>\n
        CompromisedAdmin@example.com<\/td>\nSendAs<\/td>\nTargetUser@example.com<\/td>\n\u201cAccepted: [BANK NAME REDACTED] Passcode\u201d<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        Figure 4: The attacker-controlled account is adjusted to masquerade as another user<\/em><\/p>\n
        Sophos XDR Query<\/h3>\n
        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 (\u2018CompromisedAdmin@example.com', \u2018CompromisedAdmin@example.com\u2019)  AND operation IN ('SendAs', 'Create', 'Update')<\/pre>\n
        Email Collection:\u00a0Email Forwarding Rule (T1114.003)<\/h2>\n
        Transport Rules<\/h3>\n
        In both cases, the threat actor implemented transport rules or edited existing rules. These transport rules follow names related to blocking suspicious activity such as \u201cBlock Spoofing\u201d or \u201c[REDACTED] Compromise.\u201d<\/p>\n
        These rules were used to redirect emails containing certain headers related to \u201cadmin\u201d or \u201cOnlineBanking\u201d to the compromised user\u2019s mailbox.<\/p>\n
        Other rules were added to delete the emails in these transport rules (Indicator Removal: Clear Mailbox Data \/ T1070.008) so that mail is forwarded to the compromised account and deleted from the user\u2019s mailbox instantaneously.<\/p>\n
        Exchange Operations:<\/strong> \u2018New-TransportRule\u2019, \u2018Set-TransportRule\u2019, \u2018Enable-TransportRule\u2019.<\/p>\n
        Transport Rule Example 1<\/h3>\n
        This rule enabled the actor to control which emails would be delivered to a target user\u2019s mailbox by abusing the ModerateMessageByUser feature of Exchange Online.<\/p>\n
        [  \u00a0\u00a0\u00a0 {  \u00a0\"Name\": \"Name\",   \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"Value\": \"Block Phishing\"   \u00a0\u00a0 },   \u00a0\u00a0 {.            \"Name\": \"ModerateMessageByUser\",   \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"Value\": \"CompromisedAdmin@example.com\"  \u00a0\u00a0\u00a0 },     \u00a0\u00a0 {   \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"Name\": \"SubjectOrBodyContainsWords\",   \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"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]\"   \u00a0\u00a0 },   \u00a0\u00a0 {   \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"Name\": \"DeleteMessage\",   \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"Value\": \"False\"   \u00a0\u00a0 }  ]<\/pre>\n
        Transport Rule Example 2<\/h3>\n
        This rule enabled the actor to delete emails with specific subject or body content to avoid raising suspicion of administrators and users of the target organization.<\/p>\n
        [  \t{  \t\t\"Name\": \"Name\",  \t\t\"Value\": \"Display name spoofing\"  \t},  \t{  \t\t\"Name\":\"SubjectOrBodyContainsWords\"  \t\t\"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 \",  \t},  \t{  \t\t\"Name\":\"DeleteMessage\"  \t\t\"Value\":\"True\",  \t},  \t{  \t\t\"Name\":\"RedirectMessageTo\"  \t\t\"Value\":\"\",  \t},  \t{  \t\t\"Name\":\"ExceptIfFrom\"  \t\t\"Value\":\"\",  \t},  \t{  \t\t\"Name\":\"HeaderMatchesMessageHeader\"  \t\t\"Value\":\"\",  \t},  \t{  \t\t\"Name\":\"HeaderMatchesPatterns\"  \t\t\"Value\":\"\",  \t}  ]    <\/pre>\n
        The following table provides a list of transport rule names observed at this stage, with some redactions to protect customer identity.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
        object_id<\/strong><\/td>\n<\/tr>\n
        Block Spoofing<\/td>\n<\/tr>\n
        Block Phishing<\/td>\n<\/tr>\n
        Copy of WarnAuditHigh-RiskPhishingPatterns<\/td>\n<\/tr>\n
        WarnAuditHigh-RiskPhishingPatterns<\/td>\n<\/tr>\n
        [REDACTED \/\/ BANKING]<\/td>\n<\/tr>\n
        Display name spoofing<\/td>\n<\/tr>\n
        Bypass SPAM Filter<\/td>\n<\/tr>\n
        [REDACTED] Compromise<\/td>\n<\/tr>\n
        redirect [REDACTED] email to DC<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        Figure 5: A selection of indicators supporting the hunters\u2019 conclusion that this is T1114.003 in action<\/em><\/p>\n
        Sophos XDR Query<\/h3>\n
        SELECT creation_time, user_id, operation, client_ip, object_id, parameters  FROM xdr_identity_o365  WHERE lower(user_id)  IN (\u2018CompromisedAdmin@example.com', \u2018CompromisedAdmin@example.com\u2019)  AND operation LIKE '%Transport%'<\/pre>\n
        Defense Evasion: TA0005<\/h2>\n
        Impair Defenses: Disable or Modify Tools (T1562.001)<\/h3>\n
        TenantAllowBlockListSpoofItems<\/h3>\n
        In both cases, the threat actor leveraged the Exchange Online function \u201cTenantAllowBlockListSpoofItems\u201d to add spoofed sender entries to the tenant allow list, enabling them to bypass spoofed sender rules and send emails to targets from spoofed domains.<\/p>\n
        In one of the cases, the threat actor went a step further and added a few additional domains as well as an IP address to the Tenant Allow\/Block list:<\/p>\n