Setting up an O.MG cable for keystroke injection attacks, and then forensically dumping the firmware for analysis.
During my SANS 508 I first heard about something called Google Rapid Response (GRR) and it peaked my interest then. Unfortunately as is normal following a SANS course I was lost in the dark world I like to call ‘Indexing and Study’ or Hell 🙂 . I have since emerged from the other end after successfully obtaining my GCFA certification!
Thanks to Kev I am now in possession of a small ProxMox server. With some time on my hands I decided to deploy a server and play with some ‘Live Forensics’.
My first step is to deploy a custom Ubuntu 14.04 OpenVZ template. (you can read more about templates for ProxMox on Kev’s blog) . The container doesn’t need much in the way of resources, especially for my small test network, I assigned 2Gb of RAM and 1Gb of swap with two virtual cores and 40Gb of disk space. These will be more than enough to run GRR.
Once the template is deployed and has a static IP assigned i grab my SSH client of choice and connect.
Thanks to the GRR developers installation is reasonably straight forward for Ubuntu with a script that will walk you through all the required stages. The official documentation and the issues board on the GRR github should be your first stop if things go wrong.
Lets grab the install script.
# wget https://raw.githubusercontent.com/google/grr/master/scripts/install_script_ubuntu.sh
Now its just a case of running the script and I chose to press ‘a’ to allow the script to fully run without any more input from me, if there are any errors it will stop to tell you anyway.
# bash install_script_ubuntu.sh
For me this was the longest phase of the install and as I was testing (breaking things) I had to restart the process a few times during the day. It did not always go smoothly and would stop with error messages. I am unsure why it broke but after a few attempts it would normally complete the install.
Whilst I was verifying the build steps to write this post I was presented with an error that I had not been receiving the day before with my successful build. This was raised by Kev on the GRR Github and a fix was created and merged within a few days.
Once it has downloaded and installed its dependencies, the script will pause and wait for user input to configure the server. It is at this point you really need to be awake, unlike me! The information you provide now will determine whether the GRR server and its agents will work as intended or fail due to a Fleshware (User) error. Please don’t waste hours by not taking the time to read what it is asking you for 🙂 .
The first piece of information it will request from you is the hostname. In the case of my install I will be running GRR completely internal to my test network, which doesnt make use of internal host names, for this reason I used the ip address of the VM I was installing the GRR server to.
In my example 192.168.1.19.
The next piece of information it requires is the Server URL. This is the address that your deployed agents will be configured to call back to. Please ensure you do not forget to enter the requested port number and remember to use http://, believe me from personal experience that will cause you pain!
In my example http://192.168.1.19:8080/control
The next piece of information will be for the UI URL, this is how you will administer the server and gain access to the below GUI
In my example http://192.168.1.19:8000
It will then ask you for monitoring and backup email addresses you can use any email addresses you wish for that.
Step 3 will add an admin user account to the GRR server and you must choose a good, strong password.
It is worth noting that you only enter this once as it does not require to to confirm the password you entered, therefore be certain you don’t have any fat fingered moments 🙂
If you do enter a password incorrectly and find yourself locked out there is no need to panic you dont need a full install. There is a command line script to reset passwords.
# grr_config_updater update_user admin --password yourpasshere
you can run grr_config_updater -h for a full list of commands
If all has gone well you should see the following.
By default it will display the hostname rather than the IP you have provided, although the IP will still work.
Now we all know I love a good GUI and GRR has one of those! I just open my browser on my analysis machine and go to http://192.168.1.23:8000 and then login with the credentials I provided during the setup of the server, and hey presto!
Now I may have posted the link above to that really handy user guide but I am the first to admit I totally ignored it because I am a man and I like to think I know everything already 🙂
Initially I just clicked everything and was lucky to find the area for creating my agents.
For those of you who don’t enjoy the bull in a china shop method it can be found under the ‘Manage Binaries’ menu:
I initially wanted to test on a Win 7 VM I already have running on the network so I selected grr_188.8.131.52_amd64.exe as the VM is a 64bit VM. Select the agent and then click on the download icon above it. It really is then a case of deploying the agent to the VM. There are numerous methods that could be used PSExec, USB etc but on this occasion I uploaded the agent to the public area of my dropbox and then downloaded it from within the Windows VM.
Once downloaded onto the host VM I ran it as administrator and it then silently installs. Switching back to the Grr web panel I was expecting to see a connected client. Its at this point I realised I really should read that very handy user guide. Upon doing so it became apparent that I would need to use the handy search feature to find the client!
Now I tried searching for the IP of the client but had no joy, The user guide holds a key to a possible explanation.
There are several search types that you can perform which are detailed within the user guide linked above:
To find my Windows VM I chose to search for the user, which I knew on this occasion to be ‘windows’. As soon as I clicked search I was greeted with the following:
Clicking on the row will bring you to the ‘Host Information ‘ screen which in itself has a large amount of information regarding the host the client is now reporting from.
The idea behind this post was purely to document my build and deployment process. As I delve further into GRR and its abilities I will post more on the features as I discover them.
I am very impressed with what I have seen so far and some of the features within GRR are certainly massive time savers for the incident responder!
I hope this blog post was useful or interesting to you in some way and as always comments, suggestions and corrections are welcome below.