Jump to content

dark_pyrro

Dedicated Members
  • Posts

    2,572
  • Joined

  • Last visited

  • Days Won

    194

Everything posted by dark_pyrro

  1. What features? What components? It's been 4 updates since the product release, so I don't get the "shit practice".
  2. What do you want in an update? Updates are generally not time based, but based on need.
  3. I'd suggest that you contact Hak5 directly instead of using the forums. There's no guarantee that it will be monitored by Hak5 staff.
  4. I guess that the end of that quote is actually your question. I'd suggest that you ask the question in some forum (or whatever) that is relevant to your hardware since you obviously isn't using a Hak5 USB Rubber Ducky.
  5. Repeating the same question as for the other user; tried to install it? opkg update opkg list | grep python3 Find some install candidate and install it, perhaps opkg install python3
  6. "With this", what? What do you want to do, and... there's a dedicated forum section for the Ducky, use that for Ducky questions/posts.
  7. Tried to install it? You don't have to wait for it if it's in the repos. Not sure any Python3 package available for the Turtle is new enough to run the most recent version of Responder though.
  8. Could be a client side (Turtle) issue, or host side. A bit difficult to say without digging deeper into it. When running the Python based shell component manually on the Turtle, it reports "Unable to connect" even though the Meterpreter host reacts. The dynamically generated URL on the client side doesn't seem to be accepted by the Meterpreter host.
  9. If you downloaded the deb package from this forum thread and installed it as per the instructions from Hak5, the Metasploit should be considered as installed on the Bunny. Note though that the contents of that deb package is about two and a half years old. Don't expect everything to work since the security domain has moved quite a bit over such a period of time. Things needs to be up to date to be useful in most cases. When it comes to Metasploit specifically, I guess the best advise is to dig elsewhere to get more knowledge about how to use it all. There are for sure people here that knows stuff, but my bet is that the response is better on dedicated forums, etc. that is focused around Metasploit. If you want to get hold of credentials, then you could try the QuickCreds payload instead. It doesn't deliver 100% clear text stuff though, but it's a step on the way of showing what is possible to get hold of in customer engagements/pen tests/red team activities.
  10. I would go for the Bunny, I have both the Bunny (Mk1 and Mk2) and the Turtle and between them I use the Bunny the most. It's more useful, but that of course always depends on what you are trying to achieve.
  11. The thing I think you have misunderstood is that it's kind of fruitless to post things related to the Mark VII in the Mark V section of the forum. Post this in the correct part of the forum instead. Or better still, take it to Discord. Those discussions are far more active and responsive.
  12. https://github.com/kleo/evilportals
  13. Describe the problem more in detail. Explain the steps you do and where it fails.
  14. copy the portals to /root/portals and they will appear in the web gui, activate one of them and you are ready to go
  15. Still not sure what your problem is. Why don't you just download all the kleo portals to the Pineapple from github and then activate the desired one from the Pineapple web gui?
  16. Tell us what you have done this far. In what stage are you experiencing problems? You need to be more detailed than this to get help. Just asking for a "fix" is not enough.
  17. I know, the post is some months old, but I don't care. What do you mean by saying "included"? Out of the box or possible to install? It's for sure possible to use on the Bunny. I have Scapy installed and running on my Mk2.
  18. Tried different USB ports? Tried on another computer? What happens if you use any of the other switch positions (SW1, SW2)? That the Bunny initially reports itself as an Ethernet device isn't abnormal really.
  19. 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/
×
×
  • Create New...