Richard Fan: [00:00:00] It is a very dangerous agent because it is basically doing cyber attack. One of the vulnerability I find is I got the reverse shell into the environment.

Ashish Rajan: If I start the pen test and it goes to that URI which is not in scope, can I stop this, or I just have to wait and see what happens?

Richard Fan: But it's just simply a promise from the AI agent, and we all know the promise from AI is not guaranteed.

Ashish Rajan: A lot of people perhaps want to do a pen test and not wait six months.

Richard Fan: It just run for around one hour, and then it cost me almost $200 already. I think it is a very low level, stupid mistake. This security agent is very capable, and is so capable that I'm worried about the people making the guardrail is being outsmart by the AI.

Ashish Rajan: If you don't know what AWS Security Agent or AWS Continuum is, I had a great conversation with Richard Fan. He is an AWS security hero, and he did some research on what is it like to use AWS Security Agent, what are some of the things that, let's just say, were, quote unquote, "interesting findings." And we [00:01:00] also spoke about the possibility for who should use it, when should you not use it.

Definitely do not use this in production. And where does the line for shared responsibility now change when your cloud provider starts doing pen test of the applications you're hosting, either internally or externally. All that and a lot more in this conversation. If you know someone who is looking at perhaps using some kind of agentic capability for pen testing their cloud infrastructure, specifically the application, not the EC2 instance.

And as always, if you have been finding the episodes of "Cloud Security Podcast" valuable and have been here for the second or third time, I would really appreciate if you take a quick second to hit the follow, subscribe button, whichever podcast platform you listen to us on. We are on Apple, Spotify, YouTube, and LinkedIn, and wherever you listen to your podcasts from.

I hope you enjoy this episode with Richard, and I'll talk to you soon. Peace. Hello, and welcome to another episode of "Cloud Security Podcast." I've got Richard with me. Hey man, thanks for coming on the show.

Richard Fan: Yeah. Hello, Ashish. Thanks for having me.

Ashish Rajan: We've been... I think we have known each other for a while, and I'm so glad that we finally get an opportunity to have you on the [00:02:00] podcast.

Maybe to set some context for people who may not have heard from you before, could you share a bit about yourself and your professional background?

Richard Fan: Yeah. I'm a AWS Security Hero. I'm from Hong Kong, and actually I did quite a lot of thing on security research, but I think most of them are just halfway done.

That's why I cover a lot of area. So previously I did something on the Nitro Enclave. If somebody doesn't know, it's a confidential computing on AWS. And then I pivot to doing the supply chain security research as well. I did some research on Sigstore, and also gave a talk on Sigstore Con. And when the AI era cames, I was also interested on all the AI security stuff.

And then I think last year, AWS s-start to offer the AWS Security Agent, which- It's exactly my expertise. I'm an AWS security hero. I know a lot of AWS stuff, and they have [00:03:00] AI security agent which do-- I use AI to do security stuff. So I, I did some research on that, and luckily my research got some result.

And also I gave a talk in this year fwd:cloudsec in London about my research.

Ashish Rajan: Awesome. And thank you for sharing that 'cause that's is also a good segway into the topic that we have. Maybe to set some context, 'cause a lot of people may not be from the AWS ecosystem, 'cause AWS has a few... It's called the AWS Continuum.

Could you explain that and also share a bit about AWS Security Agent, how they fit together, and what the relationship between the two is?

Richard Fan: Yeah. So actually the AWS Continuum you described is actually the new name of AWS Security Agent. I did a joke on my fwd:cloudsec talk that AWS naming used to be confusing, and I believe Security Agent is too obvious.

That's why AWS decided to change the name to Continuum.

Ashish Rajan: Yeah. That's fair. It's the same thing, but hey, it's so obvious people know what that is, so [00:04:00] let's just change the name.

Richard Fan: Yeah. Yeah, probably. But anyway, the security agent is, I would say, a managed agent to do security stuff. So there are few area the product focus, the code review, which I think a lot of people do is using the- AI to scan your code for some security issue.

And design review and threat modeling is to- ... take your threat model requirement and also your document. You can basically throw in all your document into it and connect with your code, and it will help you to do the threat modeling and do the design review on the security aspect.

Ashish Rajan: Yeah.

Richard Fan: But the most interesting feature is to do the autonomous pen testing.

So basically, is it will spin up an AI agent, and you can point it to your web app, and it will just do the automatic pen test, which is, I think, is really interesting.

Ashish Rajan: Interesting to also call out then. So does it help with the code review pieces as well, [00:05:00] or is it just the pen testing piece?

Richard Fan: Actually, the customer can choose what to use, but how they structure the product is that you can connect a lot of things.

Your GitHub repository, you can connect to the agent. You can give it some knowledge, like your design document or whatever document you produce for the product. You can upload to the agent. You can also choose not to do that, and which it will become like a white... black box pen test versus a white box pen test.

You can if you connect the, your repository to your agent, and the agent will have the context on how your web app works, it will help a lot on the pen test process because first of all, the agent know which endpoint to pen test and what specific issue need to be taken care of. Instead of black box pen testing you burn a lot of token just to do the reconnaissance.

And also after the pen test, if the agent finds some findings, it will help you to link to the specific line of codes which the vulnerability is caused.

Ashish Rajan: But would you say, 'cause you know how basically you called out [00:06:00] the fact that like an SDLC has all these different components where you have threat modeling, code review.

So to be specific, I guess security agent helps with the security assessment or slash pen testing or assessment, like security assessment, whatever you may wanna call it, for the code or an application. It's not for threat modeling. It's not for... you can use the information from security agent for threat modeling But it's not a threat modeling software or service.

Richard Fan: I... Actually, I don't know how AWS position the product because out of the four capabilities, only the pen test capabilities is GA, general available.

Ashish Rajan: Oh, okay.

Richard Fan: And all the other three capabilities are just, they are s- they claim they are in preview, but it's preview for a year. So I don't know how they position the product, but I would say the whole product of Continuum is something like better than nothing.

If you have a, a security team in your company, [00:07:00] you do threat modeling yourself with the help of AI, of course, instead of just throw in whatever document you have to the agent and hope for the best that the agent will help you do the threat modeling.

So I would say it's not a dedicated threat modeling software, but it's better than nothing.

If your company is small or your team doesn't have your dedicated security team support it may help on something. Because I also want to share my experience before the AI era. I work in a security team, and we used to have a call security partner program. Yeah. Basically it's, I will be embedded in several application team, and I will join their meeting and then help them to observe their software development life cycle and help them to understand how to threat model.

And most of the time is that I feel difficult to explain to the team how to do threat modeling because it's just like a creative game. You imagine all the scenario but if you're not security-minded [00:08:00] person, you don't know what to expect what to think of. So that's why I think with the Security Agent product, it will help a lot for those team just didn't know how to start.

Ashish Rajan: And to your point, it's a good starting point for people who would like to pen test. But I'm also curious in terms of the findings you had. There were quite a few interesting things. Maybe if you can expand on some of the... Without me naming them, I'm curious, there are a few things you called out in your talk, which I'll highly recommend people check out on fwd:cloudsec Europe's YouTube page.

I'll link the talk in the show notes as well. What did you find as you explored AWS Security Agent or AWS Continuum now? What, when you used AWS Continuum- I would

Richard Fan: love to call it Security Agent because- Yes ... Continuum is just so

Ashish Rajan: hard to pronounce. AWS Continuum, when you used it what was your finding like?

What were some of the things you found as, "Oh, this is interesting"?

Richard Fan: Yeah. So to be clear, the findings I found is not the same finding the agent find. Because- Oh ... when- whenever people say a pen test finding is, "I use a pen test agent to find some vulnerability on my website," that's the finding. Yeah. But [00:09:00] this is not the finding I found.

Interestingly, my finding is on the Security Agent itself. So what I try to do is... back to the background. Last year, I think it's late last year when AWS just published this service. What I was thinking is, "Hey, this is agent." So I... Maybe I would say it's a very dangerous agent because it's very capable of attacking something.

So I just want to know how dangerous it is. So I tried to exploit the agent to do some damage to see how far it can go. So what I do is I created a intentionally vulnerable website- ... and used different prompt, different infrastructure configuration trick to see how the agent... how I could trick the agent to break through the guardrail.

So before I go through the detail, I want to briefly talk about the guardrails AWS put into the agent so that I can- Yeah ... explain how I bridge it. Yeah, sure. So first of all is, yeah, first of all is, as I say, this is a very dangerous agent because it is basically doing cyber attack. So AWS [00:10:00] doesn't want anyone to use the agent to "Hey," today some customer go and say, "Hey help me pen test google.com, see what google.com has, has vulnerability."

