Overview of the Threat Actor: APT29 (Midnight Blizzard)

APT29, also known as Midnight Blizzard, NOBELIUM, UNC2452, or Cozy Bear, is a highly sophisticated Russia-based threat actor attributed by the US and UK governments as the Foreign Intelligence Service of the Russian Federation (SVR). Midnight Blizzard (NOBELIUM) primarily targets governments, diplomatic entities, NGOs, and IT service providers in primarily the US and Europe. Their primary objective is to collect and exfiltrate intelligence through espionage of foreign interests and government. They utilise diverse initial access methods ranging from stolen credentials, domain takeover, phishing and exploitation of on-premises environments to laterally move to the cloud exploiting service providers’ trust chain to gain access to downstream customers.

How does APT29 use Microsoft Teams for phishing campaigns?

Step 1: Compromising and spoofing tenant domains

Midnight Blizzard begins operations by conducting password spray attacks that successfully breached an outdated, non-production test tenant account lacking multifactor authentication (MFA) or purchasing abandoned corporate domains on dark web markets. Furthermore, the threat actor increased stealth by routing their activity through a distributed residential proxy network. These tactics helped conceal their actions and allowed them to maintain the attack over time until they achieved access.

Between 2023-2025, the group systematically:

• Renamed compromised tenants to mimic trusted entities (e.g., “Contoso IT Support”)
• Created “. onmicrosoft[.]com” subdomains like “support-contoso[.]onmicrosoft.com”to bypass domain reputation checks
• Registered lookalike domains such as “microsoft-support[.]tech” with valid TLS certificates to host phishing pages

This infrastructure spoofing enabled the threat actor to send Teams messages appearing as internal notifications, with most of the targets perceiving them as legitimate due to Microsoft-branded headers.

Step 2: Social Engineering

During this step, Midnight Blizzard either has obtained valid account credentials for the users they are targeting, or they are targeting users with passwordless authentication configured on their account; both of which require the user to enter a code that is displayed during the authentication flow into the prompt on the Microsoft Authenticator app on their mobile device.

• Teams request to chat

The target receives a Microsoft Teams message request as a member of the security team or technical support team.

• Request authentication app action

Once the victim accepts the message request, the threat actor convinces the victim to input a code into their Microsoft Authenticator app.

• Successful MFA authentication

Once the user complies with the threat actor’s instructions, the threat actor gains the token to authenticate as the victim. This allows the threat actor to gain access to the victim’s M365 account. The threat actor then follows up with their post-compromise exploitation.

Step 3: Post-Compromise Exploitations

The threat actor then proceeds with post-compromise activity, which typically involves information theft from the compromised Microsoft 365 tenant.  

• Malicious use of OAuth applications

Once the threat actor gains access to the targeted tenant as the victim, they create, modify, and grant high permissions to OAuth applications that they can misuse to hide malicious activity. The misuse of OAuth also enables threat actors to maintain access to applications, even if they lose access to the initially compromised account. Midnight Blizzard leveraged their initial access to identify and compromise any legacy test OAuth application that had elevated access to the Microsoft corporate environment. The threat actor creates additional malicious OAuth applications. In certain scenarios, the threat actor used the legacy test OAuth application to grant them the Office 365 Exchange Online “full_access_as_app” role, which allows access to mailboxes to gain access to tenant users and perform exfiltration and phishing.

Moreover, Midnight Blizzard has also been known to abuse OAuth applications in past attacks against other organisations using the “EWS.AccessAsUser.All” Microsoft Graph API role or the Exchange Online “ApplicationImpersonation” role to enable access to email.

For a deeper technical breakdown of how APT29 exploits cloud-native services and OAuth abuse in Microsoft 365, see our detailed analysis: APT29 in the Cloud – A Comprehensive Analysis of Threats and Detection Strategies.

• Adding Malicious Devices to Compromised Tenant

In other instances, Midnight Blizzard attempts to register a device with the organisation’s Microsoft Entra ID (formerly Azure Active Directory) in an effort to enrol it as a managed or compliant device. This tactic is designed to bypass Conditional Access policies that restrict access to sensitive resources such as email, SharePoint, or Teams to only devices that are marked as compliant or hybrid Azure AD-joined. By registering their own infrastructure as a managed device, the actor seeks to meet these conditional access requirements without raising immediate suspicion. When abused by a threat actor, it allows malicious endpoints to masquerade as trusted devices, thereby evading key security controls designed to prevent unauthorised access.

In newer campaigns, Volexity published a blog post on Russia-linked threat actors, tracked as UTA0352 and UTA035 conducting similar phishing campaigns abusing Microsoft OAuth 2.0 to target entities with ties to Ukraine.

Compared to Midnight Blizzard campaigns, the resource requested is for the Device Registration Service. This service is used by Windows to join new devices to Entra ID. The attacker uses this access to enrol a new device to the victim’s Entra ID. Using the ROADTools project, Volexity is able to replicate these steps to create a new token with full permissions for Microsoft Graph API access. This technique leverages a flaw in the Entra ID API design to grant an access token with a greater level of access than initially granted.

In one observed interaction, UTA0355 requested that the victim approve a two-factor authentication (2FA) prompt under the guise of accessing a SharePoint site tied to a conference. This step was critical for bypassing additional security controls enforced by the victim’s organisation, ultimately enabling the attacker to gain access to the victim’s email.

• Lateral Movement via Teams Chats

Once the threat actor successfully compromises an account, they are able to impersonate the legitimate user within the organisation. Leveraging this impersonation capability, the attacker continues their intrusion by sending phishing messages via Microsoft Teams to additional users listed in the tenant’s directory. These messages often appear as legitimate communications from a trusted colleague, increasing the likelihood of the recipients engaging with malicious content, such as links to credential-harvesting sites or weaponised attachments. This lateral movement technique allows the attacker to propagate their access within the environment, compromise more accounts, and establish a wider foothold for further exploitation or data exfiltration.

 How to Detect APT29 Activity with InsiderSecurity CSX

 Organisations can detect and respond to these threats with advanced cloud-native monitoring. InsiderSecurity CSX provides robust detection use cases, including:

1. Abnormal Token tenant ID
2. Concurrent Sessions
3. MFA Request Bombing
4. Unusual App Given Access (Azure, GWS, M365)
5. Application Credentials Added
6. Third Party Cloud Application Installed
7. Email forwarding settings changed
8. User Updated Mailbox Rules
9. Email Data Theft
10. Unusual Device
11. Unusual ISP

Zero Trust Security and continuous behavioural analytics are essential in detecting modern identity-based attacks.

MITRE ATT&CK MAPPING

CONCLUSION

In conclusion, phishing campaigns via Microsoft Teams have emerged as a sophisticated and highly targeted attack vector exploited by the Russian APT group Midnight Blizzard (also known as APT29 or Cozy Bear) primarily for espionage purposes. Leveraging compromised Microsoft 365 tenants, the group crafts convincing social engineering lures that impersonate technical support to trick users into revealing credentials or approving multifactor authentication prompts, enabling persistent access to sensitive environments. To defend against such threats, organisations should enforce strict identity and access management controls, implement robust user awareness training focused on social engineering tactics, and apply continuous monitoring of authentication events and external collaboration activities to detect and mitigate unauthorised access attempts early.

Indicators of Compromise (IoCs)

Domain	Type	Description
msftprotection.onmicrosoft[.]com	Domain name	Malicious actor-controlled subdomain
mlcrosoftaccounts.onmicrosoft[.]com	Domain name	Malicious actor-controlled subdomain
msftonlineservices.onmicrosoft[.]com	Domain name	Malicious actor-controlled subdomain
msonlineteam.onmicrosoft[.]com	Domain name	Malicious actor-controlled subdomain
msftservice.onmicrosoft[.]com	Domain name	Malicious actor-controlled subdomain
noreplyteam.onmicrosoft[.]com	Domain name	Malicious actor-controlled subdomain
accounteam.onmicrosoft[.]com	Domain name	Malicious actor-controlled subdomain
teamsprotection.onmicrosoft[.]co	Domain name	Malicious actor-controlled subdomain
identityVerification.onmicrosoft[.]com	Domain name	Malicious actor-controlled subdomain
accountsVerification.onmicrosoft[.]com	Domain name	Malicious actor-controlled subdomain
azuresecuritycenter.onmicrosoft[.]com	Domain name	Malicious actor-controlled subdomain
teamsprotection.onmicrosoft[.]com	Domain name	Malicious actor-controlled subdomain

What is xp_cmdshell? 

xp_cmdshell is an extended stored procedure in Microsoft SQL Server that allows users to execute Windows shell commands from the SQL Server environment. While it is a powerful feature designed for administrative tasks, it can also be abused by attackers to gain initial access, escalate privileges, and move laterally within a network. The Windows process spawned by xp_cmdshell has the same security rights as the SQL Server service account. 

How does xp_cmdshell execute Windows commands? 

When xp_cmdshell is executed, it spawns a command shell on the Windows operating system and runs the specified command. The command is executed with the privileges of the SQL Server service account, and this determines the level of access the attacker has to the underlying system. 

Below are the service accounts that are commonly used to execute the command: 

1. SQL Server Service Account: By default, xp_cmdshell executes commands under the context of the service account running the SQL Server instance. 

1. “NT AUTHORITY\SYSTEM” (Local System) – Full administrative privileges. 

2. “NT SERVICE\MSSQLSERVER” (Default SQL Server service account) – Limited privileges. 

3. A domain service account  

2. Proxy Account (Optional): If configured, xp_cmdshell can use a lower-privileged proxy account instead of the SQL Server service account.  

If the user is not a member of the SysAdmin Role, the xp_cmdshell will execute the commands using the account name and password stored in the credential named “xp_cmdshell_proxy_account”. 

The main vulnerability is that the service account often has more privileges than the executed processes require, which means it should be enabled for some specific users only.  

Why is xp_cmdshell susceptible to attacks? 

Several factors contribute to the security risks associated with xp_cmdshell: 

1. Privilege Levels – Since xp_cmdshell executes commands with the SQL Server service account’s privileges, it can be extremely dangerous if that account has administrative rights on the system. 

2. Weak Authentication & Misconfigurations – Poorly secured SQL Servers with weak credentials or default settings make it easier for attackers to gain access and enable xp_cmdshell. 

3. SQL Injection Exploits – If an application connected to SQL Server is vulnerable to SQL injection, attackers can execute commands through xp_cmdshell without even having direct access to the database. 

4. Lack of Monitoring & Logging – Many organisations fail to properly monitor SQL Server logs, allowing attackers to enable xp_cmdshell and execute commands undetected. 

5. Lateral Movement Capabilities – Once an attacker gains control of a system via xp_cmdshell, they can use built-in Windows tools like psexec and wmic to pivot to other machines in the network. 

6. Persistence Mechanisms – Attackers can use xp_cmdshell to create scheduled tasks or modify registry entries to maintain long-term access. 

MITRE ATT&CK MAPPING

The misuse of xp_cmdshell aligns with several MITRE ATT&CK tactics and techniques below:

Real-world exploitation techniques of xp_cmdshell  

By default, xp_cmdshell is disabled in modern versions of SQL Server, but attackers often attempt to enable it during exploitation. If enabled, it provides a direct path to executing malicious commands, downloading additional payloads, and gaining full control over the compromised system. 

 Thus, attackers begin by checking if xp_cmdshell is enabled and if it isn’t, they proceed to enable it. 

If the MSSQL returns an error, then the attacker enables xp_cmdshell with the following command: 

