Keypoints
- SVR actors have adapted to cloud-first environments by focusing on cloud account authentication rather than on-premises exploitation.
- Initial access methods observed include brute force/password spraying against service and dormant accounts, and reuse of credentials.
- Actors have stolen and used cloud-issued access tokens to authenticate without passwords.
- Multi-factor authentication (MFA) bypass techniques such as MFA “bombing” (repeated push requests) have been used to gain access.
- After account compromise, actors register devices in the tenant to persist and evade evictions if device enrollment policies are weak.
- Residential proxies are used to blend malicious traffic into residential IP ranges, reducing the value of IP-based detection alone.
- Recommended mitigations include enforcing robust MFA, short session/token lifetimes, strict device enrollment, canary service accounts, least privilege for service accounts, and richer application/host logging.
MITRE Techniques
- [T1110] Brute Force – SVR used brute forcing and password spraying against service accounts to gain initial access (‘The SVR use password spraying and brute forcing as an initial infection vector.’)
- [T1078.004] Valid Accounts: Cloud Accounts – Actors targeted dormant and cloud system accounts to authenticate into cloud services (‘The SVR use compromised credentials to gain access to accounts for cloud services, including system and dormant accounts.’)
- [T1528] Steal Application Access Token – SVR stole system-issued tokens to access accounts without passwords (‘The NCSC and partners have observed SVR actors using tokens to access their victims’ accounts, without needing a password.’)
- [T1621] Multi-Factor Authentication Request Generation – Actors used MFA fatigue/bombing by repeatedly pushing MFA prompts until a user accepted (‘the actors repeatedly push MFA requests to a victim’s device until the victim accepts the notification, providing SVR access to the account.’)
- [T1098.005] Account Manipulation: Device Registration – After compromise, SVR registered their own devices in tenants to maintain access (‘SVR actors have been observed registering their own device as a new device on the cloud tenant.’)
- [T1090.002] Proxy: External Proxy – SVR used residential proxies to make traffic appear from residential ISP ranges and evade IP-based detection (‘The SVR use open proxies in residential IP ranges to blend in with expected IP address pools in access logs.’)
Indicators of Compromise
- [Network IPs] Residential IP ranges used to proxy traffic – examples not listed (article notes use of residential proxy IPs to blend with typical user traffic).
- [Credentials/Accounts] Service and dormant cloud accounts – examples: “service account” login attempts, inactive/dormant user accounts being used to regain access after password resets.
- [Tokens] Stolen application/session tokens – example context: tokens used to authenticate without passwords (no specific token strings provided).
- [URLs/Reports] Advisory and PDF resources – https://www.ncsc.gov.uk/files/Advisory-SVR-cyber-actors-adapt-tactics-for-initial-cloud-access.pdf, https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-057a
SVR-associated actors have shifted initial access toward cloud authentication mechanisms. Observed technical procedures include brute force and password spraying against highly privileged service accounts and dormant cloud accounts, credential reuse, and exploitation of accounts that cannot use strong multi-factor methods. They also steal system-issued access tokens to bypass passwords and apply MFA fatigue (repeated push notifications) to coerce users into approving logins.
Post-authentication, these actors frequently register new devices in a victim’s cloud tenant to persist and evade incident response when device enrollment controls are lax. To remain covert on the network, they route traffic through residential proxies so connections appear to originate from typical home ISP ranges, reducing the effectiveness of IP-based blocking and detection.
Practical defenses center on hardening authentication and enrollment controls: enforce robust, phishing-resistant MFA and block push-only approval methods where feasible; implement short session and token lifetimes; apply least privilege to service accounts and disable dormant accounts through joiner/mover/leaver processes; require strict device enrollment (zero-touch or strong 2SV) and prevent old devices from re-enrolling; create canary service accounts for high-confidence alerts; and rely on application- and host-based logging (e.g., user-agent changes, token/session anomalies) instead of IP-only signals for detection.
Read more: https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-057a