Keycroc cannot connect to c2

[ipfsec]

Hi,

I'm not shure if i'm in the right forum because i don't know if its a C2Cloud or a Keycroc or a user issue 😕 I've got my keycroc last week and configured it over the weekend and played around. Now i have installed C2Cloud on a AWS Lightsail Instace and it's running fine.

I've downloaded the device.config and scp'd it over to the keycroc (so its online in my wireless network) but the device never gonna connect to the c2 installation. 😕

C2 is running with certificate. Service status seems fine. I opened the ports tcp/80, tcp/8080, tcp/22, tcp/2022 and tcp/443 incoming.

Does anyone have an idea why its not working? 😞

Thanks a lot!
ipfsec

[ipfsec]

Nevermind. Got it. Seems to be a problem when copying from OSX Machine via finder to the device. So if you having trouble also, try to scp directly 😉

[Darren Kitchen]

Our of curiosity, what was the issue you had with Finder on your Mac? 

[ipfsec]

Hi Darren,

seems that Finder is copying in strange way. Just drag & dropped it from my downloads folder onto the keycroc and it didn't work. After scp'ing it via terminal I had no issues with connecting.  😕

[brish]

Since upgrading to the latest firmware, I have been unable to get my Key Croc to connect to C2. Was there any follow up with this issue or other known aspects about it? 

I have completely reset it. I have tried with multiple internet and wifi connections where I have complete control. The Croc can see (at least ping) the server where C2 is located. All other devices can still connect to C2. I have tested removing the firewall settings on the C2 server. I have removed and created a new device in C2 downloading the updated config. Based on this post, I have removed all aspects of the device.config file and sent it to the Croc with scp from Windows. In all previous cases (including when it worked in the past), I was using arming mode and just copied the device.config file to the root of the Croc in Windows Explorer.

On a side note that may not be related, I have had much more difficulty connecting to wifi since upgrading. Changing the config.txt has not worked immediately. I did find that I could update the wpa_supplicant.conf file which would work. After resetting, I noticed that the connections were easier. However, after I changed the root password, it was not wanting to connect when making changes to the config file. Once I changed it back to the default password, the config.txt file changes seem to work just fine. I have not tested this thoroughly, so it may just be a coincidence. This also did not resolve the issue with C2.

[Jscott3717]

I am having issues getting my key croc to connect to the C2 server  I have moved to device.config file to the udisk using both the explorer and the command prompt with no luck  Any suggestions? Thank you

 

[Jtyle6]

Did you put your WiFi info into the confg file?

https://docs.hak5.org/hc/en-us/articles/360048015093-Getting-the-Key-Croc-Online

Edited October 20, 2020 by Jtyle6
Website

[P0E]

Sorry to resurrect such an old thread but I'm having similar issues to you @brish - I've got a full functional C2 server with other Hak5 devices connecting fine, my KeyCroc connects to wifi no problem, C2 has a proper CA signed certificate, my KeyCroc can telnet to my C2 server on all ports no problem but it will just not connect!  Tried both firmware versions, no luck - it's driving me nuts.

[dark_pyrro]

From my post(s) on Discord:

It could be linked to the fact that Let's Encrypt changed their root certificate as per the 30th of September. This can/will create problems for certain devices and operating systems. There is a fair amount of general info about this on the internet to read and how to solve it. Since the Croc is running Debian Jessie 8, it could be working, or not. Jessie is one of the operating systems that could work depending on how updated it is. If it's not updated, it might not work since it trusts the old/unsupported chain and root cert. So, IdenTrust DST Root CA X3 has expired and ISRG Root X1 is the one to use. Validate the chain (for example using the "openssl" command on the Croc). It will perhaps say that the chain ends up with the expired IdenTrust DST Root CA X3 certificate. The scenario might be worth checking at least.

On the Croc, do the following

First check if this is the problem you are facing or not, either by executing:
openssl s_client -connect your.c2-domain.com:443 -servername your.c2-domain.com
or:
curl -I https://your.c2-domain.com/

Both should indicate that the certificate has expired (the root certificate that is)

Verify if the expired "DST Root CA X3" certificate is available on the system (hence probably giving you problems with the Croc), it will be there if you got expired certificate issues from the commands above
Command:
grep X3 /etc/ca-certificates.conf
Output (or the vital part of it):
mozilla/DST_Root_CA_X3.crt

Older Debian releases most likely have the needed ISRG Root X1 present as well
Command:
grep X1 /etc/ca-certificates.conf
Output (or the vital part of it):
mozilla/ISRG_Root_X1.crt

"Backup" the ca-certificates.conf file
cp /etc/ca-certificates.conf /etc/ca-certificates.conf.old1

Disable/remove/"blacklist" the X3 root certificate:
sed -i '/^mozilla\/DST_Root_CA_X3/s/^/!/' /etc/ca-certificates.conf

