Credential and session abuse

A valid identity is the best disguise there is. Once an attacker has a password, session cookie, API key, or OAuth token, they come in the same way employees do. The preventive controls see a successful login and move on. And yet, there’s no malware involved at all. No attachment, no dropped executable, no exploit, no sketchy C2 domain. The attacker uses an approved app, and everything afterward runs through services the company already trusts.

What you see instead is a change in behavior. A privileged account starts working from a machine it has never used. An account that’s been quiet for months wakes up and heads straight for sensitive systems. Someone grants consent to an app nobody else in the company uses. Or a help desk password reset is followed, minutes later, by mailbox access and a role change.

Sessions and tokens remain a blind spot for many security teams. Resetting a password closes one door, while stolen cookies and refresh tokens keep working. If you see activity after remediation, especially from a new device or in apps the user rarely opens, assume the attacker still has a way in.

Location data is much less useful than it used to be. Attackers route through residential proxies or rent infrastructure close to the victim, so a login from the expected country can still be hostile. Meanwhile, cloud providers sometimes authenticate through other regions and trigger impossible-travel alerts over nothing. Device history, authentication method, token use, and what happens after login are much better evidence.

And a login is just the starting point. MFA resets, new device registrations, OAuth grants, conditional-access changes, mailbox rules, and directory role assignments tend to show the setup and follow-through that a login alert misses. When several land close together, valid credentials are not a reason to relax.

Native tools create ready-made camouflage

Windows ships with nearly everything an attacker needs for an entire intrusion. PowerShell, WMI, RDP, MSBuild, rundll32, regsvr32, certutil, scheduled tasks, service control. These tools all have legitimate uses. All of them can also run code, fetch payloads, set up persistence, pull credentials, move laterally, and switch off security controls. You can’t block them without breaking things, and you can’t alert on every run without drowning your analysts. The value as signals comes from context: what launched them, the command line, the user, where they ran from, where they connected to, and what else was going on.

PowerShell is the classic example. When your automation platform launches it, you usually know the script, the arguments, the signer, and the destination. When a Word document launches it, you might see an encoded command, a connection to a domain registered last week, files written to a temp folder, and a new scheduled task. It’s the same binary telling two very different stories.

Parent-child relationships are one of the best ways to separate the stories. Office apps have little reason to spawn script interpreters, and web servers shouldn’t be starting command shells, and a database server launching a credential dumper is about as bad as it looks. A chain from wscript.exe to PowerShell to MSBuild can reveal staged execution even when Microsoft signed every file in it.

Command lines and paths come next. Hidden windows, execution-policy bypasses, encoded strings, long obfuscated arguments, odd download methods, and execution from user-writable folders all push risk up. Some legitimate management tools do these things too, though, so treat them as evidence and not as a verdict.

Trusted services provide cover

Businesses run on cloud storage, collaboration tools, CDNs, code repositories, remote access products, and tunneling services. Attackers like them for the same reasons everyone else does: they’re reliable, encrypted, and they come with spotless domain reputations.

Traffic to major cloud services  can bypass reputation-only controls. TLS hides what’s inside, and nobody is going to block Microsoft or Google company-wide. For an attacker, that’s a dependable channel for payloads, command and control, or exfiltration that looks like ordinary cloud use.

Defenders pull it apart using the right context. One team might live in Dropbox while another never touches it. A small download from a known corporate folder may be fine, but a scripted request to a brand-new shared link, followed immediately by PowerShell, isn’t. Developers hit GitHub constantly. A domain controller repeatedly pulling raw files from GitHub is very hard to explain.

Tunneling and remote access follow the same logic. Cloudflare traffic is everywhere. A new tunnel from a server that has never used one could be someone trying to get around your inbound controls. And a sanctioned remote support tool is fine when the help desk launches it, but a standard user installing it right after an odd login is a different situation.

Cloud and SaaS logs can show first-time service use, logins to unfamiliar tenants, new OAuth grants, large transfers, rapid file enumeration, and admin changes from unmanaged devices. They can also catch tokens that survive account cleanup and integrations that went around the normal approval process.

Low-and-slow attack activity

Plenty of detection rules only look back a few minutes. They check an event, count what happened recently, and fire when a threshold is crossed. An attacker who knows that just slows down.

They run a few directory queries, wait a few hours, look at one server, and come back tomorrow. They grant themselves new privileges and don’t use them for days. They move data out in small batches. They plant persistence and leave it alone until they need it.

Catching this takes enough history to reconstruct a long sequence. Analysts need to follow one identity across devices, tie cloud sessions to processes on endpoints, tell service-account automation from a human at a keyboard, and review rare behavior over weeks.

