MA.18.03.03-900x600

MA-1038.022024: MyCERT Advisory – Advisory on Russian SVR Actors Targeting Cloud Infrastructure

1.0 Introduction
Recently, UK’s National Cyber Security Centre (NCSC UK) published an advisory which details how Russia-based cyber actors are adapting their tactics, techniques, and procedures (TTPs) to infiltrate and access intelligence hosted in cloud environments as a growing number of targets store data in the cloud.

The NCSC and international partners assess that the group commonly known as APT29, also known as Midnight Blizzard, the Dukes or Cozy Bear is a cyber espionage group, almost certainly part of the SVR, an element of the Russian intelligence services. The US National Security Agency (NSA), the US Cybersecurity and Infrastructure Security Agency (CISA), the US Cyber National Mission Force (CNMF), the Federal Bureau of Investigation (FBI), Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC), the Canadian Centre for Cyber Security (CCCS) and the New Zealand National Cyber Security Centre (NCSC) agree with this attribution and the details provided in this advisory.

2.0 Impact
Potential intelligence gain from the targeted governmental, healthcare, and energy sectors.

3.0 Description  
As organisations continue to modernise their systems and move to cloud-based infrastructure, the SVR has adapted to these changes in the operating environment. They must move beyond their traditional means of initial access, such as exploiting software vulnerabilities in an on-premises network, and instead target the cloud services themselves. To access most of the victims’ cloud hosted network, actors must first successfully authenticate to the cloud provider. Denying initial access to the cloud environment can prohibit SVR from successfully compromising their target. In contrast, in an on-premises system, more of the network is typically exposed to threat actors. Below describes in more detail how SVR actors are adapting to continue their cyber operations for intelligence gain. These TTPs have been observed in the last 12 months.

3.1 Access Via Service and Dormant Accounts
The actors have effectively employed password spraying and brute forcing in previous SVR campaigns to gain access to service accounts. Usually, programmes and services are run and managed with this kind of account. These accounts are more vulnerable to a successful hack as multi-factor authentication (MFA) cannot readily protect them because there is no human user behind them. Service accounts have varying degrees of privilege based on the apps and services they oversee. Threat actors can initiate additional activities on a network by gaining privileged access to these accounts.
SVR campaigns have also been directed on inactive user accounts that are still active on the system but belong to people who have left the victim organisation. SVR actors have also been seen going into dormant accounts and following instructions to reset the password after an event where an enforced password reset for every user was carried out. After incident response eviction efforts, this has made it possible for the actor to reclaim access.

3.2 Cloud-Based Token Authentication
Usually, system-issued access tokens or username and password credentials are used to validate account access. SVR actors have been seen by the NCSC and its partners employing tokens to gain password-free access to their victims’ accounts. System-issued tokens have different default validity times depending on the system; cloud platforms should let administrators change the validity duration so that users can utilise them as needed.

3.3 Enrolling New Devices to the Cloud
Using password spraying and credential reuse, the SVR has repeatedly been able to get around password authentication on personal accounts. Then, using a tactic called “MFA bombing” or “MFA fatigue,” SVR actors have gotten around MFA by sending numerous MFA requests to a target’s device until the victim accepts the notification.
SVR actors have been seen registering their own device as a new device on the cloud tenant after getting over these systems to access the cloud environment. SVR actors can successfully register their own device and get access to the network if device validation rules are not set up.
In several cases, these protections have prevented SVR actors from accessing the cloud tenancy by enforcing device enrolment regulations within the network.

3.4 Residential Proxies

SVR actors have looked into alternative methods of remaining anonymous online as network-level defences get better at identifying suspicious activities. Using residential proxies is one of this actor’s TTPs. Residential proxies usually mask the real source of traffic by making it appear as though it is coming from IP addresses inside residential broadband customers’ internet service provider (ISP) ranges. This may make it more difficult to discern between malicious and legitimate connections. Because of this, network defences that rely on IP addresses as signs of penetration are less effective, so while looking for suspicious activity, it’s crucial to consider a range of information sources, including application- and host-based logging.

4.0 MITRE ATT&CK

Tactic Id Technique Procedure
Credential Access T1110 Brute Forcing The SVR use password spraying and brute forcing as an initial infection vector.
Initial Access T1078.004 Valid Accounts: Cloud Accounts The SVR use compromised credentials to gain access to accounts for cloud services, including system and dormant accounts.
Credential Access T1528 Steal Application Access Token The SVR use stolen access tokens to login to accounts without the need for passwords.
Credential Access T1621 Multi-Factor Authentication Request Generation The SVR repeatedly push MFA requested to a victim’s device until the victim accepts the notification, providing SVR access to the account.
Command and Control T1090.002 Proxy: External Proxy The SVR use open proxies in residential IP ranges to blend in with expected IP address pools in access logs.
Persistence T1098.005 Account Manipulation: Device Registration The SVR attempt to register their own device on the cloud tenant after acquiring access to accounts.

 

5.0 Recommendation
CyberSecurity Malaysia recommends users and administrators to follow the security best practices as follows:

  • Use multi-factor authentication (/2-factor authentication/two-step verification) to reduce the impact of password compromises. See NCSC guidance: https://www.ncsc.gov.uk/guidance/multi-factorauthentication-online-services and https://www.ncsc.gov.uk/guidance/setting-two-factor-authentication-2fa.
  • Accounts that cannot use 2SV should have strong, unique passwords. User and system accounts should be disabled when no longer required with a ‘joiners, movers and leavers’ process in place and regular reviews to identify and disable inactive/dormant accounts. See NCSC guidance: https://www.ncsc.gov.uk/collection/10-steps/identity-and-access-management.
  • System and service accounts should implement the principle of least privilege, providing a tightly scoped access to resources required for the service to function.
  • Canary service accounts should be created which appear to be valid service accounts but are never used by legitimate services. Monitoring and alerting on the use of these account provides a high confidence signal that they are being used illegitimately and should be investigated urgently.
  • Keep session lifetimes brief to minimize the chance for adversaries to exploit stolen session tokens. Use an authentication method that balances regular user authentication with a positive user experience.
  • Set up device enrolment policies to allow only authorized devices. Prefer zero-touch enrolment, and if self-enrolment is necessary, implement a robust 2-step verification method that is resistant to phishing and prompt bombing. Disable (re-)enrolment for old devices that are no longer needed. See NCSC guidance: https://www.ncsc.gov.uk/collection/device-security-guidance/getting-ready/provisioning-and-distributing-devices.
  • Utilize diverse information sources like application events and host-based logs for preventing, detecting, and investigating potential malicious behaviour. Prioritize sources and indicators with lower false positive rates. For instance, monitoring changes to user agent strings, which could signal session hijacking, may be more effective than solely identifying connections from suspicious IP addresses. See NCSC guidance: https://www.ncsc.gov.uk/guidance/introduction-logging-security-purpose.
Share: