By Hunters Team Axon
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.
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:
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.
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:
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.
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.
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.
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.
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
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.
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
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:
Systeminfo
net time
Get-WmiObject -Class
Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID
{$_.interfacetype -eq \"USB\"}"
The following screenshot shows the main parts of the process tree related to malicious activities:
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.
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.
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.
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.
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“.
“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:
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).
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.
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.
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.
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.
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.
Let’s dive into the flow of the OneDrive C2 functionality and how those UUID files are being used in practice:
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:
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:
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.
”checkFile”: This function checks if there is a file named == machineUUID in the home folder of the current user OneDrive
OneDrive file that’s named by the machineUUID of the device (without prefixes).
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.
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 |
C5f077f6-5f7e-41a3-8354-8e31d50ee4d
893e5862-3e08-434b-9067-3289bec85f7d
B686e964-b479-4ff5-bef6-e360321a9b65
2c73cab1-a8ee-4073-96fd-38245d976882
SafeShift390[.]onmicrosoft[.]com
GreenGuard036[.]onmicrosoft[.]com
a515634efa79685970e0930332233aee74ec95aed94271e674445712549dd254
1040aede16d944be8831518c68edb14ccbf255feae3ea200c9401186f62d2cc4
7f61ff9dc6bea9dee11edfbc641550015270b2e8230b6196e3e9e354ff39da0e
d6af24a340fe1a0c6265399bfb2823ac01782e17fc0f966554e01b6a1110473f
7f33398b98e225f56cd287060beff6773abb92404afc21436b0a20124919fe05
40.90.196[.]221
40.90.196[.]228
38.180.136[.]85
213.87.86[.]192
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.
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'
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'
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'
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:
Finally, we retrieve detailed information about the user and their associated domain by querying the filtered results from LATEST_EXTERNAL_DOMAINS.
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:
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).