Soldier Sentenced to 70 Months for AT&T and Verizon Extortion: Defending Snowflake Tenants and Call Metadata from Credential-Based Theft

On September 2026, a U.S. Army soldier was sentenced to 70 months in federal prison and ordered to pay nearly $300,000 in restitution for his role in one of the most consequential data theft campaigns of the past two years: the compromise of telecommunications giants AT&T and Verizon, including the theft of mobile call and text metadata belonging to more than 100 million AT&T customers in 2024.

For defenders, the sentencing is not the story — the tradecraft is. This campaign, which investigators and the security community have tied to the broader wave of Snowflake cloud data warehouse intrusions attributed to the threat cluster tracked as UNC5537, is a masterclass in what happens when three mundane failures converge: infostealer-harvested credentials sitting in criminal marketplaces for years, SaaS tenants without multi-factor authentication, and cloud data platforms holding enormous volumes of highly sensitive records with weak monitoring.

The defendant — known in underground forums under the handle "kiberphant0m" — pleaded guilty to hacking into multiple telecommunications companies and using the stolen data for extortion. The stolen AT&T dataset included call and text metadata: who communicated with whom, when, and for how long. That is not content, but from an intelligence and targeting perspective, metadata of that scale is arguably more dangerous than content. It enables social network mapping, doxxing, SIM-swap targeting, stalking, and nation-state-grade counterintelligence operations.

If your organization stores customer data in Snowflake, BigQuery, Redshift, Databricks, or any SaaS data platform, this case is your incident report. The access method used here was not exotic. It was valid credentials, no MFA, and bulk SQL exfiltration. Every one of those is detectable and preventable.

Technical Analysis: How the Attack Chain Actually Worked

No CVE — and That's the Point

There is no CVE associated with this campaign, and no software vulnerability was exploited. This is critical for defenders to internalize: the intrusions succeeded through credential-based initial access against cloud SaaS tenants, not through a patchable flaw. The affected "platform" was the customers' own Snowflake tenant configurations — and by extension, any SaaS data platform where authentication relies on a static username and password.

The Attack Chain

Based on court records and public reporting on the broader Snowflake campaign, the kill chain looked like this:

Credential acquisition (years in the making): Infostealer malware families (Lumma, Raccoon, Vidar, RedLine, and similar) harvested credentials from infected endpoints — in some cases contractor or employee machines — dating back years. Those credentials were sold or traded in stealer log markets and Telegram channels.
Tenant discovery: Threat actors enumerated Snowflake customer tenants using publicly known account locator URLs (<account>.snowflakecomputing.com) and tested harvested credentials against them at scale.
Authentication without MFA: Accounts protected only by username/password — including service accounts and legacy users — granted direct access. Snowflake does not force MFA by default; it must be explicitly configured per user or enforced via SCIM/SSO policy.
Reconnaissance and bulk exfiltration: Once authenticated, the actors ran large SELECT queries and used COPY INTO <location> to stage data to external cloud storage (attacker-controlled S3 buckets and similar), then GET/unloaded the staged data out of the environment.
Extortion: Victim organizations were contacted with samples of their data and extortion demands. Data was advertised on criminal forums including BreachForums. AT&T reportedly paid a ransom (reportedly ~$370,000 in Bitcoin to a related actor) in an attempt to have the data deleted — and still faced the consequences.

Exploitation Status

In-the-wild exploitation: Confirmed. Hundreds of Snowflake customer tenants were compromised in this campaign, including AT&T, Ticketmaster/Live Nation, Santander, Advance Auto Parts, and others.
CISA KEV: Not applicable — no CVE exists. CISA and the FBI did, however, issue joint guidance (AA24-151A and follow-on advisories) specifically addressing detections and mitigations for this threat cluster.
Current relevance (2026): The sentenced defendant's co-conspirators and copycats remain active. Stealer-log credential markets continue to grow, and SaaS tenants without enforced MFA remain the single highest-yield target set for financially motivated actors. The Verizon-related portion of this case shows the actors pivoted across the telecom sector specifically — call detail records (CDRs) remain a priority target for both criminal and espionage-motivated actors (see also the Salt Typhoon telecom intrusions for the nation-state parallel).

Why Call Metadata Is a Tier-One Asset

Defenders in telecom and any industry handling communications records should treat CDRs as crown jewels:

Social graph reconstruction: 100M+ subscribers' contact patterns reveal relationships, hierarchies, and routines.
Targeting enablement: Journalists, executives, government officials, and their contacts become identifiable and targetable for SIM swapping, phishing, and physical surveillance.
Regulatory exposure: FCC CPNI rules, state breach notification laws, and contractual obligations make telecom metadata breaches extraordinarily expensive — AT&T faced FCC scrutiny and class actions on top of the breach itself.

Detection & Response

This is a credential-abuse and bulk-exfiltration scenario. The highest-fidelity detections live in the SaaS platform's own logs (Snowflake ACCOUNT_USAGE views), not on the endpoint — but endpoint detections for infostealer activity close the loop upstream. The rules below are tuned for analyst value, not volume.

Sigma Rules

YAML

---
title: Infostealer Access to Browser Credential Stores
description: Detects non-browser processes reading Chromium or Firefox credential databases, a hallmark of infostealer malware (Lumma, Raccoon, Vidar, RedLine) whose logs fueled the Snowflake/AT&T credential-theft campaign.
references:
  - https://attack.mitre.org/techniques/T1555/003/
  - https://krebsonsecurity.com/2026/09/u-s-soldier-gets-70-months-in-prison-for-att-verizon-extortions/
author: Security Arsenal
date: 2026/09/15
id: 8f2c1a44-6b3d-4e5a-9c71-2d4e6f8a0b12
status: experimental
logsource:
  category: file_access
  product: windows
detection:
  selection_paths:
    TargetFilename|contains:
      - '\AppData\Local\Google\Chrome\User Data\'
      - '\AppData\Local\Microsoft\Edge\User Data\'
      - '\AppData\Local\BraveSoftware\'
      - '\AppData\Roaming\Mozilla\Firefox\Profiles\'
  selection_files:
    TargetFilename|endswith:
      - '\Login Data'
      - '\Cookies'
      - '\Web Data'
      - '\logins.json'
      - '\key4.db'
  filter_browsers:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\brave.exe'
      - '\firefox.exe'
  condition: selection_paths and selection_files and not filter_browsers
falsepositives:
  - Enterprise password managers and EDR agents legitimately inspecting browser stores
level: high
---
title: Web Process Spawned from Unusual Parent — Possible Session Token Theft or Stealer Staging
description: Detects browsers or cloud CLI tools spawned by script interpreters or Office processes, consistent with infostealer execution chains and hands-on access using stolen SaaS session material.
references:
  - https://attack.mitre.org/techniques/T1059/
  - https://krebsonsecurity.com/2026/09/u-s-soldier-gets-70-months-in-prison-for-att-verizon-extortions/
author: Security Arsenal
date: 2026/09/15
id: 3b7e9d02-5a1c-4f8b-b6d3-9e2c4a7f1058
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection_parents:
    ParentImage|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\cmd.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\winword.exe'
      - '\excel.exe'
  selection_children:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\snowsql.exe'
      - '\aws.exe'
      - '\az.exe'
      - '\gcloud.exe'
  condition: selection_parents and selection_children
falsepositives:
  - Rare legitimate automation launching browsers or cloud CLIs; investigate parent command lines
level: medium

KQL — Microsoft Sentinel (Snowflake Audit Logs via Connector / Syslog / CEF)

The highest-value hunt is against Snowflake's own telemetry. Ingest LOGIN_HISTORY and QUERY_HISTORY exports (via the Snowflake connector or a scheduled export to Blob/Event Hub) and hunt for impossible travel, MFA-less logins, and bulk exfiltration patterns:

KQL — Microsoft Sentinel / Defender

// Hunt 1: Successful Snowflake logins without MFA from unusual sources
// Requires Snowflake LOGIN_HISTORY ingested as custom table SnowflakeLogin_CL
SnowflakeLogin_CL
| where IS_SUCCESS_s == "YES"
| where SECOND_AUTHENTICATION_FACTOR_s == "" or SECOND_AUTHENTICATION_FACTOR_s == "NO"
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
            Logins=count(), SourceIPs=make_set(CLIENT_IP_s), Clients=make_set(REPORTED_CLIENT_TYPE_s)
    by USER_NAME_s
