Connecting to OWL via SSH after WIFI_CONNECT

[Sect10n_9]

After getting my OWL today and spending way more time then necessary trying to figure out the "LED BLINKS" I have finally gotten my OWL onto my WiFi and accessible via SSH. This seems like it would be easy to do, but alas its not.

1. You need to understand that the OWL is not running its payload off of the USB device you plug into it. Rather it overwrites the payload.txt file located in /root/payload and overwrites the files located in /root/payload/extensions. I have yet to confirm that it erases the directory completely before writing, but I think it is likely just overwriting files with the same name. Once the files are written the USB stick just becomes mounted space.
2. Clicking the "Button" causes the system to re-run the payload and dumps the created folder in /root/loot to the mounted USB device. I don't think this folder is created on the mounted USB stick until the button is pressed.
3. Pressing the "Button" at the wrong moment in the boot can crash the entire thing. I have also noticed that it may corrupt or erase the payload.txt and cause you to need to reinsert the USB stick and refresh the payload.txt or extensions.

The following is my WIFI_CONNECT named payload.txt

#!/bin/bash
WIFI_SSID="%mySSID%"
WIFI_PASS="%myPWD%"
WIFI_CONNECT
/etc/init.d/ssh start
C2CONNECT
LED SPECIAL2

The following is my WIFI_CONNECT extension located in /root/payload/extensions labeled WIFI_CONNECT.sh I did not write this, i located it at https://github.com/hak5/owl-payloads/

#!/bin/bash
#
# Title: WIFI_CONNECT
# Description: Simplifies WiFi client mode connection. Expects $WIFI_SSID and $WIFI_PASS
# Author: Hak5Darren

function WIFI_CONNECT() {
    logger running extension: wifi_connect
    ifconfig wlan0 up;sleep 2
    echo -e "network={\nssid=\"$WIFI_SSID\"\npsk=\"$WIFI_PASS\"\npriority=1\n}">/tmp/wpa.conf
    wpa_supplicant -B -Dnl80211 -i wlan0 -c /tmp/wpa.conf
    while(iwconfig wlan0 | grep Not-Associated); do sleep 1; done
    udhcpc -i wlan0
}
export -f WIFI_CONNECT

After a few attempts to run this payload and about 2-3mins of waiting it was accessible VIA ssh on my network.

the default login is

USER:root

PWD:hak5owl

notice that on my payload.txt i have the line /ect/init.d/ssh start. In the small amount of documentation I've found this line has always been /ect/init.d/sshd start. I don't know why this made a difference for me but i could never access it via SSH until i changed this line. The system is running on OpenWrt and I've since looked at some info on commands there and i still don't have an answer. I do know that once you successfully login you are greeted with the following:

BusyBox v1.30.1 () built-in shell (ash)

 .___.
 {o,o}
 /)__)  Hak5 Signal Owl
  "  "  Version 1.0.0
=======================================
 Built on OpenWRT 19.07
=======================================
root@Owl:~#

Mby this will give everyone some version numbers to research and find answers.

For any Hak5 people reading this.

1. Multi color LEDs are a must on this. even 2 or 3 colors with blink patterns is better than what this has. I have had it 1 day and I want to throw it into a wall trying to diagnose the rapid red led blink codes.
2. Stop recessing the "Button". If I were to go on engagement and bring this with me it would need to be something i can manipulate one handed.
3. we would like some documentation on how some of the "uncommon" Features work. i.e. the uploading and downloading from usb drive.
4. Explain how to connect this to C2. I cant find anything to get this to work. There is a file that C2 gives you but where do i put it. Where in my payload do I run the command.

That's just a few questions, I'm sure ill have more. Unless I break it first. 😉

 

[Sect10n_9]

I did just figure out how to connect the OWL to C2. See https://docs.hak5.org/hc/en-us/articles/360014295634-Adding-Devices-to-Cloud-C2

[rylore]

@austinwilly So you mention "After a few attempts to run this payload and about 2-3mins of waiting it was accessible VIA ssh on my network." How did you get the IP address for the owl that was assigned to it once it connected to the WiFi through the payload, did you run nmap etc. Curious how this would work with an engagement where you plug it into someone's computer have the payload connect to a wifi that you can get access to as well (Lets say an open starbucks network near the office),  how do you know which IP it is so you can connect via ssh.

