This week, CSO Online published a rundown of 14 ways attackers are abusing cloud services to break into enterprises. The theme is a shift security teams can no longer ignore: attackers have moved from “living off the land,” abusing tools already on your systems, to “living off the cloud,” abusing the trusted SaaS platforms, cloud APIs and identity systems your business runs on every day.
Read the list closely and a pattern emerges. Many of these attacks don’t start with an exploit at all. They start when someone presents a valid credential or token, and the system believes them.
The pattern behind the headlines
Consider a few of the incidents the article describes:
- Veradigm. Attackers used a third-party vendor’s credentials to reach patient data, including some Social Security numbers. The company says the impact was limited, but the path in was simple: a trusted identity with a route to sensitive data.
- Murky Panda. According to CrowdStrike, this China-nexus group compromised upstream IT service providers, then moved quietly into those providers’ customers through trusted connections between their Microsoft cloud identity environments.
- Stryker. Attackers reportedly gained access to Microsoft Intune, the cloud service the company used to manage employee laptops and phones, and remotely wiped thousands of employee devices. The disruption reached hospitals, which had to reschedule some surgical procedures.
- Phishing on trusted infrastructure. Phishing kits now run on legitimate developer platforms, and APT29 has sent victims through genuine Microsoft login pages. There is no suspicious domain to catch.
In every case, the attacker didn’t have to break anything. They presented something the environment already trusted, and the environment let them in.
We’ve seen this movie before
I’ve worked in IT since 1985, and this pattern is older than the cloud. Mainframe passwords, VPN credentials, SSO tokens: each generation of access technology made a credential the key, and whoever held the key was trusted. The cloud didn’t create the problem. It multiplied the number of doors that open with a single key, and it made the traffic behind those doors look like normal business.
The lesson hasn’t changed. When one credential is treated as proof of identity, stealing that credential is all an attacker needs.
A credential is evidence, not proof
Total Access Control (TAC) takes a different approach. A username and password, even with MFA, is treated as one piece of evidence, not the whole case. TAC can bind multiple factors of authentication into every session, configured by each customer to fit their environment:
- Credentials and MFA
- Device validation, confirming the session comes from a known, approved device
- Registry entries and secret files that exist only on legitimate endpoints
- Other unique, customer-defined markers
Bound together, these factors change the math for an attacker. Credentials harvested in a breach, phished from a user or bought from an initial access broker don’t create an immediate opening. Without the validated device and the markers that live on it, the login doesn’t complete.
Just as important, most of these factors work behind the scenes. Users don’t see extra prompts or juggle more codes. Security goes up without adding friction or feeding the MFA fatigue that attackers exploit.
Where the access decision is made matters
Strong authentication only protects what sits behind it, so architecture matters as much as features.
Organizations get the most protection when TAC is the front door. In that model, every session passes through TAC first, and TAC evaluates all of the configured factors before the user reaches any application or cloud service. If TAC protects only some applications, sessions that go directly to other services never pass through those checks.
An example of this is Microsoft 365, the cloud service many organizations use for email, documents and collaboration. Users typically sign in to Microsoft 365 directly, with their usernames and passwords verified by Microsoft Entra ID, Microsoft’s cloud identity service. With TAC as the front door, that sign-in is redirected from Microsoft to TAC. TAC sees the session first and checks the device, its markers and every other configured factor before the user ever reaches Microsoft 365. User accounts can stay in Entra ID; TAC simply decides who gets through.
Some organizations instead let users sign in to Microsoft 365 directly and use TAC to protect specific applications. Those applications are still protected, but Microsoft 365 sessions don’t pass through TAC’s checks. If credential theft and token abuse are on your risk list, and after this article they should be, it’s worth reviewing where your access decisions are actually made.
There’s a second benefit. Applications behind TAC aren’t exposed to the internet. The article describes attackers spinning up thousands of short-lived cloud functions to scan networks from high-reputation IP addresses that firewalls can’t block. Blocklists don’t matter when there’s nothing exposed to find.
What this does and doesn’t solve
Not every technique in the article is an access problem. Malware that hides its command channel in Google Sheets or AI APIs, data exfiltration through Slack or Discord, and attacks on cloud metadata services and snapshots call for endpoint, egress and cloud posture controls. And if an attacker is already running on a legitimate user’s device, device-based factors are present by definition. Defense in depth still applies.
But a large share of these attacks begin with an identity the environment trusts too easily. That part is solvable, and it’s where attackers get the most leverage for the least effort.
Questions to ask about your environment
- If a vendor’s credentials leaked today, what else would an attacker need to get in?
- Which applications can be reached with a username, password and MFA alone?
- Where is the access decision made: before users reach your applications and cloud services, or after?
- Do your additional authentication factors add security without adding friction for users?
If those answers aren’t comfortable, let’s talk. PortSys has been helping organizations control access since 2008, and we’re happy to walk through how TAC would fit your architecture.