Thread by @Frichette_n

Today is an interesting day! I read a report about a threat actor, and for once I'm impressed! This is the first I can remember in which a TA has displayed NEW tradecraft, before researchers have shared it widely. Let's review in this 🧵
invictus-ir.com/news/the-curio…

Okay, starting off rough. There was an access key that was exposed that had AdministratorAccess. This happens way too frequently and is always a major risk. Security Teams: Delete these keys and these IAM users! They are a major risk to you. Let's see what the TA does with this

It's important to note, unless the IAM user was named something like "Admin", the TA has no idea what permissions are associated with the user. They have to enumerate those. They start off a little silly, immediately checking for SES access which is a major focus for bad guys.

However, I do have to credit them! They not just blindly spamming API calls. This was not a smash and grab, which is rare for a cloud intrusion. Good on them for going low and slow.

This line floored me. No trace of them running sts:GetCallerIdentity! It could be that they just didn't try it, or (and bear with me) maybe they got that info silently!

Here's the thing - they are in a tricky spot and they MIGHT be able to guess that they have AdminAccess but they don't know for sure. Most attackers run sts:GetCallerIdentity to a) learn if the keys work b) know what account they are in and c) get the user name.

Calling sts:GetCallerIdentity though is not a good idea because it leaves a trace in CloudTrail and you want to avoid leaving artifacts as much as possible. hackingthe.cloud/aws/enumeratio…

Here's the thing though, they have admin access. If they make a call like sqs:ListQueues, it won't log to CloudTrail, but it WILL work. So from that alone, what are the odds it has that permission and doesn't have AdminAccess? Pretty low.

If they really wanted a quiet way of getting their identity, they could try an API call that doesn't log to CloudTrail cross-account. If they have admin (which they probably suspect at this point), any API call they make would work (which wouldn't silently give them the info)

Cross account though, it would! So they may have tried something like sns:Publish which is a Data Event, and does not log by default. Because it's cross account they would see a Deny error with their identity. hackingthe.cloud/aws/deprecated…

This is a bit of a stretch because I don't think anybody has documented this use case. But I will add it to Hacking the Cloud so it is more explicit. Totally possible they didn't do this, but we have no way of knowing because it doesn't log to CloudTrail 🤷‍♂️

They next created an IAM user. Creating a user is smart but a role would have been smarter. Creating a new identity is a good idea from a "I don't want you to notice my suspicious API calls" point of view, because this new identity doesn't have a history that can be compared to.

It's not weird if it starts calling all IAM API calls because there is not history to compare it to. You are still at risk for other detections related to suspicious API calls but by doing this you have limited your overall exposure. Smart.

They attached AdministratorAccess to this policy which I think was a bit of a blunder. Creating new users with AdminAccess is a common detection which could have caught them if the defenders were REALLY on their toes. Instead, they should have...

written a custom policy with the services they were interested in. You don't have "AdministratorAccess" but who cares about that when you have s3:*, ec2:*, lambda:*, secretsmanager:*, iam:*, etc.

Again, using the new user for enumeration was smart for previously stated reasons. I would have liked it more spread out rather than doing it over the course of an hour though. They already waited two weeks to do this, why not do it OVER 2 weeks instead?

This is especially disappointing considering the previous mention that they appeared to be doing this using automation and not hands on keyboard.

The next surprising thing to me was that they pivoted a bit and decided to maintain persistence from IAM roles they created and attached AdministratorAccess. Why didn't they do this from the start?

To my knowledge, this is the first time a threat actor has been identified to be using their own attacker controlled AWS accounts! (CTI people correct me if I'm wrong). This is huge for me personally as in my old pentesting days, I demoed attacks where I used..

an attacker-controlled AWS account for various things and the client responded with, "Real hackers don't have AWS accounts to do this though. You need a credit card!". I had to explain that there are loads of ways an attacker could get their hands on an AWS account.

And now I have a public reference to point to! I'm so happy! Security Teams: Do you have roles in your account with a trust relationship to 265857590823 or 671050157472? Go check that!

This next part I was absolutely stunned at. They used iam:SimulatePrincipalPolicy for permission enumeration!! This was a technique that I had on the backlog for Hacking the Cloud, and I don't <think> anyone has talked about this publicly.

The idea behind it is this: You want to know if you can perform an API call. Even if you have AdminAccess there are still SCPs and resource-based explicit denies which can block you. If you call secretsmanager:GetSecretValue and get an error, that may be suspicious for a SIEM.

How do you check if you CAN access something? Well, use iam:SimulatePrincipalPolicy. You can paste in your ARN, the action you want to perform, and the resource ARN and it WILL TELL YOU IF YOU CAN PERFORM THE CALL! Further, while a CloudTrail log entry exists,

it will be for iam:SimulatePrincipalPolicy which I think few services are tracking. Again, this was a hypothetical technique, I don't think anyone has talked about it publicly or has any research out there about it. There are other uses for it as well, for example,

If you want to spread out your identities in CloudTrail, you can test if OTHER roles/users have access to something so you don't get caught by things like this. docs.datadoghq.com/security/defau…

Again, this is really smart and indicates an attacker who....actually knows what they are doing? When so many TAs just blindly spam their enumeration and brute force stuff, it's crazy to see an attacker demoing NEW tradecraft, before cloud researchers do.

This next one really scared me because it felt like a 0day. What do you mean you can read GuardDuty from RDS?!?!? As it turns out, this will happen normally from just browsing the console in RDS. It has a proxied call

Ultimately they got caught for boring reasons. They tried to increase the SES quota, created a support ticket, someone saw that and said, "....wut". And they got caught. A shameful end to what was otherwise a well-organized (if occasionally mistake prone) intrusion.

What does this mean for cloud security practitioners? Threat actors are getting GOOD now. And that is scary. Your average AWS attacker is no different than a junior pentester copy and pasting Pacu commands on their Kali linux box. To an organized detection engineering

team in an enterprise, they would get rolled up quickly. But this? They thought about it. They demonstrated tradecraft that was thoughtful. They cleaned up after themselves. This is a cloud actor that is an actual threat. Did they make mistakes? Yeah. Could this be

optimized? Definitely. But if this becomes the new bare minimum, I think we are in for a rough time in the cloud security industry. Now more than ever we should be exploring cloud services for flaws, vulnerabilities, and new ways to attack them.

One last thing here. I know this is a LOOONG shot, but I want to mention. If an attacker is thinking like this, and trying out weird tradecraft for defense evasion, they might also be thinking about bypassing CloudTrail. We have no way of knowing if they did that (only AWS does)

But I've done a LOT of work in this field, and I know there are a ton of opportunities for it. It's entirely possible they did and that some of that activity is not visible to the authors of the blog post.