In theory on my home network I can just look at my wifi controller and see it connect, but out and about how would you go about doing that. Only option I can think of is use nmap to scan for port 22

[Sect10n_9]

I am running a Google Mesh setup at home and the app allows me to view all connected devices by MAC. I suppose NMAP would work to find it. If your on the network then there are a number of ways to discover devices.

What i would like to see is having dual network cards one connecting to the network to run the payload and one for management with the option to disable the SSID brodcast to collect loot or manage. If you have the device permanently deployed you could use it to collect loot anytime you are in range as well. 

[rylore]

From my home I'm the same way I can see the connections (couldn't get it to work last night though), but from an engagement perspective I agree that it would be easier to have the dual network. Maybe that's why they created the C2 connect that I still need to look into. I know this product is new, but I would like to have seen a little more documentation.

[Sect10n_9]

I agree, having some sort of management option is a must with this device. I am curious if it could be set up with a WiFi or Bluetooth chip in the usable USB slot but I'm worried about storage space for the "Loot" or how many times it has failed during boot for me even after 1 day. I know we are on firmware 1.0.0 but it really seems to have issues during boot. It seems like every other boot attempt either fails or corrupts the current "Payload". I've taken to leaving the USB stick plugged in as the only way to ensure a clean boot. once its online it can be removed and reinserted if necessary. It does seem to auto mount the sda1 without issue.

My next experiment will be having it C2 connect to a domain outside of its network. Though from an engagement standpoint this would be dangerous as it would leave a traceable connection. I just want to be sure that it can be pointed in that direction and if i can set a custom port to use. on the receiving end i will use a custom port number as well and see if it can be hopped across multiple connections. Think Seedbox, in an offsite location where i can connect and download at will, a sort of logging server.

For a BlueTeam device this might be an interesting "Canarie". i could leave it onsite at locations that have experienced issues or is at risk. Have it uploading a constant NMAP or other tools and set alerts on the logging server to alert me when certain conditions are connected. This is already something that can be done with other devices but i like the low power use and the Stealth aspects of this device. Its small, light, and can easily be mistaken for a USB hub.

I have already use a Pineapple Nano for this in a few circumstances but this would be an interesting addition, assuming the bugs can be worked out.

[vepr]

That's strange that you have to run /etc/init.d/ssh instead of /etc/init.d/sshd

When I'm SSH'd in arming mode, I have to restart SSH using /etc/init.d/sshd restart.

Just giving SSH will give me command not found.

Does attack mode use a different SSH service?

[vepr]

So one method we can get information on the device when connected to a large network is have it reach out to a web server on the internet and relay it's information.  Maybe create a simple form and write a script to have the Owl post to that form with it's current IP address and other information. 

If the network allows SMTP,  we could possibly use a Python script that sends an email using Gmail credentials?

When I get some time, I can help you guys do this if you want.

[Sect10n_9]

26 minutes ago, vepr said:

That's strange that you have to run /etc/init.d/ssh instead of /etc/init.d/sshd

When I'm SSH'd in arming mode, I have to restart SSH using /etc/init.d/sshd restart.

Just giving SSH will give me command not found.

Does attack mode use a different SSH service?

I cant just issue /etc/init.d/ssh start on the command line either but having it in the script is the only way I've gotten it to work. Its strange as hell.

[vepr]

Yeah, that is strange.  I'll try /ssh again.  Are you using a USB adapter on the host port of your Owl device? I wasn't sure if I should be trying to connect with the built in wifi or an external wifi adapter.  I've tried both.  Also, do you keep % on your SSID and Password or do you just have that there to show that it is a user variable?  I don't have % but I'm just checking every option. lol

Edited August 14, 2019 by vepr

[Sect10n_9]

12 hours ago, vepr said:

So one method we can get information on the device when connected to a large network is have it reach out to a web server on the internet and relay it's information.  Maybe create a simple form and write a script to have the Owl post to that form with it's current IP address and other information. 

If the network allows SMTP,  we could possibly use a Python script that sends an email using Gmail credentials?

