Skip to content

Security Sense

AI Threat Intelligence

  • About
  • Blog
  • Privacy Policy

Tag: cloud

ASOS Confirms Data Breach Following Snowflake Environment Compromise

Posted on October 6, 2026 by Kyle

Overview

UK fashion retailer ASOS confirmed a data breach after threat actors leveraged its mobile app to send unauthorized push notifications to customers. The attackers claimed to have stolen customer data from ASOS’s Snowflake cloud data warehousing environment. This incident highlights the risks associated with third-party cloud service compromises and their potential impact on customer data and brand reputation.

Technical Analysis

  • Threat actors gained unauthorized access to ASOS’s Snowflake cloud data warehousing environment.
  • The compromise enabled the exfiltration of customer data, as claimed by the attackers.
  • Attackers subsequently utilized ASOS’s mobile application infrastructure to send unauthorized push notifications to users, displaying messages such as “HACKED”.
  • The specific method of initial access to the Snowflake environment (e.g., compromised credentials, API key misuse, vulnerability exploitation) has not been publicly detailed.
  • The ability to send push notifications suggests compromise of an API key or service account with permissions to interact with ASOS’s mobile app backend.

Detection

  • Snowflake Audit Logs: Monitor Snowflake LOGIN_HISTORY and QUERY_HISTORY for unusual login locations, IP addresses, user agents, or large-volume data export queries from service accounts or dormant user accounts.
  • API Gateway Logs: Look for unusual or unauthorized API calls to push notification services or customer communication platforms, especially those originating from unexpected source IPs or using compromised credentials.
  • Cloud Access Security Broker (CASB) Alerts: Review alerts related to unusual data access patterns, large data transfers, or suspicious activity within cloud environments like Snowflake.
  • Network Flow Logs: Monitor for unusual outbound connections from cloud environments or internal systems to unknown external destinations, especially large data transfers.

Sigma Detection Rules

⚠️ AI-generated detection rules. These are experimental starting points. Review field names, EventIDs, and logic against your environment’s schema before deploying. Tune to reduce false positives.

Snowflake – Unusual Login Location

title: Snowflake - Unusual Login Location
id: 9a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects Snowflake logins from IP addresses or locations not typically associated with legitimate access. Requires tuning for known internal/VPN IP ranges.
logsource:
  product: snowflake
  service: login_history
detection:
  selection:
    EVENT_TYPE: 'LOGIN'
    IS_SUCCESS: 'TRUE'
  filter_known_ips:
    CLIENT_IP|startswith:
      - '192.168.'
      - '10.'
      - '172.16.'
      - '172.17.'
      - '172.18.'
      - '172.19.'
      - '172.20.'
      - '172.21.'
      - '172.22.'
      - '172.23.'
      - '172.24.'
      - '172.25.'
      - '172.26.'
      - '172.27.'
      - '172.28.'
      - '172.29.'
      - '172.30.'
      - '172.31.'
  condition: selection and not filter_known_ips
level: high

Snowflake – Large Data Export to External Stage

title: Snowflake - Large Data Export to External Stage
id: f1e2d3c4-b5a6-7890-1234-567890abcdef
status: experimental
description: Detects large data export operations from Snowflake to external stages, which could indicate data exfiltration.
logsource:
  product: snowflake
  service: query_history
detection:
  selection:
    QUERY_TYPE: 'COPY_INTO'
    QUERY_TEXT|contains: 'LOCATION='
    BYTES_TRANSFERRED|gt: 100000000 # Example: >100MB transferred
  condition: selection
level: high

