Cloud adoption in Asia-Pacific (APAC) is no longer up for debate. The question isn’t if organisations are moving to the cloud, but how fast. Hybrid cloud is already the dominant model (73%), and SaaS platforms like Microsoft 365 (68%), Google Workspace (47%), and Salesforce (33%) are firmly embedded in daily operations.

As cloud adoption accelerates, so do the risks. The Security Challenges for Cloud Adoption in APAC 2025 report reveals that 35% of organisations suffered a data breach in just the last six months, while 72% admit their security tools still have blind spots. Only a third of security professionals (34%) feel “very confident” about their organisation’s cloud security posture.

Cloud is inevitable — but cloud resilience is the missing link. The challenge for many APAC organisations is shifting from fragmented defences and hidden risks to a state of robust, proactive cloud resilience. This post explores how to close the gaps, adopt best practices, and transform blind spots into breakthroughs.

The Gaps Holding Organisations Back

The survey highlights three key obstacles undermining cloud security across APAC:

• Blind spots in visibility (72%): Despite heavy investments, most organisations still can’t see everything happening in their cloud environments. This creates dangerous gaps where threats can hide.
• Compliance challenges (80%): Meeting regulatory requirements remains the top concern. With data dispersed across multiple clouds and SaaS platforms, aligning with data privacy laws and industry standards is complex and costly.
• Skills shortage (58%): More than half of organisations lack trained staff to manage cloud security effectively. This gap contributes to shadow IT usage (62%) and accidental data exposure (60%) by employees.

Together, these challenges create an environment where both technical vulnerabilities and human error amplify the risk of breaches.

A Phased, Risk-Based Security Strategy

One of the strongest recommendations from the report is to avoid trying to “secure everything at once.” Cloud environments span SaaS, IaaS, and PaaS — tackling all of them simultaneously overwhelms security teams and leads to missteps.

Instead, organisations should adopt a phased, risk-based approach:

1. Start with the highest-risk platforms. Begin with widely used SaaS applications like Microsoft 365, which are both heavily targeted and business-critical.
2. Roll out in stages. Focus on one platform, achieve measurable improvements, and then expand coverage to other services.
3. Align security with operational maturity. Early stages should deliver quick wins — such as detecting hijacked accounts or preventing data leakage — before scaling to more advanced workloads.

This staged approach helps organisations strengthen resilience step by step while ensuring each investment delivers tangible value.

SaaS Security: The New Frontline

The report shows clearly that SaaS is the frontline of cloud security in APAC. With Microsoft 365 and Google Workspace at the heart of most businesses, they have become the most common entry points for attackers.

Top SaaS concerns identified include:

• Hijacked accounts (72%): Credential theft and phishing continue to plague organisations, enabling attackers to impersonate employees and steal data.
• Misconfigurations (66%): Poorly configured file-sharing policies or permissions expose sensitive documents.
• Accidental leaks (62%): Employees unintentionally share confidential data externally, often without realising the risks.

To address these issues, organisations must make SaaS-specific security a priority, with stronger identity and access controls, continuous monitoring of file sharing, and regular audits of third-party app permissions.

Simplifying Security for Lean Teams

The skills gap across APAC is real. With 58% of organisations lacking trained staff, it’s not realistic to expect small or overstretched teams to manage complex, resource-heavy security solutions.

The path forward is to simplify security operations:

1. Adopt tools that automate repetitive tasks such as misconfiguration checks.
2. Use dashboards that make alerts easy to understand and act on.
3. Focus on reducing false positives so teams can spend time on real threats.

Simplification doesn’t mean reducing coverage — it means making security achievable for lean teams without requiring an army of specialists.

Automating Security with AI and Continuous Monitoring

Misconfigurations remain one of the biggest risks, with 53% of organisations reporting them as a concern. Yet, only 9% perform continuous monitoring, while the majority check monthly or even less frequently. This creates dangerous windows of vulnerability, sometimes leaving organisations exposed for more than a month.

AI and automation are game changers here. By using AI-driven monitoring and remediation, organisations can:

• Detect suspicious account activity or abnormal data access in real time.
• Identify and resolve misconfigurations quickly, before attackers exploit them.
• Apply User and Entity Behaviour Analytics (UEBA) to spot insider threats or compromised accounts.

Automated systems cut down the lag between detection and response, transforming security from reactive firefighting to proactive resilience.

Bridging the Skills Gap

The shortage of cloud security talent in APAC is one of the region’s most pressing challenges. According to the report, 58% of organisations lack the staff to manage cloud security effectively. Without intervention, this gap will only widen as adoption continues.

Bridging the gap requires a two-track strategy:

• Invest in training and upskilling. Provide certifications, hands-on labs, and continuous learning opportunities for IT staff.
• Adopt user-friendly tools. The less time teams spend wrestling with complicated interfaces or unnecessary alerts, the more they can focus on high-value work.

For some organisations, managed security services can also provide immediate support while internal capabilities are developed.

Building Cloud Resilience in 2025

The findings in the report reveal that organisations in APAC are already preparing for the next stage of cloud security. Nearly 80% plan to increase their adoption of cloud security tools, and 32% will invest between USD $100,000 and $500,000, while 10% will invest more than $1 million in the next three years.

This level of commitment reflects both urgency and opportunity. Organisations that embrace best practices now can reduce their breach exposure, strengthen compliance, and build trust with customers and partners.

The pathway to cloud resilience is clear:

• Close blind spots with continuous visibility.
• Adopt phased, risk-based strategies.
• Prioritise SaaS as the frontline.
• Automate misconfiguration detection and response.
• Empower lean teams with simpler tools and training.

Cloud adoption is non-negotiable. But cloud resilience is a strategic choice — one that can define whether organisations merely survive or truly thrive in 2025 and beyond.

Download the Full Report

This blog draws on key insights from the Security Challenges for Cloud Adoption in APAC 2025 report, which examines regional security gaps, SaaS risks, and best practices for building resilience. To explore the complete findings and recommendations, download the full report here.

In the era of hybrid work and cloud-first strategies, Microsoft 365 (M365) has become more than just a productivity suite — it’s the nerve centre of operations. In the Asia-Pacific (APAC) region, 68% of organisations rely on M365 as their primary SaaS environment, ahead of Google Workspace and Salesforce. That makes it a critical crown jewel — and a prime target.

However, dominance breeds danger. According to the Asia-Pacific’s State of Cloud Security 2025, 35% of organisations suffered a breach in the past six months, and a startling 72% admit their tools leave blind spots. Only around one in three security leaders feel “very confident” in their cloud security posture.

Let’s explore why M365 has become the frontline in SaaS attacks — and what every organisation must do now to defend it.

SaaS Adoption: M365 Leads the Pack

Microsoft 365 touches everything: Outlook, Teams, SharePoint, OneDrive, calendar data, document collaboration. It’s woven into the business fabric. But that also makes it an attractive attack surface.

Unlike on-premises systems, SaaS platforms operate beyond the immediate control of your data centre. Files, emails, identities all roam the cloud. That mobility is convenient — but it also magnifies risk.

With M365 so deeply embedded, attackers view it as a lucrative point of entry. The more dependent your organisation is on M365, the greater the potential fallout from even a single compromised account.

The Top Threats Facing M365

The APAC report identifies several SaaS risks — but in M365, these are especially acute.

1. Hijacked Accounts (72%)

Credential-based attacks are the easiest route inside. Through phishing, credential stuffing, or brute-force attacks, adversaries compromise accounts and gain lateral access. Once inside, they can impersonate executives, send malicious emails, or exfiltrate data.

• Microsoft reports that over 99% of identity attacks involve compromised credentials, and the company blocks an average of 7,000 password attacks per second.
• A survey across 27 million M365 users found 71.4% suffer at least one compromised account per month.

These numbers reflect the extreme pressure on the need for active protection.

2. Misconfigurations (66%)

Security often fails not because of hackers, but because of human oversight. The report reveals that only 9% of organisations perform continuous configuration checks, while 65% do so monthly or less. Misconfigured sharing settings, open SharePoint sites, or permissive admin roles create vulnerabilities that attackers can easily exploit.

3. Accidental Data Leaks (62%)

Employees remain a major weak link. Many unintentionally expose confidential data by sharing files externally or connecting unauthorised third-party apps. The combination of convenience features and limited user awareness leads to unintentional exposure of sensitive documents, contact lists, or credentials.

Shared Responsibility Confusion

One of the most misunderstood aspects of SaaS security is the shared responsibility model. The report notes that many organisations wrongly assume that because Microsoft hosts the infrastructure, it also secures everything within the environment.

That’s a dangerous misconception.

Here’s the truth:

• Microsoft secures the platform itself — the physical servers, network, and uptime.
• You, the customer, are responsible for your data, users, and configurations.

If an attacker steals a password or an employee shares a confidential document publicly, Microsoft isn’t liable — your organisation is. This misunderstanding leads to dangerous blind spots where threats go unnoticed until it’s too late.

Building resilience means recognising this shared model and actively securing the parts that you control: identity management, configurations, and user activity.

Real-World Attack Trends That Hit Home

The UK’s National Cyber Security Centre (NCSC) recently issued a warning about Russian state-linked actors (Fancy Bear / APT28) targeting M365 accounts via Auth token phishing and fake login prompts.

Globally, Microsoft customers face more than 600 million cyber attacks daily, including identity, ransomware, phishing, and supply chain methods.

Sophisticated insider abuse and misconfigured admin privileges remain a chronic risk. A survey cited in a whitepaper showed instances where IT administrators abused privileges— highlighting why continuous monitoring of privileged accounts is essential to detect unusual or suspicious behaviour early.

These are not edge cases: they are very much part of the shifting threat landscape.

The path forward is to simplify security operations:

The Cost of a SaaS Breach

A single M365 breach can have devastating consequences.

• Data theft: Sensitive data like contracts, emails, and intellectual property are prime targets.
• Operational disruption: Hijacked accounts can lock out legitimate users or spread phishing campaigns internally.
• Regulatory penalties: Exposure of personal or customer data may trigger fines under privacy laws such as GDPR or regional frameworks.
• Reputational damage: Clients and partners lose trust quickly after a cloud-based data leak.

The report reveals that 35% of organisations in APAC experienced a data breach within the last six months — a staggering figure that underscores the growing urgency to secure M365 environments.

These breaches aren’t isolated incidents; they’re symptoms of a growing threat landscape that exploits poor visibility and mismanagement of SaaS applications.

How to Secure Microsoft 365 Effectively

The good news is that Microsoft 365 offers a rich security foundation — but it needs to be actively managed, monitored, and enhanced. Based on the findings of the report, organisations should focus on the following key areas:

1. Monitor User and Data Activity

• Continuously track file sharing and collaboration patterns in OneDrive and SharePoint.
• Set alerts for unusual behaviour such as large file downloads, external sharing spikes, or logins from unfamiliar locations.
• Leverage User and Entity Behaviour Analytics (UEBA) to detect compromised or malicious insiders.

2. Automate Misconfiguration Detection

The report found that 29% of organisations resolve configuration issues within a day, but 6% take over a month. Delays of that length give attackers ample opportunity to exploit vulnerabilities.

Regularly audit:

• SharePoint and OneDrive permissions.
• Admin role assignments.
• Third-party app access requests.

Automate detection and remediation wherever possible to reduce manual workload and response times.

3. Empower Employees with Security Awareness

Human error accounts for a significant portion of SaaS security incidents. Regularly train employees on:

• Recognising phishing attempts and suspicious login prompts.
• Safe sharing practices within M365 tools.
• The risks of connecting unauthorised applications or browser plugins.

An aware workforce is one of the most powerful defences against SaaS breaches.

Investing in SaaS Security

The APAC region is responding to these challenges with increased investment. The report notes that 41% of organisations plan to expand their budgets for SaaS cybersecurity over the next few years..

This investment is focused on improving:

• Account protection and identity management.
• Real-time threat monitoring and automation.
• Misconfiguration detection and policy enforcement.

For many, this shift represents a recognition that SaaS isn’t “set and forget” — it’s an evolving environment that requires continuous attention and smart tooling.

From Exposure to Resilience

Microsoft 365 has redefined how organisations in APAC collaborate, communicate, and store data. But it has also redefined the threat surface. Account hijacks, misconfigurations, and accidental leaks are no longer edge cases — they are daily realities.

Resilience begins with visibility and vigilance. Organisations must own their part of the shared responsibility model, proactively monitor SaaS activity, and automate wherever possible.

By doing so, they can ensure that the same platforms driving business productivity don’t become the source of the next data breach headline.

Your SaaS apps are the front door to your business. It’s time to make sure that door is locked, monitored, and always under your control.

Download the Full Report

This blog only scratches the surface of the insight within the Asia-Pacific’s State of Cloud Security 2025. For deeper analysis, benchmarks, and a full set of recommendations to harden your cloud security, download the full report now.

Background of M365 Copilot

What is a Retrieval Augmented Generation (RAG)?

Retrieval Augmented Generation (RAG) is a technique that improves the responses of LLMs by connecting external data sources. The connection to relevant data sources allows responses to be more accurate and contextually relevant by reducing hallucinations and generic responses.

M365 Copilot and RAG Intergration

M365 Copilot is a RAG-based chatbot that queries the Microsoft Graph and retrieves any relevant information from the user’s organisational environment, including mailboxes, OneDrive storage, Microsoft 365 Office files, internal SharePoint sites, and Microsoft Teams chat history. Copilot’s permission model ensures that the user only has access to their own files which may include sensitive, proprietary and compliance-related information. M365 Copilot integration with Microsoft Graph potentially exposes it to threats originating from outside the organisation.  

Attack Background

The attack discussed uses the number one exploit in OWASP Top 10 list known as Prompt Injection. Prompt Injection occurs when an attacker or user prompts alter the LLMs’ behaviour or output in an unintended way. These inputs can affect the model even if they are imperceptible to humans; therefore prompt injections do not need to be visible or readable to humans, if the content is parsed by the model.

Prompt injection involves manipulating model responses through specific inputs to alter its behaviour, which can include bypassing safety measures. Prompt Injection vulnerabilities exist due to how models process prompts, and how input may force the model to incorrectly pass prompt data to other parts of the model, potentially causing malicious output.

The prompt injection used in this attack can be classified as “Indirect Prompt Injection”. Indirect prompt injections occur when an LLM accepts input from external sources and the content when interpreted by the model, maliciously alters the model’s behaviour.

In addition, Aim Labs has classified the attack as “LLM Scope Violation”. The term describes the situation where an attacker’s input manipulates the LLM to access trusted data in the model’s context without user interaction.

The attack relies on Copilot’s default behaviour to combine and process content from Outlook and SharePoint thereby turning trust into a silent data leak vector.

Attack Diagram

Attack Flow Breakdown

1. XPIA bypass via crafted email

Attackers are able to bypass the XPIA (cross-prompt injection attack) classifiers by phrasing the email that contained malicious instructions as if the instructions were aimed at the recipient. The attackers are careful not to  mention AI/assistants/Copilot to make sure that the XPIA classifiers don’t detect the email as malicious.

• User initiates attacks

User asks Microsoft 365 Copilot a business-related or research question that triggers Copilot to access Outlook and other connected Microsoft applications for context. This action leads to Copilot ingesting the crafted email sent by the attacker.

• Scope Violation through Redaction Bypass
  • Link redaction bypass

By default, Copilot redacts external markdown links from the chat history before the user has any chance of clicking those links. This solution should enforce that only safe link targets (i.e., internal webpages) are presented as clickable links to the user. But we are able to bypass this restriction by using Reference-style markdown links as they are not redacted and are not recognised by Microsoft.

Below are examples of links not removed from the chat by M365 Copilot:

• Image redaction bypass

To ensure the link is clicked without user interaction, the attacker can trick the LLM into outputting a markdown image with an embedded image. When the link is embedded, the browser automatically accesses the links allowing the attacker to exfiltrate data.

The markdown image format also includes Reference-style links that are able to bypass Copilot’s link redaction. Here the examples of links not removed from the chat by M365 Copilot:

• Data Exfiltration through SharePoint and Teams

Even while using Reference-style markdown link, the attacker is not able to use custom domain to exfiltrate data as Microsoft has Content-Security-Policy whitelisting in-place to deter such attacks. Here is the list of domains whitelisted by Microsoft:

But the attacker is able to bypass the CSP through these whitelisted domains. Among the list of domains are “*[.]sharepoint[.]com” which can be exploited to craft a malicious invite URL:

This crafted link allows the attacker to request on behalf of the client to fetch embedded data for the SPO site, but this flow requires the victim to accept the invitation from the attacker to allow data exfiltration.

To achieve a zero-click vulnerability, the attacker instead uses Microsoft Teams “*[.]teams[.]com” to craft better malicious link which does not require user interaction:

MITRE Mapping

Mapping based on MITRE ATT&CK and ATLAS.

Recommended Remediation

Implement a robust monitoring strategy across all M365 environments, including anomalous access and exfiltration data that may indicate malicious activity.

M365 environment administrators should enforce proper logging and access management for users to prevent further unauthorised access.  Moreover, users should monitor user activity in their tenant to ensure activities performed are not due to AI agents or attackers.

In addition, the deployment of automated alerts and remediation workflows is essential for reducing response times and minimising the overall impact of an attack. By integrating automated detection systems with remediation protocols, organisations 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.  

Conclusion

Aim Labs has discovered a critical zero-click AI vulnerability named EchoLeak that leverages Microsoft 365 Copilot, which enables attackers to exfiltrate sensitive data with zero user interaction. The exploit uses a novel technique introduced as “LLM Scope Violation”. This technique manipulates Copilot which uses retrieval-augmented generation (RAG) by sending an email with embedded prompt injection. Although no known customer impact has occurred yet, this vulnerability expands to all known LLM models that have RAG or connected to data sources. These vulnerabilities indicate a growing security threat that can be exploited by novice attackers due to a lack of proper scope control and security measures in place.

What is Microsoft Power Pages?

Microsoft Power Pages, a low-code SaaS platform, enables organisations to swiftly develop external-facing websites. While it offers convenience and efficiency, recent findings have highlighted significant data exposure risks stemming from misconfigured access controls. These misconfigurations can inadvertently expose sensitive information to unauthorised users, underscoring the critical need for robust security practices. 

Common Use Cases for Microsoft Power Pages 

Organisations across various sectors leverage Microsoft Power Pages for numerous applications, including: 

• Customer Service Portal – Self-service platform for customer inquiries and support 

• Employee Onboarding – Streamlined processes for new hire documentation and training 

• Event Registration Platform – Automated registration and management systems 

• Vendor Management System – Centralised vendor information and relationship management 

• Community Forum – Interactive platforms for user engagement and discussion 

• Knowledge Bases – Centralised repositories for organisational information 

• Appointment Scheduling Site – Automated booking and calendar management 

• E-learning Portal – Educational content delivery and training platforms 

• Patient Portal – Healthcare information access and appointment management 

• Incident Reporting System – Streamlined reporting and tracking of organisational incidents 

How Did This Happen? 

A cybersecurity researcher discovered substantial data exposures in Microsoft Power Pages websites due to misconfigured access controls. These vulnerabilities resulted in the public exposure of sensitive data, including Personally Identifiable Information (PII) such as full names, email addresses, phone numbers, and home addresses.  

Most notably, a large, shared business service provider for the UK’s National Health Service (NHS) inadvertently leaked information about over 1.1 million NHS employees, encompassing email addresses, telephone numbers, and home addresses. This specific issue was caused specifically due to misconfiguration of power apps. 

Severity of the Breach 

The misconfigurations identified have led to the exposure of millions of sensitive records across various sectors, including technology, healthcare, and finance. The NHS incident alone affected over a million employees, highlighting the extensive impact such vulnerabilities can have on both individuals and organisations. The exposed data, accessible to unauthorised users, poses significant risks, including identity theft, phishing attacks, and other malicious activities. 

Impact on Affected Organisations 

The data exposure has far-reaching implications for the organisations involved. Beyond the immediate risk of data theft, companies may face legal repercussions, regulatory fines, and damage to their reputations. Customers whose data has been compromised are at increased risk of identity theft, financial fraud, and other malicious activities. 

For businesses, this incident underscores the importance of thoroughly understanding and correctly configuring security settings in all platforms they use. Relying on default settings without a comprehensive security review can lead to vulnerabilities that are easily exploitable. 

Causes of Data Exposure 

The primary cause of these data exposures is the misconfiguration of access controls within Power Pages. Key factors contributing to the breach include: 

• Enabling Open Self-Registration: By default, newly deployed Power Pages sites permit anonymous users to register and obtain “Authenticated” status, which generally comes with expanded permissions. Even if registration pages are not explicitly displayed on the site, users can still sign up and authenticate through associated APIs. 

• Assigning “Global Access” Permissions to External Users: Granting “Global Access” to tables for anonymous users makes all records within those tables publicly accessible. Similarly, if authenticated users are assigned this permission and self-registration is open, unauthorised individuals could exploit it to gain unrestricted data access.  

• Lack of Column-Level Security for Sensitive Data: Even when table-level access controls are in place, attackers may still access unprotected columns if column-level security is not applied. This inconsistency in security implementation, often due to the complexity of the setup process or a lack of awareness, leaves certain data vulnerable to exposure.   

• Failure to Mask Sensitive Data: Instead of using column-level security, organisations can apply data masking techniques to obfuscate sensitive information. However, many fail to implement this, leaving confidential data readable by unauthorised users. 

•  Overexposing Data via the Power Pages Web API: Organisations frequently configure the Web API to expose all columns of a table, rather than limiting access to only necessary fields. This practice increases the risk of data leaks, as unauthorised individuals gaining access to the API could retrieve excessive amounts of sensitive information. 

How to Detect Misconfigurations in Microsoft Power Pages 

Detecting such misconfigurations requires a comprehensive review of access control settings within Power Pages deployments. Organisations should: 

• Audit Site-Level Settings: Ensure that authentication and registration configurations align with security policies, disabling open registrations if not necessary. 

• Review Table and Record Permissions: Verify that permissions granted to roles, especially ‘Anonymous Users’ and ‘Authenticated Users,’ are appropriate and do not provide excessive access. 

• Implement Column-Level Security: Utilise column security profiles and data masking to protect sensitive information from unauthorised access. 

• Continuous Monitoring: Regularly monitor and assess configurations to detect and remediate any deviations from established security baselines. 

Conclusion

The incidents of data exposure in Microsoft Power Pages serve as a stark reminder of how easily misconfigurations can compromise sensitive information on a massive scale. While the platform offers immense value across industries—from healthcare and finance to education and community services—the responsibility of securing these deployments ultimately lies with the organisations that use them.

By proactively auditing configurations, applying granular access controls, and implementing continuous monitoring, organisations can mitigate risks and safeguard the sensitive data entrusted to them. The lesson is clear: security cannot be treated as an afterthought. In today’s threat landscape, robust configuration and vigilant oversight are not optional—they are essential to protecting both people and businesses from preventable breaches.

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.

1. Teams request to chat

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

2. 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.

3. 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.  

1. 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.

2. 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.

3. 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.

MITRE ATT&CK MAPPING

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. Unusual App Given Access (Azure, GWS, M365)
3. Application Credentials Added
4. Third Party Cloud Application Installed
5. Email forwarding settings changed
6. User Updated Mailbox Rules
7. SharePoint/OneDrive Data Theft
8. Unusual User Agent
9. Unusual User IP address

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

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.