Project name: WEIRDFEED

 Project name: WEIRDFEED


Instruction on installing Kali Linux 2020.4 AMD64 using an ISO file downloaded from kali.org on a Windows 10 2004 host/"hypervisor" running VirtualBox 6.1.16 r140961 (w/ VirtualBox Extension Pack) and get the Hak5 Shark Jack available to the VM

Make sure that virtualization is enabled in BIOS/UEFI (VT-x/AMD-V) otherwise you might get the turtle



Create a new VM in VirtualBox by clicking "New"

Name the VM and select Linux as Type and Debian 64-bit as Version

Set the desired amount of RAM (using 2048 MB here)

Create a Virtual storage device (using 24 GB here)

The VM is now created, click "Settings" and make any additional config to the VM (# of CPUs/cores, video RAM, disable floppy, disable audio, shared folders, etc. anything of choice that is valid)

Last but not least, attach the Kali Linux ISO file to the virtual optical drive of the VM

Click "OK"

Click "Start" to boot the VM

Select the startup disk if asked (once again the Kali ISO image)

Select Graphical Install (default selection) and press enter

Select language, location and keyboard

Enter a hostname (skip domain if it's not something you need for some reason)

Enter user information

Select clock/time

Partition disks using the "Guided - use entire disk" and select the virtual storage device that was previously created (24 GB ish...), all files in one partition, finish and write to disk

Selected "options" are: Xfce, top10 and default

Do some push-ups while waiting...

Install the GRUB boot loader to the primary drive, select /dev/sda

The installer should detect that Kali is installed in a VM as a last step, so no need of installing Guest Additions like in other VirtualBox VMs (if missing, it can be installed manually, search for it, it's out there...)

Finish the installation (or Finnish the installation, if you're from Finland...)


Reboot into your new Kali VM

Login and resize the VM window (the first "proof" of the fact that the Guest Additions has been installed)

Upgrade the Kali VM

sudo apt clean
sudo apt update
sudo apt upgrade

or put it all together with some &&&&&&&&&&&&& and ------yyyyy

(more push-ups..., but with 0.5 Gbps down, there will be just a few push-ups during that 1 minute, lucky me!)

Run some more to really get it all in a clean upgraded state

sudo apt autoremove
sudo apt upgrade
sudo apt dist-upgrade


Shutdown the VM


OK, so now the fun begins... Hak5 time! Make the Shark Jack swim and bite in the VM

Since the onboard ethernet NIC on the Windows host machine is already used for main network access on the PC used in this particular instruction, an ASIX AX88772B based USB NIC is used (the "Hak5 branded" one from the Ethernet Essentials) to get access to the Shark from within the VM

Although the ASIX is a USB device, don't mess with USB filters, it will be enumerated/made available as a NIC in Windows and can be used directly in the VM settings

Plug the ASIX USB NIC into the host Windows PC

Make sure it's enumerated on the host Windows PC (I'm old fashioned, so... Control Panel > Network and Internet > Network and Sharing Center> Change Adapter Settings or... just run ipconfig /all from the Command Prompt)

Put the Shark in arming mode (middle position of the Shark switch) and plug it into the ASIX USB NIC

Try to ping the Shark @ 172.16.24.1 from the host Windows PC

Since Windows 10 is equipped with ssh, we don't need no PuTTY anymore, try to ssh into the Shark from the Command Prompt, should be no problem at all

Exit out of the ssh session


OK, with that verified, head over to VirtualBox again, note that the VM should still be powered off!

Click on "Settings" and the move to the "Network" section

Leave the "Adapter 1" tab as it is and click on the "Adapter 2" tab

Enable the adapter

Select "Bridged Adapter" in the "Attached to" drop down box

Select the USB NIC (ASIX) in the drop down box called "Name"

Close the Settings dialog box using the OK button


Start the VM

Open a Terminal and run ifconfig or ip addr

The Shark should be "visible" using its 172.16.24.0/24 range

ssh into the Shark using the 172.16.24.1 address, no problems!

Done! The Shark is alive!


If you want internet access (and name resolution) from the Shark, then some additional work is needed... Internet will most likely also disappear on the VM when the Shark is connected

To enable networking, on the VM, do:

Edit /etc/sysctl.conf and "enable" IPv4 forwarding

net.ipv4.ip_forward=1

Edit /etc/resolv.conf and add nameserver(s), remove any local ones

nameserver 1.1.1.1

nameserver 8.8.8.8

Set a static IP address in the VM for the NIC that is connected to the Shark, use 172.16.24.24/24 (or any address that corresponds with the address selected for the route command below on the Shark)

Restart networking service or reboot the VM

sudo service networking restart


Adjust the bb.sh or wp6.sh script from Hak5 to make it work with the Shark, call it sj.sh (if I'm kind enough, I might make my edited one available)

Execute sj.sh with sudo

The guided setup might not work, if so edit the defaults in the script instead and connect using saved settings, it should end up letting you know that the Shark is connected to the interwebs


NOTE! The below might mess with your Shark default setup, you have been warned and it's on your own risk, there's no risk for bricking it but you might have to use the firmware recovery to get it back to its original state if you don't memorize it all and reverse it

On the Shark, run:

route add default gw 172.16.24.24 eth0
or
ip route add default via 172.16.24.24

uci add_list dhcp.@dnsmasq[0].server="1.1.1.1"
uci add_list dhcp.@dnsmasq[0].server="8.8.8.8"
uci commit dhcp
service dnsmasq restart

now ping for example 1.1.1.1 or 8.8.8.8 from the Shark

then ping www.google.com to verify name resolution

Run some OpenWrt updates (the Hak5 package list will throw an error, it has been broken "for ages", or... at least a year ish)

opkg update


Tip: If having problems with not being able to connect to the Shark from the VM (even if it has worked before), make sure that the virtual network adapter hasn't been assigned to some other physical NIC than the one that the Shark is connected to, it may happen, verify (and change) under Network for the VM


EOF


Popular posts from this blog

Hak5 Cloud C2 on a Raspberry Pi

Setting up the Raspberry Pi (RPi) itself isn't covered here, a default installation of Raspberry Pi OS Lite will do the job. This setup will work on a LAN only, i.e. no external access to the C2 instance from the internet. To get that working, port openings and stuff is needed but that isn't covered here. If needed, run the following to get information about which C2 version to run on the RPi: cat /proc/cpuinfo Note! You need a license key from Hak5 in order to activate/validate the installation (the community edition is free, but still needs a license key). The RPi also needs to have a working connection to the internet since the C2 license is validated at service start, and during runtime as well. Download the C2 zip file to the RPi and unzip it wget https://c2.hak5.org/download/community -O c2.zip unzip c2.zip Start the server manually to verify that it works: ./c2-3.1.2_armv7_linux -hostname <ip address> (or whatever version that was downloaded) When the C2 instance h
Read more

Hak5 Cloud C2 as a Windows service

As long as the C2 Windows binary is just a plain and simple exe (i.e. a "non-service" executable), it won't be allowed to start as a service in Windows (error 1053). To do this, either A) the C2 binary for Windows needs to be developed in a way that it is allowed to be started as a service or B) use one of the utilities out there on the interwebs that allows using an "ordinary" exe as a service. The "Plan B" is used here building on the tool "srvstart". Download the latest C2 zip file from Hak5 and extract it Download srvstart and extract the zip file https://github.com/rozanski/srvstart/blob/master/srvstart/srvstart_run.v110.zip Copy/move the two DLL and two EXE files from the srvstart zip to the C:\Windows folder of the computer (or somewhere in PATH) Make sure that there is a "msvcrt.dll" file in C:\Windows\System32 Rename the Hak5 C2 executable (64 bit variant used here) to c2_amd64_windows.exe This makes it more "transpare
Read more