Then execute:
update-ca-certificates -f

Check that the change has taken place. The output of the command below should show the "DST Root CA X3" as the "diff" since it's removed
diff /etc/ca-certificates.conf /etc/ca-certificates.conf.old1

Verify the certificate chain again, it should now be OK (or, if you have C2 running, the Croc should show up more or less immediately after the "update-ca-certificates" command has been executed):
openssl s_client -connect your.c2-domain.com:443 -servername your.c2-domain.com
and/or:
curl -I https://your.c2-domain.com/

Edited November 6, 2021 by dark_pyrro

[P0E]

Awesome thanks buddy - I'll try it out!

[MikeCheval]

Thank you so much ! Works perfectly ! 💯

[oldjamey]

This is the only thing that worked for me. It took me hours of troubleshooting to finally find my way to this post.  The only thing that I might add is that this should also be done on the c2 server and not just the croc.  It was only when I updated both that it successfully connected.  Thanks for the help.  @Darren Kitchen, they should really address this in the documentation or fix this via the device firmware and c2 binaries.

Until then, just create use this patch script from @dark_pyrro's commands above and save in `~/c2_connection_patch.sh` on the croc and c2 server, then run `sh ~/c2_connection_patch.sh`:

#!/bin/sh

# check if patch needs to be applied:
if grep X3 /etc/ca-certificates.conf | grep -qE '^!'; then
  echo 'system is already patched.'
  exit 0
fi

# backup /etc/ca-certificates.conf:
echo 'backing up /etc/certificates.conf...'
cp /etc/ca-certificates.conf /etc/ca-certificates.conf.bak

# blacklist the X3 root certificate:
echo 'blacklisting the X3 root certificate...'
sed -i '/^mozilla\/DST_Root_CA_X3/s/^/!/' /etc/ca-certificates.conf

# update ca certs:
echo 'updating ca certs...'
update-ca-certificates -f

echo 'done.'
echo
echo 'please reboot hak5 device, and restart cloud c2 server.'

 

[tommyq]

I have a digitalocean droplet running. SSL isn't configured yet. TCP ports 22, 2022, 8080 confirmed open with nc from the key croc and tcpdump on the server.  Port 80 does not seem to be open.  I can access the C2 UI with port 8080 as per various setups.  From the croc, I can ssh to the server with ports 22 or 2022 and see different ssh servers are behing the ports. OpenSSH associated with port 22 and SSH-2.0-Go with 2022.

The croc is getting an IP from my home router. I can ssh to it from my laptop. I've downloaded and copied the device.config file to the root of the croc with both windows file manager (drag/drop) and winscp.  Using the example payload I even added the C2NOTIFY instruction.  Typing 'hello' sees the expected 'world!' . 

I've recreated the c2.db and the device is shown as never connected.   The only odd thing I see is the reativate licenses go red, but the audit and server logs don't seem to show any errors. I'm on the community edition and have no devices.  The reactivate seems to have lottle effect but if I hit F5 to refresh the page, it is again red?  Any ideas on how to progress gratefully appreciated.

[dark_pyrro]

You can read some things to try in the other thread where you recently posted about the same thing.

[tommyq]

The device.config has mangled looking characters in it and the rest looks like a ssh key?  An excerpt from the 1st and 2nd line is:

 

root@croc:~/udisk# cat device.config                                                                                                  eth0*8080B ▒o▒▒~V▒qnؖL▒i▒▒▒▒▒▒ժ▒)9▒▒3J ▒▒
                                        ▒EH▒▒k}h▒▒ ?No▒ i▒q▒Ɂ▒▒PZ▒ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDtgzXk

 

I also looked at pretty well all 8 pages of stuff in the other thread. Nothing seemed to relate to my issue.

Edited July 12, 2022 by tommyq

[dark_pyrro]

Not sure what that eth0 is doing there. Your hostname should show.

What about the other things I mentioned in the other post?

What other thread with 8 pages are you referring to?

[tommyq]

Ah. I trawled through the stuff at https://forums.hak5.org/forum/96-hak5-cloud-c²/

Looking at it from that angle as well as the key croc.  Sorry for being dense, what other things are you suggesting?  I've ignored anything to do with certs as I'm not using https yet.    I'm adding the device and then downloading the device config. Well thats what I believe, so I also have no idea how this is happening.   Can you point me to the other things and I'll try them.  

[dark_pyrro]

Can you resolve the hostname of the server on the Croc?

Also check the cc-client error log on the Croc. I think it's in /tmp (if I remember it correctly).

 

And, as said, that eth0 entry in the device.config file looks odd. Are you using that as a parameter in some way when starting the C2 server?

