Onion Peeler: Batch Tor Lookup Program

Logs, Logs, Logs. I see, IPs. When reviewing log files for suspect activity it can be helpful to look up information related to IP addresses. There is a great utility for this by Nirsoft called IPNetinfo. You can import a whole list of IP addresses and it will give you "the owner of the IP address, the country/state name, IP addresses range, contact information (address, phone, fax, and email), and more."

When I am reviewing log files, an IP address associated with a foreign country may peak my interest. Another check I like to do is look for activity associated with Tor nodes. In a corporate environment, a user accessing a system from a Tor exit node may be a red flag.

When I am checking an IP address to see if it is associated with a Tor exit node I will use a website like ExoneraTor. It lets me put in an IP address and a date, and lets me know if the IP address is associate with a Tor relay. While this is a great tool, if I have a list of IP addresses to check, it's not very efficient. To that end, I wrote a little program to help automate the process of checking a list of IP addresses against Tor Relays and Bridges, Onion Peeler.

Onion Peeler is written in Python and uses OnionPy. OnionPy is a wrapper for the OnionOO Tor Api. Using OnionPy, Onion Peeler caches a local copy of the Tor exit nodes and performs a check for a list of supplied IP addresses. What's nice is that if you have a list of sensitive IPs, the information is not shared and is kept locally:

It will output a list of matches:

Since it's in Python, the program is cross-platform compatible. I've tested it on Windows, Linux and Mac. It just requires OnionPy, which can be installed using "pip install OnionPy". I also have a compiled Windows Executable if you don't have Python installed. It requires an Internet connection as the initial query grabs the latest Tor nodes from OnionOO. I am thinking about adding in a way to store an offline copy in the next version as well as add in additional details about the Tor nodes (first seen, last seen etc.)

It took about a minute to check 8,000 IP addresses. Of course, a bigger list will take longer, so be patient.

Code and program are available on my github.

When Windows Lies

Wait, What? Windows lies? I believe so...

I worked a case where I checked the Windows Install date and it was a couple days before we received the system. GREAT....did the user reformat their drive and do a fresh install before handing over the laptop? Did they reinstall the OS? This would not have been the first time a laptop or system was rebuilt after an incident (either on purpose or by accident).

Checking basic information like the Operating System and Installation date can help a examiner prioritize the systems they need to examine and check for evidence spoliation issues. If you have 20 systems to go through, and the Operating System has been installed AFTER the date of the incident you may want to focus on some other systems first. In civil or criminal cases, an installation date right before you receive the evidence may raise some red flags.

So now that we have established why the Operating Installation date can be important, there is a registry key you can retrieve it from, HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion. RegRipper has a great plugin for this, named OSVersion that pulls not only the OS version, but the install date from the registry key . Running this against my test system I got the following output:

----------------------------------------
winver v.20081210
(Software) Get Windows version

ProductName = Windows 10 Home
InstallDate = Fri Feb  3 15:58:47 2017
----------------------------------------

What??? Install date of February 3rd, 2017?? 2 weeks ago??? Since this is my system, I know I did not install Windows 10 February 3rd. I have had Windows 10 Home since the roll out in 2015!

Just to be a thorough, I verified the date was being parsed correctly and looked at the raw data in the registry:
 

Install date is  0x5894a8b7 which is Fri, 03 February 2017 15:58:47 UTC.

Ok, one last check... running the systeminfo command it clearly shows "Original Install Date" as  2/3/2017 8:58:47 AM. I am UTC -7, so this information matches my above results.

OK - Windows, I think you are lying to me. I'm hurt. But, to add insult to injury, with some more digging around I find out that YOU MESSED WITH MY LOGS during this supposed install.

I have a snapshot of my system previous to the supposed install date of February 3rd, 2017. Note the created dates on the Event Logs - 12/12/2015 and a size of 20MB:

 Now I look at the current created dates and files sizes of my event logs. Note that the created date is the same of this supposed install date, 2/3/2017. Not only that, but my log files are much smaller, some about 2MB:

When I opened my logs, as expected, there are no entries before 2/3/2017, and the first entry matches with this supposed install date:

I was curious what may have caused this. Since Windows updates have caused issues with artifact timestamps before, such as USB devices, I checked the Windows Update history. Sure enough, there was a Windows update, "Feature update to Windows 10, version 1607" which ran on 2/3/2017.This date matches the supposed install date:

Since my update history contained more than one update ran on 2/3/17, I wanted to check some other Windows 10 systems to see what I could find out. I knew approximately when both of these systems  had their operating systems installed, and both had incorrect installation dates listed, as well as the Feature Update v. 1607 that ran on the same day.


System 1 (Windows 10 Home)
Registry Install Date: 9/27/2016 11:22:39
Event Log created Dates: 9/27/2016 11:11
Feature update to Windows 10, version 1607:  9/27/2016

System 2 (Window 10 Pro)
Registry Install Date: 10/1/2016 3:47
Log created Dates: 10/1/2016 3:42
Feature update to Windows 10, version 1607: 10/1/2016

So, my working hypothesis is that the Feature update to Windows 10, version 1607 is updating the Windows Installation time and deleting the logs.

This may just be a matter of semantics.. maybe "Operating Install Date" really means - latest major version update??? This artifact may be open to misinterpretation if that is the case.

Why is this important?

Possible Incorrect conclusion of evidence spoliation
Imagine you are working a civil case where the opposing side is supposed to produce and turn over a laptop. If you see the installation date was recent, you might incorrectly conclude that they installed the OS right before handing over the system. Or, in Incident Response you may incorrectly assume that the operating system was just installed and there may not be too many goodies to find.

 
You loose event logs
Event logs can make up a critical component of an exam. In the case I was working, this update happened right before I received the laptop. The event logs only had about a day in them. Yes, there may be backups, or a SIEM collecting them, but it just makes the exam more involved. 

Other Artifacts????
These are just the two inconsistencies I have found so far... there are probably  more...

I would like to test this more formally by setting up a virtual machine and tracking the updates to see what happens, however, based upon the systems I have looked at, I think Windows is lying.

As always, correlating findings against multiple artifacts could help determine if this install date is accurate.

Just a note and something else to be aware of - in many corporate environments the Operating System install date may be incorrect due to clones/images being used to  push out machines. However, I don't consider this as Windows lying because the date would reflect the install date of the original before it was cloned.