| where Logins > 3
| project USER_NAME_s, Logins, SourceIPs, Clients, FirstSeen, LastSeen
| order by Logins desc;

// Hunt 2: Bulk extraction — large COPY INTO / external stage unloads
// Requires Snowflake QUERY_HISTORY ingested as custom table SnowflakeQuery_CL
SnowflakeQuery_CL
| where QUERY_TEXT_s has_any ("COPY INTO", "@%", "s3://", "azure://", "gcs://")
| extend RowsWritten = tolong(ROWS_WRITTEN_s), RowsProduced = tolong(ROWS_PRODUCED_s)
| where RowsWritten > 100000 or RowsProduced > 1000000
| project TimeGenerated, USER_NAME_s, CLIENT_IP_s, QUERY_TEXT_s, RowsWritten, RowsProduced
| order by RowsWritten desc;

// Hunt 3: Endpoint-side stealer behavior in Defender
DeviceFileEvents
| where FileName in~ ("Login Data", "Cookies", "logins.json", "key4.db", "Web Data")
| where InitiatingProcessFileName !in~ ("chrome.exe", "msedge.exe", "firefox.exe", "brave.exe")
| where FolderPath has_any ("\\User Data\\", "\\Firefox\\Profiles\\")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath, FileName
| order by TimeGenerated desc;

Velociraptor VQL — Endpoint Hunt for Stealer Artifacts

If you suspect the upstream compromise vector (infostealer on an employee or contractor endpoint with Snowflake access), hunt for mass browser-store access and stealer staging directories:

VQL — Velociraptor

-- Hunt: Processes accessing browser credential stores (infostealer behavior)
-- Deploy as a hunt across systems of users with SaaS admin or data-platform access
SELECT Pid,
       Name,
       Exe,
       CommandLine,
       Username,
       CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(login data|logins\\.json|key4\\.db|\\\\cookies|web data)'
   OR Exe =~ '(?i)(appdata\\\\(local|roaming)\\\\temp|\\\\programdata\\\\[a-z0-9]{6,12}\\\\)'

-- Hunt: Stealer staging artifacts in Temp/AppData
SELECT FullPath,
       Size,
       Mtime,
       Ctime
FROM glob(globs='C:/Users/*/AppData/{Local,Roaming}/**/*.zip',
          accessor='ntfs')
WHERE Mtime > now() - 86400 * 7
  AND Size > 100000
  AND FullPath =~ '(?i)(temp|downloads)'
ORDER BY Mtime DESC

Hardening Script — Enforce MFA and Audit Snowflake Access

The single most effective remediation from this case is enforcing MFA on every human account and network policies on the tenant. The following runs against a Snowflake tenant via SnowSQL (or adapt via the Python connector) to audit exposure and lock down accounts:

Bash / Shell

#!/usr/bin/env bash
# Snowflake tenant hardening audit — run with an ACCOUNTADMIN-context session
# Requires: snowsql configured with an admin connection (itself MFA-protected)
set -euo pipefail

echo "[1/4] Users WITHOUT MFA enabled (human accounts should be zero):"
snowsql -q "SELECT name, login_name, type, disabled, has_mfa, last_success_login
            FROM snowflake.account_usage.users
            WHERE deleted_on IS NULL AND disabled = FALSE AND has_mfa = FALSE
            ORDER BY last_success_login DESC;" -o output_format=tsv

echo "[2/4] Recent successful logins WITHOUT a second factor:"
snowsql -q "SELECT user_name, client_ip, reported_client_type,
                   first_authentication_factor, second_authentication_factor,
                   event_timestamp
            FROM snowflake.account_usage.login_history
            WHERE is_success = 'YES'
              AND (second_authentication_factor IS NULL OR second_authentication_factor = 'NO')
              AND event_timestamp > DATEADD(day, -30, CURRENT_TIMESTAMP())
            ORDER BY event_timestamp DESC;" -o output_format=tsv