In addition to the above, you could also execute cc-client and look for errors, or run C2CONNECT (don't remember if it's on the Croc, but pretty sure it's there, I don't have the Croc around at the moment so I can't check).

[tommyq]

Here the plot thickens.  The cloud server has something like a 46.xx.xx.xx IP address BUT, I got the impression that the droplet may not keep the IP when powered off. So, I added a static IP in the control panel for digital ocean.  There is an attach to droplet feature.  What I believed I was doing by taking out the reserved IP was ensuring that if it changed, there would be no problem.  The cloud firewall has a 188.xx.xx.xx IPaddress.  My assumption was that is NATing to whatever IP the server assigns at boot??   Certainly I can nc IP PORT to either IP and it's all fine so traffic wise the firewall isn't causing a problem.   Here may be the really stupid bit.  I set the start on boot as follows:

 ./c2-3.2.0_amd64_linux -hostname $(ifconfig eth0 | grep 'inet ' | awk '{print $2}') -listenip $(ifconfig eth0 | grep 'inet ' | awk '{print $2}')

So there is a eth0 but now I'm thinking I've likely got the syntax wrong..    I've fiddled with this but not got the substitution right yet ..

[tommyq]

I'm closer now but I think I've got to re-register the whole UI wrt tokens etc.

[dark_pyrro]

If doing it that way, I would separate it all to not get faulty inputs to the start of the C2 server.

First of all, I would start the C2 server with any of the IP addresses and skip the command that is included. Just to make sure that the C2 server starts as intended.

If I would use that way of getting hold of the IP address, I would most likely separate it all and put it in a bash script and first put the IP address into a variable, then use that variable when starting the C2 server, something like:

#!/bin/bash

IP_ADDR=$(ifconfig eth0 | grep 'inet ' | awk '{print $2}')
LISTEN=$(ifconfig eth0 | grep 'inet ' | awk '{print $2}')

/path/to/c2/binary/c2-3.2.0_amd64_linux -hostname $IP_ADDR -listenip $LISTEN

(Not sure I would use the listenip parameter though if there is no real reason to, I know I'm not for my C2 server).

Edited July 12, 2022 by dark_pyrro

[tommyq]

I'll drop the listenip as you say. Thanks.

I put getting the IP into .bash_profile and did an export IP.

IP=$(ifconfig eth0 | grep 'inet ' | awk '{print $2}')
export IP

After sourcing it I can echo $IP and it looks fine.  Pretty well the same as you have shown.  I want it as start on boot though and I assume using the systemctl restarts things if they crash? . When I reload the daemon and start the cloud service, I get in the status command a line that looks like $IP isn't evaluating still?

ExecStart=/usr/local/bin/c2-3.2.0_amd64_linux -hostname $IP -listenip $IP -db /var/cloudc2/c2.db

I know this is more linux stuff now key croc, but any ideas here would also be very much appreciated.

 

root@xxxxxxxx:~# systemctl status cloudc2.service
● cloudc2.service - Hak5 Cloud C2
     Loaded: loaded (/etc/systemd/system/cloudc2.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2022-07-12 21:17:06 UTC; 2s ago
   Main PID: 1651 (c2-3.2.0_amd64_)
      Tasks: 14 (limit: 1131)
     Memory: 17.8M
     CGroup: /system.slice/cloudc2.service
             ├─1651 /usr/local/bin/c2-3.2.0_amd64_linux -hostname -listenip -db /var/cloudc2/c2.db
             └─1665 /usr/local/bin/c2-3.2.0_amd64_linux -hostname -listenip -db /var/cloudc2/c2.db

 

As I was typing this, I saw your update.  It looks very close indeed to what I just did, but when I tried to use this with systemctl it didn't seem to take $IP as a variable??

 

[tommyq]

Using your script and re-doing the TOKEN/LICENSE codes has the device connecting.  THANKS!!!    I'm still unable to pass the param to the systemctl command line for some reason though and so I have to keep the putty window open to keep the session up.  I'm on the right track thanks to your kind help.   That was driving me nuts.  Still is but I'm so much closer now 🙂

 

[dark_pyrro]

If you get a static public IPv4 address with the DigitalOcean droplet (you should, I at least got one when I did a test a while ago setting up a C2 server on DigitalOcean), I'd suggest using that IP address in "clear text" when starting the C2 server as a service and not mess around with variables. To get the variable populated, the use of .bash_profile is probably not the way to go since that won't be "executed" until login of the user. To make it work at boot and "system wide", I would most likely use /etc/profile (however, I would avoid using a variable, as said).

If you haven't already, then use the docs that describes setting up a service for C2 (it looks like you have though judging from the paths used in your previous post).

https://docs.hak5.org/cloud-c2/guides/enabling-cloud-c-as-a-service-on-boot-and-exfiltration

[tommyq]

Hi. Just one last thanks for all your help!!  I'm going to do what you say and avoid the extra complexities that crept in.