A Million Dollar Phone Call

Last September, Stellantis, the automotive giant behind Chrysler, Jeep, Dodge, and Ram, disclosed that hackers had breached their Salesforce instance and stolen 18 million customer records. The attack started with a phone call to an employee who thought they were helping IT support. Salesforce wasn’t the only target that month.

In August 2024, Stoli Group suffered a ransomware attack that disabled its SAP ERP system and encrypted its entire accounting and financial systems.e The attack forced most internal processes, including accounting functions, into manual entry mode, with systems not expected to be fully restored until at least Q1 2025. The cyberattack prevented the U.S. subsidiaries from complying with their lenders’ reporting requirements, contributing to Stoli Group USA and Kentucky Owl filing for Chapter 11 bankruptcy on November 29, 2024, with approximately $84 million in debt.

Scattered Spider used LinkedIn to identify an MGM Resorts employee, impersonated them, and called the MGM IT help desk. The phone call lasted ten minutes, during which the attackers gained administrator privileges to MGM’s Okta and Azure tenant environments. ALPHV deployed ransomware to more than 100 ESXi hypervisors across MGM’s network, disrupting reservation systems, digital room keys, and slot machines. MGM faced approximately $100 million in damages during the third quarter of 2023.

The caller was professional, patient, and knew … things. They knew the company’s organizational structure. They understood the development workflow from engineering blog posts. They referenced recent infrastructure changes mentioned in release notes. When they asked the employee to help verify a data backup tool, explaining that this was standard procedure for their audit compliance, the diligent employee was eager to help. Ten minutes later, customer data, including names, email addresses, phone numbers, and vehicle information, was on its way to servers controlled by attackers who would later identify themselves as ShinyHunters.

This is UNC6040, aka ShinyHunters, and they could very well be systematically targeting companies like yours.

Understanding the Threat

The Mandiant and Google Threat Intelligence teams have been tracking UNC6040 (see The Cost of a Call) for months now, watching them destroy mid-market companies with nothing more than a telephone and a convincing story. Their methodology is simple and effective.

It starts with some research. They study your company: LinkedIn profiles reveal your organizational structure, job postings explain your tech stack and challenges, company blogs describe your infrastructure, and GitHub profiles show your developers’ work patterns. Your website and press release show what you’re up to, your employees are proud of their technology and systems skills, and marketing tools explain who reports to whom. They study how you communicate. And when they call, they sound like colleagues.

For software companies, they target GitHub and cloud console access. They research your repositories, recent commits, and deployment patterns. They identify developers who recently joined or work remotely. When they call claiming to be that developer locked out during a critical production incident, they create urgency that bypasses verification procedures.

For manufacturing companies, they focus on ERP systems like SAP. They study your supply chain from press releases, understand your fiscal calendar from SEC filings, and learn your operational terminology from job descriptions. They call during quarter-end or month-end close when finance teams are overwhelmed, claiming they need urgent access to complete critical reports.

Calls follow a pattern that’s been refined through hundreds of successful attacks. They create urgency without suspicion. Perhaps there’s a security audit, a critical update, or a compliance requirement.

The timeline is always tight but not unreasonably so. They guide victims to authorization pages they’ve carefully studied: GitHub’s OAuth app approval screen, AWS IAM role creation, SAP’s user management interface. Once authorization happens, automated scripts begin extracting everything. For GitHub, they clone all repositories. For SAP, they export financial data, customer records, and supplier information. For cloud consoles, they snapshot databases and download backups. Extractions are completed in less than an hour, faster than your incident response procedures can truly respond.

Months later, when the ransom demand arrives, the attackers often claim affiliation with “ShinyHunters” to add credibility to their threats. By then, your data has been thoroughly analyzed and prepared for sale or release on dark web markets if you don’t pay.

An Identity Crisis Nobody Wants to Discuss

Here’s what happens at most companies when someone calls the help desk claiming they’re locked out:

1. The help desk asks for their employee ID, which they don’t have because they claim to be traveling.
2. They provide their manager’s name, which is on LinkedIn.
3. They offer the last four digits of their social security number, information that’s been leaked in dozens of data breaches over the past decade.
4. Then the help desk resets their password and disables MFA “temporarily.”

Your help desk should operate under one inflexible rule: Never reset passwords or multi-factor authentication over the phone without impeccable verification assurance. No exceptions. Not for the VP of Product who’s traveling. Not for the developer who claims a production outage depends on their access.

Instead, send a reset link to their registered corporate email. If they claim their email is inaccessible, require a video call where they show their face and government-issued ID. If they’re in the office, they walk to IT in person. These are minimum viable defenses against this kind of social engineering. When there’s such precedent, it’s not paranoia.

The same principle applies to vendor support. When someone calls claiming to be from GitHub, AWS, SAP, or your managed service provider, thank them politely and tell them you’ll call them right back. Look up the official support number yourself. Not the number they provided, not the number in the email they sent, but the number from your official documentation or the vendor’s verified website. Call back through those official channels.

The Geography of Compromise

If your business operates exclusively in the United States, why can someone in Moldova access your SAP system? Or Vietnam? Or any of the dozens of countries where you have no employees, no customers, and no business interests?

Virtually every platform you use has geographic restriction capabilities. In GitHub Enterprise, it’s IP allow lists at the organization level. In AWS, it’s in IAM conditions and resource-based policies. In SAP, it’s through network access configuration and security policies. In Microsoft 365, it’s in Conditional Access policies. In Google Workspace, it’s Context-Aware Access. These features are included in your enterprise licenses, but need to be configured.

The configuration takes thirty minutes. Navigate to your security settings, add your country, maybe add one or two others if you have international travelers, and block everything else. No, it’s not infallible, but it immediately eliminates vast swaths of the internet from which attacks could originate, forcing the use of VPNs, proxies or other compromised assets - driving up attacker effort and detection risk.

Permission Problems

Walk into most mid-market software companies and ask how many people have organization owner access in GitHub. They can usually name them. Then ask how many people can create OAuth apps with full repository access, and they’re uncertain. Ask how many service accounts exist with admin tokens, and they start to get concerned. Ask how they can rotate those tokens, and you’ve started to keep them up at night.

This is how breaches happen.

Attackers gain access through users who had far more permissions than their jobs required. The receptionist who could see all customer financial data. The developer who kept org owner access after changing roles. The contractor whose admin rights were never revoked. The CI/CD service account with a hard-coded token in a public repository’s Git history from three years ago. Or legitimate automation accounts with access tokens exposed on an internal repository accessible to all employees (compromised accounts).

GitHub Access Hygiene

Start with organization owner access—you need two or three people for redundancy, not ten. Everyone else gets specific permissions through teams.

Review the OAuth applications authorized in your organization. Unused apps like “GitBackup”? Remove. Deployment tools replaced years ago but still with full repository access? Revoke. Require documented justification and reviews for all OAuth apps.

Audit personal access tokens. GitHub Enterprise shows you every token and its permissions. Revoke tokens unused in 90 days. Tokens with admin scope need documented justification.

Service accounts present the highest risk. Every CI/CD pipeline and automated workflow should use fine-grained personal access tokens with minimum permissions and expiration dates. An anti-pattern ripe for abuse: a single service account with org owner access and a token that never expires.

GitHub Monitoring

Your GitHub Enterprise audit logs are included in your license. Someone should monitor them daily, at the very least manually for small organizations, through automated alerting for larger ones.

Watch for new OAuth applications with repository access, organization permission changes, repository cloning at scale, off-hours access from anomalous locations, and personal access token creation with admin scope. Check out Panther’s open source rules for good ideas here.

GitHub Advanced Security includes secret scanning and push protection.

Go into your Salesforce setup and look at each profile. Uncheck “API Enabled” for everyone except the one or two people who legitimately need to run data exports. Create a permission set called “API Users” and document why each person has it.

SAP Access Control

In many SAP implementations, too many people have excessive permissions without business justification. A procurement manager who can modify financial master data, a plant manager accessing all company codes, and maybe a financial analyst approving their own journal entries.

SAP’s authorization model is complex, but the segregation of duties principle is straightforward. No single user creates and approves transactions. No one has unrestricted authorization administration access unless that’s their specific role. Users shouldn’t retain full access after role changes.

Start with the group which controls user and authorization administration (S_USER_GRP). Only a very small handful, need this authorization. Everyone else should have it explicitly restricted.

Review who can move code between your SAP systems or configure how your systems connect to each other (STMS and SM59). These capabilities let attackers map your environment, jump from one system to another, and locate where sensitive data is stored.

Audit who can run extraction transactions like SE16 (Data Browser). These allow direct database table access and bulk exports. Most organizations need only a handful of people with these capabilities.

Service accounts present the biggest risk. System accounts with SAP_ALL (unrestricted access) are breaches waiting to happen, yet they’re surprisingly common in mid-market implementations.

SAP Security Monitoring

SAP maintains comprehensive audit logs through the Security Audit Log (transactions SM20/SM19), but who is reviewing it systematically?

Configure alerts for privileged transaction execution, user administration changes, RFC destination modifications, direct database table access, and impossible travel patterns (California to Eastern Europe in 30 minutes means compromised credentials or undocumented VPN use).

One organization company implemented basic audit log monitoring and discovered a contractor’s account accessing financial tables when the contractor hadn’t been working - their credentials had been compromised at a different company. Audit logs identify these things.

For organizations with compliance requirements (SOC 2, ISO 27001, CMMC), SAP’s GRC modules provide sophisticated monitoring and segregation of duties enforcement. These aren’t cheap, but for regulated industries, they’re necessary rather than optional.

Cloud Console Monitoring

Software companies running on AWS, Azure, or GCP face similar risks. Every cloud provider offers audit logging (CloudTrail, Activity Log, Cloud Audit Logs). Monitor console logins from unexpected locations, privilege escalation, and database access patterns from new IP addresses.

One software company discovered their breach when CloudTrail logs showed an administrative account creating production database snapshots when it had never done so before, then transferring them to an unused region. They were monitoring CloudTrail primarily for SOC 2 compliance, and that requirement saved them from significant data loss.

Watching Without Spending Millions

Every security vendor wants to sell you their AI-powered, machine-learning-enhanced, next-generation threat detection platform. What you really need is to pay attention to the obvious signs that are ignored.

Your Salesforce instance maintains login history for every user. It’s free, it’s built-in. Every day, a vibe-coded tool should review that history. Sort by IP address and look for VPN providers or shady VPS IP blocks. Check for logins from countries where you don’t do business. Look for users accessing the system in the middle of the night.

These aren’t sophisticated detection techniques, but they’re common sense. Please note that the credentials used in that vibe-coded tool should be vaulted rather than hard-coded. That was precisely how one of our recent Red Team clients ’ Salesforce instances had its data leaked.

If you have a budget for monitoring, start with Salesforce Event Monitoring, which, while it isn’t cheap, gives you visibility into API usage, report exports, and bulk data operations. You don’t need complex correlation rules or a security operations center.

You can watch for a few things:

• impossible travel (same user, two distant locations, insufficient time)
• mass exports (anyone downloading more than 1,000s of records)
• newly connected apps (especially ones with words like “Data,” “Export,” or “Backup” in their names).

One company discovered they’d been breached when they noticed an integration account had exported thousands of records from a never-before-seen EC2 IP address using SOQL database queries.

Making It Stick

Technical controls fail when people don’t understand why they matter. Your employees want to be helpful. When someone calls with a problem, their instinct is to solve it. This helpfulness, this fundamental decency, is what attackers exploit.

The solution isn’t to make your employees suspicious of everyone or stop all productivity. But rather to give them clear, simple rules that protect both them and the company.

“We never reset passwords over the phone, it’s for your protection and ours.”

“We verify all vendor requests independently” is professional due diligence.

Every month, share a five-minute security story at your all-hands meeting. No one cares about policy documents or sets of rules. But stories stick. “Last month, a company like ours lost millions of personal records because someone thought they were helping IT support.” Make it real, relevant, and memorable.

Create a culture where verifying requests is normal and questioning urgency is encouraged.

The Sad Truth

UNC6040 isn’t sophisticated. They don’t use zero-days, advanced persistent threats, or any of the sexy attack vectors that security vendors build products around. They use the telephone, social engineering, and the unfortunate reality that most companies have poor identity verification processes.

Your defense requires changing behaviors, implementing controls you already own, and accepting that security sometimes means making things slightly less convenient when the impacts are large.

You will be targeted. The question is whether you’ll be ready. Whether your help desk will verify the caller’s identity. Whether your employees will recognize the urgency as manipulation. Whether your logs will show the attack in time to respond.

UNC6040 is out there right now, researching their next target. They’re looking at LinkedIn profiles, reading press releases, mand apping out organizational structures. They’re preparing their scripts, testing their tools, refining their approach.

The question that matters is simple: When they call your company, will you be ready?

‍

Adversis helps technology leaders and high-tech software and manufacturing companies build practical defenses against real-world attacks. We find vulnerabilities before attackers exploit them, accelerate compliance journeys, and translate security investments into measurable business outcomes. If you need help assessing your exposure to vishing attacks or implementing the controls discussed in this article, let’s talk.