Unmasking VEILDrive: Threat Actors Exploit Microsoft Services for C2

TL;DR

• Hunters’ Team AXON has identified and is currently monitoring an ongoing threat campaign, dubbed “VEILDrive”
• The campaign was originally identified as part of an AXON engagement to address a malicious activity identified in one of our customers' infrastructure
• As part of the investigation, we identified different Microsoft infrastructure components of additional victim organizations that were compromised and used by the attacker
• The attacker leveraged different Microsoft SaaS services and applications as part of the campaign, including Microsoft Teams, SharePoint, Quick Assist, and OneDrive
• The attacker used a unique OneDrive-based Command & Control (C&C) method as part of the malware found in the victim’s infrastructure
• Based on the conclusions from our investigation, there is a significant probability that this campaign originates from Russia
• Team AXON reported its findings to Microsoft to assist in shutting down the actor’s infrastructure
• The team also reached out to multiple affected victims identified during our research.
  
  

Executive Summary

Hunters’ Team AXON has uncovered and is actively monitoring an ongoing threat campaign dubbed "VEILDrive”. Initially discovered during an investigation of malicious activity in a customer's infrastructure, VEILDrive leverages Microsoft’s SaaS suite—particularly Teams, SharePoint, Quick Assist, and OneDrive—to execute its tactics. Uniquely, the threat actor utilizes a OneDrive-based Command & Control (C&C) method embedded within custom malware that is deployed on compromised environments. Our analysis indicates a probable Russian origin for this campaign, and Team AXON has since alerted both Microsoft and impacted organizations to mitigate further exploitation.

Our research began in September 2024 following a response to an attack on a critical infrastructure entity in the United States. VEILDrive’s attack techniques diverge distinctly from typical threat behavior. They heavily rely on Microsoft’s SaaS infrastructure to distribute spear-phishing campaigns and store malicious software. This SaaS-dependent strategy complicates real-time detection and bypasses conventional defenses.

The malware associated with VEILDrive is a Java-based .jar file that notably lacks obfuscation, making it unusually readable and well-structured. Despite its simplicity, the malware evaded detection by a top-tier Endpoint Detection and Response (EDR) tool and all security engines in VirusTotal. This highlights a critical risk: even non-obfuscated, straightforward code can evade modern detection mechanisms, suggesting a broader need to revisit detection strategies in high-risk environments.

This report provides insights into VEILDrive's methodologies and the limitations of current detection approaches to better equip the cybersecurity community against evolving threats.

Background

In September 2024, Team AXON responded to an incident targeting a critical infrastructure company in the United States. This investigation revealed a unique threat campaign, "VEILDrive”, which displayed unusual tactics, techniques, and procedures (TTPs) that deviated significantly from those typically seen in similar incidents.

Based on our findings, we estimate that the VEILDrive campaign began in early August 2024 and remains active as of this report. Leveraging Microsoft SaaS services—including Teams, SharePoint, Quick Assist, and OneDrive—the attacker exploited the trusted infrastructures of previously compromised organizations to distribute spear-phishing attacks and store malware. This cloud-centric strategy allowed the threat actor to avoid detection by conventional monitoring systems.

Notably, VEILDrive introduced a novel OneDrive-based Command & Control (C&C) method embedded in Java-based malware deployed on compromised devices. The malware itself, a .jar file, exhibits two striking features:

• Code Transparency: With zero obfuscation and well-structured code, this malware defies the typical trend of evasion-focused design, making it unusually readable and straightforward.
• Stealth Effectiveness: Despite its simplicity, this malware remained undetected by both the top-tier Endpoint Detection and Response (EDR) solution deployed in the victim environment and all security engines in VirusTotal (see Figure 1 below):

Figure 1: VirusTotal screenshot showing undetected Java malware; no detections from any VirusTotal engines.

These characteristics highlight that even without sophisticated evasion techniques, carefully crafted, non-obfuscated malware can evade modern defenses. This investigation underscores a gap in current detection strategies and emphasizes the need for vigilance against less conventional attack approaches.

Team AXON has shared its findings with Microsoft and impacted organizations, offering actionable intelligence to mitigate this ongoing threat.

The VEILDrive Attack Path 

In early September 2024, one of Hunters' customers, referred to here as "Org C”, engaged Team AXON for support in handling an active incident. The case centered on a specific device within Org C that had been compromised via social engineering.