"Hey, go attack attack amazon.com." So they don't want to do that, so they have guardrails on the domain ownership. Yeah. Just like you, you issue a SSL cert on your website, you need to prove your do- the domain is owned by you. Security Agent do the same thing.

They require you to put the token into your DNS record to prove you are the owner of the website.

Ashish Rajan: Yep.

Richard Fan: Without that, the agent will refuse to do the pen test on the target website. But they also have feature is to pen test your internal website inside of VPC. And if you are pen testing your internal website, internal DNS record, that means you can have whatever DNS record inside your internal DNS, because you can have your internal DNS for amazon.com.

It's controlled by you because it's not a public DNS record. You can do whatever you want in your internal

Ashish Rajan: DNS. Oh, wait, so is it testing the AWS infrastructure that has been given to you as [00:11:00] well?

Richard Fan: It's pen testing... Let's say I have a EC2 instance inside my VPC.

Ashish Rajan: Yeah.

Richard Fan: I can point the agent to pen test my internal EC2 instance.

And that EC2 instance, I can name it whatever I want because it's an internal website. Yeah. I can name it amazon.com. Yeah. I can name it google.com because it's using my internal DNS record. So what I do is I try to pen test amazon.com. Actually, it's not amazon.com. It's another website that, that is owned by me, but I pretend it's not owned by me.

Of course I don't want to pen test amazon.com and got... being got got sued by Amazon.

Ashish Rajan: Oh,

Richard Fan: yeah. Fair. But yeah. But the idea is I create pen test, autonomous pen test internally targeting my VPC, call it amazon.com, and then I have my DNS record point to my private IP. Let's say 10.0.0.1, okay?

Yeah. And then the agent will do the typical DNS verification. Of course, I can put a token into my amazon.com DNS record [00:12:00] because- Yeah ... it's my internal host system. I can do whatever I want. Because self-hosted- I'm not touching the public amazon.com ...

Ashish Rajan: is it still Route 53, or is it... 'cause-

Richard Fan: Yes, Route 53. Route 53, private host system.

Ashish Rajan: Oh. And then- 'cause I was like, how are you gonna get the amazon.com as a publicly listed domain? Not

Richard Fan: public- '

Ashish Rajan: Cause you won't be the- ...

Richard Fan: but the private.

Yeah. But by the desi- by design, if you are pen testing a privately owned network-

Ashish Rajan: Yeah ...

Richard Fan: it will use the private host system. Okay, so I point my internal amazon.com to my private IP, and then- the security agent verify the token, and then start the pen test. At that time, I changed my private DNS, point amazon.com to the real amazon.com public IP, and the agent follow that modified DNS record and start pen test the real amazon.com. So this is the first finding I, I found, which I think is pretty...

I would say it's pretty stupid If you are talking to a human pen tester. To a AI pen tester, I don't know how to call it. [00:13:00] But to a human pen tester, I think it would be really stupid because if you are a human pen tester, I tell you I'm pen testing amazon.com, first of all, you'll be suspicious. Why you ask me to pen test amazon.com in your internal network?

What is your intention? Yeah. Yeah. First you will have this, this kind of thing. Even though I convince you that, "Hey, this is only the private pen test," you'll be extra cautious because you don't want to be accidentally pen test the real amazon.com.

Ashish Rajan: Yeah.

Richard Fan: But the AI agent just ignore this fact. It just forgot that it was validating against a private IP, but then they are pen testing the public IP.

So I think it's just a context switching between two agent, two brain. The first agent validate it is, "Oh, I'm pen testing a private amazon.com." And the other agent comes in and do the real pen testing, didn't know what was going on. It just look up the DNS record again, and this time it's a public IP. "Okay, I trust you.

I pen test the public amazon.com."

Ashish Rajan: So do you reckon this is the missing context piece that you're referring to? So it d- it may be [00:14:00] a... To what you said so if I were to put this in a- another way, if you were, instead of being a AWS security hero who is very deep into AWS security's ecosystem, if you were a malicious person who just basically happened to have a GitHub repository Or a, let's just say a digital twin of the Amazon ecosystem.

You could literally just pen test that thing using AWS Security Agent internally and find out the flaws of it, and basically just move forward if you wanted to. Would that be a fair statement? 'Cause what you did where you did host a amazon.com domain and it recognized it, started pen testing it.

