dark_pyrro
-
Posts
2,621 -
Joined
-
Last visited
-
Days Won
198
Posts posted by dark_pyrro
-
-
37 minutes ago, Albert van Harten, What The Hack Aps said:
Danish companies have no idea what is on their network.
I would dare to disagree with such a generalization. I'm pretty sure there are organizations in Denmark that has (at least some) kind of control. I can't imagine that 802.1X is totally absent in Denmark. Hamlet isn't always correct about every aspect of that country.
45 minutes ago, Albert van Harten, What The Hack Aps said:So I would like to be able, to connect a little network tapping to a unattended outlet, connect a power bank to the tapping device, and connect to the device using Wi-Fi, while sitting in the office of the CEO.
What are you going to listen to? I assume they have switched networks and not hubs broadcasting traffic everywhere. What are you going to show the CEO? Packet captures?
EU organizations will most likely get a bitter pill to swallow when the NIS2 directive becomes domestic law in the member states on the 17th of October 2024. If they haven't done their homework, the risk is that it will be costly if they get reported or caught not being compliant when being scrutinized. Instead of showing some "tech based arguments", I would start educating the organization (and with top management as a priority) to make it clear to them what could happen if they aren't compliant. That will then lead to technical actions needed, preferably based on some method/model like ISO27000, NIST Framework, and/or CIS Controls.
-
The Plunder Bug has no WiFi built in.
It depends on the use case and what's desired, but using some alternative hardware would most likely not be that much of a challenge. Especially taking into account your profession and the type of company you run. You should have the knowledge needed.
If speaking of Hak5 devices, it could probably be possible to use a slightly modded Packet Squirrel to achieve "Plunder Bug-like features" along with WiFi capabilities. Note that the Squirrel doesn't have WiFi out of the box but it's possible to add it. However, and as said, it all depends on the use case and it wouldn't be exactly like a Plunder Bug.
-
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.zipUnpack 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.145Start 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.crtVisit the Cloud C2 web UI, do the initial Cloud C2 setup, and add the Packet Squirrel device
https://172.24.12.145Create 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:/etcCopy 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/certsssh 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.
-
1
-
-
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"
-
1
-
-
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
-
1
-
-
What screen resolution are you using?
Tried different browsers?
Any addons/plugins installed in the browser(s)?
-
14 hours ago, natosama said:
on Kali, and PC I proceeded to change to an static IP Address
Is Kali running on bare metal, or in a VM?
14 hours ago, natosama said:then proceeded to connect to http://172.16.41.1:80 and http://172.16.42.1:1471
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.
WiFi Pineapple Compatibility
in WiFi Pineapple
Posted
It's a web interface, so I can't see why it wouldn't. Depends on how you define "all the functions" though.