A suspiciously created scheduled task on an Org C employee’s device triggered an alert, prompting further investigation. By correlating logs and communicating with the affected user, the team clarified the method of initial access.

Below is an Attack Diagram that provides a high-level overview of the attack flow: 

The sequence of events unfolded as follows:

Step 1

• The malicious actor leveraged Microsoft Teams to message four selected employees at Org C, who, aside from being non-technical based on their roles, had no other apparent connection. The attacker impersonated an IT team member and requested access to each employee’s device via the Quick Assist remote utility tool.
  
  Rather than using a newly created account for impersonation, the attacker utilized a compromised user account from a potential previous victim, referred to here as "Org A.”
  
  M365 Audit Logs were used to identify the Microsoft Teams spear-phishing. 

• • Multiple “MessageSent” and “ChatCreated” events were identified, all originating from the previously compromised user of Org A, owned by the threat actor.
  • While 4 employees were targeted, only one “MemberAdded” event was identified targeting the compromised user of Org A.

Figure 2: Microsoft 365 audit logs entry from Org C - showing the "MemberAdded" event in which Org A's previously compromised user account was added to a One-On-One chat with the victim of Org C.

• • This “MemberAdded” event was conducted by the only user account of the 4 targeted users that accepted the threat actor access request, creating a one-on-one chat. This means this user was the only one who actively interacted with the incoming message.
  • This information aligned with data from the organization's EDR telemetry, confirming that the user not only accepted the request and received the message but also enabled the attacker to gain initial access due to successful social engineering.

The above insight was both intriguing and valuable, highlighting the increasing prevalence of phishing through Microsoft Teams and similar communication tools. Distinguishing between successful and failed phishing attempts using M365 audit logs, alongside correlation with EDR logs, can be highly significant for investigations.

The Microsoft Teams messages received by the targeted users of Org C were made possible by Microsoft Teams’ “External Access” functionality, which allows One-on-One communication with any external organization by default.

Step 2

The attacker successfully lured the victim of Org C to execute Microsoft's Quick Assist tool and provided them with the access code via Microsoft Teams. This led to the threat actor's interactive access to the victim’s computer.

Step 3