Yeah. And I'm just taking your example a bit further where it's not just a domain. What if the repository underneath that or what if the infrastructure that you have underneath that is a digital twin of the crawl you did of the AWS websites, and it finds a, I don't know, I'm just making up shit here, but hey, like what if it finds a XSS or a IDOR or, which is basically like a, "Hey, I just changed a parameter on the URL, and suddenly I'm in a different domain."

You could extend the example to other things as [00:15:00] well, or am I just making it too complicated? It just stops at the DNS part, and that's the end of it.

Richard Fan: No, I, actually I think it's a very good point because I never think of it from this angle. And then you start triggering me to think what is a legit pen test by

Ashish Rajan: definition?

'Cause I could be a malicious person, and I just happen to have... 'cause, and the only reason I thought of this is because these days a lot of the open source repos, and everyone uses open source, if I know that Amazon uses, and I don't wanna give any ideas to any malicious people who listen to this. You almost wanna be-

Richard Fan: Whenever the PHP.

Using

Ashish Rajan: PHP. Yeah. Let's just say PHP involved. Actually, PHP just did have their,

Richard Fan: Yeah,

Ashish Rajan: exactly ... massive vulnerability as well. It's a very bad dream. So I would be mindful of that, but I think it's the, the notion is that internal is an interesting one, and I wonder if they perhaps need to consider having some kind of a verification for even if it's internal, you should still be able to do a domain verification.

'Cause, to what you were saying earlier, and I think in your talk you called out as well that if you wanna pen test a public site, you have to do the domain verification.

Richard Fan: [00:16:00] Yes. Yes. But now I think of it's about the infrastructure and data versus the code. So of course, if, I don't know, let's say amazon.com one day publish their webs- web app source code on GitHub.

Yeah. I think of course you can duplicate the infrastructure and pen test their source code, but what you cannot do is to extract the customer information from their website. Oh,

Ashish Rajan: Yeah.

Richard Fan: That- Or what you can do is, what you cannot do is break down their real website. So I think there's a distinction on why a security agent require you to prove the ownership is to prevent it- Making real damage to the innocent production environment-

Ashish Rajan: Yeah

Richard Fan: or

Ashish Rajan: the data. I think may- where I was going with this was that, obviously you're talking about amazon.com, which is a very big target, but malicious users will look at the smaller ones, the manufacturing lawyer or anyone else. But this is interesting. And so you found some other things as well.

What would be some of the other things you also discovered as part of your... Obviously, this was broken scope, basically. Yeah. [00:17:00] Internal DNS, you could point to anything domain and just works. What were some of the other things you found as well?

Richard Fan: This one is interesting. It's about redirecting the attack to the other website, which is not even inside the target list.

So the previous example is, I want to target amazon.com, so it is just the verification is broken. So this one redirecting is something I am targeting website A, but suddenly throughout the pen test, the agent started to pen test the website B, which I didn't ask it to do. So what happened is I built two web app let's call it website A and website B.

So what website A do is do a HTTP redirect to website B. So whatever URL you're going to website A, it will redirect you, a 301 or 302 redirect to website B. And then after a few iteration, the agent believe that, "Hey, why website A always [00:18:00] redirect me to website B? Maybe website B is the real website behind website A.

Let me pen test website B." So what I basically achieve is that I can have my website, my own website, have nothing, just HTTP redirect to amazon.com.

And then the agent will keep pen test my website and then suddenly think, "Hey, why amazon.com is always coming up? Maybe I should pen test amazon.com."

Ashish Rajan: Oh. Wait, so is that because you were not defining it as out of scope and, or is there no capability for us to define out of scope domains in it? I'm gonna say AWS Continuum now, but it in AWS Continuum. Sounds a bit odd to say AWS Continuum, but let's just say for simplicity of this conversation so people understand what we're talking about.

AWS Security Agent, can you define out of scope, in scope even if there is a URL? 'Cause many people have third-party URLs on their websites.

Richard Fan: Yeah, you talk about URL, I can talk about it later, but to your original question about firewall it is, and it's quite [00:19:00] conservative. So basically, it's a whitelist, not a blacklist.

Okay. So what they do is you can put your target URL into your pen test. It will actively do the pen test on, on, on those domain, on the target domain, which you need to verify, of course. You have additional allow URL you can put. So the rationale is, let's say your website need authentication, third-party authentication.

If the firewall is blocking the OAuth request, then the agent cannot log into your website, then it's meaningless without authentication i-if you're asking the pen-pen test agent to pen test your website. So-

...

Richard Fan: They have the additional allow URL list you can add to it, and the firewall will only allow the outbound traffic from the agent environment only to the target domain and the additional allow URL.