Following the enabling of xp_cmdshell, attackers then execute a reverse shell to maintain access and conduct further exploitation. Commonly, attackers encode their reverse shell command to evade security measures.  Below is an example: 

Once the payload is executed through xp_cmdshell, a reverse shell connection is spawned and connectable by the attacker with access to a privileged service account. 

How xp_cmdshell misconfiguration enable SQL Injection to Target the OS 

In many environments, SQL Server runs with high privileges, sometimes as Local System or an administrator-level service account. This means any command executed through xp_cmdshell inherits these privileges, allowing an attacker to perform system-wide operations. If the SQL Server service account has excessive permissions, an attacker exploiting xp_cmdshell could execute an SQL Injection Leading to OS Exploitation. Below are the following examples: 

Exploiting a Vulnerable Web Application 

Consider a login form with an improperly sanitised SQL query: 

An attacker could input the following payload in the username field: 

This forces the database to execute whoami, revealing the privilege level of the SQL service account. With administrative privileges, an attacker can: 

1. Add a new administrator account 

2. Download and execute a backdoor 

Exploiting MSSQL Access via Reverse Proxy 

If an attacker has gained access to an MSSQL server through a reverse proxy (e.g., from an initial foothold), they can use xp_cmdshell to further escalate privileges: 

If the server is domain-joined, they can attempt lateral movement: 

They may also dump credentials: 

Remediation Against xp_cmdshell exploitation 

To defend against xp_cmdshell exploitation, organisations should disable it unless necessary and enforce strict authentication for database access. The SQL Server service account should have minimal privileges, preventing it from executing system-wide commands. Logging and monitoring tools should be used to detect unauthorised use of xp_cmdshell. Implementing network segmentation and restricting database access to trusted systems can limit lateral movement. Additionally, web applications should be hardened against SQL injection by using parameterised queries and Web Application Firewalls (WAFs). Regular security audits and vulnerability assessments should be conducted to identify misconfigurations and reduce exposure to attacks. 

Implementation of an automated response and alert system can be done through InsiderSecurity’s Database Activity Monitor (DAM).  

Conclusion

xp_cmdshell is a powerful yet dangerous feature in MS SQL Server. While it can facilitate administrative tasks, it is also a prime target for attackers seeking initial access and privilege escalation. Organisations must disable xp_cmdshell when not needed, enforce strict security policies, and monitor their SQL environments for potential exploitation attempts. 

By understanding the risks and attack vectors associated with xp_cmdshell, security teams can better defend against cyber threats and ensure the integrity of their SQL Server deployment. 

Staying ahead of cyber threats

Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behaviour analytics products that help your company to uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security.   

DAM is designed to detect sophisticated attacks described in this article making it an essential subscription for any organisation serious about its cybersecurity posture. Beyond detecting threats, DAM offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.  

Introduction

SecurityScorecard discovered that Microsoft 365 (M365) tenants globally are targeted with password spraying attack by a nation state threat actor. These attacks exploit non-interactive sign-ins with Basic Authentication. This enables threat actors to bypass modern login protections by evading Multi-Factor Authentication (MFA). The botnet, active since at least December 2024​​, was composed of over 130,000 devices working in the Asia/Shanghai timezone. 

Attack Overview

According to SecurityScorecard, the botnet consists of over 130,000 compromised devices controlled by six command and control (C2) hosted on servers in United States​. These botnets route their traffics through proxies hosted on China affiliated hosting servers, UCLOUD HK and CDS Global Cloud. The threat actor targets M365 accounts across multiple organizations. These attacks employ Tactics, Techniques & Procedures (TTP) such as Password spraying, non-interactive sign-ins, Basic authentication abuse, Use of stolen credentials and Proxy-based evasion. The botnet uses stolen credentials from infostealer logs to systematically attempt login to M365 accounts by using Non-Interactive sign-ins. This allows the threat actor to evade Multifactor Authentication (MFA) enforcement and bypass Conditional Access Policy (CAP)​. Due to these logins being logged as Non-Interactive Sign-In, it results in reduced security visibility. Commonly, Non-Interactive Sign-In are used for service-to-service authentication, legacy protocols (e.g., POP, IMAP, SMTP), and automated processes thus not triggering MFA in many configurations. Basic Authentication enabled in some environments, allows credentials to be transmitted in plain form, making it a prime target for threat actors.  

Mapping the attack to MITRE ATT&CK framework 

We can map the attacks to the following Tactics, Techniques, and Procedures (TTPs) in MITRE. 

Attack Analysis 

The threat actor performs password spraying through Non-Interactive Sign-In in order to gain access to M365 accounts. Events associated with spraying attacks through these botnets use “fasthttp” user agent string as detected by SpearTip Security Operations Center. Fasthttp is a high-performance HTTP server and client library for the Go programming language, designed to handle HTTP requests. All observed attempts have targeted the Azure Active Directory Graph API (Application ID: 00000002-0000-0000-c000-000000000000). Data analyzed from a large set of Microsft 365 tenants indicates that “fasthttp” was first observed as a user agent on January 6^th, 2025. Further investigation led to the discovery of six Command and Control (C2) servers with these IP addresses:  

1. 70.39.115.74  

2. 70.39.120.10  

3. 204.188.218.178 

4. 204.188.218.179 

5. 204.188.210.226 

6. 204.188.210.227  

Investigating the C2 servers reveals 10 open ports that are being used for various purposes. The list of ports used by the C2 servers are:  

Port	Service	Possible Use
1002	Unknown	Unknown
2181	Zookeeper	Kafka
3306	MySQL	Data storage or Botnet Configuration
6379	Redis	Key-value store
7779	Unknown	Unknown
8081	Jetty web service	Zookeeper query service
10050	Zabbix Agent	Potential botnet monitoring
33060	MySQL X Protocol	Likely used with MySQL service
12341		Botnet C2 channel (Client Registration)
12342		Possibly used for tasking infected hosts
12347		Possible data exfil or backup C2
12348		High probability of main C2 command execution

