Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


About chrizree

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I assume that you are on the v6.2 firmware since you have included a screenshot displaying that firmware version. I can't reproduce the problem with my v6.2 based LAN Turtle though. Is it the openvpn module alone that produces the described problems, or all, or just some? Which modules in that case? I had the same kind of problem with the urlsnarf module when upgrading to v6.2. First I got the indication that the module was started even though I hadn't done anything to enable it apart from installing the module itself. The reason for this was that no executable binary was actually available in the system at all. My conclusion is that the urlsnarf module (although available via the Module Manager) isn't available anymore since v6.2 and therefore "deprecated" as a module (executable not installable either using opkg, the script file is now also empty when installing it using the Module Manager and the module/script is also removed from the GitHub repository of modules). So, check that the openvpn binary actually is present in your system. It should, I have it in my stock v6.2 system. It should reside in /usr/sbin (check permissions as well). You can also position yourself in the root of the file system and run: find . -perm /u=x | grep "openvpn" I know, it sounds really "non-logical" that the module indicates that something is started that isn't even available. Well, it's the module that is started, not the executable binary, I guess. OK, so now on to the next issue with trying to unsuccessfully stop a module. Yet again I had this issue with urlsnarf (although on an older firmware, I think it was 5.0 since that is the "restore firmware" version that also holds the urlsnarf binary). I got a message similar to yours, i.e. that the module with a certain process ID was killed. But..... it was still running when issuing ps to check for processes. I might remember the details wrong but in any way I solved it by renaming the module script file. When trying to "debug", I executed ps before trying to stop the module, but the PID that was returned in the Turtle GUI was not the same (but a higher number) as the one I had been identified previously. I'm not sure though how this affects the openvpn module since that seems to use "killall" to stop processes. As I remember it, urlsnarf (that I had problems with) didn't use killall. However, I figured out that there is a “naming conflict” between the binary urlsnarf (in /usr/sbin) and the script urlsnarf (in /etc/turtle/modules) The negative effect to this “conflict” is that the process of stopping urlsnarf kills one process but is leaving one running. I'm not sure that this solves your situation at all though since you seem to have nothing running. However, I renamed the urlsnarf script file in /etc/turtle/modules to “get-some-http-loot” and after doing that, I didn't have this problem anymore. The only effect was a different name listed among the LAN Turtle modules in the LAN Turtle "GUI", but I could live with that 🙂 Also compare the content your version of the openvpn module script with the one published on GitHub. Some files (openvpn is one of them) where updates just some days ago. Not sure though if it really affects the problems you are facing. The modules are located on the Turtle in /etc/turtle/modules https://github.com/hak5/lanturtle-modules/tree/gh-pages/modules Also try to start and stop the modules from the command line. It's sometimes easier to catch output there rather than in the "semi GUI" of the Turtle. /etc/turtle/modules/<module_name> start /etc/turtle/modules/<module_name> stop it's also possible to run it with a kind of "shortcut" start <module_name> stop <module_name> For example /etc/turtle/modules/netcat-revshell start /etc/turtle/modules/netcat-revshell stop start netcat-revshell stop netcat-revshell Try to "hack" the LAN Turtle based on the above and hopefully you will find something that works for you.
  2. There are posts on the forum that states that there are ideas about getting non-Hak5-devices, such as the Raspberry Pi, connected to Cloud C2. Those posts were back in late 2018 though, but I guess there's a lot of stuff going on in the "Hak5 factory" that occupies valuable dev resources. Most likely not a top priority compared to the management of the Hak5 ecosystem, but totally possible to happen I guess. In the meantime, a Raspberry Pi can still exfiltrate loot to Cloud C2 if using Hak5 devices as "loot shippers". It is possible to use at least the LAN Turtle, Packet Squirrel and WiFi Pineapple for such purposes. Collect the loot desired using the Raspberry Pi, ship the loot to the Hak5 device and then let the Hak5 device upload the loot to Cloud C2. I have made example bash code available for both the Raspberry Pi and different Hak5 devices on my GitHub. https://github.com/chrizree/LootShipper
  3. In short; one thing to check is the command line string that Cloud C2 is executed with, either if it is a service or started manually, and make sure the identification of the server (hostname) is correct since this is used when creating device.config files in the C2 web GUI. The TLDR version of this post is that I set up my Cloud C2 instance on a VPS and was trying it out when started manually. I added devices and everything was working as expected. I then set up my C2 instance with https and added it as a service and everything still worked as expected. Recently I was messing around with my LAN Turtle and had to remove it from C2. Since I didn't have any device.config file laying around, I created a new one in the C2 interface. After scp'ing the file to the LAN Turtle, it never showed up in Cloud C2. I tried to force the Turtle online using C2CONNECT but it just told me the device was already connected. Well, that made me start to think something fishy was going on. I then opened the device.config file to view its content. Although it's mainly filled with binary garbage, the domain name is visible in plain text and I could immediately notice that the domain name was wrong since it included the example.com domain. After calming down and removing the paranoia hat, I realized that I hadn't been hacked and it was most likely my bad. Heading over to the server running my C2 instance and executing ps ax, it was obvious that my C2 service was running with the wrong domain name/hostname. When changing to the correct domain name in the cloudc2.service file and restarting the service (and of course generating a new device.config file and adding it to my Turtle), the Turtle popped up on the beach again. So, I was a bit too quick when setting C2 up as a service according to Darren's video (link below), I just made a copy/paste of the service file example that is in the description of the video and didn't pay enough attention to the content (that included the domain example.com) https://www.youtube.com/watch?v=rgmL75ZBfSI Since everything was working fine for the other previously provisioned devices when running with example.com as hostname, I guess that the only use for the hostname parameter is to generate device.config files correctly.
  4. I'm using cron bash jobs and C2EXFIL to get loot to Cloud C2 from the LAN Turtle, the exact solution depends on the module used and the kind of loot that is exfiltrated. Not really equal to "getting a specific folder shared" but it's a way to get a kind of automated "loot stream" from the LAN Turtle. It's not manual at least.
  5. Is there some binary of urlsnarf available for v6.2 of the LAN Turtle firmware? It is available in the v5 recovery image but that one doesn't execute on v6.2. It is possible to grab the urlsnarf binary from the latest WiFi Pineapple firmware version (running OpenWRT 19.07x) and it executes on the Turtle but required libraries are missing and can't be installed using opkg on the Turtle. I've tried to temporarily add the Pineapple repo/feed to opkg to install libraries but it just messes up the Turtle. It would be good to have a working urlsnarf binary for the LAN Turtle v6.2 since it's available as a module via the Module Manager. As an alternative, the urlsnarf module should perhaps be flagged as broken and removed from possible install candidates of LAN Turtle v6.2 modules. It is possible though to recreate similar kind of functionality using variants of tcpdump execution.
  • Create New...