Jump to content

dark_pyrro

Dedicated Members
  • Posts

    2,618
  • Joined

  • Last visited

  • Days Won

    198

Posts posted by dark_pyrro

  1. Just so that you know, I don't offer any personal troubleshooting support using DM.

    6 hours ago, jumpjr619 said:

    So if I put the bunny in either switch position all that happens is a purple light illuminates for a couple seconds then a green light illuminates for a couple seconds,but then that's it absolutely nothing else.

    What payloads are used in each of the switch positions (switch1 and switch2)?

     

    6 hours ago, jumpjr619 said:

    So I tried my Ubuntu system and that payload was a storage attack and that seemed to.

    "seemed to" what? that sentence doesn't make sense, or is it continued in the second post of yours?

    6 hours ago, jumpjr619 said:

    Work to begin with

    if so, then it actually does something after all

    To continue to try to troubleshoot this, you need to post the content of the payloads you have tried this far.

  2. Obviously, you are able to access the Pineapple if you are able to factory reset it, so it can't be all "dead".

    To continue to troubleshoot this, more info is needed such as output of the network setup, how you are powering your Pineapple (i.e. does it get enough power), does it work when you connect to the Pineapple using a USB cable, what USB cable are you using in that case (the one that came with the Pineapple, or something else), etc.

  3. 8 hours ago, Rusty_83 said:

    DELAY 3000

    Not really important in terms of getting the payload in general to work, but instead of using the initial delay, you could use the PASSIVE_WINDOWS_DETECT extension since the target is Windows based.

    8 hours ago, Rusty_83 said:

    GUI x
    DELAY 500
    STRINGLN a
    DELAY 1000

    Something's missing in this code block. Usually, you need to confirm the elevated terminal/console, but I can't see that here (i.e. "Yes" has to be pressed to get to the elevated prompt). A longer delay is perhaps also needed, but it depends on the performance of the target and how fast it can open the PowerShell window.

    9 hours ago, Rusty_83 said:

    ATTACKMODE HID
    DELAY 500

    This shouldn't be necessary since the default ATTACKMODE for the Ducky is ATTACKMODE HID. And, if it wasn't, it still had to be moved to the top of the payload since keystrokes are entered before ATTACKMODE HID is introduced in the payload code.

    9 hours ago, Rusty_83 said:

    STRINGLN cd "c:\program files\windows defender"; ".\mpcmdrun.exe -RemoveDefinitions -All Set-MpPreference - Disable!OAVProtection $true";

    Try running this line manually exactly the way it looks. What is the result? It will cd into the directory, but then just echo the rest of the commands. Remove the quote marks around the commands and try it again. Any difference?

    A general tip is that if something isn't working, try running it manually and see what the results are. It will help a lot when troubleshooting.

  4. 4 hours ago, Rusty_83 said:

    tried a number of scripts

    What scripts? It's much easier to try to help troubleshoot things when knowing as much as possible about what's been tried and not. Pick 1 payload that isn't working.

  5. I guess you're the same user as the one posting on Discord (since it's the exact same subject).

    7 hours ago, kylej916 said:

    Unable to negotiate with 172.16.84.1 port 22: no matching host key type found. Their offer: ssh-rsa

    You can read about how to solve that a few posts up this thread.

    7 hours ago, kylej916 said:

    I try ssh root@172.16.84.110 and it prompts for ssh password but default password sh3llz doesn't work

    That's because you're not ssh'ing the Turtle (which has 172.16.84.1) but instead ssh'ing yourself, and if your machine doesn't have the root user along with the sh3llz password set, then you're not going to be able to log in (and you won't be logging in to the Turtle for sure since .110 is the wrong IP address).

  6. As I posted on Discord, ssh doesn't work out of the box, you will have to hack/tweak the Crab to enable that. But it will also void warranty since you're not expected to do such things to the Crab. As soon as you start to change things, you're really on your own (at least when it comes to any claims against Hak5 as a company). One important thing to remember when it comes to the Crab (compared to other Hak5 devices), is that there is no "factory reset" option. So if you get stuck or brick the Crab, you can't easily revert it back to an "out of the box" state. Therefore, it's important that you don't do things that you haven't got the knowledge to back out of (if it's even possible to back out of it). If you, despite the warnings, try to do things to the Crab, you will most likely start by accessing it using hardware serial and go from there. It's not the "ordinary" Linux box either, it's Android based which also requires some extra knowledge when it comes to how that OS "branch" works. I've got ssh set up on my Crab along with a web server, etc. etc. But I wouldn't at all recommend it if you don't know what you are doing and the risks that comes with it.

    • Like 1
  7. So... this should take care of the cert issue... at least did for me

    With the Crab powered off, remove the Micro SD card from the Crab and insert it into a computer. If doing the step creating the hash for the certificate, it needs to be a computer with openssl installed. That step shouldn't really be necessary though since the hash displayed in this post should be "universal" (i.e. it won't change since it should be unique to the certificate). A Linux based PC has been used in the instructions below, so if using something else, commands need to be adjusted.

    Download the Let's Encrypt X1 pem file
    https://letsencrypt.org/certs/isrgrootx1.pem

    also linked on the page
    https://letsencrypt.org/certificates/

    Calculate the certificate hash (optional)

    openssl x509 -inform PEM -subject_hash_old -in isrgrootx1.pem | head -1

    Rename the pem file (or copy it) to a file name based on the hash and a .0 suffix

    cp isrgrootx1.pem 6187b673.0

    Copy the .0 file to the root of the Micro SD card

    Create an autoexec.txt file in the root of the Micro SD card that contains...

    source /system/bin/crab && locate_sd && mount -o rw,remount /system && cp $SD_LOCATION/6187b673.0 /system/etc/security/cacerts/. && chmod 644 /system/etc/security/cacerts/6187b673.0

    With the Crab still powered off, insert the Micro SD card into the Crab, then power up the Crab

    If everything works as expected, the Crab should show up in the C2 server web UI (assuming it has network and internet access and a device.config file that is valid for the C2 server)

    The .0 file (and the autoexec.txt file) can be deleted from the Micro SD card when it has been verified that the Crab can connect to the C2 server

  8. I think I got it working now. I transferred the X1 cert to the Crab and it connected to the C2 server straight away. Just need to fix how to get it on the Crab without voiding warranty. I have "full access" to my Crab so it's easily done (since I've done a bunch of hacking of the box over time), but that's not something you get out of the box. I'll try to make a tailored autoexec.txt if I get time to do it.

    • Thanks 1
  9. On 3/21/2024 at 1:24 PM, SSC said:

    I just get the message "TLS handshare error from *ScreenCrab-IP* remote error: tls: unknown certificate

    I guess you've stumbled upon a "new" thing that's related to the upstream Let's Encrypt certificate handling. I haven't had time to do it up until now, but I started my Crab and I got the same issue, i.e. the Crab is not connecting to the C2 server (it did just a week ago), and I get the same error on the C2 server side. This is probably related to Let's Encrypt phasing out a certificate type which affects certain devices such as ones that runs specific OSes, such as Android 7 and older (which includes the Crab running Android 6). I will check things further if I get the time to do it, but right now it's just a "qualified guess" from my side that seems likely to be true.

    • Like 1
  10. 25 minutes ago, SSC said:

    I tried appending the public key to /etc/ssl/cert.pem (found the path in the howTo in https://docs.hak5.org/cloud-c2/guides/cloud-c-setup-with-self-signed-ssl-certificates)

    It's not where the Crab stores public key files, fwiw (that's what I was referring to when mentioning "default" destination). It should probably be /system/etc/security/cacerts/ since it's Android.

    It also needs to be named in a specific way in order to be accepted by the system (also an Android "thing"). You need to calculate the hash of the certificate and name the file using that hash (along with a trailing ".0")

    30 minutes ago, SSC said:

    didn't use the VPS's nameservers, but that shouldn't make a difference, or should it? 

    That shouldn't matter. It should work. Is port 80 open in the VPS firewall (and any OS firewall that might be enabled)?

  11. 2 hours ago, SSC said:

    I couln't bring my local installation to connect via https, the autoexec file ignored the copy commands for my self-signed CA public key (commands in the backend seem to be whitelisted as they should be 😉

    Even though you've seemed to have given up the idea; the public key file needs to be copied to a destination that isn't exactly "default" and it has to be named a specific way (the public key file) as well to be accepted.

    2 hours ago, SSC said:

    everything worked with http and 8080, after switching to https and renewing the screencrab config, it stopped working and every few seconds the TLS handshake error is thrown.

    Did you run http/8080 using the public IP or the DNS name, or did you "introduce" the DNS name to the setup when you started using https? Just to make sure that there's no issue with the domain name (and linking it to the public IP of the VPS using a DNS record).

  12. Be more specific and detailed

    Select one (1) module and describe the steps you do and where/when the error occurs.

    If it happens "almost all of the time on every module", then I would probably look somewhere else other than the modules themselves. But... more info needed to be able to try to assist. Never had such issues, at least not for all modules and not all of the time.

×
×
  • Create New...