These servers run Apache Zookeeper, a distributed system coordination framework, suggesting the likely use of a distributed campaign infrastructure. Notably, the presence of Zookeeper—an industry-standard for distributed systems—may indicate a sophisticated threat actor with advanced software engineering expertise, considering the challenges of maintaining a Zookeeper cluster at scale. Port 8081 remains unrestricted, allowing server queries that revealed additional details including uptime information. Further analysis of the Zookeeper nodes indicates they also operate Apache Kafka. 

Remediation

For remediation, implementing a robust monitoring strategy across all M365 environments. This includes monitoring Non-interactive Sign-In access logs for the presence of unknown or suspicious user agents that may indicate malicious activity. M365 environment administrator should enforce an immediate password reset for all compromised accounts and invalidate active sessions to prevent further unauthorized access.  

In addition, the deployment of automated alerts and remediation workflows is essential for reducing response times and minimizing the overall impact of an attack. By integrating automated detection systems with remediation protocols, organizations can ensure that security teams are alerted in real time, enabling them to take swift, targeted actions. This not only improves operational efficiency but also ensures that security breaches are mitigated with minimal delay. It is imperative that these processes be continuously reviewed and updated to address evolving threat tactics and maintain a high level of protection for M365 environments. 

Implementation of an automated response and alert system can be done through InsiderSecurity’s CSX.  

CSX dashboard highlights multiple failed login attempts from different IP addresses into the same user account, helping security teams quickly identify potential brute-force or credential-stuffing attacks.

Staying ahead of cyber threats  

Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behavior analytics products that help your company to uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security.   

CSX is designed to detect sophisticated attacks described in this article making it an essential subscription for any organization serious about its cybersecurity posture. Beyond detecting threats, CSX offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.  

CSX provides an easy way to perform mitigation and remediation.

​​​ 

Introduction

Although the CapitalOne breach occurred in 2018, the methodologies and lessons learned remain highly relevant today. In 2018, CapitalOne, a US-based bank, suffered a massive data breach where over 100 million customer records stored in a private S3 bucket were compromised. The attack was executed by a former AWS employee who exploited a vulnerability in Capital One’s infrastructure, leveraging insider knowledge and expertise with AWS services.

As a result of this breach, Capital One agreed to pay $80 million to settle federal bank regulators’ claims that it lacked proper cybersecurity protocols, highlighting the severe repercussions of inadequate cloud security measures.

This article delves into the specifics of the data exposure, offering an easy-to-understand guide with illustrative details. We also provide guidelines for detection and prevention to help safeguard against similar cloud security threats.

What happened in the CapitalOne data breach?

1. Threat actor exploited a SSRF vulnerability in CapitalOne’s WAF to access the AWS metadata service
2. The Threat actor gotten credential from the metadata service
3. The threat actor mounted the S3 bucket with the stolen credentials and started accessing data stored in the S3 bucket.

The SSRF allows the threat actor to bounce their web request to any IP of the threat actor’s choosing and SSRF is a well-known vulnerability that is listed on the OWASP’s top 10 web vulnerability. There are at least 4 SSRF vulnerabilities that were patched in Azure cloud services in Jan-2023 alone and threat actor will continue to exploit this vulnerability.

Mapping the attack to MITRE ATT&CK framework

We can map the attacks to the following Tactics, Techniques, and Procedures (TTPs) in MITRE.

What is metadata service?

The AWS metadata service is an essential component for compute instances running in AWS. It provides information about the instance and its environment. This service is accessed through a special IP address (169.254.169.254) and provides various types of metadata such as:

• Instance ID
• Security group name
• Public IP of the instance

Accessing http://169.254.169.254/latest/meta-data from within a virtual machine provides this information. This also works from within a container running in Amazon Elastic Kubernetes Service (EKS).

What sensitive information can be leaked from the AWS metadata service?

If the ‘IAM’ profile is attached to the EC2 instance, accessing the URL http://169.254.169.256/latest/meta-data/iam/security-credentials/ from within the compute instance will reveal a temp access key (Security Token Service – STS). This mechanism provides the developer a way to avoid hard-coding credential into the application. The developer simply has to attach the ‘IAM’ profile to the compute instance, so that the application can request for the temp access key only when needed (Just-In-Time access).

The following is an example of access key which can be gotten from the metadata service when the ‘curl’ is launched from within a EC2 instance with an IAM profile attached.

ubuntu@ip-xxx-xx-xx-x:~$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2_ROLE_NAME

{
"Code" : "Success",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIA5A6XXXXXXXIFH5UQ",
"SecretAccessKey" : "sXXXXXXXXXXkBcJunpyR",
"Token" : "AgoXXX--SNIP--XXXs=",
"Expiration" : "2024-08-04T03:16:50Z"
}

With the access key, the threat actor could simply mount the S3 bucket with the following commands:

> set AWS_ACCESS_KEY_ID=Stolen_Access_Key > set AWS_SECRET_ACCESS_KEY=Stolen_Secret_key > set AWS_SESSION_TOKEN=Stolen_Token > aws s3 ls s3://bucket-name

How to detect?

There are multiple opportunities for detection. Let’s walk through the timeline and determine possible detection strategies. In Stage 3, when the attacker was accessing the S3 bucket, we can detect such activities by:

1. Detect for file access anomaly to S3
2. Detecting logins from unusual IP

Summary of detection strategies

Below is a summary table outlining the threats demonstrated by the threat actor on the cloud and corresponding detection strategies.

Threats	Detection strategies	Stage in illustration
Threat actor accessing the S3 bucket with the stolen API key	Detect logins from unusual locations.Detect for spike in data access in S3.	3

Staying ahead of cyber threats

In a world where cyber threats like the CapitalOne breach can compromise millions of records, staying ahead of attackers requires cutting-edge solutions. InsiderSecurity empowers businesses with advanced cybersecurity behavior analytics to safeguard both on-premise and cloud infrastructures.

Innovative solutions for cloud security

CSX is designed to detect and respond to sophisticated attacks like those seen in the CapitalOne incident. Here’s how CSX ensures robust security:

• Unusual Login Detection: CSX triggers alerts for logins from unfamiliar IP addresses

• Data Access Monitoring: By flagging unusual spikes or irregular access patterns in S3 buckets, CSX prevents unauthorized data exposure.

Actionable Recommendations

What sets InsiderSecurity apart is its ability to provide actionable recommendations immediately after detecting threats. By combining real-time detection with actionable recommendations, InsiderSecurity ensures your team can mitigate threats efficiently and effectively.

Imperva Hack: Understanding the AWS RDS Data Breach

Although the Imperva breach occurred in 2019, the methodologies and lessons learned remain highly relevant today. In Aug 2019, Imperva disclosed a security incident involving the compromise of a database containing email addresses, hashed and salted passwords, and customers’ API keys. The breaches were limited to customers of a Cloud Web Application Firewall (WAF) product.

The breach involved an AWS RDS (Amazon Relational Database Service), a managed service by AWS that makes it easier to set up, operate, and scale a relational database in the cloud.

It supports various database engines, including Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, and Microsoft SQL Server.

The hack has since become a critical learning point in cybersecurity, demonstrating how small vulnerabilities, such as a misconfigured virtual machine (VM), can lead to large-scale data breaches. This article dives deep into the details of the breach, detection strategies, and how organizations can protect themselves from similar threats.

What happened in the Imperva 2019 security breach?

The breach was discovered in August 2019, though it’s unclear how long the threat actors had access prior to this. Investigations suggested that the attack began when a threat actor found an accessible vulnerable VM.

The Attack Process

1. Threat actor compromised a VM which was accidentally left accessible by anyone on the internet
   1. No details given on how the VM was hacked, it could possibly be through a previously stolen credential, unsecure credential or through other installed vulnerable software.
2. Threat actor found API key within the configuration or environment variable within the VM
   • If AWS CLI is used within the VM, the API Key can typically be found in ~\.aws\credentials
   • API code could have been found through code files
3. Threat actor reused the API key to access the RDS
4. Threat actor accesses customer’s data in RDS

MITRE Framework: Mapping the Tactics and Techniques

We can map the attacks to the following Tactics, Techniques, and Procedures (TTPs) in MITRE.

How to detect AWS RDS breaches?

There are multiple opportunities for detection. Let’s walk through the timeline and determine possible detection strategies.

In Stage 3 of the Attack Process, we can detect the threat actor using the following metrics when the threat actor uses the stolen API key to access RDS:

1. Detect logins from unusual locations into RDS:
   Attackers often operate from geographic locations that differ from normal business activities. Unusual login origins can indicate compromised credentials being used outside of expected regions, time zones, or trusted networks.
2. Detect spike in data access in RDS:
   A sudden surge in data queries, downloads, or exports—beyond normal business use—may signal unauthorized data harvesting. Threat actors often try to exfiltrate as much sensitive data as possible once they are inside.
3. Detect API usage anomaly:
   Abnormal API calls, such as unusual frequencies of requests, calls at odd hours, or invocation of previously unused methods, can reveal the presence of an attacker abusing stolen credentials to access or manipulate cloud resources.

Summary of threats and detection measure

Below is a summary table outlining the threats demonstrated by the threat actor on the cloud and corresponding detection strategies.

Threats	Detection strategies	Stage in illustration
Threat actor accessing the RDS with the stolen API key	Detect logins from unusual locations into RDS.Detect for spike in data access in RDS.Detect API usage anomaly.	3 During unauthorized RDS access stage

Staying ahead of cyber threats with advanced security solutions

Innovative solutions by InsiderSecurity

Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behavior analytics products that help your company to uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA, and Database Activity Monitor for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security.

Database Security Monitor simplifies database monitoring with its AI-powered solution. It identifies suspicious data activity without manual rule-writing, providing early warnings for threats across on-premises and cloud databases. This continuous monitoring detects unusual behavior and potential threats before they escalate. For example, in scenarios similar to the Imperva breach, it would identify sudden spikes in data access in Amazon RDS.

Captions: Database Security Monitor tracks normal activity patterns and flags deviations, helping security teams identify threats early

CSX is designed to detect sophisticated attacks described in this article making it an essential subscription for any organization serious about its cybersecurity posture. For example, in scenarios similar to the Imperva breach, it would detect API usage anomaly.

Beyond detecting threats, CSX offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.

CSX provides an easy way to perform mitigation and remediation.

The 2018 Cisco WebEx hack serves as a stark reminder of the risks posed by insider threats in today’s digital landscape. With over 39 million users relying on WebEx for virtual conferencing, the sabotage carried out by a disgruntled ex-employee had far-reaching consequences, both financially and operationally.  In 2018, 456 virtual machines hosting WebEx services were deleted, resulting in $2.4 million in damages for Cisco.

A similar event in Singapore has highlighted the vulnerabilities in IT systems. An employee who was fired hacked into the computer system of NCS and deleted 180 virtual servers, causing the company to lose S$918,000.

Delving into the Cisco WebEx service hack, this article aims to offer an easy-to-read guide accompanied by illustrative details. Additionally, we will provide guidelines for detection.

What happened in the Cisco WebEx hack?

In April 2018, Ramesh, an engineer, resigned from Cisco. During Ramesh’s tenure at Cisco, he was given access to Cisco’s AWS account to maintain the virtual machines responsible for the WebEx services.

In September 2018, Ramesh discovered that even after he had left the company, he could still access Cisco’s AWS account with the AWS key that had been provided to him during his employment. Using this key, Ramesh logged into Cisco’s AWS tenant (2). Notably, Ramesh performed the login from his new workplace without any attempt to mask his company’s internet address.