When I get some time, I can help you guys do this if you want.

That might work but its going to look really odd to anyone paying attention. Which is ultimately the point i guess. 😉  I really like the idea of having a second adhoc network not broadcasting SSID that i could "drive by" connect and dump data from. Or fly a drone by with a micro comp set to pull on connection. I really want to use a drone one time. Just to say I've done it.

10 hours ago, vepr said:

Yeah, that is strange.  I'll try /ssh again.  Are you using a USB adapter on the host port of your Owl device? I wasn't sure if I should be trying to connect with the built in wifi or an external wifi adapter.  I've tried both.  Also, do you keep % on your SSID and Password or do you just have that there to show that it is a user variable?  I don't have % but I'm just checking every option. lol

No, Ive been using the builtin WiFI because Ive been having to reinsert a USB stick after the OWL randomly fails to boot to refresh the Payload.

No the %sign% is just a place holder. Like %appdata%.

make sure you have the #!/bin/bash a the start of your payload and your WIFI_CONNECT.sh https://docs.hak5.org/hc/en-us/articles/360033504014-Payload-Development-Basics for some reason Ive seen people leave this out.

#!/bin/bash
WIFI_SSID="something"
WIFI_PASS="somethingelse"

The best advice i can give is approach the process piece by piece. Get it on the WiFi, confirm its on the WiFi, then try to get a shell prompt, afterwards try to get it connected to C2. If you try to approach it all at once you can run into a lot of problems.

 

[vepr]

Yeah, I'm out of ideas.  I have added the #!/bin/bash.

I've run the payload with the SSH line commented out.  I've also tried using /etc/init.d/ssh and sshd. 

I wiped everything and copied and pasted the .sh and .txt.  Both files are executable.  No luck with multiple AP names and passwords.

I guess I can try and set a static IP  instead of using DHCP.

Edited August 14, 2019 by vepr

[Sect10n_9]

21 minutes ago, vepr said:

Yeah, I'm out of ideas.  I have added the #!/bin/bash.

I've run the payload with the SSH line commented out.  I've also tried using /etc/init.d/ssh and sshd.

I guess I can try and set a static IP  instead of using DHCP.  I'll also try connecting to a different AP.

I have a couple of questions

1. Did you do the firmware update? https://docs.hak5.org/hc/en-us/articles/360033611914-Setting-up-the-Signal-Owl-for-the-first-time
2. What is the LED showing?
   1. In my config up top i have LED SPECIAL2 which changes the LED to a double blink followed by a solid red that repeats once the payload runs successfully. 
3. Is your payload labeled payload.txt and on the root of a inserted flash drive?
4. Is your extension labeled WIFI_CONNECT.sh (in all caps) and located in a folder labeled extensions on your flash drive?
5. Did you use the configs i have at the top exactly? (except for the SSID and password of course)

[vepr]

ahhhhh I didn't have WIFI_CONNECT.sh in all caps.  That did it.  Thanks for analyzing that!

I'm not using a flash drive for the payload.  I have the payloads directly on the Owl device.

 

I checked and it works with both

/etc/init.d/sshd start

and

/etc/init.d/ssh start

Edited August 14, 2019 by vepr

[Sect10n_9]

22 minutes ago, vepr said:

ahhhhh I didn't have WIFI_CONNECT.sh in all caps.  That did it.  Thanks for analyzing that!

I'm not using a flash drive for the payload.  I have the payloads directly on the Owl device.

 

I checked and it works with both

/etc/init.d/sshd start

and

/etc/init.d/ssh start

Np, I've done that a few times. going back and forth between windows boxes and linux makes my head hurt sometimes.

The SSH thing is interesting. I'm curious why that works. I'd really like to see log output on what happens when the script runs the command. I am really interested in setting up a second WiFi adapter for management. I just wish there was some way to set both the USB ports for either pass-through or active use.

Now i have discovered something interesting. When the OWL is booted with a USB storage device attached at some point during boot it auto-mounts it. Once this is done It can be removed or reinserted at will. However, if a new drive is inserted it does not auto mount. I suspect this (https://openwrt.org/docs/guide-user/storage/usb-drives-quickstart) is happening.

Next i connected a USB 3.0 hub and had 2 USB drives inserted at the time of boot. It auto-mounted both starting with slot 0 then moving on to slot 1. I suspect if 4 drives were placed in the hub it would follow the same pattern. in the end i think they all would be auto mounted. I suspect that if we want to connect WiFi adapters, Bluetooth adapters, or USB drives they will need to be inserted before boot before they will work. Unless we can built a script into the payload to control mounting new hardware when its attached.

The following is my SSH output after booting with 2 usb drives in a usb 3.0 hub. Pay attention to the names it gives the drives. It names drive 0 /sdb and creates a seperate partition mount /sdb1 even though it is in slot 0. the drive in slot 1 receives /sda.

BusyBox v1.30.1 () built-in shell (ash)

 .___.
 {o,o}
 /)__)  Hak5 Signal Owl
  "  "  Version 1.0.0
=======================================
 Built on OpenWRT 19.07
=======================================
root@Owl:~# cd ..
root@Owl:/# ls
bin      etc      mnt      proc     root     sys      usb      var
dev      lib      overlay  rom      sbin     tmp      usr      www
root@Owl:/# cd mnt
root@Owl:/mnt# ls
sda   sdb1
root@Owl:/mnt# cd sda
root@Owl:/mnt/sda# ls
System Volume Information
root@Owl:/mnt# ls
sda   sdb1
root@Owl:/mnt# cd sdb1
root@Owl:/mnt/sdb1# ls
System Volume Information  owl_loot_1565663725
extensions                 payload.txt
root@Owl:/mnt/sdb1# ls -al /dev/sd*
brw-------    1 root     root        8,   0 Jan  1  1970 /dev/sda
brw-------    1 root     root        8,  16 Jan  1  1970 /dev/sdb
brw-------    1 root     root        8,  17 Jan  1  1970 /dev/sdb1
root@Owl:/mnt/sdb1#

 

[vepr]

That is interesting.  Something is wrong with my Owl.  I've been messing with it for a few hours tonight and discovered that it only works part of the time.  It connects to the Wifi AP about 25% of the time.  I have several APs that I have tested this on and it won't even connect to some of them.  About 50% of the time, the Owl boots up going through the usual LED pattern, then it just goes black and doesn't do anything at all.  This is really frustrating.

[d0nw4n]

So definitely a work in progress  :}  but it has great potential.   The blinking is definitely confusing.  I stumbled into a way to reliably get sshd up on WiFi which doesn't follow the docs (although my WIFI_CONNECT config file was taken from the docs):

- plug in owl let it boot (dont press button)
- plug in usb drive with /payload/extensions/WIFI_CONNECT
- press button
- wait at least 30 seconds (sometimes only takes 5)

(edit:  oh!  Totally missed Darren's payload: https://github.com/hak5/owl-payloads/tree/master/payloads/library/wifi/WiFi-Connect  - I just put the single WIFI_CONNECT file on the usb.  Now I see why y'all talking about .txt files :)

Edited August 15, 2019 by d0nw4n

[Sect10n_9]

31 minutes ago, d0nw4n said:

So definitely a work in progress  :}  but it has great potential.   The blinking is definitely confusing.  I stumbled into a way to reliably get sshd up on WiFi which doesn't follow the docs (although my WIFI_CONNECT config file was taken from the docs):

- plug in owl let it boot (dont press button)
- plug in usb drive with /payload/extensions/WIFI_CONNECT
- press button
- wait at least 30 seconds (sometimes only takes 5)

 

What your doing is really interesting, whats happening is that pressing the button after the payload has been run is causing a soft reboot. You can start the owl at anytime with the USB drive containing the payload & extensions and it does the same thing. However if the button was easier to press. (see first post in thread about things id liked changed.) you could quickly run multiple payloads as long as you have a few drives and a different payload on each drive. you could color code the drives and quickly change your attack or scan on the go.

Ive also discovered that starting the OWL with a USB drive containing the payload and extensions decreases the fail rate by a lot. It still happens from time to time but its less the 50% failure rate Vepr mentioned. However if you do this, unless you are using a USB hub, you lose the ability to have a Bluetooth or secondary WiFi adapter connected. Ive only tested this with USB drives but if it isn't booted with the device connected it cannot be accessed. If this behavior is different for WiFi adapters or Bluetooth adapters ill find that out soon as I've got one of each on order to mess around with.

Also if you boot with a USB device connected and then once the payload is run press the recessed button, it creates a folder on the USB drive that contains the "LOOT" from the previous payload. Its a quick way to dump your "LOOT" during engagement and why I'm upset that the "Button" is not easily accessed.

[tecno]

Hi,

As I was reading your posts above about how to get the IP address assigned so you can later SSH in, and I had an idea.  Insed of writing scripts and using a web portal and all that, couldn't you just do this...

1.  have your script loaded and ready so you know the Owl will connect to the target network.  Have a blank USB Drive handy

2. Once your script is tested and working add a simple line like

ifconfig wlan0 > /root/loot/systemIP

If you want to get fancy, you could even grep out the IP line and AWK the IP so it is alone in the file, but that's not really neccessary

3. Take that blank USB Drive and insert it into the hot USB port, then click the button.  The owl will copy the loot directory to your USB Drive and Whala...

 

simple and uncomplex to minimize failure.. from there your gold. Your already on-site with physical access and this process will take only a few minutes.

 

Alternatively you could have a second flash drive with the production script and have the device loaded with the "recon" script to obtain IP info.  Now once you put in the blank drive and get the loot dump, put in the second drive with the production script on it.  Once you do, press the button and it will copy the script, overwriting the old one, and restart running the production script and you have the IP and can SSH into it later.This requires no python or HTML or anything and seems more reliable to me.  

 

I haven't tested this at all, it is just an idea, so if you see any reason it wouldn't work please post.

 

Hope this helps

tecno

 

 

[Sect10n_9]

7 minutes ago, tecno said:

Hi,

As I was reading your posts above about how to get the IP address assigned so you can later SSH in, and I had an idea.  Insed of writing scripts and using a web portal and all that, couldn't you just do this...

 

Its an interesting Idea. I guess it depends on how you are using the OWL.

• Is it a an on-network tool that you want to access to pull loot over a period of time?
  • Is it somewhere you will have repeated access to or will most of your "retrievals" have to be remote/from somewhere else "AKA the lobby"?
• Are you using it like a payload dumper for onetime use?
  • The look of the device (looks like a USB hub) lends to a more permanent placement.
• Can you somehow use it to create a secondary management network as to keep your connections of the target network, to reduce the possibility of unfriendly attention.

I do like the idea though, but if only the "BUTTON" was easier to access. I will admit along with the LED being only one color, the "BUTTON" is my main hangup with this device." I wonder if there is some way to use what you suggest to get the device to "Call Out" to a predetermined path. This would also solve re-connection issues if you were to lose a DHCP lease and get ReIp'd. Id love to see something like this with a 3g card. Just a thought 😉

 

[tecno]

Hello,

 Hello,

I have been contemplating what to do about the button myself and I have an  idea for a solution which I guess would be considered layer 1, You know, a hardware solution. So because these devices are simple and one step above disposable let’s keep the solution super simple as well what do you think of this…

 

 Get a small ball bearing or plastic bead the perfect size to fit into the hole where the recessed button is.  Now,  take one of those artist rubber bands, you know the ones that are extra wide, but the right size to snuggly fit around the device and cover over the ball bearing sitting in the little button hole.  Now whenever you want to press the button simply squeeze the area and it will press. When you are finished installing simply remove the rubber band and the button is back to recessed and on able to be pressed by accident which could be a good thing if it’s in a place where you don’t want anyone to disturb it or press the button if someone gets curious. 

 

Now before you scarf and laugh at my hillbilly solution, think about it, it is a fool  proof  Solutions to the problem which will work reliably every time and costs pennies, is easily removed, and can be obtained just about anywhere. Simple and easy… 

 

Hope my wacky ideas are helpful

 Hope my wacky ideas are helpful

Tecno 

 

 

 

 So because these devices are simple and one step above disposable let’s keep the solution super simple as well what do you think of this…

 

 

[tecno]

That is supposed to say scoff…I wish I could go back and edit my typos