Jump to content

chrizree

Active Members
  • Content Count

    305
  • Joined

  • Last visited

  • Days Won

    20

Everything posted by chrizree

  1. The very first of the tips I can give you is really to get dirt under your fingernails and dig into the the area of cyber security to better understand it all to get a foundation to build upon. Even though I think that Hak5 devices is a very good starting point since they make things easier for those that might not be that proficient, knowledge is always the base for everything. Operating within cybersec isn't like using a toaster sadly. There is no single button to press and get a slice of toasted bread. Of course there are scripts and solutions that can be used by nearly anyone, but they sti
  2. And... of course, since we are on the Hak5 forum, there are Hak5 devices that possibly can be used for this as well. It depends on how you want to do it and to what extent. For example the WiFi Pineapple, the Signal Owl, the Plunder Bug and the Packet Squirrel.
  3. There are two different scenarios here; one is to collect traffic passing your router/network and the other is to scan for WiFi devices. When it comes to Wireshark it's not an easy to use tool/software if skill levels are low or moderate. Collecting info is one thing, but analyzing it all later and fnd what you are really looking for will require a pretty heavy amount of skills when it comes to understanding protocols and networks in general. Then, you can't just capture traffic "just like that". You need some kind of relevant equipment to do it. It all depends on your setup. If it's an ordina
  4. chrizree

    Telegram

    The original post is pretty much almost 1 year old and the user has just posted once, so I guess there will be less of a chance that the original poster will get back with the final solution. However, there is a fairly new post (linked below) involving Telegram. Perhaps not the exact use case scenario as described in this thread, but it can be used as a base to develop/reproduce the same functionality using Telegram and the Shark Jack. https://forums.hak5.org/topic/53042-telegram-bot-nmap-sharjack/ https://github.com/felinuxing/sharkjack-payloads/blob/master/payloads/library/recon/Te
  5. I can replicate the problem using the same setup. I then tried the same with one of my GL.iNet mini-routers that are running a slightly later release of the OpenWRT kernel. It wasn't successful but the ALFA adapter at least identified itself with a correct MAC address. The rest of the test was a "crash and burn" though. Not working at all so I guess it has something to do with the package/driver/kmod for the 8812AU chipset or kernel related or a combo (or something else). Perhaps something more needs to be installed to get it working. From previous experience, dependencies aren't always instal
  6. If using the 5 GHz spectrum and if the AP is operating on a DFS channel (depending on country/region) and if in possession of some suitable device that can generate radar traffic (such as an AWG), it should be possible to force an AP to change channel without having administrative control over it. DFS works in a way that makes an AP drop ongoing transmissions if a radar signal is discovered on the active channel, broadcast a channel switch, then disassociates all clients and changes to another channel. If the new channel is a DFS channel as well, the AP/wireless controller waits for about 60 s
  7. I can't comment on the overheating issues that you have. It isn't anything that I've experienced and I see no real need of adding a fan to a design that Hak5 would already have been thinking of when creating the Nano. It should be able to stand the workload without additional cooling. Since I'm not normally a Windows user, I just hooked up my Nano to a clean and freshly installed Windows 10 Home 64 bit box (with the 2004 release and all updates added) and the Nano identifies itself without any complaints. What version of Windows are you using and have you tried to hook the Nano up to anot
  8. Yes, either that, or the passwords are simply the same as the usernames Running the following for the usernames user, admin and support results in the same sha256 output that is said to be the user passwords for the respective username according to the config file output echo -n '<username>' | sha256sum
  9. I have never experienced any issues with my Nano, but I have noticed that there are comments of various kinds related to problems with the Nano. I haven't dug any deeper though in trying to understand if those complaints are related to actual platform problems or lack of knowledge about the platform. Some (SD card related) seems to be known platform problems though that is said to be fixed if I understand the ongoing discussion correctly. What kind of problems are you facing with the Nano? Provide a detailed description of your scenario so that the community can try to help you moving forward.
  10. The biggest difference in my opinion is the fact that the Nano (or Tetra) won't have the same focus anymore when it comes to upgrades and features. If you want to ride the wave of the future when it comes to the WiFi Pineapple, I guess there's no other option than going with the Mark VII. The interface has gotten new features that will most likely never become available on the Nano or Tetra. The community support will most likely remain (at least for some time) for the Nano and Tetra but I think it will tilt over towards a more active community for the Mark VII, especially since the Hak5 team
  11. A bit off topic, but regarding ALFA adaptes and Kali Linux, I have the AWUS036AC (Realtek RTL8812AU, same chipset as the AWUS036ACH), the AWUS036ACS (Realtek RTL8811AU) and the AWUS1900 (Realtek RTL8814AU) and they all work in Kali Linux using realtek-rtl88xxau-dkms Check to really see that the adapter is working or not with a fully updated version of the latest release of Kali and installed adapter support as per below Install support for the adapter apt install realtek-rtl88xxau-dkms Attach the adapter to the PC Run lsusb and iwconfig to see that the adapter is identified
  12. Running the script in CLONE mode isn't working due to the fact that the Packet Squirrel hasn't got a br-lan interface in CLONE mode. You can easily add a couple of lines to the original payload script to see what is happening "live" as the payload is running and watch the br-lan interface "disappear" when entering CLONE mode. Replace these lines in the "run" function: # Set networking to TRANSPARENT mode and wait five seconds NETMODE TRANSPARENT sleep 5 With these lines: # Set networking to TRANSPARENT mode and wait ten seconds NETMODE TRANSPARENT
  13. I think that if Hak5 has the Alfa adapter listed as compatible, it will work. I guess the reason why many are complaining about lack of Linux support is that those comments are "historical" (i.e. rather old) since the MT7612U chipset (that the AWUS036ACM is built around) is supported in newer kernels. I have a couple of Aukey WF-R13 (with the MT7612UN chipset) and they work "out of the box" in Ubuntu and fresh releases of Kali Linux along with for example airodump-ng in monitor mode. Even MediaTek themselves lists Linux as a working operating system on the MT7612U chipset info page: https
  14. RP-SMA according to page 2 of the manual https://fccid.io/2AA52MK7/Users-Manual/User-manual-4650996 It can also be spotted on the FCC external images https://fccid.io/2AA52MK7/External-Photos/External-photos-4650988
  15. Have you tried just plugging the LAN Turtle into the Surface? It should work, but you won't get an IP address from the network. The IP address will originate from the LAN Turtle range (i.e. 172.16.84.x). The LAN Turtle in its hand will get an IP address from the network to which the LAN Turtle is connected to. Not sure if that is important to you though.
  16. I''m still not sure what you mean by "This", but the only thing that you should need to exit in step 7 is the vim editor. To do that you need to make sure you aren't in Insert mode, press the Esc key to exit Insert mode and then exit the vim editor and write the file using :wq! and press Enter. Just like Void-Byte does in his step-by-step video at about 7 minutes into the video. https://youtu.be/aVQ9Df_v5X4?t=420
  17. Are you meaning exiting the vim editor or what menu are you referring to?
  18. OK, so when you reboot and check with, for example, the date command, the timezone is still UTC and not the timezone you previously configured?
  19. Perhaps you will find the answer posted by Dragorn (most likely "Mr Kismet" himself) in the WiFi Pineapple Mark VII section of the forum.
  20. Try editing: /etc/config/system in section: config system change: option timezone 'UTC' to: option timezone 'whatever timezone' reboot and verify with the date command and/or cat /tmp/TZ
  21. I've made a payload script that should more or less accomplish the scenario describe in this forum thread. The code isn't all that pretty and can be tidied up for sure. A lot of LED blinking that isn't really necessary and variables that can be reused in a more appropriate way. However... the payload should work. It at least does for me. It's available on my GitHub. https://github.com/chrizree/Hak5-SignalOwl-Loot-or-Scan
  22. I was planning to edit my previous post, but it will just get cluttered so I posted this separately for visibility. Here's my findings and suggestion for a solution. The line below in the "scan_wifi" function in the payload script cat /tmp/wifi_scan | grep "Encryption key:off" -A1 | grep ESSID | sort | uniq | cut -c 28- | sed "s/.$//g" > /tmp/open also grabs open APs with no ESSID string, this causes the script to stop executing since it's not possible for the later "connect_wifi" function to actually connect to an ESSID that has no name. The current payload script also grabs th
  23. I don't know if it is to any help and it's certainly not fast, but here's some information from my point of view. At SSH logon, the banner similar to the one pasted below should show, it displays the current version of the Signal Owl firmware BusyBox v1.30.1 () built-in shell (ash) .___. {o,o} /)__) Hak5 Signal Owl " " Version 1.0.1 ======================================= Built on OpenWRT 19.07 ======================================= The banner showing the version can of course also be obtained by viewing the /etc/banner file M
  24. I found some odd behavior using this script today. It stops executing and the reason for it is logic but at the same time... yeah, odd... Some executions of the payload script works pretty much as expected, but sometimes it just stops. Even if the payload.log file says it has found, for example, 2 open access point to scan it just scans the first but halts on the second one. Sometime it halts on the first AP found. As I was analyzing all the files produced during a scan that are placed in the /tmp directory, I observed the fact that the payload script identifies an AP as "open" but when lookin
  25. Did you use any "official" payload script as base for your modifications? I.e some Shark Jack nmap payload script available on the Hak5 GitHub. https://github.com/hak5/sharkjack-payloads EDIT: Remove the -sC parameter and the scan will work. Run the nmap scan "live" when SSH'd into the SharkJack and you will get the answer why the payload isn't working, i.e. nmap will run but (as it normally does when encountered with something that is not correct or supported) it just shows the list of all the options combined with any eventual error messages and then exit, hence the result tha
×
×
  • Create New...