Riggs

I think these values are hardcoded to the binary itself. You could set up a reverse-proxy server in front of the C2 service and then configure the server acting as a reverse-proxy to only allow updated protocols and cipher suites. I've just done this myself for my nginx reverse-proxy sitting in front of my C2 service and everything seems to be working fine. Before: After:

Looks like all resolved now.

Another user has reported the same issue on Discord. It looks like the https://c2.hak5.org cert expired 2 days ago: https://crt.sh/?id=9739993486 I suspect like this is a wider issue possibly affecting all Hak5 C2 instances. For now, if you have a live Hak5 C2 running and are not experiencing any issues, I would recommend you do NOT click re-activate or upgrade, as this will likely cause your Hak5 C2 to try to contact the https://c2.hak5.org licensing server and you'll end up with the same problem we have.

Thanks, I've just raised a support request and added a link to this post.

I just paid to upgrade my C2 license to Professional tier, but noticed that my C2 server is now unable to validate licensing. I noticed that https://c2.hak5.org is (at the time of this post) throwing an SSL error so I'm guessing this might be why: My original community license C2 is now stuck in a licensing prompt loop and I can't spin up a fresh C2 as during setup all I'm getting are infinite 500 and 418 errors (lol). Any staff around that might be able to resolve this please?

Maybe she'll see this thread and respond to it with a write-up on her pure wizardry.

If I've understood your intentions correctly, I've already achieved this for myself. I basically forced the Hak5 C2 application to bind to port 8080 and then spun up an nginx server on the same VPS and bound that to 80 and 443, then used the nginx server to reverse proxy traffic to/from the Hak5 C2 application which remains running on 8080. This gives me some flexibility in being able to actively modify the responses being sent from the Hak5 C2 application on the fly to my browser (over 80 and 443). In a high-level example, if a request is made to access the Hak5 C2 application from any browser (in practice it will only be mine as it requires auth), the nginx server will first see the traffic on 80 and 443, then forward the request to the Hak5 C2 application running on 8080, then (for example) replace the .css code being sent back with my own .css code to persistently change the cosmetic appearance. I've actually created a persistent theme this way and named it 'HAK5 THE PLANET EDITION', although it's only me using it for now. I don't believe this is against the licensing terms of use, as I technically haven't reverse-engineered, disassembled, nor modified the original application code. The Hak5 C2 application remains in its original state, I'm just choosing what parts of the code I want to see presented in my browser in response to my own browser requests. I was also thinking of adding MFA, but haven't got around to that yet.

I know I'm reviving an old thread, but I'm about to try this myself and came across this while looking for discussions on the topic. I suspect that when you try to redirect a user to a HTTPS site like Google, the browser knows that Google should only be accessed over HTTPS (because of HSTS). In this case it would make sense that your browser is prompting the connection is not secure, as the end-to-end connection cannot be made securely (because your evil portal is proxying it). You might wish to try temporarily redirecting visitors to a HTTP version of your site (not HTTPS), and from there, have a link or .htaccess file that redirects them to HTTPS. Obviously it's not ideal as HTTP is insecure, but it may be a workaround.

Plug-and-play. For some reason Hak5 just have the O.MG Programmer auto-associate any selection from the full O.MG product line during checkout.