dark_pyrro

I'm a bit confused. It's marked as a solution but still there is a question. Is the issue that it works but sends the replayed traffic to the "wrong" interface, i.e. using br-lan pushes the traffic in the wrong direction/to the wrong actual interface? What happens if you use eth1 instead?

I guess you've gotten some answers on Discord regarding this.

OK... doing it from scratch... Setup: - Cloud C2 running on a Ubuntu 20.04.x LTS machine - Packet Squirrel Mk1 on fw 3.2 - Cloud C2 and Packet Squirrel both on local network (Cloud C2 server = 172.24.12.145) Download the Cloud C2 binary to the Ubuntu machine (verify the sha256 checksum of the downloaded file) wget https://downloads.hak5.org/api/devices/cloudc2/firmwares/3.3.0-stable -O c2.zip Unpack the zip file Create a private/public key pair on the Ubuntu machine openssl req -newkey rsa:2048 -x509 -sha256 -days 3650 -nodes -out c2-publ.crt -keyout c2-priv.key NOTE! Be sure to use the address of the Cloud C2 server for the Common Name field when creating the key pair, in this case 172.24.12.145 Start the Cloud C2 server using the keys created sudo ./c2-*_amd64_linux -hostname 172.24.12.145 -https -keyFile ./c2-priv.key -certFile ./c2-publ.crt Visit the Cloud C2 web UI, do the initial Cloud C2 setup, and add the Packet Squirrel device https://172.24.12.145 Create a device.config file for the Packet Squirrel using the Cloud C2 web UI and download the device.config file from the Cloud C2 server (The copying/scp of the files below can be made in different ways, here, it's done connecting to the Packet Squirrel in "arming mode" switch position to a computer, then the Packet Squirrel will be moved to the network where it will interact with the Cloud C2 server) Copy the device.config file to /etc on the Packet Squirrel scp device.config root@172.16.32.1:/etc Copy the public key file (never copy the private key!) to /etc/ssl/certs on the Packet Squirrel scp c2-publ.crt root@172.16.32.1:/etc/ssl/certs ssh into the Packet Squirrel and add the public key to the already existing ca-certificates.crt file on the Packet Squirrel cat /etc/ssl/certs/c2-publ.crt >> /etc/ssl/certs/ca-certificates.crt (Move the Packet Squirrel to the network where the Cloud C2 server is running, if it hasn't already, and connect the Packet Squirrel to that network using the "WAN" Ethernet port) If the Cloud C2 Ubuntu based machine is running any local firewall, make sure to allow the relevant ports for Cloud C2 The Packet Squirrel should now show as online in the Cloud C2 web UI

You create a private/public key pair on the C2 server (using the correct/relevant CN). The public key/cert file from that key pair is then copied to the Squirrel. When it has been copied to the Squirrel it should be added to the file you mention.

You mentioned in another post that your Packet Squirrel runs firmware version 3.2 which indicates that it's a Mk1 Squirrel. Is this valid for this post as well? I.e. that the question is about the Mk1 Packet Squirrel and not the newer Mk2 version.

The private key should never be copied to any other place than where it is really needed (which should be the C2 server in this case), only the public key/cert should "leave" the C2 server. The CN needs to represent the C2 server if you are using self signed certs, nothing else.

ok, so the C2 server is called "squirrel01" and it's possible to resolve that hostname to the IP address where the C2 server is running. With that established, where did you put the public key/cert file on the Squirrel?

Is that possible to resolve to the address where the C2 server is running? You seemed to be running the C2 server using an IP address in a previous post. Has this changed now?

Well, I'm pretty sure you're not a Certificate Authority, so you're just using a self signed public and private key combo, nothing else, but anyway... First of all, what information did you provide for CN when creating the private/public key pair?

What CA certificate? Aren't you using a self signed one?

it's because the Shark hasn't got any RTC so it will revert to something it knows (which isn't the correct date or the date you last set it to). If it has got internet connection (which isn't always the case) you could run ntpd to get the date and time from the internet. But if it's offline, it will behave like that (i.e. revert to that date you posted which most likely is linked to when the firmware was created since 1.2.0 has that specific date stamp on files and directories).

It's because the URL used in the UPDATE_PAYLOADS script file is https based and curl just throws an error back (that you can't see since it's set up to execute silently) if the date/time is wrong which results in the fact that the tar.gz file isn't downloaded which is why you get those errors. The script file can't really handle that though and it gets a bit confusing since it says that things are successful.

it's basic Linux and you can find how with a simple search, you use the date command with options/parameters to set the date, such as date -s "yyyy-MM-dd hh:mm:ss"

date (for example)

is the date and time correct on the Shark?

If you refer to the Kali password, the reason to why that password fails is most likely because Kali has "evolved" since that video/tutorial was created. It doesn't use default/predefined credentials anymore, but something that you set yourself during setup/installation.

Do you have any idea of what firmware version the Pineapple is running on? What web browser are you using?

Well, there's ATTACKMODE STORAGE available out of the box for that

Post Pineapple Mk7 question in the section of the forums where that device is discussed

What screen resolution are you using? Tried different browsers? Any addons/plugins installed in the browser(s)?

Is Kali running on bare metal, or in a VM? None of those URL:s will work for the recovery, use http://172.16.42.1/

You need to get the source code, set up an environment where you can build/compile the source for the relevant target architecture and create the binary needed. Note though that it's not for sure that the source code is compatible with the architecture used, so that has to be established as well. There is information available (OpenWrt web site and other places) that describes how to write and compile code and create binaries/packages.

You have to be more specific about your setup in order to try to troubleshoot. Is it a Mark VII Pineapple? How are you connected to the Pineapple? If it's a Mark VII, I assume it's via the USB-C Ethernet port of the Pineapple. Can you ping the Pineapple (even if you won't get any response using the URL in a browser)? Are you sure that the browser you are using isn't "reverting" to https instead of http, i.e. forcing https? What OS is the device running to which you are connecting the Pineapple? In what way did you set up the 172.16.42.42 address on the device connected to the Pineapple? Can you connect to the management and/or open AP of the Pineapple (without setting any static IP address on the device from which you are connecting, and just let DHCP take care of it) and then access the web UI? What specific part of the documentation are you referring to?

Not that it's impossible, but I wouldn't select the Pineapple for that specific task. I'd probably rather use Wireshark along with a directional antenna in that case.

The answer for your question about tshark on the Shark Jack is most likely valid for the Squirrel as well