For a few years, I had been using Access Data’s FTK (Forensic Toolkit) software without any formal training. I had managed to work my way through the fundamentals on my own, but I always sensed that there was much on which I was missing out.
FTK Email Analysis Visualization
It was only after I recently attended the Advance FTK class offered by AccessData (Syntricate) that I realized the enormity of what had been right under my nose the whole time.
You can read my complete review of this course at Forensic Focus or by clicking here.
The other day I came across a social media post that was about utilizing Burp Suite to identify vulnerabilities in web applications. I had heard of Burp before but never really had the chance to play around with it – until now.
Just like a lot of other security tools, Burp has a community version along with its commercial product. I decided to download the free edition from here in my home lab. The installation process is straightforward and in no time you have Burp up and running. Here is how the initial interface looks like:
Right when I finished my installation of Burp, I realized that I did not have a web application running in my lab that I could use to test Burp against. Bummer! Now I had to decide between setting up a web server myself or finding a commercial distribution that came pre-built with one. This was a no-brainer – and within minutes I found a few distributions that were designed for testing and learning web application security; such as SamuraiWTF,WebGoat and Kali Web Application Metapackages. I decided to go with SamuraiWTF.
SamuraiWTF gives you the option to run from a live disk or install it in a VM. I decided to install the VM. Here is a good guide to the installation process. I give my VM instance 4GB RAM and 3 cores; more than enough horsepower.
After finishing all of the above prep work, I was ready to run Burp!
For those who are not familiar with Burp, it’s an interception proxy which sits between your browser and the web server and by doing so it is able to intercept requests/responses and provides you the ability to manipulate the content. To do so you have to configure Burp as your proxy. On your VM, this would be your localhost (Proxy Tab > Options):
Likewise, you would have to configure your browser to that same proxy. Here is my proxy configuration on Firefox:
Now as you navigate through your Mutilliadae webpage, all your requests should go through Burp. One thing you have to do is turn on the Intercept option in Burp. It’s under Proxy > Intercept.
What this allows you to do is see the request as its made but gives you the control to either forward it to the web server or simply drop the request (like a typical MiTM). For example, on the login page of Mutilliade i used admin name and admin123 password. And as soon as I hit “Login” I saw the request being made from my browser to the web server in Burp:
In the screenshot above, you can see the two options: Forward and Drop. If you hit forward, the web server will receive this request from your browser and will respond as it would normally. In this case, the account I used to log in did not exist:
Burp has the capability to also capture the responses. It is an option that you can turn on by going to Proxy > Options and towards the middle of the page you will see “Intercept Server Responses”. By turning this on you will be able to see and control both sides of the requests:
If you look at Target > Site Map; on the left pane you will see a list of all the sites that you have visited with the Burp proxy on:
One advantage of the above feature is that it allows you to go back and revisit requests and responses. The sites that are in grey color are those that are available on the target web page but you have not visited them.
Another neat feature is that if you do not want to visit each page individually you can run the “Spider” feature which will map the whole target page for you.
If you go under Spider > Control you are able to see the status of the Spider as it runs:
When you intercept request or response, you have the ability to send that to other features of Burp. You are able to view these additional options by right-clicking on the intercept:
Towards the bottom of the official Burp Suite guide page here you can see a brief description of most of the options shown in the screenshot above. The one I found really neat is the “Repeater” option which allows you to modify and re-transmit requests repeatedly without having the need to perform new intercepts each time.
This concludes my brief journey of getting started with Burp using SamuraiWTF. There is a whole lot more than I had the chance to explore but here is a great reference for advanced topics.
Below is a quick blurb on some of Burps features:
Spider: crawls the target and saves the numerous web pages that are on the target.
Intruder: automated attack feature which tries to automagically determine which parameters can be targeted i.e. fuzzing.
Fuzzing options: Sniper (fuzz each position one-by-one), Battering Ram (all positions on the target receive one payload), Pitchfork (each target position is fuzzed in parallel) Cluster Bomb (repeats through payloads for multiple positions at once).
Proxy: used to capture requests & responses to either just monitor or manipulate and replay.
Scope: controls what (pages, sites) is in/out of the test “scope”.
Above is in response to COVID19 – valid until May 15, 2020.
The process of timeline creation is extremely critical in forensic because it provides you with a holistic view of the system in question and gets you one step closer to answering those key questions. There are multiple ways that you can create a system’s timeline. However, the one I recently came to know is Autopsy’s Timeline Analysis module and here is my first experience with it.
Autopsy can be downloaded from here. The installation is simple – no dongle required!
To test the timeline module, I used one of my test windows 7 machines. And to create some activity, I browsed the known-bad-URLs and downloaded some potentially malicious files. Also, installed AVG AntiVirus Free edition as a basic detection mechanism. However, to my surprise, AVG was able to detect and block most of the executables that I tried to run.
Since I had to run some executable to create the lab, so instead of making exceptions in AVG – I decided to uninstall it. I figured it would be interesting to see how the evidence of software uninstall will be presented.
I went back and ran the following three executables: sydzcr22.exe, b.exe, b01.exe.
In addition, I added the total of two new accounts on this machine. First, one (admin01) I created using the windows “Manage Accounts” interface and the second (admin02) via command prompt. Both accounts have administrative privileges.
Lastly, I made a logical image of the target system and created a new case in Autopsy. Here is a guide on how to create a case and add evidence in Autopsy.
This is how the output after the initial processing is completed looks like:
As you will notice from the screenshot above, a lot of the common places that you would want to look in an image are readily available in a nice, organized manner. The first thing I did was perform keyword searches for the three executables that I ran earlier (sydzcr22.exe, b.exe, b01.exe) just to confirm their presence.
The keyword search was pretty fast and it found all the three exe files that I had browsed and installed. In the screenshot we can see the exes’ browsed URL, date, and the location on the disk where that piece of evidence is located; index.dat. I searched the Temporary Internet Files but was only able to find one B01.exe but not others; not sure why.
The second thing I wanted to look for is the installation of the AVG antivirus and then the removal. Let’s see what we find.
The first place I looked at was the “Installed Programs” menu option:
I do not see any instance of AVG here. But regardless, I guess this is a handy feature to have quick access to in order to see the installed applications at the time the image was acquired. I see the AVG2015 folder under Program Data directory but not much more:
So with this, now we get to the reason why we started this project – timeline! The process for generating a timeline is pretty simple. You go to Tools and the Timeline. You see a status bar and at least for my image (120G) it took around 2-3 minutes and I had my timeline opened in the second window:
As you will notice in the second screenshot above, there are some anomalies in the time range. You can easily modify the scope by using the scale on the top left, the start and end (not shown in the screenshot) options towards the middle of the screen as well as using the graph itself to zoom into the date of interest. From all of these options, the one that I liked the most is right-clicking on the time range of your interest and select the “Zoom into Time Range” options. In my option this is faster and easier than messing with the scales:
As you continue to zoom in you will get to the month timeframe where you can see which date of the month had what amount of events:
Lastly, when you zoom into one specific day of the month you can see the events by the hour:
So getting back to finding AVG activity, I first see the web activity
In the screenshot above, please take a note of the “Text Filter” option; which comes handy in narrowing down results. In fact, if you don’t narrow down the results the system will not be able to display the events and instead will give the following message:
However, it seems like if you change the “Visualization Mode” from “Count” to “Details” you are able to overcome the above limitation. However, the output is in a different format:
Notice above that when you hover over any of the events, you receive the option for further details by the symbols of “+” and “-“. However, after spending some time going through the information presented above, I did not get close to finding answers to the original questions. This is not to say that information here is not valuable, it just did not come handy in answering our particular questions.
So my next step was to extract windows event logs from the image and review them. And pretty quickly we find the following entries:
Similarly, we find log entries for removal:
With the information presented from our target system’s event logs, we are now able to see both the successful installation and later the removal of the AVG anti-virus software. It would have been nice to see some of the event log information in our timeline.
On a side note, while looking through application logs, I found two application crash events; one for our b.exe and the second for sydzcr22.exe – both of which we attempted to install from the browser earlier in the lab.
The last question that we wanted to answer was the evidence of account creation for admin01 and admin02. Both of which we created earlier – one using Windows Account Management interface and the second via command prompt. Here is the windows log event for the first one:
Here is the evidence of the second account creation:
Based on the above to account creation logs, we cannot tell which account was created via windows interface vs command prompt. The only difference that we see is that one account has its password set (which is the account we created through command prompt and had to give it a password but without this knowledge we cannot tell the difference). Also, the account created from the command prompt (admin02) does not have the “Display Name” set; maybe this could be an identifier.
On a separate note, if we go back to our timeline and see the events around the time frame of the above windows events we see the following activity.
If you look at that first entry, it refers to the following default account display picture:
Around the same time we see security logs getting updated:
This is all the information that I can pick out from our timeline that I think is there to indicate the creation of an account. However, what’s interesting is that in our timeline we do not see any entry to command prompt – which we used to create the second account and if there was an entry for it, it could be used as another hint.
Anyway, at this point, I was not sure how to go about getting user account artifacts so I reached out to the people of DFIR community via Twitter and as always got wonderful feedback. One of the suggestions was to perform shellbag analysis. This was a great suggestion however, this was not going to work in our situation. The reason being, shellbag analysis requires two artifacts for each account: ntuser.dat and usrclass.dat. These two artifacts are created the first time the user interactively logs on at the computer; establishing a user account on the computer does not create a profile for that user. In our case, we did not login using either of the (admino1, admin02) accounts after we created them, hence there aren’t any profile files like there are for our main (dfir) account:
Some of the other suggestions included examining memory of the target system (which we did not acquire) and reviewing windows command line history (which is not saved by default on the disk running Win7-32 but again could have pulled from memory).
So the last thing I wanted to check out before closing out this lab was to do a quick comparison with traditional log2timeline. So I ran l2t against the same disk image and here is the outcome of our super timeline:
There is a lot that is going on here but the key things to look at is when the two accounts are created and what happens to them. The first account (admin01 – created via GUI) is underlined in red and the second account (admin02 – created via cmd) is underlined in blue. The section marked in green shows the launch of command prompt. It is obvious that the first account was created right after the creation of few security event logs however, the second account was created right after the launch of windows command prompt (there is some delay in seconds but that was due to me confirming the cmd line syntax before executing).
The last thing I want to point out from our super timeline – which correlates with our earlier finding during the manual review of event logs and is the small section in the screenshot above highlighted in yellow. You will notice that for the first account, admin01 there is an account name right next to the SAM ID of the same name. However, for the second account we just see the SAM ID but no account name.
This concludes my exploration of Autopsy and its timeline feature. The goal here was not to simply go through the different menu options of this powerful tool but rather run it against a made up scenario. And even the scenario itself is something that I made up as I went along in the process; so to be honest, I am not sure how some of the other (even commercial) tools would handle this scenario. In the end, the whole post became another CDR entry where we almost went through all the three stages to an extent. Anyway, it took me some time to gather all the screenshots and do this write up from the time when I actually did the lab; so I am sure numerous updates have been made to the tool since then. Overall, I am very pleased with the tool and the capabilities that it provides; hard to believe its free! When I did the lab, the timeline feature was fairly a new addition to the tool but we can surely expect some awesome updates to it. Definitely, an awesome, powerful and fast tool to have in your toolbox – check it out!
(Here is the update on user account creation analysis done by @b!n@ry – Great job!; instead of looking for usrclass.dat for the new accounts created, you would look into the account you suspect created those two new accounts! Ref: 1 and 2. Also the net.exe and net1.exe prefetch files proved to be extremely valuable). #NoteToSelf! :)
My last blog post was related to setting up Nessus home edition scanner for your lab to do testing. Nessus is properly what I am most familiar with and I like it. I also have some experience using Qualys scanner but it has been couple years since I have used it. However, the scanning technology that I have only heard of but never actually used is Nexpose. So for that reason, I figured I give it a try.
Similar to other commercial scanning technologies, there is a community edition of Nexpose that you can download in your home lab for testing from here.
They have a pretty straightforward user/installation guide here, which I followed in my installation. But just in-case, here is the high-level overview of how I did my setup.
Selected the VMWare Virtual Appliance option of the Community Edition
Completed the online forum and received the activation code in the email
The download contains 1.02GB of .ova file called NexposeVA.ova
I opened that file using VMWare Workstation
Please note that by default, it allocates 8GB of memory, 2 processors and 160GB of disk space. So, please modify these settings if you do not have those resources available before you power-on the VM.
After the VM completely boots, you will login using the following credentials: login: nexpose password: nexpose (please change this)
If you just want to complete the most basic setup and want to get up and running immediately without messing with any of the advanced configurations or upgrades, the only configuration you need to do is networking. The virtual appliance is set up in bridge mode by default and should be able to get you an IP automatically. But if you need to give it static IP then you will have to do that manually.
At this point, you are pretty much done with the setup. You will be able to complete the rest of the setup by accessing your Nexpose instance by typing following in your browser: https[:]//[VM-IP-Address]:3780
The default username for the web interface is: nxadmin and the password is: nxpassword
After your first login, the initialization process will take some time. For me, it was about 5-7 minutes.