Could Your SSO Security Be the Weak Link? What Abbott’s Two Cyber Incident Probes Mean for You

SSO is supposed to make access cleaner. One login. Fewer passwords. Less friction. The problem: one good login is also one great target. Abbott is now probing two separate extortion-linked incident claims—one tied to a vishing-led compromise of a Microsoft Entra SSO account and limited access to legacy systems in its Cancer Diagnostics business, and another tied to its externally hosted LabCentral portal, where a threat actor claims they used compromised customer credentials and API endpoints to pull files. Abbott says operations weren’t impacted and disputes how sensitive the LabCentral data was, but the pattern is the point: attackers are aiming at identity and access paths because that’s where the doors are.

What Abbott’s two probes signal: identity is the new perimeter (and extortion loves it)

Abbott’s two separate incident probes are a clean snapshot of where attackers are putting their time: SSO identities and externally facing portals. Not because they’re flashy, but because they’re efficient.

Probe #1: vishing → Microsoft Entra SSO compromise → limited legacy access

One claim tied to the ShinyHunters extortion group starts with a basic tactic: vishing (voice phishing). ShinyHunters told BleepingComputer the access began after a vishing campaign targeting multiple Abbott employees in mid-June, leading to a compromised Microsoft Entra single sign-on (SSO) account and access to internal systems .

Abbott’s public position is also important: it said it’s investigating unauthorized access to a limited number of internal systems in its Cancer Diagnostics business, and that this did not impact operations, manufacturing, lab operations, or patient service . Abbott also stated the impacted legacy Exact Sciences systems are separate from Abbott’s other systems .

Two things can be true at once:

• The blast radius might be limited today
• The entry path (SSO + social engineering) is the same one that can scale fast in other environments

Probe #2: LabCentral portal → compromised customer credentials → API endpoint file pulls

The second claim came from a threat actor called ShadowByt3$, who said they accessed Abbott’s Core Laboratory diagnostics business through the LabCentral customer portal using compromised customer credentials, then slowly exfiltrated files by targeting API endpoints .

Abbott disputed the attacker’s framing, saying LabCentral is an externally facing, third-party hosted portal that stores publicly available technical product reference documents (manuals, troubleshooting checklists, specs) and does not contain proprietary/sensitive customer or business information . Still, the attacker saw enough “value” to attempt extortion—because extortion isn’t always about secrets. Sometimes it’s about pressure.

Why extortion groups love SSO and portals

Extortion groups don’t need to “hack” encryption when they can borrow trust.

SSO (Microsoft Entra / Okta / Google) is a trust engine. Once an attacker gets into a corporate SSO account, they can often pivot into connected SaaS apps and pull data through normal-looking paths. ShinyHunters has been linked to campaigns targeting Entra/Okta/Google SSO accounts, and after SSO access, they commonly steal data from connected platforms like Microsoft 365 and many other SaaS services .

Customer portals are quiet data pipes. If a portal allows credential-based access and has APIs built for convenient downloads, an attacker doesn’t need malware. They just need:

• a working login (often from credential reuse)
• endpoints that return files
• weak monitoring that treats bulk downloads as “normal customer activity”

The pattern across both probes is the point: identity and access paths are the doors. Extortion groups go where the doors already open.

How SSO gets cracked in real life: the vishing playbook (and why smart people still fall for it)

When an SSO account gets compromised, a lot of teams jump straight to “Was Entra hacked?” Most of the time, SSO isn’t broken. The workflow around it is.

In Abbott’s case, the threat actor claimed access came from a vishing attack that targeted several employees, and that it ended with a compromised Microsoft Entra single sign-on (SSO) account . That sequence is painfully normal in 2026.

The vishing chain (how it usually goes)

This is what “real life” tends to look like:

1. Pretext + credibility: The caller pretends to be IT/helpdesk, a Microsoft contractor, or a security vendor. They’ll name-drop tools people already use (Entra, Microsoft 365, ServiceNow).
2. Urgency: “We’re seeing active sign-in risk,” “your account is about to be locked,” “we need to stop a breach right now.”
3. A single ask that sounds harmless:

• “Read me the code you just received.”
• “Approve the MFA prompt so we can complete the security check.”
• “We need you to register a new MFA method because the old one failed.”

4. The pivot: Once the attacker has a working session, token, or MFA approval, they ride SSO into connected apps. ShinyHunters has been tied to campaigns like this, and after corporate SSO access, they typically go after connected SaaS data .

Smart people fall for this because it doesn’t feel like “clicking a sketchy link.” It feels like cooperating with IT under time pressure.

Controls that actually shrink the blast radius (Microsoft Entra-focused)

You’re trying to make vishing “expensive” for the attacker, even if a user has a bad moment.

1. Use phishing-resistant MFA where it counts

Target admin accounts and high-risk roles first.

• FIDO2 security keys / passkeys (best option for stopping OTP read-outs)
• Certificate-based auth for managed devices (where it fits)
• Reduce reliance on push approvals that can be socially engineered

2. Lock sign-ins behind Conditional Access

The goal: even with the right password, the attacker can’t get a clean session.

• Require managed/compliant devices for sensitive apps
• Use risk-based sign-in policies (user risk, sign-in risk)
• Block or tightly gate logins from impossible locations, unfamiliar devices, or suspicious networks

3. Harden admin roles (because extortion groups love “easy escalation”)

• Separate daily user and admin accounts
• Time-bound elevation (PIM-style workflows)
• Alert on new MFA method registration and role assignments

4. Put guardrails on sessions and tokens

Attackers don’t need your password if they can keep a token alive.

• Shorten session lifetime for high-risk apps
• Re-authentication for sensitive actions (downloads, exports, admin changes)
• Watch for patterns that look like “token replay”: rapid access across apps, odd IP shifts, abnormal user agents

A micro-script employees can use when the phone rings

Give people something simple they can repeat without thinking:

• “What’s your ticket number and department?”
• “I’m going to call back using the number in our internal directory, not the one you gave me.”
• “I won’t approve any MFA prompt or read any code on a phone call.”
• “If this is urgent, email the request from your corporate address and I’ll route it to IT Security.”

That’s not paranoia. It’s how you break the attacker’s momentum—because vishing works best when your people feel rushed, alone, and responsible for fixing the problem right now.

Your ‘connected SaaS’ problem: once SSO is in, attackers go shopping

Once an attacker gets a valid corporate SSO session, the scary part isn’t the login. It’s what that login quietly unlocks.

ShinyHunters has a track record of going after Entra/Okta/Google SSO accounts, and after they get in, they typically steal data from connected SaaS applications—think Microsoft 365, Salesforce, Google Workspace, Slack, Zendesk, Dropbox, and more . In the Abbott-related claim, the threat actor specifically pointed to data sources that sound like a normal enterprise stack: Microsoft Entra, ServiceNow, SharePoint, Databricks, and Coupa .

That’s the “connected SaaS” problem in one line: SSO turns one compromised identity into many familiar-looking logins, and defenders drown in “but it’s the right user” noise.

What “shopping” looks like (and why it blends in)

Attackers usually don’t smash windows. They use front doors:

• Microsoft 365 / SharePoint: search, browse, download, export—like any employee would
• ServiceNow: pull tickets, user info, internal notes, attachments
• Data platforms (Databricks, etc.): grab datasets, notebooks, configs
• Procurement/finance apps (Coupa, etc.): contracts, vendor data, approvals

If your detections only look for malware, you’ll miss it.

High-signal alerts to set up in Microsoft Entra (SSO logging that matters)

You want alerts that answer: “Is this person suddenly acting like an attacker?”

Prioritize signals like:

• New device sign-in for a user who normally signs in from 1–2 endpoints
• New MFA method added or MFA reset events (especially outside business hours)
• Conditional Access changes and policy exclusions (even “temporary” ones)
• OAuth app consent grants (a sneaky persistence move): new enterprise app added, new delegated permissions granted, unusual scopes like mail/file access
• Unusual token/session patterns: rapid access across many apps, sign-ins from new geos, impossible travel flags

Containment moves that cut the blast radius fast

If someone reports a suspicious call, treat it like a live incident. Don’t wait for proof of exfil.

Do this immediately:

• Revoke active sessions / tokens for the user (and any privileged accounts touched)
• Force MFA re-registration if there’s any chance the attacker got into the factor setup
• Review app consent and remove any unfamiliar OAuth grants
• Pull a quick access list: “What SaaS apps did this identity touch in the last 24–72 hours?”

Make “SSO access” less powerful by default

This is boring, but it works.

Least privilege everywhere

• Remove standing admin rights
• Reduce “can export” and “can download all” roles in SaaS apps

App consent restrictions

• Don’t let users approve high-risk OAuth permissions casually
• Require admin approval for sensitive scopes

Rapid access reviews

• After any social-engineering report, run a short, repeatable review: sign-ins, MFA events, OAuth grants, and SaaS audit logs (especially SharePoint and ServiceNow)

The goal isn’t perfection. It’s making “one stolen SSO login” a small incident, not a company-wide data shopping spree.

Customer portals and APIs: the quiet exfiltration route you’re probably under-watching

SSO compromise is loud in the org chart. Customer portal compromise is quiet in the logs. And that’s why it works.

In Abbott’s second probe, the threat actor claimed they got into the LabCentral customer portal using compromised customer credentials, then slowly exfiltrated files by targeting API endpoints . Abbott pushed back on the “sensitive data” angle, saying LabCentral is an externally facing third-party hosted portal and the content is publicly available technical product reference documents (manuals, troubleshooting checklists, specs), not proprietary or sensitive customer/business data .

That detail matters, but not in the way most teams think. Attackers can still use “we took your files” as leverage even if the files are mundane. The bigger lesson is the mechanics: valid customer creds + predictable APIs = a download pipeline that can look like normal usage until it’s too late.

Why portal/API exfiltration blends in

Portals are built for self-service. APIs are built for automation. Both are built to be used.

• “Slow and steady” downloads don’t spike alarms.
• API pulls can look cleaner than browser scraping.
• A single compromised customer login can be used for weeks if you don’t have strong anomaly detection.

Portal hardening that actually moves the needle

Skip the vague advice. Focus on controls that stop credential-driven abuse and limit what a stolen login can do.

1. Strong customer authentication (where you can)

• Add MFA for customer accounts at least for high-risk actions (bulk download, admin changes, adding users).
• Use step-up auth when behavior shifts (new device, new geo, high-volume activity).

2. Credential stuffing defenses (because “compromised creds” rarely come from nowhere)

Treat your portal like it’s under constant bot pressure:

• Rate-limit login attempts by IP + account + device fingerprint
• Add bot protection / WAF rules tuned for login and token endpoints
• Monitor for password spray patterns (many accounts, same password) vs brute force (one account, many passwords)

3. Make API access less abusable by design

If your portal has file download endpoints, assume they’ll be enumerated.

• Issue scoped API tokens (least privilege for endpoints and data types)
• Use short-lived tokens and rotate refresh tokens
• Require server-side authorization checks on every download (don’t trust the client)

4. Put hard limits on “normal”

Attackers love APIs because they can go endpoint-by-endpoint like a catalog.

• Rate limits per user, per token, per endpoint (especially file and search endpoints)
• Download caps (files/hour, MB/day) with an exception process for legitimate heavy users
• Pagination limits to reduce crawling

5. Anomaly detection that’s specific to exfil

Generic “security monitoring” won’t catch slow API pulls. Look for these signals:

• Download spikes relative to the account’s baseline
• High frequency of 404/403 responses (endpoint probing)
• Unusual sequences like: search → list → download repeated thousands of times (“endpoint crawling”)
• New device + new geo + high download volume in the same session

6. Tighten data classification so “public docs” are truly public

Abbott’s point was that the portal content was public and not sensitive . If that’s your stance too, prove it operationally:

• Separate truly public documents onto a public CDN with no login
• Keep authenticated portals for content that actually needs access control
• Tag files with classification and enforce policy at download time (not in a spreadsheet)

Customer portals and APIs tend to sit outside the core identity stack, outside the SOC’s daily muscle memory, and sometimes outside the company’s hosting environment. That combo is exactly what makes them such a clean exfil path.

A tight response checklist: what to do this week (and what to measure next month)

When extortion is on the table, speed matters. Abbott’s public response hits the standard playbook: activate incident response, bring in cybersecurity experts, notify law enforcement . You want that same muscle memory—without improvising at 2 a.m.

This week: containment and clarity (fast, boring, effective)

Goal: cut off access, preserve evidence, and figure out what the attacker could touch.

1. Lock down identity first (Microsoft Entra / SSO)

• Revoke active sessions for suspected users and admins (assume tokens are live).
• Reset MFA for impacted accounts (re-register stronger factors where possible).
• Disable suspicious accounts and block sign-ins from risky locations until you have signal.
• Pull Entra logs for:
• new device sign-ins
• MFA method additions/resets
• Conditional Access policy changes
• Enterprise app changes and suspicious OAuth consent grants

2. Triage connected SaaS access like it’s a crime scene

The attacker claim around Abbott referenced common enterprise systems (Entra + apps like ServiceNow/SharePoint/etc.) . Whether or not you believe the list, your review should be systematic:

• Identify the top 10 SaaS apps tied to SSO.
• For each, pull the last 7–14 days of audit events for the impacted identities:
• mass download/export
• permission changes
• new API tokens / integrations
• new mailbox rules / forwarding (for email suites)

3. Check third-party hosted portals and customer-facing surfaces

Abbott described LabCentral as an externally facing third-party hosted portal . That’s common—and it’s exactly why it needs an explicit checklist.

• Confirm who can access logs (you, the vendor, or both).
• Force password resets for affected customer accounts if there’s credible credential compromise.
• Audit portal/API access for:
• abnormal download volume per account
• new IPs/ASNs
• repeated endpoint enumeration (lots of 404/403)
• Validate what data is actually stored there. Abbott said its portal held public technical docs and not sensitive business/customer info . Don’t assume. Verify.

4. Communications: reduce noise, increase reporting

• Tell employees exactly what to report: suspicious calls, MFA prompts they didn’t trigger, “IT” requests that feel off.
• Give them one channel (ticket + hotline) and one rule: report fast, no shame.

Next 30 days: fixes that prevent the repeat

Goal: reduce your chance of another SSO/portal-driven extortion attempt and make detection less optional.

1. Run a vishing tabletop that includes your helpdesk

Keep it realistic:

• A user reports a weird call.
• Then you discover a suspicious Entra sign-in.
• Then you see abnormal downloads in a SaaS app.

Measure:

• time to revoke sessions
• time to identify impacted apps
• time to produce an executive summary you’d stand behind

2. Tune Conditional Access with an “identity is the perimeter” mindset

• Require managed devices for high-value apps.
• Tighten admin access paths.
• Remove exceptions that exist only because “it broke one workflow last year.”

3. Build portal + API telemetry baselines (so “slow exfil” isn’t invisible)

For every customer portal and major API:

• baseline normal downloads per account/day
• baseline top endpoints and request rates
• baseline geo/device patterns for key accounts

Then alert on deviations, not raw counts.

4. Shrink your exposure to convincing vishing in the first place

A lot of vishing starts with personal data an attacker can stitch together from vendor accounts, conference lists, and old sign-ups.

If your team signs up for lots of external tools and portals, it can help to use Cloaked identities—masked emails and phone numbers—so employees aren’t spreading their real contact details everywhere. It’s not a “security tool” replacement; it’s just fewer breadcrumbs for attackers to build believable calls and fewer real inboxes/phone numbers getting hammered.

What to measure next month:

• % of privileged users on phishing-resistant MFA
• of risky OAuth consent grants blocked/reviewed
• mean time to revoke sessions after a social-engineering report
• portal/API anomaly alerts that are high-signal (and not 500 false positives a day)

‍