Keeping logs longer doesn’t solve it on its own, since the data has to agree on who and what it’s describing. A single employee might appear as an email address, a directory account, a cloud identity, and an endpoint user. A single server might show up under a hostname, an IP, a cloud instance ID, and an agent ID.

Normalize those records, and you can see that a VPN login, a SaaS session, a PowerShell process, and a privileged directory change are all the same person. Skip that step, and the intrusion stays in pieces that don’t seem connected.

Correlating identity, endpoint and network signals

Higher-confidence detections often combine an unusual login, suspicious endpoint activity, a rare network destination, and access to sensitive data. User history and peer behavior will tell you how rare something is. Threat intelligence can add known infrastructure or techniques. Timing helps you separate a real attack chain from coincidence.

Indicators of compromise are important during an active campaign, but domains, IPs, and hashes change fast. Behavioral detections last longer because attackers can’t skip the fundamentals. They still have to run code, stay in, get credentials, move around, talk to the outside, and get to the data.

The Securonix Threat Labs 2025 annual analysis identified recurring late-stage signals across different intrusion types. Bulk outbound transfers, shadow-copy deletion, event-log clearing, mass file changes, and the use of common transfer tools frequently appeared before ransomware deployment or data extortion.

Shadow-copy deletion on a server is concerning, and the risk rises sharply when it follows privilege escalation, security-tool tampering, remote service creation, and outbound data transfer. Correlation gives analysts enough evidence to act without waiting for encryption or public disclosure of a new malware family.

Building useful behavioral baselines

Behavior analytics gets noisy when “normal” means “average.” People act differently when they travel, change roles, close the quarter, ship a release, or sit through an audit. Service accounts may run once a month and do an enormous amount of work when they do. Admins still fix things at 2 a.m.

Comparing an engineer to the whole company is mostly futile. Comparing them to people with the same tools, systems, and responsibilities is actually informative.

Then we need to consider business cycles. Month-end close, annual audits, patch Tuesday, backups, and overnight batch jobs all look strange to a baseline that doesn’t know about them. New hires are even harder, since there’s barely any history to say what’s normal for them.

Analyst feedback keeps all of this honest, and it only works if people record why an alert was a false positive. A sanctioned admin task, a badly drawn peer group, a known vulnerability scanner, and an unclassified asset each need a different fix and approach. Write down which one it was, and you can tune the rule without going blind to the same behavior elsewhere.

You might exclude one documented automation account, require correlated network activity, change a threshold for a single group, or raise severity when a critical asset is involved.

Hunting for behavior-based threats

A good hunt starts with something the attacker will certainly have to do. Stolen credentials usually lead to remote administration, so look for first-time tool use, installs outside your normal deployment process, sessions started by people who don’t usually start them, and connections right after odd logins.

If you suspect cloud exfiltration, look elsewhere: rare cloud destinations, command-line upload tools, archives created right before outbound transfers, unusual access to sensitive repositories, and accounts pulling far more data than their peers.

Scheduled-task persistence has its own poker tell. Watch for tasks created by unexpected users, names designed to look boring, commands running from temp folders, hidden execution, and creation shortly after a suspicious download. A plain “task created” alert catches almost none of that.

Internet-facing apps need the same scrutiny. A web server exploit often leaves new web-accessible files, strange POST requests, worker processes spawning shells, credential access from the server, and outbound connections to rare infrastructure.

Hunts built this way turn into reusable detections, because they target what an intrusion requires instead of what one particular piece of malware looks like. Threat intelligence sharpens them with known indicators, affected technologies, observed procedures, and likely next moves.

Reconstructing the intrusion

Alerts fire somewhere in the middle of an intrusion. That suspicious PowerShell might run hours after the account was compromised, and the attacker may already be persistent on another machine. Data could be sitting in a cloud app, with a stolen token that outlived the password reset.

Triage has to answer questions quickly: Which identity is affected, and what can it do? Which device did this start on, and what has it touched since? What do the authentication history, process tree, network connections, persistence, role changes, and data access look like? Related activity elsewhere can show the compromise is much bigger than the alert suggested.

Containment must block every path that’s been used. Depending on the case, that means isolating endpoints, disabling accounts, revoking sessions and tokens, removing malicious OAuth grants, rotating credentials, blocking C2 infrastructure, and preserving evidence.

A lot of that work happens on systems that never fired off an alert. Following the identity, the processes, the persistence and the network paths gives responders a clear boundary and makes it much less likely that one surviving foothold restarts the whole thing.

The way to catch attackers is to keep the context and connect it: user history, peer behavior, process ancestry, app access, network activity, asset sensitivity, timing. Any one of those is weak. Together they usually tell you whether something belongs.

Teams that follow the relationships between events have a real chance of stopping an intrusion while it still looks ordinary, before it turns into encrypted servers and a ransom note.