Mitigations

  1. Review and Rotate Credentials: Immediately review and rotate all credentials (passwords, API keys, tokens) associated with Snowflake access, especially those used by applications or service accounts. Implement strong, unique passwords and enforce regular rotation.
  2. Enforce Multi-Factor Authentication (MFA): Ensure MFA is enforced for all user accounts accessing the Snowflake environment, including administrative and service accounts where possible.
  3. Audit Cloud Access Policies: Conduct a thorough audit of access controls and permissions within the Snowflake environment, adhering to the principle of least privilege. Remove unnecessary permissions.
  4. Monitor Cloud Activity: Implement continuous monitoring of Snowflake audit logs and integrate them with a SIEM for real-time alerting on suspicious activities, such as unusual login patterns or large data exports.
  5. Secure API Endpoints: Review and secure API endpoints used for mobile application communications, ensuring proper authentication, authorization, and rate limiting are in place.

References

  • https://www.bleepingcomputer.com/news/security/asos-confirms-data-breach-after-hacked-in-app-notifications/

Indicators of Compromise

No public IOCs available at time of writing.

MITRE ATT&CK

  • T1537 — Transfer Data to Cloud Account
  • T1567.002 — Exfiltration to Cloud Storage
  • T1078.004 — Cloud Accounts
🤖 AI Attribution
Generated by gemini-2.5-flash ·
1,495 input / 1,414 output tokens ·
Reviewed and approved by a human analyst before publication
Posted in UncategorizedTagged cloud, data breach, high, mobile app, snowflakeLeave a comment

JADEPUFFER-Linked Attackers Used Compromised Service Principals to Delete Azure Resources

Posted on September 28, 2026 by Kyle

Overview

The JADEPUFFER threat actor (Microsoft’s Storm-3168) has been observed executing destructive actions within Microsoft Azure environments. This activity, occurring over approximately 18 hours in early June 2026, involved the use of compromised service principals to delete Azure resources. This represents an evolution in the actor’s tradecraft, posing a critical threat to cloud infrastructure integrity and availability.

Technical Analysis

JADEPUFFER attackers gained unauthorized access to Azure environments by compromising service principals. These compromised identities were then leveraged to initiate destructive operations, specifically the deletion of Azure resources. The attack unfolded over an 18-hour window, indicating a sustained effort to cause disruption or data loss. The specific methods of initial service principal compromise were not detailed in the available information, but the subsequent actions focused on resource removal.

Detection

Defenders can identify this activity by monitoring Azure Activity Logs and Azure AD Audit Logs for suspicious actions by service principals.

  • Monitor Azure Activity Logs for operationName related to resource deletion (e.g., Microsoft.Resources/subscriptions/resourceGroups/delete, Microsoft.Compute/virtualMachines/delete, Microsoft.Storage/storageAccounts/delete) where the identity.type is ServicePrincipal.
  • Look for an unusual volume or pattern of resource deletion events originating from a single service principal or a cluster of service principals within a short timeframe.
  • Analyze Azure AD Audit Logs for suspicious modifications to service principal permissions or credentials, or sign-ins from unusual geographic locations or IP addresses for service principals.
  • Hunt for service principals performing actions outside their established baseline or expected scope of work.

Sigma Detection Rules

⚠️ AI-generated detection rules. These are experimental starting points. Review field names, EventIDs, and logic against your environment’s schema before deploying. Tune to reduce false positives.

Azure Resource Group Deletion by Service Principal

title: Azure Resource Group Deletion by Service Principal
id: 9a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects the deletion of an Azure Resource Group by a Service Principal, which could indicate a compromised identity or destructive activity.
logsource:
  product: azure
  service: activitylogs
detection:
  selection:
    operationName: 'Microsoft.Resources/subscriptions/resourceGroups/delete'
    identity.type: 'ServicePrincipal'
  condition: selection
level: critical

Suspicious Azure Resource Deletion by Service Principal

title: Suspicious Azure Resource Deletion by Service Principal
id: 0f1e2d3c-4b5a-6f7e-8d9c-a0b1c2d3e4f5
status: experimental
description: Identifies general resource deletion operations performed by a Service Principal in Azure, potentially indicating a compromised account or malicious activity.
logsource:
  product: azure
  service: activitylogs