The threat actor then shared a download link to the SharePoint of a separate organization (the victim belonged to a different tenant than the one used for phishing through Microsoft Teams chat, which we'll refer to as 'Org B'). This link contained a password-protected .zip file named Client_v8.16L.zip, which included various files, among them an additional RMM tool.

The file was downloaded, likely through interactive means, by the attacker—already equipped with remote access—operating under the context of explorer.exe, enabling them to click the link and download tools as needed.

It’s worth mentioning that during the investigation, we correlated M365 audit logs, which provided precise information about the incoming URLs in Microsoft Teams messages, with the EDR telemetry of the victim’s host to fully understand the attacker's TTPs.

Figure 3: Microsoft 365 audit logs from Org C showing a 'MessageSent' entry with a malicious URL sent by the attacker via an Org C user account. The URL directs to Org B's SharePoint, where malware files were hosted for download.

Step 4

Multiple attempts were made to carry out manual malicious operations via remote access. These activities primarily involved persistence efforts, such as creating scheduled tasks to repeatedly execute one of the attacker-downloaded files—an RMM tool called LiteManager ("ROMServer.exe").

schtasks /Create /TN "Perfomance monitoring" /SC MINUTE /TR C:\ProgramData\500000003\ROMServer.exe

Step 5

Following the activities above, the actor manually downloads another .zip file named Cliento.zip.

As before, the link was shared in the chat between the victim user and the threat actor. This .zip file included the main .JAR malware as well as the entire Java Development Kit to execute the .JAR malware.

Step 6

The threat actor executed the .JAR malware using the following: C:\\ProgramData\\Cliento\\jdk-22_windows-x64_bin\\jdk-22.0.2\\bin\\javaw.exe -jar C:\\ProgramData\\Cliento\\Cliento.jar

Step 7

Multiple network activities and command executions were identified under the context of the malicious .JAR file, including:

• Several outgoing DNS Request/Network Activity to → safeshift390-my.sharepoint.com
• Several outgoing DNS Request/Network Activity to → graph.microsoft.com
• Several outgoing DNS Request/Network Activity to → login.microsoftonline.com
• Execution of local enumeration commands:
  • Get system specs - Systeminfo
  • Get machine time information - net time
  • Get the UUID of the machine (remember this one; we’ll discuss it later) - Get-WmiObject -Class Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID
  • Enumeration of USB devices - {$_.interfacetype -eq \"USB\"}"
    

The following screenshot shows the main parts of the process tree related to malicious activities:

Figure 4: Summarized process tree from Hunters' Next-Gen SIEM

Step 8

The attacker also added a malicious JAR binary as a runkey in the registry for persistent execution of the Java malware.

Command line:

Set-ItemProperty -Path \"HKCU:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\" -Name \"current\" -Value \"C:\\ProgramData\\Cliento\\jdk-22_windows-x64_bin\\jdk-22.0.2\\bin\\javaw.exe -jar C:\\ProgramData\\Cliento\\Cliento.jar\" -ErrorAction Stop"

The containment and eradication of this incident was very rapid and effective, and according to the forensics evidence we had, there was no indication that the attacker managed to cause any significant damage to the victim host and organization.

One key insight from the attack flow detailed above is that the attacker used different well-known and commonly used Microsoft services as part of his attack, both for hiding in plain sight and potentially also for their convenience.

Let’s quickly summarize the Microsoft services used by the threat actor by now using the following table:

“ODC2” Java Malware - OneDrive as Command & Control

We used a Java Decompiler named “JDGUI” to decompile the Client.jar malware (we named “ODC2”).

Just from the initial high-level look at the malware, we could immediately correlate it with the PowerShell execution we saw in the incident investigation. This is due to the inclusion of the “jPowerShell” Java package - a PowerShell wrapper for Java.

In addition, we could see additional packages like “commands,” “connection,” “launcher,” “or connect,” etc. This provided us with a high-level understanding of the malware structure.

Figure 5: Screenshot of Java Decompiler showing the contents of Cliento.jar file

1. We started with the Main.class under the “launcher“ package and found a set of hard-coded credentials used by the malware. This was a bit surprising for us, but very interesting.

Figure 6: Screenshot of Java Decompiler showing the contents of the Cliente.jar file with a focus on the 'Main.class' file

By further analyzing the malware (as described in the detailed analysis below), we found that the malware used these credentials to conduct “on-behalf” authentication to Entra ID. To conduct this authentication, the hard-coded refresh token was used with the client ID and client Secret to request an access token.

The authentication allowed the malware to access the OneDrive of specific Entra ID users, in tenants supposedly owned by the actor, abusing this access for C2 purposes.

2. In the main function of Main.class we can see the entry point itself, which includes multiple threads. It includes the execution of functions “odThread1” and “mainThread1“.

Figure 7: Java code snippet showing the main method in a decompiled Java class, with multiple threads (odThread1, odThread2, mainThread1, mainThread2) initializing Controller objects

“odThread1” includes the execution of the Controller “odRun” function that gets the first set of hardcoded credentials (Refresh Token, etc.) for authentication.

• It uses the “40.90.196.221“ IP address for “odRun” connection setup
• The “40.90.196.228” IP address for “Run” initializes the HTTPS socket to the attacker’s C2. This IP is Azure’s IP as well, and it is very likely to be a virtual machine. This C2 channel, as detailed below, is more “classic” and leads to the execution of PowerShell commands
• To obtain more information about these IP addresses, we checked known resources like ipinfo.io and the Service Tags of Azure IP addresses published by Microsoft, as shown in the screenshot below

Figure 8: The IP lookup on the right provides details for IP '40.90.196.228', associated with 'microsoft.com' under 'hosting' type, with no VPN, proxy, tor, or relay flags enabled

• It is also worth mentioning that the additional hard-coded IP address found in this malware (38.180.136.85) seems to be owned by another service provider and is associated with hosting services. Based on our insights, this IP address was not actively used by the malware. We assume it was there for legacy reasons (previous C2 infrastructure).
  
  

HTTPS Socket C2

3. By digging a bit deeper into the “mainThread1()“  which executes the “ctrl.run()” function, we can see that the run() function tries to create a connection and routinely checks if the connection is alive. It then tries to “parseCommand,” trimming irrelevant parts out of it.

Figure 9: Java code snippet from the Controller class in a decompiled Java program

4. This “run” function uses “connect()” to setup/reset a connection. It creates a socket to the remote IP address we saw above - 40.90.196.228.

5. This “run” function uses “CommandManager,” which includes different handlings for the different types of commands/capabilities this malware provides, including file transfer from client to server and from server to client, file compression, screenshots, closing network connections, and, of course, command execution.

It checks if the command received is empty or if an actual command was received from the C2 server.

Figure 10: Java code snippet from the CommandManager class in a decompiled Java program

6. If a command is found, it parses it and executes it. The execution is basically under the context of PowerShell.

The execution of the incoming command as a PowerShell command is being conducted using the jPowerShell wrapper we mentioned earlier.

Figure 11: Java code snippet from the CommandManager class in a decompiled Java program

OneDrive Command & Control

Before delving into the core of the OneDrive C2 functionality, it's important to note that critical parts of the malware's code rely heavily on three specific 'types' of OneDrive files: UUID, cf_UUID, and rf_UUID. As observed in our investigation, the command Get-WmiObject -Class Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID was executed, revealing the UUID of the device hardware. This unique identifier serves to distinguish each victim in the VEILDrive campaign.

Each file type plays a distinct role in the malware’s operations. The following screenshot provides examples of these files and their primary roles in malware execution.

Figure 12: Screenshot showing three files in a directory, each with a unique UUID

Let’s dive into the flow of the OneDrive C2 functionality and how those UUID files are being used in practice:

7. In addition to the classic Remote Execution capabilities over PowerShell, the “odRun” function is responsible for another thread based on “OneDrive” as a communication channel. This is the unique part of this malware.

The “odRun” as we see it, is probably named after “OneDrive” (OneDriveRun), and includes the creation of a OneDrive connection using the “Odconnect” function as a first step:

Figure 13: Java code snippet showing the odRun method, which takes parameters including tenantId, clientId, clientSecret, grantType, accessToken, and refreshToken

8. As you can see, first the “machineUUID” string is set as an empty string. Followed by the execution of the “getMachineUUID()” function, which is, as its name suggests, gets the Machine UUID of the victim device:

Figure 14: Java code snippet showing the getMachineUUID method, which retrieves the machine's UUID. 

9. We can then see that the OneDrive connection is being conducted using the “OdConnect” function—the connection is being made to “login[.]microsoftonline[.]com“ for the creation/update of a set of new access tokens and refresh tokens.

Figure 15: Java code snippet showing the updateTokens method in the Odconnect class

10. The “WriteFileToOneDrive” function is the next one that is being called, as long as there is no file named as the current victim machine UUID in the target computer, based on a check conducted by the “checkFile“ function.

• ”checkFile”: This function checks if there is a file named == machineUUID in the home folder of the current user OneDrive

Figure 16: Java code snippet showing the checkFile method in the Odconnect class. This method checks for the existence of a file in OneDrive by using Microsoft Graph API to list files in the root directory

11. If there is no such file, the “writeFileToOneDrive()” gets into the game, and creates a file named as the current victim Computer UUID without any prefix.

Figure 17: Java code snippet showing the writeFileToOneDrive method in the Odconnect class. This method uploads a file to OneDrive by sending a PUT request to the Microsoft Graph API

12. The next part of “odRun” is the “getFiles()” function that gets the content of the UUID

OneDrive file that’s named by the machineUUID of the device (without prefixes).

• If the content of the file is not empty it checks if it starts with the word “send”
  
  • If so, it conducts some normalization of the content, preparing it for the next checks - by removing the string “send “ and replacing “\”“ with “” (nothing) saving it in a variable named “filenameForDownload“
  • filenameForDownload is being passed to getFileDownloadUrl function. This gets the file of the attacker’s choice. The attacker would specify the file name after the word “send” in the UUID file and save it to the specified destination path on the victim machine which is “user.home“\downloads (the downloads folder).
  • Following that, the “downloadFile” function is being called, downloading the remote file to the local victim device, based on the getFileDownloadUrl function output.
  • The attacker gets an indication about the execution of the file using “writeFileToOneDrive“ which is executed right after as part of “odRun” to write the following “rf_“ + “send file” + filenameForDownload + “done” → to let the attacker know that the execution was conducted.
    Following that, there is another execution of “writeFileToOneDrive“, in which another file, named “cf_” + machineUUID is being written to OneDrive, without any content in it.
• If the content of the file is not empty but doesn’t start with “send”:
  • The content of the cf_MachineUUID file will be executed.
  • Followed again by writing a file to OneDrive, using “writeFileToOneDrive“, first “rf_“ + machineUUID, with the content of the response of execution.
  • And another usage of “writeFileToOneDrive“, to write and empty “cf_” file, basically preventing another execution of the same command (since the malware runs in a loop).

To shortly summarize, this malware seems to have two different C2 channels it can work with:

• HTTPS Socket C2: a more classic approach, receiving commands from a remote Azure VM and executing them under the context of PowerShell.
• OneDrive-based C2: this is more unique, and the way it works is a bit more complex and creative. It includes three different files, all of which include the UUID of the victim device, some with prefixes (rf_ and cf_). To make it easy for the threat actor to send commands and receive them using Microsoft Graph.
  
  Note: It’s important to mention that this malware has additional capabilities besides the standard command execution, including file transfer. However, the detailed information above focuses on the command execution aspect only.
  
  

Microsoft Services/Apps as Attacker's Infrastructure

At this point, it’s clear that this attack skillfully combined simple techniques with sophisticated, unique tactics. One standout feature from our initial investigation was the extensive use of Microsoft infrastructure and services integrated throughout the campaign.

After analyzing the malware and correlating the new information with our investigation insights, we gained a clearer understanding of the attacker’s use of various services and their purposes. We discovered that the utilization of Microsoft services and infrastructure was even more extensive than initially realized.

See the table below for a short summary:

Indicators of Compromise  (IOCS) 

• Known Entra ID tenants owned by the attacker:
  • C5f077f6-5f7e-41a3-8354-8e31d50ee4d
  • 893e5862-3e08-434b-9067-3289bec85f7d
• Known applications’ registered by the attacker client IDs:
  • B686e964-b479-4ff5-bef6-e360321a9b65
  • 2c73cab1-a8ee-4073-96fd-38245d976882
• Entra ID tenants used by the attacker (Look for outgoing DNS request toward those domains):
  • SafeShift390[.]onmicrosoft[.]com
  • GreenGuard036[.]onmicrosoft[.]com
• File IOCs (SHA256) found as part of the investigation:
  • ROMServer.exe
    a515634efa79685970e0930332233aee74ec95aed94271e674445712549dd254
  • HookDrv.dll 1040aede16d944be8831518c68edb14ccbf255feae3ea200c9401186f62d2cc4
  • ROMFUSClient.exe 7f61ff9dc6bea9dee11edfbc641550015270b2e8230b6196e3e9e354ff39da0e
  • AledensoftIpcServer.dll
    d6af24a340fe1a0c6265399bfb2823ac01782e17fc0f966554e01b6a1110473f
  • ROMwln.dll 7f33398b98e225f56cd287060beff6773abb92404afc21436b0a20124919fe05
  • IP Addresses:
    • 40.90.196[.]221
    • 40.90.196[.]228
    • 38.180.136[.]85
    • 213.87.86[.]192 
      
      

Hunting Queries

In addition to the specific IOCs mentioned above, we crafted multiple threat-hunting queries that can be used to detect attacks originated by the same actor, conducted under the same campaign, or sharing similar characteristics (TTPs). 

Note: The recommended hunting timeframe for VEILDrive is from July 2024. 

HUNTING QUERY 1: Javaw Spawning Powershell with Specific Flags - Unusual Behavior 

• Query logic: During our analysis, we identified that the attacker’s Remote Access Tool (RAT) used Powershell to fetch the machine's UUID as part of its execution process. This query detects unusual instances of Powershell being spawned by javaw.exe with the specific command line flags used by the threat actor.
• Query:

SELECT EVENT_TIME,
       AGENT_ID,
       PARENT_PROCESS_NAME,
       PARENT_PROCESS_COMMANDLINE,
       INITIATING_PROCESS_NAME,
       INITIATING_PROCESS_COMMANDLINE,
       TARGET_PROCESS_NAME,
       TARGET_PROCESS_COMMANDLINE,
       TARGET_PROCESS_OS_PID
  FROM INVESTIGATION.EDR_PROCESS_CREATION_EVENTS
 WHERE 1=1
   AND PARENT_PROCESS_NAME ILIKE '%javaw%'
   AND INITIATING_PROCESS_NAME ILIKE '%cmd%'
   AND TARGET_PROCESS_NAME ILIKE '%powershell%'
   AND TARGET_PROCESS_COMMANDLINE ILIKE 'powershell.exe  -ExecutionPolicy Bypass -NoExit -NoProfile %'
   AND EVENT_TIME > current_timestamp - interval '60d'

HUNTING QUERY 2: ROM Tool Persistence via Scheduled Tasks

• Query logic: This query detects instances of a scheduled task registering with the execution of a ROM tool used by the threat actor for persistence. 
• Query: 

SELECT EVENT_TIME                   AS EVENT_TIME,
       AID                          AS AGENT_ID,
       CID                          AS COMPUTER_ID,
       EVENT_SIMPLE_NAME            AS EVENT_NAME,
       RAW:TaskName                 AS TASK_NAME,
       RAW:TaskExecCommand          AS TASK_EXEC_COMMAND,
       RAW:TaskAuthor               AS TASK_AUTHOR,
       RAW:UserName                 AS USER_NAME
  --- Adjust according to your EDR of choice
  FROM RAW.CROWDSTRIKE_RAW_EVENTS
 WHERE EVENT_SIMPLE_NAME = 'ScheduledTaskRegistered'
  AND TASK_EXEC_COMMAND ILIKE '%romserver%'
  AND EVENT_TIME > CURRENT_TIMESTAMP - interval '60d'
    

HUNTING QUERY 3: Non-Organizational Users Sharing Links to Third-Party Sharepoint Domains via Microsoft Teams

• Query logic: This query detects cases where a SharePoint link is shared in a Teams chat, but the domain of the SharePoint link does not belong to any of the chat participants. This could indicate a potential phishing attempt or data exfiltration, where an external domain is being used to share files or information with unsuspecting users within the organization.
• Query:

SET YOUR_ORGANIZATION_NAME = 'hunters';

SELECT EVENT_TIME,
      ORGANIZATION_ID                                          AS ORG_ID,
      OPERATION                                                AS EVENT_TYPE,
      SPLIT_PART(LOWER(SPLIT_PART(USER_ID, '@', 2)), '.', 1)   AS SENDER_ORG_DOMAIN,
      RECORD_SPECIFIC_DETAILS:message_ur_ls                    AS MESSAGE_URLS,
      WORKLOAD                                                 AS WORKLOAD,
      USER_ID                                                  AS USER_ID,
      RECORD_SPECIFIC_DETAILS:chat_thread_id                   AS CHAT_THREAD_ID,
      RECORD_SPECIFIC_DETAILS:communication_type               AS COMMUNICATION_TYPE,
      RECORD_SPECIFIC_DETAILS:members[0].DisplayName           AS MEMBER_DISPLAY_NAME,
      RECORD_SPECIFIC_DETAILS:members[0].UPN                   AS MEMBER_UPN,
      RECORD_SPECIFIC_DETAILS:members[0]                       AS MEMBERS,
      RECORD_SPECIFIC_DETAILS:resource_tenant_id               AS RESOURCE_TENANT_ID,
      RECORD_SPECIFIC_DETAILS
FROM RAW.O365_AUDIT_LOGS
WHERE NOT USER_ID ILIKE '%' || $YOUR_ORGANIZATION_NAME || '%'
 AND (NOT (MESSAGE_URLS ILIKE '%' || SENDER_ORG_DOMAIN || '%') AND MESSAGE_URLS ILIKE '%sharepoint%')
 AND NOT MESSAGE_URLS ILIKE '%' || $YOUR_ORGANIZATION_NAME || '%'
 AND EVENT_TIME > CURRENT_TIMESTAMP - interval '60d'
    

HUNTING QUERY 4: Microsoft Teams - Phishing Detection - Multiple DM’s from Non-Common Domains

• Query logic: The following query detects messages sent in a one-on-one chat by external users from non-common domains. The query filters out extensively used domains based on historical activity and identifies external members added to chats who may be conducting phishing attacks.
• Query:

SET YOUR_DOMAIN_NAME = 'hunters';

--- GET EXTERNAL TEAMS AND ONEDRIVE USERS OF THE LAST 3 MONTHS - TO CLEAN EXTENSIVELY USED DOMAINS
WITH COMMONLY_USED_DOMAINS AS (
   SELECT LOWER(SPLIT_PART(USER_ID , '@', 2))                      AS DOMAIN_COMMONLY_USED,
          MIN(EVENT_TIME)                  AS MIN_EVENT_TIME,
          MAX(EVENT_TIME)                  AS MAX_EVENT_TIME,
          ARRAY_AGG(DISTINCT OPERATION)    AS OPERATIONS,
          COUNT(*)                         AS COUNTER
   FROM RAW.O365_AUDIT_LOGS
   WHERE WORKLOAD IN ('MicrosoftTeams', 'OneDrive')
     AND EVENT_TIME > CURRENT_TIMESTAMP - interval '90d'
     AND USER_ID ILIKE '%@%'
   GROUP BY DOMAIN_COMMONLY_USED
   HAVING COUNTER > 20
),
---- Get List of External Domains that recently communicated with our organization using Microsoft Teams
    LATEST_EXTERNAL_DOMAINS AS (
        SELECT USER_ID                                                              AS LATEST_EXT_USERS,
               LOWER(SPLIT_PART(USER_ID , '@', 2))                                  AS USER_DOMAIN,
               MIN(EVENT_TIME)                                                      AS MIN_EVENT_TIME,
               MAX(EVENT_TIME)                                                      AS MAX_EVENT_TIME,
               ARRAY_AGG(DISTINCT OPERATION)                                        AS OPERATIONS,
               ARRAY_AGG(DISTINCT RECORD_SPECIFIC_DETAILS:communication_type)       AS COMMUNICATION_TYPE,
               COUNT(*)                                                             AS COUNTER
        FROM RAW.O365_AUDIT_LOGS
        WHERE EVENT_TIME > CURRENT_TIMESTAMP - interval '50d'
          AND NOT USER_ID ILIKE '%' || $YOUR_DOMAIN_NAME || '%'
          AND NOT USER_ID IN ('app@sharepoint')
          AND USER_ID ILIKE '%@%'
          -- CLEAN-UP OF EXTENSIVELY USED DOMAINS
          AND USER_DOMAIN NOT IN (SELECT DISTINCT DOMAIN_COMMONLY_USED FROM COMMONLY_USED_DOMAINS)
          AND OPERATION IN ('MemberAdded', 'ChatCreated')
          AND RECORD_SPECIFIC_DETAILS:communication_type = 'OneOnOne'
        GROUP BY USER_ID
        HAVING COUNT(*) > 5
    )

SELECT EVENT_TIME,
      ORGANIZATION_ID                                          AS ORG_ID,
      WORKLOAD                                                 AS WORKLOAD,
      OPERATION                                                AS OPERATION,
      USER_ID                                                  AS USER_ID,
      LOWER(SPLIT_PART(USER_ID , '@', 2))                      AS USER_DOMAIN,
      RECORD_SPECIFIC_DETAILS:chat_thread_id                   AS CHAT_THREAD_ID,
      RECORD_SPECIFIC_DETAILS:communication_type               AS COMMUNICATION_TYPE,
      RECORD_SPECIFIC_DETAILS:members[0].DisplayName           AS MEMBER_DISPLAY_NAME_0,
      RECORD_SPECIFIC_DETAILS:members[0].UPN                   AS MEMBER_UPN_0,
      RECORD_SPECIFIC_DETAILS:members[0]                       AS MEMBERS_0,
      RECORD_SPECIFIC_DETAILS:members[1].DisplayName           AS MEMBER_DISPLAY_NAME_2,
      RECORD_SPECIFIC_DETAILS:members[1].UPN                   AS MEMBER_UPN_2,
      RECORD_SPECIFIC_DETAILS:members[1]                       AS MEMBERS_2,
      RECORD_SPECIFIC_DETAILS:resource_tenant_id               AS RESOURCE_TENANT_ID,
      RECORD_SPECIFIC_DETAILS,
      RAW:ClientIP                                             AS CLIENT_IP
FROM RAW.O365_AUDIT_LOGS
WHERE 1=1
 AND RECORD_SPECIFIC_DETAILS:communication_type = 'OneOnOne'
 AND (
   RECORD_SPECIFIC_DETAILS:members[0].UPN IN (SELECT LATEST_EXT_USERS FROM LATEST_EXTERNAL_DOMAINS)
       OR RECORD_SPECIFIC_DETAILS:members[1].UPN IN (SELECT LATEST_EXT_USERS FROM LATEST_EXTERNAL_DOMAINS)
   )
 AND USER_ID ILIKE '%' || $YOUR_DOMAIN_NAME || '%'
 AND OPERATION = 'MemberAdded'
 AND EVENT_TIME > CURRENT_TIMESTAMP - interval '50d';
    

• In-depth query logic: Since this query is a little complex, here is an explanation of the logic. First, we use the “CTE” feature of Snowflake to construct two views:
  1. COMMONLY_USED_DOMAINS:
     
     • We extract the domain names from the user ID by splitting the string after the '@'.
     • Count all events generated by each domain over the past 90 days
     • Keep domains that have more than 20 events and consider them common. You can adjust this according to your needs.
       
  2. LATEST_EXTERNAL_DOMAINS:
     
     • Filter out internal domains and commonly used domains identified in the previous view from all events in the last 50 days
     • Query all domains that have more than 5 events involving sending direct messages and member additions to Teams.
  Finally, we retrieve detailed information about the user and their associated domain by querying the filtered results from LATEST_EXTERNAL_DOMAINS.

Hygiene Nuggets

We covered hunting and investigation aspects related to multiple attack techniques used by the actor. Some of those malicious methods and techniques are also known to be used in different campaigns.

Protecting your organization from those threats can significantly reduce the risk of successful attacks targeting different parts of your organizational infrastructure.

Here are a few Hygiene Nuggets that can be used to enhance your security posture:

1. To reduce the chances of successful phishing attacks through Microsoft Teams, here are a few steps you can take:
   
   • By default, Microsoft Teams allows “External Access,” which permits one-on-one chats with outside contacts. If this isn’t essential for your organization, consider disabling this option.
   • If external communication is necessary, limit it to trusted domains only.
   • Another way to communicate with external parties in Microsoft Teams is by adding them as guests or members. We strongly recommend restricting this feature, allowing only select, high-privileged users to manage it.
2. The rise in cyber attacks using remote administration tools calls for clear distinctions between tools used legitimately and those exploited by threat actors. Here are a few recommendations:
   
   • Limit remote administration tools to specific, approved applications required for business purposes. Quick Assist is easily downloadable from the Microsoft Store; consider blocking its use if it’s not on your organization’s whitelist. You can restrict access by applying measures like AppLocker, Windows Firewall rules, or MDM management.
   • Keep track of commonly used remote management tools and monitor for any unusual or unauthorized third-party tools. For example, if Quick Assist is used and your IT team doesn’t rely on it for remote support, it should trigger an alarm.
3. Security Awareness Training—It may sound like a cliche, but human errors are consistently one of the main reasons for successful cyber attacks. Security awareness training can make a difference in this regard, protecting you from the next breach. 
   
   • We do recommend making it focused and relevant to the threats seen in the wild. For example, cases of IT impersonation via communication platforms like Microsoft Teams, Slack, or even classic phone calls are on the rise. Please make sure that your employees know how to deal with it. 
     
     

Conclusion 

• VEILDrive combines simplicity and sophistication. It was interesting to witness the use of classic C2 characteristics in parallel with C2 over OneDrive, as well as the use of classic scheduled task-based persistence combined with malware execution that a top-notch EDR does not detect. 
• The characteristics identified as part of investigation and threat research were interesting, and they allowed us to better understand how this threat actor works, which known services it is abusing, how it is abusing them, and for what purpose.
• The way OneDrive was abused for C2 communication in VEILDrive had unique characteristics. However, the general concept of OneDrive abuse for C2 purposes has been on the rise over the last months, and it is something to keep in mind.
• Initial access through spear-phishing on communication platforms like Microsoft Teams, Slack, and similar services is increasingly common.
• We forecast that it will become even more common as time goes by. Hence, hygiene and posture measures related to this aspect (as mentioned in the Hygiene Nuggets above) are crucial.
• Remote Administration tools are already very popular among threat actors. Different approaches can be taken to minimize the potential for unauthorized access using such tools. From our point of view, the recommended approach in this area is whitelisting (allowlisting) combined with robust monitoring.
• We anticipate that more campaigns of this nature will emerge, employing similar methods and characteristics. Therefore, continuous monitoring and proactive threat-hunting for this type of threat are strongly recommended.

To stay updated on threat-hunting research, activities, and queries, follow Team Axon’s X/Twitter account (@team__axon).