Offensive Defensive — the art of cybersecurity

Offensive Defensive — the art of cybersecurity

Hello fellow readers ~

In our previous article Balancing the trinity of SIRO , we shared insights on:

• what a Security Incident Response Officer (SIRO) does on a day-to-day basis, and
• the reasons why we embark on the journey of improving and enhancing the area of operation through the usage of tools and workflow

Since SIRO also conducts penetration testing, we’ll be focusing on how SIRO plays an important role in understanding both the offensive and defensive sides of the house in this article!

To allow the readers to have a better understanding of the context, we will be using a simple capture the flag (CTF) together with “Assumed Breach” scenario to explain the attack techniques used by the “Red Team” and also the countermeasures that can be used by the “Blue Team”.

A red team is a group that pretends to be an enemy who attempts a physical/digital intrusion against an organisation at its direction, and then reports back so that the organisation can improve their defences.

A blue team is a group responsible for defending an organisation’s network and system by regularly assessing the effectiveness of existing security controls, identifying potential vulnerabilities, and performing prioritised remediation efforts to maintain and improve organisational security posture against known and emerging threats.

Setting up the CTF

For this CTF, the setup is as shown below:

As mentioned previously, we will be using the “Assumed Breach” scenario. The details of an “Assumed Breach” can be found in a blog post by TrustedSec.

Unleash the offensive techniques

Since this is an “Assumed Breach” scenario, the CLI Access Key of “dino-s3-user” and details of what this user can perform in the environment were given to the SIRO. SIRO then proceeds to draft a simple plan to lay out the activities to be done in this scenario.

1. Conducting situational assessment from the given details
2. Studying the possible resources that might exist in the environment
3. Studying the naming format of the resources in the environment
4. Performing privilege escalation
5. Performing post-exploitation persistence

With the given access and details, we will, first, need to conduct situational assessment to get a better understanding of the environment. We start by loading up the CLI Access Key and then assume the role to access the resources.

With this situational assessment completed, we observed the following:

1. The role name has a convention of “dino-{aws-service}-customer-managed-role”.
2. The s3 bucket name has a convention of “dino-s3-{verb/noun}”.
3. Currently the assumption is that there’s only S3 related resources in this environment.

With the investigation and assumption completed, let’s try to apply role-guessing technique by constructing a short list of possible roles which we might be able to assume:

• dino-ec2-customer-managed-role
• dino-ecs-customer-managed-role
• dino-iam-customer-managed-role

Before we begin to do the guessing technique, we need to revert to the initial user “dino-s3-user” and then perform the technique. Notice that the assumed role action was successful on the 3rd entry — this means this role is possible for the user “dino-s3-user” to assume.

Once assumed, we will try to conduct situation awareness again by checking the policy and details associated with the newly assumed role.

From the result, this is what we noted:

1. The “dino-iam-customer-managed-role” role can be assumed by both users
2. The role was given highly permissive IAM rights
3. The given overly-permissive IAM rights allows the possibility to perform privilege escalation by altering the policy attached to an user

Since this is a simple CTF, we will keep the privilege escalation to specific resources to demonstrate the technique to perform privilege escalation through attaching a new policy. To privilege escalate the rights of the initial user “dino-s3-user”, we will do the following:

1. Create a new policy with full S3 rights on all the S3 resources
2. Attach the policy to the user
3. Access the hidden S3 bucket and view the content

Notice that after performing the privilege escalation, the initial user “dino-s3-user” has the access to the other bucket to view and download the content. Hence, this successfully demonstrates one of the many offensive techniques that can be used to abuse and compromise resources that are on the cloud!

Unleash the defensive countermeasures

We’ve just seen how the “Assumed Breach” scenario, together with various offensive techniques, were applied to successfully validate and identify possible misconfiguration that can be abused when an actual breach happens. The question is then back to:

“How can we actually prevent or reduce the likelihood of such techniques that can be used to perform the takeover of the cloud environment?”

The list of possible answers for this question will be:

• Conducting regular review of the resources that are created and managed by the team to identify if the resources have any misconfiguration or overly permissive rights. In this case, the role “dino-iam-customer-managed-role” was misconfigured to allow another user “dino-s3-user” to be able to assume as supposed to only allow “dino-iam-user”.
• Using tools such as Prowler, Scout suite to conduct regular Cloud Vulnerability Assessment (CVA) to identify signs of misconfiguration or overly permissive rights. Noticed that the policy “dino-iam-customer-managed-policy” has overly permissive rights that might be required for operational needs but was abused due to the misconfiguration on the role.
• Detecting and monitoring the activities inside the environment. Notice that the role guessing technique will perform a number of CLI calls to the environment to validate and check if the role is available and able to be assumed by the current user. If there’s detection and monitoring setup on the environment, this technique can be discovered and allows the team to perform containment actions (disable the CLI key) and eradication actions (regenerate a new set of CLI key).

To end this article, it is always good to understand the techniques that are used by both “Red Team” and “Blue Team” as it gives an edge and is able to bring across key technical information to the various product teams when conducting triaging, incident response , penetration testing and also consultancy work.

In times of any cybersecurity incident , it allows the SIRO to communicate and bring the “right set” of knowledge and technical terms to communicate with both internal stakeholders and also external cybersecurity teams that were brought in to conduct deeper triaging.

We hope this article will help you start the journey on understanding the offensive techniques and defensive countermeasures that can be adopted to achieve a more secured and hardened cloud environment. You can refer to the MITRE ATT&CK for the list of TTPs used and MITRE D3FEND for the list of countermeasures.

Do share and discuss in the comment section below on your own experiences. Till then, stay safe and keep learning!

🧙🏼‍♀Team Merlin 💛
Application security is not any individual’s problem but a shared responsibility.

Offensive Defensive — the art of cybersecurity was originally published in Government Digital Products, Singapore on Medium, where people are continuing the conversation by highlighting and responding to this story.