The stolen material may then be used to authenticate to Microsoft Entra ID, AWS, Google Cloud, or cloud-hosted applications. In some incidents, attackers abuse existing sessions or temporary credentials rather than stealing a conventional password.
Investigating these incidents requires correlating endpoint telemetry with identity-provider logs, cloud audit records, network activity, and evidence of subsequent resource access. The objective is to reconstruct how the credential was exposed, determine whether it was used, identify the resources affected, and contain the compromise.
A SOC analyst receives an alert for an unusual sign-in to a cloud identity account. The authentication originates from an unfamiliar IP address, and the account subsequently accesses resources outside its normal activity pattern.
At first, the activity appears to be an identity-related incident. However, endpoint telemetry reveals that the account's primary user's workstation recently executed a suspicious process. The process accessed browser-related files, and an infostealer detection was raised shortly before the unusual sign-in.
Investigators now need to establish whether the endpoint activity and cloud authentication are connected.
The investigation must answer several questions:
Was authentication material exposed on the endpoint?
Was a password, access token, refresh token, browser session, or cloud credential involved?
Can the suspicious cloud activity be linked to the compromised endpoint or identity?
Did the attacker access email, files, cloud infrastructure, or secrets?
Were additional credentials created or permissions modified?
What evidence is needed to determine the scope and impact?
This is a cross-domain investigation. Endpoint evidence may explain how authentication material was obtained, while cloud audit records may reveal how that material was subsequently used.
The term cloud credential covers several types of authentication material. Investigators must identify which type may have been exposed because different credentials provide different capabilities and require different containment actions.
A password may be captured through phishing, keylogging, credential-stealing malware, or insecure storage.
A stolen password does not automatically guarantee cloud access. Multifactor authentication, conditional access, account restrictions, passwordless authentication, and risk-based controls may prevent or limit its use.
Investigators should determine whether the password was used successfully and whether the authentication flow required additional factors.
Authentication tokens and session cookies can allow an application or browser to maintain an authenticated session.
Depending on the token type, resource, lifetime, and security controls, stolen authentication material may allow an attacker to act without entering the user's password again.
Examples include:
Access tokens used to call protected APIs.
Refresh tokens used to obtain new access tokens.
Browser session cookies associated with an authenticated session.
Application-specific session tokens.
These materials are not interchangeable. Their validity and capabilities depend on the authentication protocol and service.
Investigators should not assume that every stolen token provides unrestricted access or that every token remains usable after the incident is detected. Token expiration, revocation, conditional access, device binding, and other controls may affect reuse.
Cloud environments also use credentials that are not tied to an interactive employee sign-in.
Examples include:
AWS access keys.
Temporary AWS security credentials.
Azure service principal credentials.
Google Cloud service account keys.
Workload identity credentials.
Secrets used by automation pipelines.
These credentials may be stored in application configuration files, deployment systems, environment variables, secret stores, or developer workstations.
If exposed, they can enable access under the associated identity's permissions. The impact depends on the credential's scope, validity, and the permissions assigned to that identity.
Infostealers are designed to collect information from compromised systems. Depending on the malware family and its capabilities, collected information may include browser credentials, cookies, saved passwords, cryptocurrency wallet data, and other sensitive files.
A possible attack sequence is:
The user executes a malicious file or script.
Malware runs on the endpoint.
The malware accesses browser-related data or other credential stores.
Authentication material is collected.
The material is transferred to infrastructure controlled by the attacker.
The attacker attempts to authenticate to a cloud service.
Not every infostealer collects every credential type, and an infostealer alert does not prove that cloud credentials were successfully stolen.
Phishing can expose passwords, one-time authentication codes, or session-related material, depending on the technique used.
Investigators should correlate email security alerts, browser activity, identity-provider sign-ins, authentication challenges, and subsequent resource access.
A successful sign-in following a phishing event is suspicious when the timing and identity context align, but correlation alone does not conclusively establish causation.
Authentication tokens may be exposed through compromised browser sessions, malicious software, vulnerable applications, or inappropriate access to local authentication stores.
Token theft can be difficult to investigate because the attacker may not need to perform a conventional password-based sign-in.
Useful evidence may include:
Endpoint process and file-access telemetry.
Browser or application session activity.
Identity-provider sign-in records.
Authentication protocol and client details.
Session identifiers or token-related metadata, where available.
Subsequent API or resource access.
Security teams should avoid placing raw tokens in incident notes or SIEM events. Tokens are sensitive authentication material and should be handled using approved forensic procedures.
Developers and administrators may use command-line tools, SDKs, deployment scripts, and cloud management utilities from their workstations.
Credentials can be exposed through:
Insecure configuration files.
Accidentally committed secrets.
Build logs and deployment output.
Unprotected environment variables.
Local caches or credential stores.
Inappropriate access to secret-management systems.
An attacker who compromises a developer endpoint may therefore gain access to cloud resources without directly compromising the cloud provider's authentication infrastructure.
Investigators should search for evidence of secret exposure, credential retrieval, unusual CLI activity, and subsequent cloud API calls.
A compromised endpoint may contain credentials belonging to an application or workload rather than a human user.
For example, an attacker may discover an application secret on a build server and use it to authenticate as a service principal. The resulting activity may appear in application sign-in logs rather than ordinary user sign-in logs.
This distinction matters because investigating only employee authentication events can miss the actual identity used to access cloud resources.
A reliable investigation separates the incident into stages and identifies evidence for each stage.
StagePossible evidenceWhat it can establishInitial endpoint compromiseEDR alerts, process execution, email or download recordsHow suspicious code or content reached the endpointCredential exposureFile-access telemetry, malware analysis, secret-scanning findingsWhether authentication material may have been accessed or exposedExternal transferDNS, proxy, firewall, and EDR network telemetryWhether the endpoint communicated with a suspicious destinationCloud authenticationIdentity-provider or cloud sign-in logsWhether the identity or credential was used to authenticatePost-authentication activityCloud audit logs and resource access recordsWhich actions were attempted or completedPrivilege expansionIAM, application permission, or role-assignment audit recordsWhether access capabilities changedData access or exfiltrationResource audit records, DLP events, transfer logsWhether sensitive data was accessed or transferredThe stages may overlap, and some may not be observable. For example, an attacker might reuse an existing browser session, or an exposed credential may be used from infrastructure unrelated to the compromised endpoint.
A timeline should therefore distinguish observed events from inferred links.
Identify the affected endpoint, logged-on user, process tree, detection name, timestamp, and available command-line information.
Determine whether the alert indicates confirmed malware, suspicious behaviour, credential-store access, or only a heuristic match.
Preserve the alert metadata and relevant endpoint evidence according to the organisation's incident response procedures.
Review process creation, parent-child relationships, command-line arguments, file creation, persistence indicators, and network activity.
Potentially relevant Windows telemetry includes:
Security Event ID 4688, when process-creation auditing is enabled.
PowerShell Operational Event ID 4104, when script-block logging is enabled.
EDR process and file telemetry.
Relevant Sysmon events, if Sysmon is deployed and configured.
Windows Defender and other endpoint security alerts.
These sources may establish that a suspicious process ran or interacted with relevant files. Their availability depends on configuration, retention, and the capabilities of the endpoint monitoring product.
Examine the process's behaviour for evidence that it accessed browser data, credential stores, application configuration files, or cloud-related secret locations.
Do not assume that access to a browser directory proves credential theft. Browsers and legitimate applications routinely access their own profile data.
Look for corroborating evidence, such as suspicious process lineage, malware classification, unexpected file collection, credential-related detections, or outbound connections associated with the process.
Review DNS queries, proxy events, firewall records, EDR network telemetry, and other relevant network evidence.
Determine whether the endpoint communicated with an unfamiliar destination during the suspected collection window. Examine timing, destination reputation, connection frequency, and transferred volume where available.
An outbound connection does not by itself prove that credentials were transferred. Encrypted traffic, shared hosting, and incomplete network telemetry may prevent direct identification of the transmitted content.
If the endpoint remains compromised, follow the incident response playbook to isolate it where appropriate, preserve volatile evidence when necessary, and prevent further unauthorised activity.
Coordinate endpoint containment with identity and cloud teams. A compromised endpoint may continue to expose credentials even after the associated cloud account's password is changed.
For Microsoft Entra ID, review:
User sign-in logs.
Non-interactive user sign-in logs.
Service principal sign-in logs.
Managed identity sign-in logs, where relevant.
Audit logs for application, credential, and role changes.
Microsoft 365 audit records for subsequent resource access.
Investigate unfamiliar IP addresses, unexpected authentication patterns, unusual applications, unfamiliar client types, and resource access outside the user's normal behaviour.
Interpret location carefully. VPNs, corporate proxies, mobile networks, and cloud-hosted infrastructure can make IP geolocation misleading.
Also remember that an attacker reusing an existing session may not generate a sign-in pattern identical to a conventional password-based login.
For AWS, review CloudTrail and relevant authentication or workload telemetry.
Potential indicators include:
API calls from unfamiliar source infrastructure.
Use of an access key outside its normal workload.
Unusual AssumeRole activity.
Access to sensitive S3 objects or secrets.
IAM policy or role changes.
Creation of additional access keys.
Activity that follows a suspected credential exposure window.
Correlate the principal, access key identifier where recorded, role session details, source IP, user agent, and subsequent API operations.
CloudTrail coverage depends on the configured trails, event selectors, service support, and retention. The absence of a record is not proof that the action did not occur.
For Google Cloud, investigate Cloud Audit Logs, relevant identity events, service account activity, and workload telemetry.
Review whether a user credential, service account key, or workload identity was involved. Correlate authentication context with subsequent resource operations, permission changes, and access to sensitive services.
The specific evidence available depends on the service, audit-log configuration, and credential type.
The following illustrative KQL query identifies potentially unfamiliar successful sign-ins from the Microsoft Entra SigninLogs table. It is a triage example, not a complete credential-theft detector.
SigninLogs | where TimeGenerated > ago(7d) | where ResultType == "0" | summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), SignInCount = count(), Applications = make_set(AppDisplayName, 10), Resources = make_set(ResourceDisplayName, 10) by UserPrincipalName, IPAddress, Location, UserAgent | order by LastSeen descThis query summarises successful sign-ins by user, IP address, location, and user agent. It does not automatically identify unfamiliar infrastructure, stolen credentials, or malicious sessions. Baselines, identity context, and other telemetry are required to determine whether a result is suspicious.
For application-based credentials, investigate the relevant service principal or managed identity sign-in tables rather than relying exclusively on user sign-in records.
Where endpoint and cloud logs are available in a common SIEM, correlate them using the user identity, hostname, timestamps, IP addresses, and relevant process or session information.
A useful investigation sequence is:
Identify the endpoint alert and suspected compromise time.
Establish which identity or application may have been exposed.
Search identity logs for relevant authentication activity.
Review cloud audit logs for subsequent sensitive operations.
Compare the sequence with normal behaviour and approved changes.
Record which links are confirmed and which remain hypotheses.
Do not force a correlation based solely on close timestamps. A defensible incident timeline requires multiple supporting attributes wherever possible.
Once suspicious credential use is established, investigate what the identity could access and what it actually did.
Credential scope
Was the credential associated with a user, service principal, managed identity, or workload?
What permissions were available?
Was the credential temporary, revocable, or long-lived?
Authentication
Was authentication successful?
Was an existing session reused?
Were MFA or conditional access controls involved?
Are there relevant session, token, or authentication-risk records?
Post-authentication activity
Were sensitive files, mailboxes, databases, or secrets accessed?
Were resources modified or deleted?
Were new credentials, application grants, or roles created?
Was the activity consistent with the identity's normal purpose?
Data exposure
Is there evidence of collection, export, or transfer?
Can the affected files or records be identified?
Is successful external transfer confirmed, or merely suspected?
These questions help distinguish credential exposure from confirmed account compromise and confirmed data exfiltration.
Raise the investigation priority when an endpoint credential-theft alert is followed by successful authentication for the affected identity from unusual infrastructure or a new client context.
Correlate by identity, time window, endpoint ownership, and available session information. Account for legitimate remote access and expected changes in network location.
Monitor application credential additions and correlate them with service principal sign-ins and sensitive API operations.
This can help detect an attacker who obtains control of an application identity after compromising an endpoint, deployment server, or administrator account.
Look for sensitive cloud operations shortly after an endpoint or secret-scanning alert.
Examples include unexpected role assumptions, bulk object access, access to secrets, changes to identity permissions, and creation of additional credentials.
The correlation should consider whether the relevant identity could perform those actions and whether the activity was authorised.
Where device and session information is available, investigate cloud access that differs from the identity's normal device or authentication context.
Device information may be unavailable or unreliable for some authentication flows, so this signal should be combined with other evidence rather than treated as a standalone verdict.
Monitor secret-scanning findings, source-control alerts, CI/CD logs, and configuration changes that may expose cloud credentials.
Prioritise findings involving active credentials with broad permissions. Validate whether the credential was usable and investigate subsequent authentication activity.
The following techniques may be relevant when supported by evidence. Validate the current technique descriptions in the MITRE ATT&CK knowledge base before final classification.
TechniqueATT&CK IDWhen it may applyCredentials from Password StoresT1555Credentials are obtained from password stores or related sourcesSteal Web Session CookieT1539Evidence supports theft of a web session cookieSteal Application Access TokenT1528An application access token is stolenUnsecured CredentialsT1552Credentials are exposed through insecure storage or configurationValid AccountsT1078An existing account or credential is used for unauthorised accessExfiltration Over Web ServiceT1567Evidence supports data transfer through a web serviceThe mapping must reflect the observed behaviour. An infostealer alert does not automatically prove that a session cookie was stolen, and an unusual cloud sign-in does not by itself establish credential theft.
Reference: https://attack.mitre.org/
Containment must address both the compromised endpoint and the cloud identity.
Depending on the evidence and the affected platform, response actions may include:
Isolating the compromised endpoint.
Revoking exposed credentials and rotating affected secrets.
Revoking sessions or refresh tokens where supported and appropriate.
Disabling or restricting a compromised account or service principal.
Removing unauthorised application permissions and role assignments.
Reviewing and restricting access keys and temporary credentials.
Investigating persistence mechanisms and additional identities.
Preserving endpoint, identity, and cloud audit records.
Validating that the attacker no longer has a usable access path.
Monitoring for renewed authentication and suspicious activity.
Changing a password alone may be insufficient when tokens, application credentials, or workload secrets are involved. Response teams should identify the actual authentication material and invalidate or replace it using the relevant platform's supported procedures.
Containment decisions should consider business impact, evidence preservation, and whether the compromised identity is used by critical applications.
Use strong endpoint protection. Deploy EDR controls, monitor suspicious credential-store access, and investigate infostealer detections promptly.
Protect authentication material. Avoid storing credentials in source code, scripts, plaintext configuration files, or unprotected logs. Use approved secret-management systems.
Apply least privilege. Limit cloud identity permissions and separate administrative, development, and routine user access.
Use strong authentication controls. Apply phishing-resistant MFA where appropriate, conditional access, and risk-based controls supported by the identity platform.
Prefer managed identities and short-lived credentials. Where suitable, reduce reliance on long-lived secrets and static access keys.
Monitor application identities. Alert on unexpected credential additions, permission grants, role assignments, and unusual service principal activity.
Centralise audit logs. Collect endpoint, identity, and cloud telemetry in a protected monitoring platform with appropriate retention.
Review cloud credentials regularly. Identify unused keys, stale application secrets, excessive permissions, and exposed credentials. Rotate or revoke them according to a documented process.
Improve cross-domain correlation. Connect endpoint alerts with identity and cloud audit activity so that investigations can follow a credential from its potential exposure through subsequent use.
Cloud credential theft is often a chain of events rather than a single isolated alert. A compromised endpoint may expose passwords, session material, application secrets, or cloud access keys. The resulting authentication activity can then lead to data access, privilege expansion, or additional compromise in the cloud.
Effective investigation requires endpoint forensics, identity analysis, and cloud audit review to work together. Analysts should establish how authentication material may have been exposed, whether it was subsequently used, which resources were accessed, and whether data was transferred.
The most important principle is to distinguish potential credential exposure from confirmed credential use and confirmed impact. Correlating independent evidence sources produces a more reliable timeline, supports appropriate containment, and helps organisations close the access path that enabled the incident.
MITRE ATT&CK
Microsoft Entra ID — Monitoring and Health
Microsoft Security — Identity Protection
AWS CloudTrail User Guide
Google Cloud Audit Logs
NIST — Guide to Integrating Forensic Techniques into Incident Response
Continue reading
Cloud Attacks
[{"type":"text","text":" The Kubernetes API server is the primary control-plane interface through which users, automation systems, and cluster components manage Kubernetes resource...
Cloud Attacks
[{"type":"text","text":" Microsoft Entra ID applications and service principals can access organisational resources through delegated permissions, application permissions, and dire...
Cloud Attacks
[{"type":"text","text":" AWS CloudTrail records API activity across an AWS environment, helping security teams investigate identity misuse, unauthorised configuration changes, priv...
3 entries, most recent posts.
Cybersecurity researchers have uncovered an AI-assisted cybercrime operation attributed to CyberXero, a financially motivated initial access broker th...
Senior Hosting Security Engineer
The convergence of Operational Technology (OT), the Internet of Things (IoT), and traditional enterprise IT networks is transforming how organisations...
