Cloud Security Migration

Cloud Security Threat Analysis with CloudHealth Secure State

CloudHealth Secure State is a cloud security and compliance management platform that allows users to reduce the risk and manage the security posture of their overall cloud environment. You can add and remove cloud accounts individually or in bulk to accommodate smaller and larger enterprises alike and can gain multi-cloud visibility of risks across AWS, Azure, and GCP from an information security perspective. 

CloudHealth Secure State provides rich out-of-the-box rules that generate “findings” within the tool – allowing security and developer teams alike the means to discover cloud resources that violate these rules. 

Finally – it also provides the ability to query a single cloud account – or all cloud accounts in your environment. This is a very powerful feature that allows to quickly explore the cloud landscape and ask and receive answers about the resources. This capability can be very useful for threat analysis which involves assessing your environment to identify security risks as well as threat hunting which entails searching for signs of malicious activity that are not being picked up by existing alerting or detection mechanisms. 

Explore Query

With the Explore Query, security teams can explore and search for specific findings or perform ad-hoc searches to reveal interesting details about cloud resources. 

You can search for resources that have a publicly exposed port, an anonymously accessible S3 bucket, and even things like duplicate CloudTrails being enabled in a single region. It’s an easy-to-use interface to directly ask questions about your cloud environment.

Here at VMware, we deal with – tens of thousands of cloud accounts – and having a console such as the Explore Query provides an excellent way to further probe the environment across AWS, Azure, GCP and Kubernetes.

Consider this example scenario:

A specific AWS public IP address that you own is reported to be participating in unauthorized public scanning activity across the internet. This behavior is usually indicative of either a vulnerability scanner or the resource being infected with a malicious worm. The only information we have is a public IP address – imagine trying to find that public IP address and attempting to attribute it to a single AWS account. We can use the Explore feature from CloudHealth Secure State to quickly identify where in the system this public IP address resides with a query such as this:

AWS.EC2.Instance HAS PublicIpAddress = <insert IP address here>

Some More Explore Queries

AWS.EC2.SecurityGroupRule HAS RuleDirection = inbound AND CidrIp = AND ToPort = 3389

This rule can return all AWS EC2 security groups that allow inbound access to Windows Remote Desktop default port of 3389.

AWS.IAM.AccessKey HAS CreateDate <= yearsAgo(7) AND Status = Active AND AccessKeyLastUsedDate <= yearsAgo(7)

A rule to discover all AWS Access Keys across your AWS environment that are extremely old, as in this case Access Keys that were created over 7 years ago, are still active and were last used over 7 years ago. If there are any results – these would be extremely old and stale access keys that should be deleted.

Review Findings

By clicking on the “Findings” dropdown, you can select findings that are organized either by rule or by resource.  If there’s a specific resource you’ve already identified that requires review, selecting “findings by resource” will provide you a quick way to search for that resource identifier by leveraging the search magnifying glass at the top of the page.

CloudHealth Secure State takes a low-code approach so simply typing a string into the search will attempt to match your query on any number of values that may be tied to a resource – not limited to just its unique identifier. The query will also return results matching your string from tags of either the resource or of the account itself as it is configured in the product.


The “Findings by rule” on the other hand – is a quick way to begin discovering some low hanging fruit that may be present in the environment. Since security findings are organized by rule, it’s easier to navigate and understand the types of misconfigurations or threats that exist in your environment.


You can leverage the filter icon on the left to obtain a more targeted overview of findings.  Filters include:

  • Account Name
  • Provider (AWS, Azure, GCP)
  • Finding Type (Threat, Violation)
  • Rule Source (Native, Custom)
  • Service (S3, EC2, EKS, AKS, etc)

… and more!

Investigate findings from the GuardDuty detection: “cryptocurreny:ec2/bitcointool.b/dns”

This rule and its associated findings indicate one or more resources have communicated with known crypto mining domains.

Clicking on the rule – we can drill down into individual resources that have had this finding flagged against them.  We’ll explore an individual resource to learn more about the finding, the resource details, and even the history of the resource.

Starting with the finding’s details:

We can observe that this EC2 instance – which appears to belong to a Kubernetes cluster has been observed communicating with the xmr.pool.minergate[.]com domain. This could indicate that a pod being run on this Kubernetes node was created or hijacked and is leveraging the XMRig mining software to mine Monero cryptocurrency.

For this example – we can drill down into a specific resource and review it in more detail.

Drilling down into a specific resource allows us all to see all the other findings related to this resource. We can observe this by clicking on the dropdown of the resource identifier on the top left of the screen.

There are 8 findings against this instance that should raise our suspicions that this EC2 instance is potentially compromised.

Reviewing the “Resource Overview” tab reveals more details about the EC2 instance.

Based on the tags on the EC2 instance, it would appear this is likely a Kubernetes cluster being managed via KOPs.  KOP’s is an installation, upgrade, and management solution to allow users of the tool to deploy Kubernetes clusters quickly and easily.

We can review the current and historical configuration changes that were made against this EC2 instance directly in CloudHealth Secure State.  By clicking on “View Detail” at the top of the “Resource Overview” – we can observe the lifespan of this instance in terms of configuration changes that occurred against it.

CloudHealth Secure State can record the lifespan of this EC2 instance – and as we can see – it has existed since November 16th of 2021.

Instance Findings

An instance that is a member of a KOP’s Kubernetes deployment was observed to be communicating to a known crypto-mining domain.

We were able to track down the name of the Kubernetes cluster and ultimately were able to observe that there was indeed – an XMrig mining pod running in the cluster – under the name of “kube-proxy” in an attempt to blend-in.

Closing Thoughts

CloudHealth Secure State is a valuable tool for Incident Responders and Threat Hunters alike to be able to assess and explore multi-cloud environments and mitigate risks. Being able to ask a question about resources across all cloud accounts is a powerful capability.  CloudHealth Secure State provides great insight into the security posture of resources and helps identify threats such as observed brute-forcing attacks. The aggregation of findings for a resource allows security teams to understand the risk a resource is facing. This aggregation alone can provide enough information to determine if a resource is at risk or has been compromised.

CloudHealth Secure State is an excellent aid to have in your toolbelt – whether it is for a threat response or a threat hunt. As VMware is a multi-cloud organization – tools such as this are more valuable than ever before.

To learn more about how CloudHealth Secure State helps global organizations improve their cloud security posture, feel free to get in touch with our team directly.