detection:
  selection:
    operationName|contains: '/delete'
    identity.type: 'ServicePrincipal'
  condition: selection
level: high

Mitigations

  1. Implement Strong Authentication for Service Principals: Where possible, use managed identities or certificate-based authentication for service principals instead of secrets. If secrets are necessary, enforce strong, regularly rotated secrets.
  2. Apply Least Privilege: Grant service principals only the minimum necessary permissions required for their function. Regularly review and audit assigned roles and permissions.
  3. Monitor Azure Activity and Audit Logs: Implement continuous monitoring for resource deletion events, service principal activity, and changes to permissions. Integrate these logs with a SIEM for alert generation and correlation.
  4. Enable Azure Resource Locks: Apply resource locks (CanNotDelete, ReadOnly) to critical Azure resources to prevent accidental or malicious deletion.
  5. Regularly Audit Service Principals: Periodically review all service principals in your Azure AD tenant, their assigned permissions, and their activity to identify dormant or over-privileged accounts.

References

  • https://thehackernews.com/2026/09/jadepuffer-linked-attackers-used.html

Indicators of Compromise

No public IOCs available at time of writing.

MITRE ATT&CK

  • T1078.004 — Cloud Accounts
  • T1531 — Account Access Removal
🤖 AI Attribution
Generated by gemini-2.5-flash ·
1,543 input / 1,123 output tokens ·
Reviewed and approved by a human analyst before publication
Posted in aptTagged apt, azure, cloud, critical, destructiveLeave a comment

Cloudflare Containers Cross-Tenant Data Exposure Vulnerability

Posted on September 27, 2026 - September 27, 2026 by Kyle

Overview

Cloudflare has addressed a critical cross-tenant vulnerability affecting its Containers and Sandboxes services. This flaw permitted customers with a Workers Paid account to recover residual data belonging to other customers sharing the same physical host. The vulnerability posed a significant risk of unauthorized data exposure across different Cloudflare tenants.

Technical Analysis

  • The vulnerability resided within Cloudflare’s Containers and Sandboxes environments.
  • It allowed a malicious or compromised Workers Paid account to access residual data left behind by other tenants on the same underlying physical infrastructure.
  • This implies a failure in proper isolation or secure data sanitization between containerized environments.
  • The attack vector required an active Workers Paid account on the Cloudflare platform.
  • Affected services: Cloudflare Containers and Sandboxes.

Detection

  • This vulnerability was an internal platform issue within Cloudflare’s infrastructure.
  • Cloudflare customers cannot directly detect exploitation attempts or successful data recovery related to this specific flaw within their own logs or systems.
  • Customers should monitor Cloudflare’s security advisories and ensure their services are up-to-date.

Mitigations

  1. Cloudflare has already implemented a fix for this vulnerability. Customers using Cloudflare Containers and Sandboxes should ensure their services are operating on the latest patched infrastructure.
  2. Review Cloudflare’s official security advisories and best practices for Workers and Container services.
  3. Implement robust data handling and encryption practices for sensitive data stored or processed within Cloudflare environments, assuming a zero-trust model even within cloud platforms.

References

  • https://www.bleepingcomputer.com/news/security/cloudflare-fixes-containers-cross-tenant-flaw-exposing-customer-data/

Indicators of Compromise

No public IOCs available at time of writing.

MITRE ATT&CK

  • T1530 — Data from Cloud Storage
🤖 AI Attribution
Generated by gemini-2.5-flash ·
1,489 input / 557 output tokens ·
Reviewed and approved by a human analyst before publication
Posted in vulnerabilityTagged cloud, cloudflare, critical, cross-tenant, data-exposure, vulnerabilityLeave a comment

Anthropic Launches Claude AI Marketplace: New Attack Surface Considerations

Posted on September 27, 2026 - September 27, 2026 by Kyle

Overview

Anthropic has announced the Claude Marketplace, integrating over 2,000 plugins, connectors, and agents into its AI platform. This development expands the capabilities of Claude AI but also introduces new attack surfaces and security considerations for organizations leveraging these tools, particularly concerning data privacy, third-party trust, and supply chain integrity.

Technical Analysis

The Claude Marketplace allows third-party developers to create and offer plugins and connectors that extend Claude’s functionality. These integrations can access user data, interact with external services, and potentially execute actions based on granted permissions. The primary technical risks include:
* Data Exposure: Plugins may request broad permissions, leading to sensitive data exposure if not properly vetted or if the plugin itself is compromised.
* Supply Chain Vulnerabilities: The reliance on third-party developers introduces potential vulnerabilities through malicious or poorly secured plugins, which could be used for data exfiltration or unauthorized access.
* Unauthorized Actions: Over-privileged plugins could perform actions within an organization’s environment that are not intended or approved, potentially leading to system compromise or data manipulation.

Detection

Defenders should focus on monitoring the usage of AI services and the behavior of integrated applications to identify potential misuse or compromise:
* Monitor network traffic for connections to api.anthropic.com or other AI service endpoints from unexpected hosts or user agents within the environment.
* Review API logs for unusual or excessive data access requests made by AI-integrated applications or plugins.
* Implement logging for application-level events related to plugin installation, permission changes, or data processing by AI services.
* Monitor for large data egress to external AI service domains, which could indicate unauthorized data exfiltration.
* Look for suspicious child processes spawned by applications known to integrate with AI, which could signal a successful exploit of a vulnerable plugin.

Sigma Detection Rules

⚠️ AI-generated detection rules. These are experimental starting points. Review field names, EventIDs, and logic against your environment’s schema before deploying. Tune to reduce false positives.

Direct Network Access to Anthropic API

title: Direct Network Access to Anthropic API
id: 93b2a7e1-f6c0-4f5e-a8d1-1b9c0d2e3f4g
status: experimental
description: Detects direct network connections to Anthropic's API endpoint. This can help identify unauthorized or unmonitored usage of Claude AI services within an environment.
logsource:
  category: network_connection
  product: windows
  service: sysmon
detection:
  selection:
    DestinationPort: 443
    Initiated: 'true'
    DestinationIp|cidr: # Placeholder for Anthropic IP ranges, e.g., '104.18.0.0/16'
    # Alternatively, for network logs (e.g., Zeek, Suricata) looking at HTTP host:
    # http.host|contains: 'api.anthropic.com'
  condition: selection
level: informational

Mitigations

  1. Establish AI Governance Policies: Develop clear policies for the use of AI tools and third-party plugins, including data classification guidelines for information that can be processed by external AI services.
  2. Vet Third-Party Plugins: Conduct thorough security assessments of all plugins and connectors before deployment, evaluating their data handling practices, requested permissions, and developer reputation.
  3. Implement Least Privilege: Configure AI plugins and integrations with the minimum necessary permissions and data access required for their intended function.
  4. User Education: Educate employees on the risks associated with third-party AI integrations, the importance of verifying plugin legitimacy, and responsible data handling practices.
  5. Network Segmentation & DLP: Utilize network segmentation to restrict AI-integrated systems’ access to sensitive internal resources and deploy Data Loss Prevention (DLP) controls to prevent unauthorized data exfiltration to external AI services.

References

  • https://www.bleepingcomputer.com/news/artificial-intelligence/anthropic-turns-claude-into-an-ai-marketplace-with-2-000-plus-plugins-and-connectors/

Indicators of Compromise

No public IOCs available at time of writing.

🤖 AI Attribution
Generated by gemini-2.5-flash ·
1,510 input / 1,065 output tokens ·
Reviewed and approved by a human analyst before publication
Posted in UncategorizedTagged ai, cloud, data-security, low, supply-chain, third-partyLeave a comment
Proudly powered by WordPress | Theme: micro, developed by DevriX.