The distinction between target domain and additional allow domain is the target domain you need to verify, and then the agent will do the pen test. Additional URL, you don't need to. You can put [00:20:00] whatever URL you want into it, and the request still go through the firewall, going to the real website. But the agent promise not to pen test it.

But it's just simply a promise from the AI agent, and we all know the promise from AI is Not guaranteed. So this is how I do my experiment, is that I put my website A domain into a target domain which I own, and I put the website B domain into the additional allow list. Without doing that, even the agent is so stupid that follow the HTTP redirect, their request will not go through the firewall.

I think it's a good decision from AWS to do the whitelist approach of the firewall, but it's just it's not perfect because the distinction between pen testing a URL or not is really based on the agent.

Ashish Rajan: And this is good also because it gives me some confidence that Amazon is doing...

I... Was there another finding? 'Cause I also wanted to explore some things like shared responsibility and stuff as to regular pen test, there's a contract and everything else. But before I jump into it, was there any other finding that [00:21:00] you wanted to share with people that was interesting from your talk that's worthwhile mentioning?

Richard Fan: Yeah. It's about the, also the block list, which I talk about. So basically if you're very concerned on let's say I auth0.com into my additional allow URL because your website use Auth0 to do the authentication, but you are so paranoid that, oh, maybe the agent will go wild and go pen test Auth0, what you can do is to specifically put the URL, the API URL that is required in your pen test, specifically putting the full URL into the allow list.

Any requests, like if auth0.com/documentation is not in your allow list, if the agent try to access auth0.com/documentation, then it will not go through. But the funny part is, I found out this URL allow list is just a prefix only. So I made an example during my talk is, if I allow the agent to go to a website /log, [00:22:00] log-

It can also go to /login, log in, because it's just a very simple prefix match.

Ashish Rajan: Oh, so it's it wants like an asterisk or a star or whatever it's called,

Richard Fan: no There is no wildcard or whatever. You put /log.

Ashish Rajan: Yeah.

Richard Fan: It's just prefix match. L-O-G whatever behind it is also allowed.

Ashish Rajan: Oh, interesting.

Richard Fan: I think it is a very low-level stupid mistake.

I don't

Ashish Rajan: know. Yeah, but I guess to your point, that kind of goes even if it's like, obviously... Maybe that's a good segway into the, the shared responsibility thing as well, right? So when as a CISO of putting a request for a pen test or work with a third party to do a pen test, there is this understanding that, hey, I have a contract with them.

I have called out in scope, out scope, URLs and slash domains and everything. I don't s-... I may say wildcard, but in some cases just like, "Hey, just the homepage," 'cause there's, it's a single page app or whatever. But also in some cases you say, "You can go to any domain except for /login," as you mentioned, or [00:23:00] only- Yeah

do /login and nothing else. So you're saying that granularity of a slash URI is not possible today?

Richard Fan: Not possible. If you want it to only do /log, it's not possible because L-O-G and then whatever appended behind- Yeah ... is still allowed. So you cannot say... Un- unless you specifically put the login into the deny list.

There is a deny list you, you can put, but you cannot enumerate every possible- Yeah ... combination into the deny list.

Ashish Rajan: And I guess it's also assuming- That have a log

Richard Fan: now, right?

Ashish Rajan: Yeah, but it's also assuming you know yourself what the subdomains, or not subdomains, the URIs are that developers perhaps not, have not documented, but is actually still available or used to be an old website, but no one decommissioned it.

There could be so many possibilities as well. So I mean- Yeah. Yeah ... it's a good thing for people to know. But how does this kind of change the shared responsibility model? 'Cause obviously you and I have been on this cloud [00:24:00] security quote-unquote, "journey" for a long time, where we heard the first version of cloud security was, hey, the, who owns the infrastructure Who owns the data?

And then, hey, what's- Yeah ... the gray line between who owns, who is custom-- what is customer responsibility and what is the A- Amazon responsibility? In this particular case, what do you see as that change compared to that third party example that I said earlier, where I can actually find the person who actually is doing the pen test?

'Cause I also imagine if I start the pen test and it goes to that URI, which is not in scope, can I stop this or can I just basically, I just have to wait and see what happens?

Richard Fan: To be fair, you can stop it.

Ashish Rajan: Okay.

Richard Fan: Because you can monitor the process, and if it's you think it's go wrong, then you click stop run.

