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.

Understanding the LastPass hack

This marks the initiation of a series exploring hacks spotlighted in CSA’s renowned paper on the Top Threats to Cloud Computing. Delving into the LastPass hack, this article aims to offer an easy-to-read, illustrated guide. Additionally, we will provide guidelines for detection.

LastPass, a Software as a Service (SaaS) provider, offers a password vault service. These services are typically used for the secure storage of secrets and are popular with security-conscious individuals, as they facilitate the secure and easy storage of complex passwords.

LastPass assures customers that they do not have knowledge of the actual secret stored in their system because of LastPass’s zero-knowledge architecture, which includes the following:

1. Data is stored encrypted in LastPass’s database.
2. The encrypted data can only be decrypted with the master password provided by the customer just-in-time.
3. The master password provided by the customer is never stored in any persistent storage in LastPass’s system.

The following diagrams help illustrate how such a password vault works.

Step 1: The customer launches the password vault software and provides the master password. The master password might be salted or hashed further to ensure secrecy in transit before it is sent to the password vault’s server for authentication. Upon successful authentication, the password vault server sends the encrypted secrets to the customer.

Step 2: The customer can now decrypt the encrypted secrets with the master password. These secrets can typically be copied into the clipboard for Just-in-time usage. In the illustration, the customer has decrypted and copied the ‘Secret A’ into the Clipboard. The customer can now login to another software or web portal which requires Secret A to access.

In the incident of LastPass hack, the customer’s encrypted password (X), as shown in the illustration, was stolen. Additionally, customer information, such as the company name and the URL where the decrypted password could be used, was also compromised.

One can imagine the impact this could have had on the industry if the attacker had been able to decrypt any password they had stolen. This would mean the attacker could access any password-protected systems easily accessible from the internet. Of course, this is only applicable if 2FA is not present in those accounts!

The LastPass hack unveiled

How possible is it to decrypt the secrets stolen from LastPass?

Since the secrets are stored encrypted, what are the possibilities that the attacker could recover the secrets? There are multiple ways these encrypted passwords can be decrypted, and we will be discussing two possible methods:

• Password guessing:

As the secrets are stored encrypted with the customer’s master password, if a weak master password has been used, the attacker can easily guess the customer’s master password to access the data and reveal all the passwords stored by the customer.

• Tampering with the backend code:

If the attacker compromises the backend server responsible for decrypting the encrypted data and plants malicious code, they could potentially log the customer’s master password and use it to decrypt the stolen data.

How the Attack Happened

In early August 2022, attackers successfully accessed LastPass’s S3 bucket in a development environment and exfiltrated source code together with technical documents (4). A developer’s valid credentials, stolen from the developer’s compromised machine (1), were used to access the S3 bucket (3). It is interesting to note that the developer does not usually access those resources on S3; however, the access given to the developer has been overly permissive. It is also noted that the attackers obfuscated their original location by accessing the cloud resource over VPN (2).

In mid-August 2022, the LastPass security team discovered the hack and decommissioned the development environment, under the assumption that the attacker’s activity had been contained.

In October 2022, a LastPass Senior DevOps engineer’s machine was compromised (5) and used to access the DevOps engineer’s LastPass corporate vault. This allowed the attacker to access the corporate vault in the S3 bucket (6), which contains backups of LastPass customer data and encrypted vault data. Fortunately, the customers’ secrets remain safe as they are encrypted in the customer’s master key due to the zero-knowledge architecture.

LastPass discovered the hacks after the attackers triggered an ‘IAM unauthorized activity’ alert generated by AWS GuardDuty, likely be caused by running reconnaissance and enumeration operations (4).

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

Detection and prevention strategies

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

In (2) and (3), when the attacker was accessing the cloud resource over VPN, we can detect such activities by:

1. Detecting logins from unusual locations or fast-flux location changes.
2. Detecting logins from VPN IP ranges.

Storage locations with sensitive data should be tagged, and accessing such data should be monitored. In (4) and (7), when the attacker was accessing sensitive data, we could trigger an alarm.

In (6), when the attacker exfiltrated a hoard of data from the S3 buckets, we can detect this by monitoring for an unusually high intensity in data access. Since the accounts do not usually access that data, this form of alerting will have very low false positives.

Finally, when the attackers are performing reconnaissance and enumeration, they tend to execute a number of privileged activities to verify the privileges of the compromised account. These can be detected by comparing the usual privileged activities the authentic account would perform with those executed by the attacker.

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.