www.hunters.security Open in urlscan Pro
199.60.103.227  Public Scan

Form analysis
0 forms found in the DOM

Text Content

 * Product
   * SOC Platform
   * Product Tour
   * Integrations
   * Why Hunters
   * FAQs
 * Solutions
   * SIEM Replacement
   * MSSPs
   * Hunters for Snowflake
   * Hunters for Databricks
   * Hunters for AWS
 * Services
   * Team Axon
 * Customers
 * Resources
   * Blog
   * Events
 * Company
   * About us
   * Careers
   * Partners
   * Newsroom
 * Get a Demo



Team Axon


UNMASKING VEILDRIVE: THREAT ACTORS EXPLOIT MICROSOFT SERVICES FOR C2

 * * 
     
   * 
   * 

 * Nov 4, 2024
 * By Team Axon
 * 35 minutes to read


 * Table of Contents
     
   * TL;DR
   * Executive Summary
   * Background
   * The VEILDrive Attack Path
   * Microsoft Services/Apps as Attacker's Infrastructure
   * Indicators of Compromise  (IOCS)
   * Hunting Queries
   * Hygiene Nuggets
   * Conclusion
   


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 below 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:

Service Tenant Purpose Microsoft Teams From Org A to Org C Spear Phishing
Messages to lure the victim to download and execute the remote management tool 
Quick Assist Org C The threat actor sends a Quick Assist code using a Microsoft
Teams message to gain the initial remote control SharePoint From Org B to Org C
Malicious files are “hosted” in Org B's SharePoint tenant. Download links are
shared with Org C via SharePoint messages and opened by the attacker using Quick
Assist Graph API From Org C to N/A We had indications of malicious access to
Microsoft Graph (graph[.]microsoft[.]com) initiated by the malicious
cliento.jar.

At this stage, we had identified the four Microsoft services/apps mentioned
above. While we understood the purpose of the first three, the activity directed
toward the Graph API remained unclear. We had several assumptions about its
potential purpose, but in incident response, assumptions alone are not
sufficient, are they?

To gather more information and better understand the .JAR malware 'Cliento.jar'
in OneDrive/SharePoint - both to assess potential actions taken by the attacker
and to gain insight into their intentions - we proceeded with a detailed
analysis of the malware.




“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:

Service Tenant Purpose Microsoft Teams From Org A to Org C

Spear Phishing Messages to lure the victim to download and execute a remote
management tool  Quick Assist Org C The threat actor sends a Quick Assist code
using a Microsoft Teams message to gain the initial remote control SharePoint
From Org B to Org C Malicious files are “hosted” in the SharePoint tenant of Org
B. Download links are shared with Org C via SharePoint messages and opened by
the attacker using Quick Assist Azure VM Attacker’s infrastructure

The malware communicated with an Azure Virtual Machine owned by the threat actor
for HTTPS Socket C2 purposes OneDrive (Graph API) Between Attacker's OneDrive &
Org C host(s) The threat actor used OneDrive as an additional C2 channel, to get
capabilities like remote execution of commands, taking screenshots,
downloading/upload files, etc. targeting Org C host(s) Azure AD App Registration
Between Attacker's OneDrive & Org C host(s The application was used for
authentication on behalf of an Azure AD user account owned by the actor, and
access it’s OneDrive home folder


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'

SQL
Copy


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'
    

SQL
Copy

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'
    

SQL
Copy

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';
    

SQL
Copy
 * 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). 




RELEVANT POSTS


Team Axon

INVESTIGATING UNC5537: SNOWFLAKE DATABASE THREAT CAMPAIGN

Team Axon Sep 11, 2024

Research, Team Axon

PROTECTING POSTGRES: KEY SECURITY TAKEAWAYS FROM A POSTGRES HONEYPOT

Team Axon Apr 10, 2024

Research, Team Axon

HUNTING RANSOMWARE IN ONEDRIVE: STRAIGHTFORWARD TIPS FOR UNPREDICTABLE THREATS

Team Axon Feb 19, 2024

Research, Team Axon

DELEFRIEND: SEVERE DESIGN FLAW IN DOMAIN WIDE DELEGATION COULD LEAVE GOOGLE
WORKSPACE VULNERABLE FOR TAKEOVER

Team Axon Nov 28, 2023

Research, Team Axon

THE HUMAN-FRIENDLY GUIDE: INCIDENT RESPONSE & THREAT HUNTING IN MICROSOFT AZURE,
PART 1

Team Axon Oct 23, 2023


PRODUCT

 * SOC Platform
 * Product Tour
 * Integrations
 * Why Hunters
 * FAQs

SOLUTIONS

 * SIEM Replacement
 * Hunters for Snowflake
 * Hunters For Databricks
 * Hunters for AWS

SERVICES

 * Team Axon

 * CUSTOMERS

 * MSSPs

 * BLOG

COMPANY

 * About Us
 * Careers
 * Partners
 * Newsroom
 * Events
 * Privacy & Security

 * 
 * 
 * 
 * 

HUNTERS © 2024 All rights reserved

Terms and ConditionsPrivacy Policy