Google released the threat horizon report for April 2023, which showed multiple methods used by threat actors for evading security systems.
Google’s Cybersecurity Action Team (GCAT) and Mandiant researched a list of techniques and methods used by threat actors over the period for penetrating the environments and other malicious activities.
Cloud-Hosted Encrypted ZIP Files Evading Detection
Mandiant observations during Q4 2022 showed a technique where threat actors stored malicious files on Google Drive as encrypted ZIP files to evade detection.
A malware campaign also distributed URSNIF malware, a banking bot, and intrusion software by hosting the URSNIF binary in Google Drive.
Threat actors use phishing emails to lure victims into downloading the password-protected malicious ZIP files, which will then install the malware on the victim’s machine.
Q4 2022 also showed another expansion of this technique where DICELOADER malware was distributed, which had multiple purposes.
In this technique, Mandiant observed that the Google Drive link in the phishing email had an LNK file.
When this file is downloaded, it will install a Zoom MSI installer, a Trojan that eventually leads to a DICELOADER infection.
Several other threat actors used this technique for different purposes in several other cases.
Customer Challenges and Solutions When Security Patching Google Kubernetes Engine
Kubernetes has been a great feature for cloud customers due to its availability, flexibility, and security.
However, even Kubernetes needs patching routinely, which installs security and bug fixes.
As per Google’s reports, the 2021-2022 data showed most of the Google Kubernetes Engine (GKE) customers delayed their patching due to the fear that “patching might affect production operations.”
This delay in security patching might sometimes result in vulnerabilities that threat actors can exploit over time.
Many options are available to maintain security patching and business continuity, which can also be combined with scanning and notification services to find vulnerabilities.
There were many reasons from GKE customers for delaying security patching as,
- Session maintenance of customers (Pinned sessions) will be terminated.
- AI/ML application-based clients were worried that unsaved workloads might be lost during the patch and restart activity.
- Some customers were worried that patching might bring unexpected API changes, affecting their application’s functionality.
- Large node customers will take more time for patching, creating a weak security posture.
Solutions for Balancing Availability and Security Patching in GKE
- Choose appropriate and relevant channels (Rapid, Regular, and Stable) upgrades for the applications
- Use maintenance windows for patching with proper duration.
- Have maintenance-exclusion windows to prevent upgrades during some special cases.
- Setting up a Pod Disruption Budget is preferable for session maintenance-based customer applications.
- Setting up regional clusters rather than zonal clusters is recommended for workload availability.
- Having a Security posture dashboard is highly result-providing.
- Using various notification services will have additional security awareness for patching.
The low hanging fruit: Leaked Service Account Keys and the Impact on Your Organization
Leakage of service account credentials has been the greatest threat to organizations with Cloud-based infrastructures.
As per Top Threats for cloud computing during 2022 by CSA (Cloud Security Alliance), 42% of the incidents were leaked key incidents.
Identity, Credentials, Access, and Key management are extremely important for Cloud-based systems as the keys might have access to confidential information.
Most of these were due to new account creation or developers testing their code in a public repository, leading to the leaking of service account credentials.
Google stated, “In 42% of leaked critical incidents detected by our abuse systems, customers did not take action after Google attempted to contact the project owner, so the key remained vulnerable to abuse.
While there are many instances of new accounts or developers testing code exposing service account keys, our teams have observed compromises distributed across varying sizes and maturities of organizations”.
Attackers Shifting Tactics to Conceal API Calls
Threat actors who get these leaked service account credentials have been using several defense evasion techniques to hide the origin of their API calls.
Most attackers use Tor nodes, open proxies, and other compromised cloud instances or cloud service providers for anonymous API calls.
Often, attackers are unaware of the capability of the service credential, hence depending on automation tools to level up its resource utilization resulting in the shutting down of the instance.
Attackers who get knowledge of the discovered credential can do extreme damage to the infrastructure depending upon the permissions of the credential.
The data survey on the IAM roles of compromised service account keys corresponds to the following data.
- 67.6% of keys had basic IAM roles
- 23.5% had Owner roles
- 44.1% had editor roles
Another report by Palo Alto’s Unit 42 Cloud Threat Research stated, “99% of the cloud users, roles, services, and resources were granted excessive permissions.”
Hardcoded credentials checked into code repositories
Credentials leaking onto a public/private repository originate when a developer downloads a service account key (typically an RSA public/private key pair) and uses it to check the code in a private code repository, leaving it there too long.
Instances where these private repositories become public are when the exposure of these keys becomes predominant.
Threat actors cast nets inside repositories to find these keys, considered low-hanging fruits.
As per the Threat Horizon report of Jan 2023, Jenkins, the IT automation software, was the most targeted.
This was because keys and other credentials were found in an organization’s commit along with CI/CD logs which displayed these keys when they were sent as command-line arguments.
Unfortunately, these went unnoticed for a very long. As per IBM’s 2022 Cost of Data breach report, 19% of the breaches were due to compromised or stolen credentials and took the longest time of nearly 243 days to detect.
Another instance where a developer scanned Python Package Index (PyPi) revealed 53 legitimate and valid AWS keys.
The fact is that Amazon themselves had a leaked key, and the oldest active key found in the scan dates back to 10 years.
Mitigations
- The need for a service account must be validated
- Local development can use personal account credentials to authenticate
- Keep an inventory of keys and audit them regularly
- Having a naming convention for service accounts might be helpful
- Audit logs monitoring and identify malicious behavior
- Having policies to disable accounts not used for some time is recommended.