Ramesh, still having high privileges to manage the virtual machines, deleted at least 456 virtual machines from Cisco’s AWS tenant (3).

Mapping the Attack: Tactics, Techniques, and Procedures (TTPs)

The sabotage executed by Ramesh can be mapped to specific Tactics, Techniques, and Procedures (TTPs) in the MITRE ATT&CK framework. Understanding these TTPs is crucial for preventing similar attacks in the future. We will subsequently refer to Ramesh as the “threat actor”.

How to detect and prevent similar insider threats

Effective detection and prevention of insider threats requires a proactive approach. Let’s break down the timeline and explore possible detection strategies.

Stage 1: Detecting Unauthorized Access

When the threat actor accessed Cisco’s cloud resources from his new company’s location, several red flags could have been detected:

1. Detecting logins from unusual IP
2. Detecting logins from an unusual software agent
3. Dormant account detection (Account inactive for over extended period)

The screenshot below is CSX detecting unusual IP and user agents.

Stage 2: Detecting Malicious Activities

When the threat actor deleted a large number of virtual machines, this activity could have been detected by:

1. An unusually high number of virtual machines deleted.
   Since the accounts do not usually delete this much virtual machines, this form of alerting will have very low false positives.

The screenshot below is CSX detecting multiple VM instances being terminated.

There may have been more actions carried out by the threat actor that were not reported. It is typical for the threat actor to perform reconnaissance and enumeration before carrying out the main part of the attack. Some examples include executing a number of privileged activities to verify the privileges of the compromised account. These can be detected by comparing the usual privileged activities an authentic account would perform with those executed by the threat actor.

The following table summarizes the threats demonstrated by the threat actor and the corresponding detection strategies.

Threats	Detection strategies	Stage in illustration
Threat actor login from new office location	Login from unusual IP Login with unusual client agent Suspicious login from inactive account	1
Mass removal of virtual machines	Change in VM access pattern	2

Staying ahead of cyber threats

InsiderSecurity’s advanced solutions for cyber threat detection

Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behavior analytics products that help your company to uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security.

CSX is designed to detect sophisticated attacks described in this article, making it an essential subscription for any organization serious about its cybersecurity posture. Beyond detecting threats, CSX offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.

CSX provides an easy way to perform mitigation and remediation.

Conclusion

The Cisco WebEx sabotage case underscores the critical importance of robust cybersecurity practices, particularly in managing employee access and detecting insider threats. By learning from this incident and implementing advanced detection strategies, companies can better protect their digital assets and ensure that similar attacks are thwarted before they cause significant damage.

In a stark reminder of the critical importance of cybersecurity in today’s digital age, Securitas, a multinational security services company based in Stockholm, inadvertently exposed over 3TB of sensitive data (more than 1.5 million files). This data, belonging to their airport clients in Colombia and Peru, dates back to 2018 and includes personal information about employees working at these airports.

The Breach: How Misconfigured S3 Buckets Led to Data Exposure

The breach involved an AWS S3 bucket which are a widely-used, reliable, and scalable cloud storage platform designed to store various types of files. The following illustration provides a quick glimpse of the files commonly stored in the S3 bucket.

However, in this case, a simple misconfiguration of the S3 bucket led to a massive data exposure. Delving into the data exposure, this article aims to offer an easy-to-read guide accompanied by illustrative details. Additionally, we will provide guidelines for detection.

What happened?

In 2021, Securitas inadvertently misconfigured an AWS S3 bucket containing employee information for airport workers. This likely occurred due to human error, with no indications that the misconfiguration was caused by a threat actor. SafetyDetective’s cybersecurity team discovered the exposure in October 2021, and Securitas fixed the issue in November 2021.

While there were no reports of breaches or the exposed data appearing on the dark web, the duration of the misconfiguration remains unknown. Given an extended exposure period, a malicious actor could have potentially accessed large amounts of sensitive data.

The Risks of Misconfiguration

Misconfigured cloud storage can lead to unintended data exposure, potentially giving unauthorized users access to sensitive information. In the case of Securitas, the exposed data included highly sensitive personal details of airport employees, which could have been exploited by malicious actors had they discovered the vulnerability.

Detection and Prevention: How to Safeguard Against Misconfigurations

There are opportunities for detection. When the administrator has misconfigured the S3 bucket, we can detect such activities by:

Detecting for ‘bucket allow public access’ event.

Instead of relying on good Samaritans to discover these vulnerabilities, organizations must take active steps to monitor and secure their cloud infrastructure, minimizing the risk of accidental data exposures due to human error.

Staying ahead of cyber threats

Innovative solutions by InsiderSecurity

Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behavior analytics products that help your company to uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security.

CSX is designed to detect sophisticated attacks described in this article, making it an essential subscription for any organization serious about its cybersecurity posture. Beyond detecting threats, CSX offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.

CSX provides an easy way to perform mitigation and remediation.

Conclusion

The Securitas data exposure incident serves as a sobering reminder of the potential consequences of cloud misconfigurations. As cloud storage becomes increasingly integral to business operations, ensuring the security of these systems is paramount. By implementing robust detection strategies and continuously monitoring cloud configurations, organizations can protect their digital assets and avoid the costly consequences of data breaches.

Intro

There’s been a rising threat concerning compromised SaaS identities due to phishing, even with multi-factor authentication (MFA) in place.  Has MFA proven ineffective? Not exactly, but we are witnessing a surge in a type of known attack that’s becoming more prevalent that has always been effective against MFA. The attack in question is AitM (Adversary-in-the-middle).

This blog post will explore this old but emerging threat, enabling threat actors to bypass MFA. Furthermore, we’ll offer guidelines for detection.

How are threat actors bypassing MFA?

Similar to any successful phishing attack, the threat actor initially deceives the victim into visiting a website controlled by them (1)(2). The unsuspecting victim would then unknowingly provide their credentials to the threat actor’s website through a form or a login page (3). If MFA has not been enabled for the account, the threat actor could simply reuse the credentials (4)(6) to gain access to the victim’s account.

If MFA is enabled for the account, the threat actor must ensure that the victim completes the authentication process with the correct MFA provided (6)(7). This can be achieved by ensuring that the actual server is able to authenticate the legitimacy of the MFA provided. In this scenario, the stolen credential alone will not be particularly useful for the threat actor. Instead, they will rely on the stolen OAuth2 tokens or session cookies (8) to access the actual service.

The threat actor could easily insert the stolen session cookie into their browser to access the actual web service (9).

However, session cookies have a limited usage period, and the threat actor needs to complete their intended operations with the account as quickly as possible. At this stage, the threat actor could either download all the files and emails before the session expires (11).

Alternatively, the threat actor could attempt to maintain access to the account over a longer period. This can be achieved by registering a new MFA device (10).

Mapping the MFA-bypass attacks to MITRE ATT&CK framework

We can map the attacks to the following Tactics, Techniques, and Procedures (TTPs) in MITRE.

Strategies to detect MFA-bypass attacks

There are several opportunities for detection. Let’s examine the attack sequence and outline potential detection strategies.

During Stage 9 of the attack, when the threat actor reuses the session cookie to access cloud resources, we can depend on the Azure AD log to detect the following anomalies:

1. Identifying logins from unusual locations or instances of rapid location changes.
2. Recognizing logins from VPN IP ranges.
3. Noticing changes in browser agents.
4. Attempt of user privilege escalation

Based on our testing, we have verified that we could access Microsoft 365 resources without encountering any authentication prompts by simply reusing a cookie session captured from our test environment. Additionally, we observed that a new ‘UserLoggedIn’ operation, including the threat actor’s IP address and browser agent, would be recorded in the audit trail accessible within the Audit Management Log. This ‘UserLoggedIn’ operation signifies that a new login event has taken place.

    "ActorIpAddress": "XX.XX.XX.XX",
    "ClientIP": "XX.XX.XX.XX",
    "CreationTime": "2024-04-03T03:12:48",
    "ExtendedProperties": [
      {
        "Name": "ResultStatusDetail",
        "Value": "Success"
      },
      {
        "Name": "UserAgent",
        "Value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0"
      },
      {
        "Name": "RequestType",
        "Value": "OAuth2:Authorize"
      }
    ],
    "Operation": "UserLoggedIn",
    "UserId": "test_victim@insidersecurity.co",

During Stage 11, when the threat actor accesses an unusually high number of files, we can depend on the Audit Management Log to detect the following anomalies:

• Detection of a spike in file or email access.

Finally, if the threat actor establishes a new MFA device, we can rely on the Audit Management Log to identify the following anomaly:

• Addition of a new MFA device.

Summary of detection strategies

Below is a summary table outlining the threats demonstrated by the threat actor on the cloud and corresponding detection strategies.

Threats	Detection strategies	Stage in illustration
Threat actor logins with stolen account	Login with an unusual browser agentLogin from one country to another within a short span of timeLogin from an unusual country	9
Addition of new MFA device	Suspicious MFA device creation	10
High amount of data downloaded	Suspicious amount of file downloaded	11

Staying ahead of cyber threats

Innovative solutions by InsiderSecurity

Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behavior analytics products that help your company to uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security.

CSX is designed to detect sophisticated attacks described in this article making it an essential subscription for any organization serious about its cybersecurity posture. Beyond detecting threats, CSX offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.

Intro

This is the third installment in a series that delves into hacks spotlighted in CSA’s renowned paper on the Top Threats to Cloud Computing. Focusing on the threat actors behind the UBER hack, this article aims to provide a user-friendly guide complemented by illustrative details. Furthermore, we will provide detection guidelines.

What happened?

LAPSUS$, alternatively recognized as DEV-0537, represents a threat actor group that has remained active over recent years. They have directed their efforts towards big technology companies including Microsoft, Uber, Nvidia, and Samsung.

Within this article, we will delve into the documented hacks orchestrated by LAPSUS$ targeting Microsoft 365 and Microsoft Azure cloud platforms. Furthermore, we will examine the detection strategies derived from these incidents.

Understanding the Uber hack

The threat actor is notorious for purchasing credentials from disgruntled insiders (1). These credentials are then utilized by the threat actor to infiltrate the corporate network (2), moving laterally internally within the corporate network, and ultimately identify the global administrator account (3) necessary for complete access to the corporation’s cloud resources.

The accompanying screenshot depicts a text found in a Telegram channel where the threat actor actively solicits credentials from potential insiders.

In the past, attackers were known to move laterally from one machine to another within the on-premise network. However, it has become increasingly common for attackers to pivot laterally from the on-premise environment to the organization’s cloud.

These attackers were observed using NordVPN (4) to obfuscate their originating IP addresses.

Once inside the Azure portal, the attackers were observed creating a new global administrator account (5) —a super administrator equivalent in Azure—as a backup, along with a virtual machine (6) to serve as a tooling server to advance their attack.

To hinder the organization’s recovery efforts, the attackers established an organization-wide email transport rule to redirect (7) all emails to another email account under the attackers’ control. They also removed all other global administrator accounts (8) to impede the organization’s recovery from the attack.

Mapping Uber hack techniques: A focus on MITRE’s TTPs

We can map the cloud-related attacks to the following Tactics, Techniques, and Procedures (TTPs) in MITRE.

Detection strategies: Identifying and mitigating threats

There are multiple opportunities to notice if something is wrong. Let’s go through the steps in the timeline and find out how we can catch these problems.

In the fourth stage of the attack, we can find signs of suspicious logins into Azure AD by checking the Azure AD or Audit management log for logins coming from:

• Unusual country, when the user logs in from a country unusual for the account.
• Impossible travel, when the user hops from one country to another within an impossible period.
• Login from a known VPN (i.e. – NordVPN) 

In the next stage of the attack, the attacker created a new global administrator account (5) and VM (6). We can detect these actions by monitoring the Audit Log or User Activity Log for such privileged activities.

In the final phase of the attack, the attacker created an organization-wide email transport rule (7) and removed the global administrator accounts (8). We can also detect these actions by monitoring the Audit Management Log for such privileged activities.

Below is a summary table outlining the threats demonstrated by the threat actor on the cloud and corresponding detection strategies:

Threats	Detection strategies	Stage in illustration
Threat actor logins with stolen account	Login from known VPNLogin from one country to another within short span of timeLogin from an unusual country	4
Creation for VM	VM creation from an unusual accountVM creation in an uncommon zone	5
Creation of a global administrator account	Suspicious account creationAssignation of privileged role	6
Forwarding all emails to an external email address	Suspicious creation of email transport rule	7
Removal of administrator accounts	Suspicious account removal	8

Staying ahead of cyber threats

Innovative solutions by InsiderSecurity

Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behavior analytics products that help your company uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security.

CSX is designed to detect sophisticated attacks described in this article, making it an essential subscription for any organization serious about its cybersecurity posture. Beyond detecting threats, CSX offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.

Welcome to the second installment of our series, in which we highlight notable cyber attacks featured in the CSA’s report, “Top Threats to Cloud Computing.”

In this article, we turn our focus to APT29—a sophisticated threat actor behind the breaches at the Portuguese and Brazilian Embassies. Our goal is to present this information in a clear, reader-friendly format, enriched with detailed examples. We also aim to provide actionable detection strategies for these kinds of cyber threats.

Understanding APT29: A new era of cyber espionage

APT29, also known as Nobelium or Midnight Blizzard, is a prominent cyber espionage group that has made multiple headlines over the past several years. This group has executed sophisticated cyber attacks targeting an array of entities — from governmental bodies such as the Portuguese and Brazilian Embassies, to corporate giants like Microsoft.

In a joint advisory, the Five Eyes agencies cautioned that APT29 is adapting to modern IT environments, particularly the widespread adoption of cloud-based infrastructure. Shifting from traditional exploitation of on-premises network vulnerabilities, APT29 now specifically targets cloud services. Notably, the group has been actively targeting Azure and Microsoft 365 environments.

In the following analysis, we will thoroughly examine the documented attacks by APT29 on Microsoft’s cloud infrastructure and discuss the strategies for detection that can be developed based on these incidents. This exploration aims to provide insights into the operational methods of APT29 and offer guidance on enhancing cybersecurity preparedness against such sophisticated threats.

APT29’s methodology in cloud-based attacks

The attacker executed a password guessing attack (1) against Microsoft’s own internal cloud tenant, which hosts the Microsoft 365 services. These attackers were observed using residential proxies (2) to conceal their origin IP addresses.

By sheer luck, the attacker successfully discovered a test account (3) that was not protected with MFA.

After successfully logging in, the attacker found a legacy OAuth Application (4) accessible by the breached account, which held a high level of privileges. This OAuth Application is also known as an ‘Enterprise App’ in Azure AD. It was likely discovered through the enumeration of all Azure Applications to identify accessible services and resources with the breached account.

The attacker proceeded to create a new Azure AD account (5) and a new malicious OAuth Application (6) through the legacy OAuth Application with high privileges (4).

Subsequently, the attacker disabled auditing for ‘Purview’ (7) and used the new malicious OAuth Application to read the emails of all users in that tenant. Due toPurview being disabled, there was no audit trail of the OAuth Application reading the email.

Mapping APT29’s Techniques: A Focus on MITRE’s TTPs

By aligning APT29’s actions with the MITRE ATT&CK framework, we can categorize and understand their tactics, techniques, and procedures (TTPs) more effectively. This alignment helps in developing targeted defenses against their known strategies.

Detection strategies: Identifying and mitigating threats

There are multiple opportunities to notice if something is amiss. Let’s go through the steps in the timeline and find out how we can detect these problems.

In the first part of the attack, we can find signs of a password guessing attack by checking the Azure AD or Audit management log. We can look for successful logins that come after failed ones (A). 

In the same login actitivties, we can also find suspicious logins from places that aren’t normal for the organization or account, such as logins from a VPN IP range (B) that the attacker used in the second part of the attack.

In the fifth part of the attack, the attacker created a new account in Azure AD. We can detect this by keeping an eye on the Audit management log for such privileged action (C).

In the sixth part of the attack, the attacker made a new privileged application in Azure AD. Similarly, we can detect this by looking through the Audit management log for such privileged actions (D).

In the last stage of the attack, the attacker disabled the Purview auditing.

The following table outlines the threats demonstrated by the threat actor and the corresponding detection strategies.

Threats	Detection strategies	Stage in illustration
Password guessing attack	Successful login with multiple failed attempts	A
Suspicious login from residential proxy	Login from one country to another within short span of timeLogin from unusual country	B
Creation of global administrator account	Suspicious account creationPrivileged role(s) assigned	C
Creation of malicious enterprise application	Suspicious enterprise applications created	D
Disabling of Purview audit logs	Audit logging disabled	E

Staying ahead of cyber threats

Innovative solutions by InsiderSecurity

Looking for ways to stay ahead of any cyber threats? InsiderSecurity provides advanced cybersecurity behavior analytics products that help your company to uncover cyber threats before there is any serious data loss. We offer a range of solutions, including Automated UEBA for securing on-premise and cloud IT infrastructure, as well as the CSX for ensuring cloud data security.

CSX is designed to detect sophisticated attacks described in this article making it an essential subscription for any organization serious about its cybersecurity posture. Beyond detecting threats, CSX offers recommendations and a user-friendly avenue for executing remedial actions and implementing mitigation strategies.