But as a human, I don't think you can monitor because it, it's not a single-threaded agent task. It's a, a lot of parallel pen test tasks happening at the same time. So I don't think it, it's feasible for a human to pen test, to monitor the pen test and stop it. And then [00:25:00] for your question about responsibility, I think there is one more variable here is the AI itself.

Because how to say that? Before the AI is a thing, so the shared responsibility is AWS is taking care the security of the cloud. And then, I don't know if I mess up the terminology, but, and the customer is, it's responsible for the security- In the cloud ... in the cloud.

Ashish Rajan: Yes.

Richard Fan: Yeah.

Ashish Rajan: That's right.

Richard Fan: But in this case, the AI agent, i- is it...

I think it's a security of the cloud because the AI model, it's for security agents specifically, the AI agent, the runtime, the available configuration are all provided by Amazon. But I think what Amazon want to s-say is that you need to use it in the right way. You cannot intentionally trick the agent to do this or to do that.

But what I would argue is, in the past, if there's no AI, if I [00:26:00] intentionally doing something wrong, then of course it's my, as, as me as a customer, are responsible for it because I misused the cloud. But now AI has its own thinking. I can claim that I'm not intentionally tricking the AI to do bad thing.

Just like the example I mentioned, the HTTP redirect.

I... My website doing HTTP redirect to amazon.com, it looks weird, it looks suspicious, but I'm doing it legitimate. I can redirect my website to any web, other website legitimately, and it's now the AI agent has taken this redirect as a redirect of the pen test scope.

So is it me doing bad thing tricking the agent or is it Amazon failed to do their guardrail, their responsibility of safeguarding the model? I think this part is not very clear.

Ashish Rajan: And I guess to your point, what's your recommendation to people who want to use this service? To what you said, there is a clear segway [00:27:00] into what is, like what it's doing.

You can pause it, you can define the scope, allow list, deny list. There is all of that available for people who want to use it. What are you calling out as, hey, if you're using this service Be mindful of this. I think say, would you recommend it for production internal hosted applications?

Is that something you recommend? Yeah,

Richard Fan: of course. Of course. Not production. Not production.

Ashish Rajan: Okay.

Richard Fan: Because it is also specifically called out in the official documentation is never use the pen test on production-

Ashish Rajan: Oh,

Richard Fan: okay ... workload. Yeah. Because what they say is, "Although we promise the agent won't do harmful action to the environment, but the guardrail is may go wrong.

So our promise may not be guaranteed, so just don't do it on production."

Ashish Rajan: Yeah, I think so. It's like one of those warning signs where, "Do not use this in production."

Richard Fan: Yeah. Yeah. Fair enough. But on top of not pen testing the pen te- the production environment, I would say how to protect yourself being sued, not about protecting your [00:28:00] envi- production environment, but about protecting yourself from being sued by other website or being...

your account being shut down by Amazon for some malicious action is, I don't know if it works, disclaimer, this is just my thought, is that when you do your pen test, whatever configuration the security agent provide to you, just use it in very detailed way. For example, if your website using Auth0 for authentication, and you want the pen test to, pen test agent to go through all the auth0.com authentication traffic, don't just put auth0.com into the allow list.

Put the whole API endpoint into it. Whatever API endpoint is required to authenticate to your website, just put it, the list of it. I'm not saying this is a technical thing, because I really don't know why the simple prefix match is being possible in the allow list. So it's not technically blocking any other URL that may be.

The URL is your allow list prefix, so this is not possible. But it's to show your attention [00:29:00] to AWS. If one day Amazon try to shut down your account saying hey, you're configuring your pen test to pen test auth0.com/dashboard/login," and you want to argue with Amazon, you can say, "Hey, I have already detailed the list out all the URL that is required to do the authentication for my website."

And then your agent still decided to pen test the other auth0.com URL, then it's definitely your fault.

Ashish Rajan: Yep. Fair point, man. Fair point. I, and I think there's a lot more consideration to be made on this before people go down the path of using security agent. But I think the way or the, what I'm hearing from you is that it's a great resource for someone to start doing, like going back to the software development life cycle where we started the conversation, a lot of people perhaps want to do a pen test and not wait six months.

You can use this as long as you have the well-defined URI for an authenticated app or maybe you give an unauthenticated version to keep it very precise. This allows for people to have the ability to do pen test. Actually, worth while calling out, when you and I were talking about [00:30:00] this, we should call out the cost piece as well here.

We didn't mention the cost piece at all. So-

Richard Fan: Yeah ... '

Ashish Rajan: cause you know how this is a reminder of when AWS config came out, everyone loved it, wanted to jump on it, but then you realize, oh, this is I won't talk about conflict 'cause that's gonna expose what I, what you should share about the cost behind security agent, the continuum.

What was what's some of the pricing like for this so people are more prepared for, "Hey, can I, should I regulate on that?" It's not a free service.

Richard Fan: It's free when it's preview, but now it's GA, so it's $50, five zero, not one five. Five zero, 50 US dollar per hour-

Ashish Rajan: Per hour ...

Richard Fan: per task. So-

Ashish Rajan: Per hour per task?

Richard Fan: Yes. So as I say, the agent will spin up multiple agent to do parallel pen test for different vulner- kind of vulnerability in parallel. Give you some number is that before my talk, I want to verify my finding. Before the forecast talk, I want to make sure my finding that AWS refused to fix is still there.

So I try [00:31:00] to run it, and then I actually keep monitor the pen test. And when I realized the screenshot I need show up, I just stop it. It just run for around one hour.

And then it cost me almost $200 already.

Ashish Rajan: Wow. Oh, wait, but actually, you know what? This is interesting. Is there some awareness of what kind of model is running in the background?

'Cause a lot of, you know how industry is talking about Daybreak, Glasswing, and all the other popular AI red team kind of tools from the frontier models. Does it actually tell you what it's using in the background? What kind of transparency or logging is available for you to see what's happening?

Richard Fan: No. There are log output you can see how, what action the agent did, like what- Okay ... command it did what is the thinking behind of the model. Or what

Ashish Rajan: tools as well?

Richard Fan: Yeah, what tools i- is being used.

Ashish Rajan: Okay.

Richard Fan: There's the agent tools, but in terms of model, I am not aware of any open source-

Ashish Rajan: No, it isn't like it didn't show you in the logs as to, hey...

'Cause you know how people talk about that, hey, some models are more expensive than [00:32:00] the other, and I wonder if this is an Amazon specific model or are they, are using some kind of a Daybreak or Mythos or something in the background. But that was not exposed as a-

Richard Fan: Yeah, as, as I'm aware, they're not talking about it.

Ashish Rajan: Exposing that. And in terms of logging and tooling that was used, a lot of people may also be thinking about the fact that, popular tools, 'cause you're in the space as well so there's Metasploit, Wireshark, and so many other tools that we know publicly. Does it tell you what public tool is it using, or is it just basically creating it on the fly to do something?

Was there anything that, that stood out in the logs when you were testing it?

Richard Fan: Yeah, they show us. I can't remember Metasploit, is Metasploit in the tool set, but some reconnaissance what was that? The FFuf. What was that? The fuzzing tools, like the do, do the URL, Like a Burp

Ashish Rajan: Suite?

Richard Fan: reconnas- not Burp Suite. It's something just brute force the URL.

Ashish Rajan: Oh. Oh, so it did have a public, like a open source tool that it used to get the URL

Richard Fan: recon.

Ashish Rajan: Ah.

Richard Fan: Yes Interesting ... they are installed. And because one of the [00:33:00] vulnerability I find is I got the reverse shell into the environment.

That's why I can also see what other tools is being used. But I can't remember it right now. But yes, they are tools pre-installed. But I want to share one more finding I,

Ashish Rajan: Sure ...

Richard Fan: regarding this. Let's say there are some guardrail in the environment that some tools are not allowed to use, like some agent tools are not allowed to use.

I can't remember what exactly because it is really long time ago. But what I found is the model is very smart.

It will just run the best script and use that open source tools. So basically is that the guardrails tell the agent, "You cannot use these tools." And then the AI agent just say, "Oh, you not allowing me to use these tools," then I'm spawn- spinning up a batch script to run that tools or spinning up a Python script to run that tools to circumvent the tool restriction.

Interesting. So in my blog post, I also have a [00:34:00] conclusion at the end is that this security agent is very capable, and is so capable that I'm worried about the people making the guardrail is being outsmart by the AI.

Ashish Rajan: Okay. Tell me

Richard Fan: more. So the engineer think if I put a guardrail on the tools that agent can use or cannot use, I can maybe protect someone like me to trick the agent to do bad thing.

But actually, the AI is very smart to just circumvent all these kind of guardrails.