echo "[3/4] Large external unloads in the last 30 days (potential exfiltration):"
snowsql -q "SELECT user_name, query_text, rows_produced, rows_written,
                   start_time, client_ip
            FROM snowflake.account_usage.query_history
            WHERE (query_text ILIKE '%copy into%@%' OR query_text ILIKE '%s3://%'
                   OR query_text ILIKE '%azure://%' OR query_text ILIKE '%gcs://%')
              AND start_time > DATEADD(day, -30, CURRENT_TIMESTAMP())
            ORDER BY rows_written DESC NULLS LAST;" -o output_format=tsv

echo "[4/4] Remediation commands (review before executing):"
cat <<'EOF'
-- Enforce MFA enrollment on a specific user:
-- ALTER USER <username> SET MUST_CHANGE_PASSWORD = TRUE;
-- Then require MFA enrollment at next login via account parameter:
-- ALTER ACCOUNT SET ENFORCE_MFA_ON_EXTERNAL_AUTHENTICATION = TRUE;

-- Create/apply a network policy restricting tenant access to corporate egress IPs:
-- CREATE NETWORK POLICY corp_egress ALLOWED_IP_LIST=('203.0.113.0/24','198.51.100.10/32');
-- ALTER ACCOUNT SET NETWORK_POLICY = corp_egress;

-- Disable password-only auth for service accounts in favor of key-pair or OAuth:
-- ALTER USER <svc_account> SET RSA_PUBLIC_KEY='<pubkey>';
-- ALTER USER <svc_account> SET PASSWORD = NULL;
EOF

For the endpoint side, hunt and block stealer delivery vectors (cracked software, malvertising, phishing attachments) and rotate any credential that has ever touched an unmanaged or BYOD device.

Remediation: What to Do This Week

This case has no patch to deploy — it has posture to fix. Prioritized for real-world impact:

Enforce MFA on every cloud data platform account — no exceptions. In Snowflake, verify HAS_MFA = TRUE for all human users, and move service accounts to key-pair authentication or OAuth. This one control would have stopped this campaign cold. Reference: Snowflake Security Best Practices and CISA/FBI joint guidance on the Snowflake campaign.
Apply network policies / IP allowlists to SaaS data tenants so authentication only succeeds from corporate egress ranges or ZTNA brokers. Stolen credentials are worthless if they can't reach the login page from a bulletproof VPS.
Alert on bulk exfiltration primitives. Any COPY INTO to an external stage, first-time use of a new external stage, or single-session row volumes above your baseline should page a human. Volume anomalies in QUERY_HISTORY are your last line of detection before data leaves.
Assume your credentials are already in stealer logs. Subscribe to stealer-log/compromised-credential monitoring (internal threat intel or commercial feeds) for your domains and SaaS account URLs. Force rotation on any hit — the credentials in this case were years old and still valid.
Kill password reuse between corporate and personal systems. The soldier in this case and his co-conspirators exploited exactly this. Conditional access policies should block legacy/basic auth entirely, and phishing-resistant MFA (FIDO2/passkeys) should be the standard for anyone with access to bulk customer data.
For telecom and communications providers specifically: Treat CDR/metadata stores as regulated crown-jewel data. Apply field-level access controls, query-purpose logging, and strict data minimization — AT&T's exposure was compounded by how much historical metadata was retained and reachable from a single compromised account. Review FCC CPNI obligations and your breach-notification runbooks now, not during an incident.
Do not pay extortion demands as a remediation strategy. AT&T's reported payment did not eliminate its regulatory, legal, or reputational exposure — and the perpetrators still ended up in federal court. Invest that money in the controls above.

The Bottom Line

Seventy months in federal prison closes one chapter, but the playbook that breached AT&T and Verizon is now public, proven, and cheap to replicate. Every element of it — infostealer-harvested passwords, MFA-less SaaS tenants, unmonitored bulk queries, external-stage exfiltration — is visible to a competent SOC and preventable with controls that cost a fraction of a single extortion payment. If you take one action from this sentencing, make it this: run the MFA audit on your cloud data platforms today. If you find even one human account without MFA that can reach customer data, you have found your next breach before it happens.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub