November 2018 - Stark 4N6

Friday, November 23, 2018

TeraCopy: A Forensic Analysis (Part 2)
November 23, 20180 Comments

In the part one we went over the details found in the "main.db" file for TeraCopy. Here we will review what the History folder looks like. It can be found in here:

C:\Users\<USERNAME>\AppData\Roaming\Teracopy\History

Each individual job that was run will get it's own History DB file. The naming convention as previously shown 

The DB file contains 15 columns as shown below:


Source - File/Folder name source

Offset - Start index position of the file/folder name from the source folder location

State - The state of the operation per file/folder 
0 - Added
1 - OK
2 - Verified
3 - Error
4 - Skipped
5 - Deleted
6 - Moved

Size - Size of the file in bytes

Attributes - properties of the individual files (source)


IsFolder - self explanatory
0 - No
1 - Yes

Creation, Access, Write - Shows the created, access, and modified dates of the file/folder in Julian format

SourceCRC - Hash of the file (MD5 by default)

TargetCRC - Verification hash post operation completion (not on by default)

TargetName - New name of the file if you copy/move and it is a duplicate

Message - For displaying errors or target issues

Marked - TBD

Hidden - Added to the operation but removed before/during ("Right click > Remove selected" from File List
0 - No
1 - Yes

One caveat for these logs is that in the interface for TeraCopy you can change the retention to 3 different options:

Never Keep History
Keep History for 1 day
Keep History for 1 week (default)



Though these options are hidden under a menu, it is easily configurable with some technical knowledge.

While TeraCopy might not be widely used, it is a huge benefit from a forensic perspective if you happen to stumble upon it in an investigation and have access to the logs.

UPDATE 12/3/2018: Part 3 is live




Monday, November 19, 2018

TeraCopy: A Forensic Analysis (Part 1)
November 19, 20180 Comments


TeraCopy is a great file transfer tool that I have been using for years because it was always faster than the Windows built in copier, allowed for pausing/resuming as well as many other features Microsoft lacked in Win7 (Win10 has added some of those). The other big thing that it was helpful with was that TeraCopy would keep all the original date/time stamps of the documents regardless if you used copy or move which was very helpful for keeping the forensic validity intact.

For information on the interface, you can find screenshots and descriptions here.

A recent case took me down the path of seeing if a user had stolen documents after they left the company for a possible competitor. My first instincts were to look at the usual locations: USB history, Recent folder and LNKs, shellbags, and Outlook/webmail. I noticed some activity that a USB drive was plugged in a week prior to the users departure date as well as some shellbag activity showing some folder structuring into what that USB had on it.

In my searchings I just so happened to stumble upon the DB log file for TeraCopy so naturally I decided to open it up and see what was inside. I'VE HIT THE MOTHERLOAD!

C:\Users\<USERNAME>\AppData\Roaming\Teracopy

This folder contains the "main.db" file which shows a list of TeraCopy jobs that were run. It also has another folder titled History which has separate DB files for each job that was run.

For this post we'll focus on the main.db file. It has 11 columns broken down to include the name of jobs run, the date/time the job was started, the source and target destinations for the jobs, the amount of files and the total size of the files in the job.



State - status of the job
0 - Pending (will also show this when Operation is Test)
1 - TBD, couldn't replicate but happened when copying the database file at the same time it was being written to I believe
2 - Completed

Name - name of the job (YYMMDD-HHMMSS naming convention, in UTC)

Started - date/time when the job was started in Julian format with offset of the computer's timezone (Never saw that format until now, thanks NASA for the clue!)

Finished - TBD, always been empty

Operation - Type of operation that was performed in the job
1 - Copy
2 - Move
3 - Test (basically a verification check)
6 - Delete (provides a deletion screen, with 3 options, all which lead to the same operation number)


Source - Folder location of the source folder/file (will show "multiple" if more than one file was dragged from different sources)

Target - Folder location of where the job was executed (operations Test and Delete leave this blank)

Overwrite - TBD, always been empty

Close - TBD, always been empty

Files - The total count of files in the job

Size - The total size of all the files (in bytes) in the job

Part 2 will look at the History folder and job DB's.

UPDATE 11/23/2018: Part 2 is live

UPDATE 12/3/2018: Part 3 is live

Sunday, November 11, 2018

BSidesDE 2018 Recap
November 11, 20180 Comments
I had the pleasure of going to one of my local BSides conferences down in Delaware this weekend. It's my third year going to this specific one and to me the talks keep getting better and better each year. Below are just a few takeaways from the talks I went to. A full list of talks can be found here.

Bryan Inagaki kicked things off with the keynote. He stressed having a good work life balance which is always welcomed from my perspective (TAKE THAT PTO).
[Talk Link]

Next up was @nightwatchcyber showing off some research on some Android bugs that he has disclosed to Google. It was interesting to see how you can be location tracked through your wifi signal.

Brandon Keath discussed ethical hacking and some simple tools and techniques you can use to get started.

Robert Simmons (@MalwareUtkonos) spoke on how you can group malicious files into families and how some AV providers use the same scanning engines. He also went through some tools for analysis.

Overall, I think the I learned a good bit of new info and that's the point of these conferences. You don't have to pay a ton of money for a ticket to learn new things, support your local BSides!