Ashish Rajan: That would be really interesting and fascinating at the same time. Dude, that was great insight into AWS Security Agent, AKA AWS Continuum, which went GA. Hopefully we get to have another round of this conversation when you have more of these other preview services get more exposed.

But where can people learn more about... i'll obviously put the blog link on the show notes as well, your talk from fwd:cloudsec in the show notes as well. Now, where can people connect with you online just to get to talk to you more about the work you've done with the AWS Security [00:35:00] Agent or even, sorry, Continuum, need to change the language, or the AWS security research that you do yourself. Is LinkedIn the best platform for people to connect

Richard Fan: with you? Oh yeah. You can definitely connect me with LinkedIn. And I think you're going to post my blog post there.

Ashish Rajan: I will share your- with the link ... i'll basically share your blog in the show notes as well for people to have a look at it, but also the fwd:cloudsec talk too.

Yeah. But man, dude, I appreciate the time. I do have three fun questions for you as well, which I normally ask people on the "Cloud Security" podcast. The first one is, what do you spend most time on when you're not working on solving AS- AWS security problems of the world or cloud security problems of the world?

Richard Fan: Doing AI's research

Ashish Rajan: nowadays. Oh. Are you doing AI research?

Richard Fan: Yeah. Now I- I'm like doing my own side project on like the workflow on how to do my coding better and try different like spec-driven framework, like open spec or this kind of stuff. So

Ashish Rajan: yeah. That's pretty cool, man.

But it- I... that's pretty cool. It's good to know that security people are also writing [00:36:00] code as well and- ... 'cause anyway I have a whole thing about why we should do code more, but second question, what is something that you're proud of that is not on your social media?

Richard Fan: Oh, I'm proud of... Wow.

It's a really- difficult question. I think I'm proud of that I'm so free to have so many time to do what I love. I think a lot of people is that they don't ha- have the luxury like us to all the thing we like after work because they have a, a family to take care of and also maybe some financial burden.

But I'm so proud of that time. I have freedom. I have the spare money that I can go to many conferences, traveling a lot. So maybe I think traveling a lot is also part of my social media because I always post ... photos on social media when I travel. But yeah, that's what I'm proud of.

Ashish Rajan: That's awesome.

That's why we end up always crossing paths in the most conferences as well. The final question- Yeah, exactly ... that I have for you is, what's your favorite cuisine or restaurant that you can share with us?

Richard Fan: A favorite cuisine, I would [00:37:00] say is a Hong Kong local food. I don't know how to say that. It- it's like oh, we, what we call in Cantonese is a gai daan zai.

Okay. Is a, basically is literally translation is a little egg. It, it's- Little egg ... like a waffle. Yeah, it's a waffle, but there is a plate of waffle with a lot of little ball on it, and how we eat it is we tear off one ball and eat it, and then tear one off and eat it.

Ashish Rajan: Egg waffle. I think I remember this when I went to Melbourne.

Yeah, I think it's egg

Richard Fan: waffle. Yeah. But- Yes ... yeah, because I always say it's a gai daan zai in Cantonese.

Ashish Rajan: No. 'Cause I've I think I've had this in Melbourne, Australia, 'cause there's a huge Cantonese population there. Yeah. But I'm looking forward to trying some of the egg waffles when I'm in Hong Kong, man.

I think we'll, I'll start attending you. I think we're more likely January, but I'm gonna try some egg waffles that time, each time. But thank you so much for this, man. And that's all the questions I had for this interview. As I said, I'll put your LinkedIn link, the blog link, as well as the link to your intro talk as well.

But thank you so much for spending the time and [00:38:00] sharing your research with us as well.

Richard Fan: Yeah. Thank you so much, Ashish. Thanks for having me.

Ashish Rajan: Thanks, everyone. Talk to you next time. Thank you for listening or watching this episode of "Cloud Security Podcast." This was brought to you by TechRiot.io. If you are enjoying episodes on cloud security, you can find more episodes like these on cloudsecuritypodcast.tv, our website, or on social media platforms like YouTube, LinkedIn, and Apple, Spotify.

In case you are interested in learning about AI security as well, do check out our sister podcast called "AI Security Podcast," which is available on YouTube, LinkedIn, Spotify, Apple as well, where we talk to other CISOs and practitioners about what's the latest in the world of AI security. Finally, if you are after a newsletter, it just gives you top news and insight from all the experts we talk to at "Cloud Security Podcast."

You can check that out on cloudsecuritynewsletter.com. I'll see you next episode.

Peace.

‍