Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How can I do fronting with Caldera? #2936

Open
Pablo-offsec opened this issue Apr 3, 2024 · 3 comments
Open

How can I do fronting with Caldera? #2936

Pablo-offsec opened this issue Apr 3, 2024 · 3 comments
Labels

Comments

@Pablo-offsec
Copy link

Pablo-offsec commented Apr 3, 2024

Hey team,

I am setting up Caldera in an EC2 instance and have it setup with SSL(using a self signed certificate). For deploying agents, for example, Sandcat, the machine will make a curl request to the server to download the agent(binary) and the running the agent(binary) will deploy the agent which then shows up in the agent tab in caldera web UI.

I am using port 8443 and don't feel comfortable opening the port to internet. Adding individual IPs to the security group get tedious very quickly. I am thinking of adding logic to first check if the request is originating from an agent and if true, sending it to the caldera server. Something like a load balancer backed by WAF and I can check that the requests coming in have this particular cookie value.

I can do this for the first curl request but I am not sure about the agent communicating with the server. Is there a way to identify the communication between agent and server. Is there a header or something else that can be used for this purpose.

If there is a simpler way of doing this already inbuilt in caldera, please do let me know

Thanks
Pankul

@aut0exec
Copy link

@Pablo-offsec Oddly enough I'm doing something similar in a lab setup currently. No idea if there is an easier/built-in way within Caldera but currently I've modified the code of the sandcat agent located at sandcat/gocat/contact/api.go and added a line to simply add a cookie to the agents requests. It works well so far. My proxy decrypts the messages and if it sees that cookie value, it will forward requests to the caldera instance otherwise the request gets sent elsewhere. Not insanely robust and is easily circumvented by analysts but it works in our lab instance.

Some future thoughts would be to leverage some sort of asymmetric crypto to check the value in the cookie to confirm that only the agent could have generated the cookie value? Don't know. Only in the early brainstorming stages but it may not even get to that point for our lab environment.

@Pablo-offsec
Copy link
Author

Pablo-offsec commented Apr 12, 2024

@aut0exec
Yeah, I did something similar. I am deploying this in AWS infra and use Load balancer rules to filter out on a custom HTTP header which I added in api.go as well.

So now all the beacon calls have that particular header but then this is way to easy to get reverse engineered. I am not sure if I can write more complex rules in load balancer(kinda new to the AWS infrastructure).

What are you using as proxy in your lab setup?

@aut0exec
Copy link

So now all the beacon calls have that particular header but then this is way to easy to get reverse engineered.

Same concern, hints the thoughts about some sort of asymmetric crypto? Given enough time, anything can be reversed though, right!? We're not trying to leverage Caldera as a true C2 so it may not be a point of concern for us.

As for which proxy, currently leveraging HAProxy for this function. Since it's a lab and I'm "faking" the internet there is some other stuff done with Apache's Mod_Proxy on the host running Caldera but it doesn't have anything to do with special headers currently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants