Jump to content


Active Members
  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by chrizree

  1. To my knowledge, port 22 has nothing to do with the functionality of Cloud C2, i.e. SSH is not a mandatory part to get it all up and running. For instance, I have no active internet facing port 22 on the VPS running my C2 instance and it works all fine for me. Why not just disabling/blocking port 22 and see how it works out for you. Not sure right now about the SSL port thing, have you tried the listenport parameter?

  2. I just created a fresh VM (VirtualBox) and followed the instructions in the page you linked in your post and it all worked out well. Browsing the info.php file works without any problems and showing the expected results. Not using 20.04 though, but Ubuntu 18.04.4 LTS. Try again from scratch and see if some of the steps where unintentionally skipped and/or look for error messages while installing or restarting services, etc.

  3. Even if I haven't tried (running mine in the famous cloud), I can't see anything that really would stop you from successfully spinning up a Cloud C2 instance on the localhost and access the web interface locally on that specific machine. However, since the IPv4 address range is reserved for host loopback only, it should never be used outside of the current host (read further in RFC 1122). So, it will not be possible to connect any Hak5 devices to the locally hosted Cloud C2 instance which kind of removes the purpose of having a Cloud C2 instance up and running.

  4. I guess you are referring to the Chromebook enrollment script that is available at https://ducktoolkit.com/

    I don't have access to my Ducky at the moment, but I think that the version/variant of Ducky Script available to the Rubber Ducky doesn't allow the use of variables like that. The Bash Bunny would work though, but that's out of scope here. The below payload uses variables, but use "Ducky Script 2.0" that is not a part of the Rubber Ducky.

  5. Agree, the Police is the place to go, not an internet forum if truly followed with possible bad intentions behind it all.

    That scan list is no proof of being followed. The only thing it tells us is that it's either a severely misconfigured router or that a scan is conducted that doesn't show the true internal network of the user. Unless owning the right to use the network, it can't be used for private purposes since it's a public routable IP address range on the internet. And, as long as you aren't an official in the Comcast organisation, you can't use that range for your own purposes since it's Comcast Cable Communications, LLC that owns the rights to use the range ( - ASN 7922.

    A range, that is within the publicly non routable IP addresses that are available, has to be used for private networks.
    https://en.wikipedia.org/wiki/Private_network – – –

    But, this is the result of a public scan, not anything showing an internal private network behind a personal router. So... no one is inside the private network that shouldn't be there, at least not by judging from the posted output. Just a bunch of New Jersey attached Comcast customers accessing the internet through their ISP.

  6. You could check /sys/kernel/debug/crashlog

    I have reset my Pineapple so I haven't got any active VPN configuration/setup to try and I won't spend any more time on that since it's clearly not working.

    I just issued echo c > /proc/sysrq-trigger to force a kernel panic and that got stuck in the crashlog file so I guess the Pineapple should be set up out of the box to trap the eventual/possible kernel panic that the VPN connection produces.

  7. There is at least some degree of built in "security by obscurity" in the use of port 1471, i.e. a user won't accidentally land on the web admin GUI just by loading and some active port scan is needed to get hold of the port in use.

    You could alter the configuration of nginx to limit the client IP address(es) that can access the web server on the Pineapple. Use a static IP address outside of the DHCP scope and allow only that IP address to access the web admin GUI on port 1471. It's not at all bullet proof though since someone might test each address outside of the DHCP scope and find the one that works. Not very likely, but totally possible. And... most important, doing this might mess up some vital WiFi Pineapple functionality. This "method" affects both the open AP and the management AP of the Pineapple since they use the same IP range.

    So, after the disclaimer of doing this at your own risk, this is how you could do if it suits your needs (not that a high risk though since it's easy to revert using an SSH session).

    Make a copy of the original/current nginx configuration file
    cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.org

    Edit the nginx configuration file
    nano /etc/nginx/nginx.conf

    Scroll down to the server segment specifying the listen port 1471

    Below the line "listen       1471;" add
                deny all;

    The "allow" address should be within the range but not within the DHCP scope, is just an example address

    Save the nginx configuration file and exit nano

    Restart nginx
    /etc/init.d/nginx restart

    Then use the static IP for the PC (or whatever device) that is supposed to be allowed to access the web GUI according to the nginx configuration file

  8. I forgot a "Q" for the last DELAY in my sample script code, but it should run anyway. Since you are using the "standard" LED modes elsewhere in the script, you could use LED FINISH in the end instead of LED G, but that's just aesthetics really.

    • Like 1
  9. First of all I would get rid of the line containing #!/bin/bash

    Q SET_LANGUAGE dk should be replaced by DUCKY_LANG=dk

    Each DELAY should have a Q or QUACK in front of them

    The GUI r could be deleted since it's about to do the same thing as the RUN WIN line

    The STRING line should also have a Q or QUACK in front of it

    Something like this:

    RUN WIN "notepad"
    Q DELAY 450
    Q STRING "Hello world"
    DELAY 100
    LED G

    • Upvote 1
  10. I have had the same experience recently, but no solution for it. It's discussed in the following thread

    I've also "alerted" about the fact in the release thread for the Nano, but I guess it won't be fixed. There has been VPN kernel panics related to the Pineapple that was said to have been solved in the latest firmware release, but it seems as it wasn't 100% successful.


  11. OK, then you are at least able to download the modules you want to get hold of.

    What OS are you trying to set up network sharing with? I assume that you have already followed the instructions in the official documentation (if you are using Windows or Linux).

    Please be more detailed in describing the steps you have taken and when you get stuck in the process.

  12. Depending on what part of the world you are living in, the chance might not be missed after all. There are at least 3 resellers within the EU that has the Signal Owl in stock at the moment. More expensive, yes, but still a possible way to get hold of a brand new one.

  13. By "can’t get pineAP to start", do you mean that clicking the Switch button under the Configuration section of the PineAP module in the web GUI of the NANO results in a Disabled state regardless how many times you click on the Switch button? I.e. PineAP Daemon: Disabled never goes into PineAP Daemon: Enabled.

    If so, I could replicate the problem myself on my NANO. It didn't matter how many times I clicked the Switch button, it still was in the Disabled state. Running ps at the terminal didn't show any signs of life either. So, I factory reset my NANO and went back to a clean 2.7.0 and after that it has never failed. I've toggled the state of the daemon 10+ times now and it works every time. I guess it has to be related to something I've installed, or such. I've been messing around lately to try to get OpenVPN to work on the NANO (and some other stuff) and my conclusion is that PineAP is sensitive to these "adventures" in some way. Another thing to have in mind is to not use the onboard wlan1 interface for something else than PineAP (such as using the radio for internet access). The GUI explicitly says that using wlan1 could interfere with PineAP.

    When you click Switch (and the state is PineAP Daemon: Disabled), it should start the process /usr/sbin/pineapd /tmp/pineap.conf

    It can be checked by running:
    ps ax
    ps ax | grep [p]ineapd

  14. OK, can you try to connect the Tetra using its Ethernet port instead of trying to get the internet connection sharing to work. Just to make sure that internet connection works at all. That is if you have some equipment that lets you connect using an Ethernet cable. I would try to get an internet connection using less "painful" methods first and then moving on to some other desired method.

  15. It seems to be a bunch of things not working judging from your output. Have you tried to run each uci command in the scripts to see which one of them that are failing? I found some that the dependency check should set, but they aren't actually set.

    What network interface are you using the Deauth module with?

    I haven't had time to go through all of the code. And that's not just the bash scripts you have tried to run manually, but also the API php file seems to have some odd code in it that doesn't spit out the desired results as I can see it.

  • Create New...