Wednesday, July 18, 2018

Daily Blog #425: How I Use It: Userassist

Hello Reader,
             I'm currently teaching in Abu Dhabi and hanging out with my family at night which means I'm not investing the time to do the next level of MAPI testing I need to do. Instead after the warm reception yesterdays post received I thought I would follow it up with a new series I will add to over time called ' How I Use It'.

Often times we talk about artifacts and evidence sources and how to interpret them, in fact there are so many that most people often forget what they know about them. What we don't often talk about is how we as examiners use that data within their casework to make conclusions or points.

So in this first post in this series of how I use different artifacts I want to talk about the Userassist key. This isn't a new key, it's been around since I first saw it in 2002 and wrote about it in the first Hacking Exposed Computer Forensics book in 2004 but people seem to overlook its usefulness.

Userassist records those programs that a user has executed from the GUI, that I would hope is well known at this point. I've posted about it once in 2013 (http://www.hecfblog.com/2013/08/daily-blog-45-understanding-artifacts.html) and even earlierin 2009 (http://www.hecfblog.com/2009/03/what-did-they-take-when-they-left-part_25.html) both times I didn't really go into detail of what I use it for.

So here are my main analysis points from reviewing this artifacts:


1. What kinds of programs is my suspect executing?


It's difficult to judge the technical proficiency of a suspect from the statements of the people who knew them as their frame of reference in judging their technical abilities is usually focused around how well they use Excel or Outlook. So rather than letting their statements of their abilities to be 'master hackers'  I like to see what kinds of GUI programs they've been executing.

Is it just Office, Outlook and IE?  Or are they loading regedit, going into the command prompt and looking into different system mmc's.  The difference in what they are executing helps me judge the types of artifacts I should expect to find and how closely I need to inspect the dates and artifacts the system is showing me.

In addition I can look for evidence of encryption tools (Veracrypt/Truecrypt), wipers (eraser/bcwipe) and even anti forensics tools (Ccleaner, everyone's favorite). All from one helpful key that will even tell me how many times they've executed it.


2. How far back does the Userassist go? Is it complete?


The Userassist key starts populating data when your first profile is first created and you've logged in for the first time. That means that the history of programs within the key should go back as far as the user profile creation. If there is a gap, especially if it is a large gap, you could be seeing evidence of anti forensics. Start looking for what happened immediately before the gap began to see what could have cleared the data.

Also remember that deleted registry keys, just like deleted files, are not gone just because we delete them. So make sure to use a tool that will show you any potential deleted userassist keys or values. tools like Registry Explorer, YARU and others can expose this data to you while exploring the keys.

3. What email clients is my suspect using?


I'm often looking for my suspects email archives. Rather than guessing what Email client they are using (yes some people don't use Outlook) I can just go to the Userassist key to find out. Unless you have a very interesting suspect using a command line based email reader (pine in windows subsystem for linux?)  the rest are GUI based and should be recorded. If I find no email clients I need to look for what web mail services my suspect is using in their browser history.


4. What web browsers is my suspect using?


Lastly in my normal inspection of the Userassist I'm looking to understand what web browsers by suspect is using. It is not uncommon now for a suspect to be using 2, 3 or even 4 different web browsers on their system during one day. So I use this as a sanity check to make sure:

1. I'm looking for history from all of those browsers, its easy to miss one and focus on the others
2.  I need to make sure my forensic tools support the browser being used, I'm looking at you Maxthon, as its easy to miss a whole browser history cache because you didn't realize the limits of your tool.

So that's the first 4 questions I would answer when reviewing this key and I review this key early in my investigation along with other basic artifacts (execution history, file access and device usage) to start understanding what to expect from this system.


Tuesday, July 17, 2018

Daily Blog #424: The registry key so nice they named it twice, computername computername

Hello Reader,
               I enjoy teaching forensics as students always ask questions to make you figure out things you just take for granted. A good example of this was last month while in Amsterdam I had a student ask, hey why is the computername registry key in the System registry (located under System\\Control\ComputernName\CompuerName) under a registry key named computername. 

I've always made jokes about this key, see post title above, but never really took the time to understand why it was setup this way. A couple of google searches and some in class testing later I had my answer.

It turns out that when you change the name of your Windows computer in the control panel that a new key is added to the base computername key. This new key called ActiveComputerName contains the old name of the computer prior to you changing it while the new name you have given the computer is now stored in the ComputerName key.

Here is the ComputerName key after renaming the computer



Here is the old name of the computer, located in the ActiveComputerName key

Here is the new name of the computer in the ComputerName key



On reboot the activecomputername key is deleted and the new ComputerName key is kept.

So there you go, there is in fact a reason and a function for the duplication in the computername registry key. Every key, every decision has a story and understanding how it works and why will only make you a better examiner. 

Sunday, July 15, 2018

Daily Blog #423: Sunday Funday 7/15/18

Hello Reader,
          Windows 10 keeps on changing and with it new features come along that we care about and old features we were excited about disappear. Let's see if you can solve this missing artifacts mystery in this weeks Sunday Funday.


The Prize:
$100 Amazon Giftcard

The Rules:

  1. You must post your answer before Friday 7/20/18 7PM CST (GMT -5)
  2. The most complete answer wins
  3. You are allowed to edit your answer after posting
  4. If two answers are too similar for one to win, the one with the earlier posting time wins
  5. Be specific and be thoughtfu
  6. Anonymous entries are allowed, please email them to dcowen@g-cpartners.com. Please state in your email if you would like to be anonymous or not if you win.
  7. In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post



The Challenge:
Cortana used to have a database that kept track of location information and other relevant DFIR data. As of a year ago the database has changed and the location data is nowhere to be found. For this weeks challenge please answer the following questions:
1. Where does Cortana keep it's data now
2. What data does Cortana retain now 
3. Is there any location history left from Cortana

Daily Blog #422 Solution Saturday 7/14/18

Hello Reader,
         Things are always changing in forensics and especially forensic analysis of cloud hosted systems. This weeks challenge involved Office 365 audit logs and while the contest was going this week Microsoft announced welcome changes that will be rolled out that will change both the question and this weeks answer. So congratulations to this weeks winner Adam Harrison .



The Challenge:
Explain in a compromise of a Office365 account what you could review in the following circumstances.

Scenario a: only default logging in a E3 plan

Scenario b: Full mailbox auditing turned on

You are attempting in both scenarios to understand the scope of the attackers access 





The Winning Answer from Adam Harrison:


The first point to note is that a compromise of Office 365 (while commonly referred to as Business Email Compromise (BEC)) is not necessarily limited to email accounts. Depending on how an organisation employs Office 365 they may host a wealth of information besides just email and attachments in O365, much of which could be valuable to an attacker. In the case of the in-scope E3 plan, each compromised user account could potentially expose:

Exchange — Email messages, attachments and Calendars (Mailbox size up to 100GB)
OneDrive — 1TB per user, unless increased by admins to up to 25TB.
SharePoint — Whatever sites that user has access to.
Skype — Messages, call and video call history data
Microsoft Teams — Messages, call and video call history data as well as data within integrated apps.
Yammer — Whatever it is people actually do on Yammer. Are you prepared for a full compromise of your organisation's memes, reaction gifs and cat pictures?

All of that before you concern yourself with the likelihood of credential reuse, passwords which may be stored within O365 (Within documents and emails) for other services, delegated access to other mailboxes and MDM functionality.

Specifically answering the two questions:

Scenario a: only default logging in a E3 plan

Below is a non-comprehensive list of evidence sources which may be available to an examiner to assist in understanding the scale/scope of an O365 compromise:

  • Unified Audit Log, via Audit Log Search in the Security & Compliance Centre and accessible using Search-UnifiedAuditLog' cmdlet. This will need to be enabled if not already enabled and will provide retrospective visibility if enabled after the fact.
  • Mailbox Content
  • Read Tracking 
  • Message Tracking Logs
  • Mailbox Rule information
  • Proxy Logs/ DNS Logs/ Endpoint AV Logs / SIEM
  • Office 365 Management Activity API
  • Azure Active Directory reports and Reporting Audit API (With Azure AD P1/P2)

Scenario b: Full mailbox auditing turned on

By default, Auditing is not enabled, nor are the more granular Mailbox Auditing and SharePoint Site Collection Audit options. However, if we assume that 'audit log search' has been enabled as well as the optional logging associated with enabling 'mailbox auditing' and that audit has been configured for all SharePoint site collections then the following additional evidence sources become available.

  • Unified Audit Log - but now with more detailed events recorded as a result of enabling 'mailbox auditing'. The 'Search-MailboxAuditLog' will now also be available.
  • SharePoint Audit log reports

It should be noted that simply enabling mailbox audit logging for all mailboxes is not enough to capture all useful events. By default, only the 'UpdateFolderPermissions' action is logged with additional events requiring configuration, these include Create, HardDelete, MailboxLogin, Move, MoveToDeletedltems, SoftDelete and Update events.

SharePoint audit logging is pretty granular and, in my experience, rarely enabled. However, if correctly configured a record of user actions including document access, modification and deletion actions can be generated.

These evidence sources, their usefulness and some suggested methodologies to leverage them are outlined in my recent blog post.


Friday, July 13, 2018

Daily Blog #421: Magical DFIR Beasts and where to find them

Hello Reader,
                  Good news, the Unicorn maybe dead but it turns out all of the issues that it raised is causing a major change from the Office 365 team. You can read the official announcement here: https://techcommunity.microsoft.com/t5/Security-Privacy-and-Compliance/Exchange-Mailbox-Auditing-will-be-enabled-by-default/ba-p/215171 but here is the TLDR:

1. Mailbox auditing will now be turned on in full mode by default for all commercial tenants
2. If you already have mailbox auditing turned on it will continue to be on
3. They are going to add more audit flags to provide more granular access

This is great news and it should be on by default across your potential investigations by the end of year, but you could always just try to talk people into turning it on now!

Thursday, July 12, 2018

Daily Blog #420: 2018 Unofficial Defcon CTF Update

Hello Reader,
           In the first 24 hours we've already had 39 signups for the CTF, last year we had 125 and I've expanded the initial amount to 200 to start with. I wanted to provide an update because we are going to cap this to keep it manageable and I expect that we are going to hit our max again this year.

Why do I expect to hit the max? Well if you consider there are over 10,000 people at Defcon then 200 is only .02% of the total population. We think there are more DFIR and DFIR interested people at Defcon than most of us realize and our hope is to build the interest into a community there to bring people into out world that may not realize we exist.

Make sure to sign up here:
https://www.eventbrite.com/e/unofficial-defcon-dfir-ctf-2018-tickets-47978189055

Tuesday, July 10, 2018

Daily Blog #419: Unofficial Defcon DFIR CTF 2018

Hello Reader,
            Matt and I are working on creating the evidence you will be examining for next months Unofficial Defcon DFIR CTF! This post is here to let you know that:

1. We plan to do it again this year
2. We will be distributing the files electronically this year, no in person transfer needed
3. Signups will happen through CTFd I'll be posting the link closer to Defcon
4. If you or your company wants to supply a prize we open to working with you on that. Last year we did it in partnership with SANS who provided DFIR Netwars Continuous to the winners
5. This years scenario is set to be much more involved than last years, if everything we are planning works out
6. We are still planning on restricting this to people who are in Las Vegas for the event. Why? So we can get everyone who qualifies together at the end

We had a lot of fun last year and we look forward to meeting new talented examiners this year.

You can sign up here:
https://www.eventbrite.com/e/unofficial-defcon-dfir-ctf-2018-tickets-47978189055

Matt and I will be doing a live stream during the event to provide some commentary on how it's going. This is something we wanted to do after the Magnet CTF and it should be fun.

Monday, July 9, 2018

Daily Blog #418: Exploring Extended MAPI part 19

Hello Reader,
         Since my last test that showed that the Extended MAPI data wasn't be updated when I modified a message in OWA in my local outlook client I've been testing ways to get this updated data.

First I tried to download my mailbox, but apparently I need to get a working EWS url first. So I'll try that again tomorrow.

Second I went into the compliance center and searched for and found my test message I've been experimenting with. In doing this I downloaded the original message in EML format (the only option given) and I still did not find the updated extended MAPI data as seen below:


Here the Last Modification time got set to when I downloaded the message from Compliance Center and the original submission time exists. But I have no Last Verb time or code showing this message was replied too.

Third I emailed myself the message in OWA as an attachment by drag and dropping the message into a new email, this actually put the message as a MSG attached to the email message. Once I accessed this within Outlook in my local system I was able to see the expected data:



Here you can see that we finally have the expected Last Verb time showing when the message was replied to and when it was replied to. The Last Modification has been updated to reflect when I sent the message to myself as an attachment.


So I now need to download the mailbox fresh and then look into my local outlook account to see if this data has finally been updated.

Sunday, July 8, 2018

Daily Blog #417: Sunday Funday 7/8/18

Hello Reader,
          The Unicorn is dead so it's time to move on with the resources that we have for an investigation. So let's see what you can do with this weeks Office365 focused challenge.


The Prize:
$100 Amazon Giftcard

The Rules:

  1. You must post your answer before Friday 7/13/18 7PM CST (GMT -5)
  2. The most complete answer wins
  3. You are allowed to edit your answer after posting
  4. If two answers are too similar for one to win, the one with the earlier posting time wins
  5. Be specific and be thoughtful 
  6. Anonymous entries are allowed, please email them to dcowen@g-cpartners.com. Please state in your email if you would like to be anonymous or not if you win.
  7. In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post



The Challenge:
Explain in a compromise of a Office365 account what you could review in the following circumstances.

Scenario a: only default logging in a E3 plan

Scenario b: Full mailbox auditing turned on

You are attempting in both scenarios to understand the scope of the attackers access 

Saturday, July 7, 2018

Daily Blog #416: Solution Saturday 7/7/18

Hello Reader,
            Looks like I went a little too far with this weeks challenge, I'll make sure that next weeks is more in line with the level of effort people are willing to spend in a week.

The Challenge:
A computer without TPM and has Windows 10 with a bitlocker encrypted drive is being upgraded. When it reboots in the upgrade process it does not prompt for the bitlocker password and it appears as though during the upgrade process the system is not protected. Your challenge is determine what level of access an examiner has during the upgrade process on a windows 10 system that is bitlocker encrypted during the reboot. 

1. Can you access the contents of the disk?
2. Can you boot to alternative media while it boots?
3. Can you access the drive if you prevent the reboot process from completing?
4. What is the mechanism that Windows is using to do this?
5. Can you force an update without logging in or while it is locked?
6. Can you reboot for an upgrade without logging in?

The winning answer:
Phil Moore


Since Adam's going with "I dunno, probably" I figured I'd do the same:

A computer without TPM and has Windows 10 with a bitlocker encrypted drive is being upgraded. When it reboots in the upgrade process it does not prompt for the bitlocker password and it appears as though during the upgrade process the system is not protected. Your challenge is determine what level of access an examiner has during the upgrade process on a windows 10 system that is bitlocker encrypted during the reboot. 

1. Can you access the contents of the disk?
Sounds like it's still in a decrypted state; probably even stores the key somewhere during the reboot process

2. Can you boot to alternative media while it boots? 
Maybe

3. Can you access the drive if you prevent the reboot process from completing?
I'm guessing it'll be re-encrypted once it loses power. 
Would probably be able to get the key out of memory

4. What is the mechanism that Windows is using to do this?
Not sure

5. Can you force an update without logging in or while it is locked?
Dont know, highly doubt it

6. Can you reboot for an upgrade without logging in?
Doubt it

But yes I think this challenge was a little bit more hands on than the previous.
Although you could do it in a VM I suppose
 

Friday, July 6, 2018

Daily Blog #415: The Death of a Unicorn

Hello Reader,
      If you followed the original Crowdstrike post or the follow on post from LMG security calling the Activities API a 'unicorn' of sorts then I'm sorry to say the technique now appears to no longer be functional. It's been a long time since I've seen the DFIR community be this obsessed with a single artifact but either Microsoft is closing this for good or is going to replace this with maybe default mailbox audit logging in the future.

To be clear this isn't the first or only evidence source that a company has retained as a secret. I'm not in the business of airing companies internal choices but I will point this out to put this in a larger context. DFIR is made up of two niche industries, Digital Forensics and Incident Response. There are differences between these two fields of work and while they may rely on each other to function those on the DF side need to document their new research in reports and disclose them to allow another party to verify and respond to their work. There are normally two or more experts from different companies working on every case.

Compare this to the very competitive Incident Response world where a company can get a substantial competitive advantage by finding a new evidence source. If one IR company can tell a client they can find evidence another can't they might win more business while if a DF expert tells a client they can find evidence no one else can it might not be admissible unless they can explain how to do it to the other side. There are many IR companies right now sitting on undisclosed evidence sources and threat intelligence sources. They will continue to do so until they are required not to.


The point? In this case the public disclosure of an evidence source has ended its use by all parties. Whether this was because
  •  it wasn't supposed to be used for these purposes
  •  too many people began taxing the use of the API
  • the powers that be at Microsoft were worried about people misinterpreting the results of the API 
  • or just a large company not enjoying being called unethical for people using an API that was documented but had a use that most within the company were not aware of
We won't know unless they come out publicly and state it, which seems highly unlikely.  What we do know is that they have responded in one way we can all see and that is by turning off the source of all the controversy in the first place.

If I was arguing to disclose a secret evidence source within my company I'm pretty sure I just lost that argument to those who worry it would stop working after disclosure.

Thursday, July 5, 2018

Daily Blog #414: Exploring Extended MAPI part 18

Hello Reader,
         I'm in the BKK airport heading to Phuket today in my continued adventures. Got here nice and early so now I'm at the gate writing a blog post! After my last post I'm very curious now about what other actions I take in OWA will effect my already downloaded Outlook mail. So to get a base line I'm doing something that I think will for sure modify the message on both sides, I'm reply to the message.

In my initial testing, replying to a message in OWA for a message I sent through Outlook connected to the same account, I brought up the original message and inspected the Extended MAPI to find there was No Change!

Meaning that the message wasn't marked a replied to and within outlook it didn't recognize the conversation thread within the message. Something very interesting is happening.

I'm going to attempt to restart Outlook and see if I can get it resync everything but this certainly changes how I'm going to have to approach these investigations. I need to start pulling the data from exchange directly to see if doing that will update the metadata.

Wednesday, July 4, 2018

Daily Blog #413: Exploring Extended MAPI part 17

Hello Reader,
            With all the talk about the Office 365 API I thought it might be worth testing how OWA (Outlook Web Access) accesses in Office 365 modified my local sync'd Outlook OST. This is important as there are many situations where the victim and the attacker are accessing the same mailbox in different forms and knowing what to expect when you do your analysis is important.

So the first thing I did today was to mark an item unread in OWA and then I sync'd my Outlook folders and saw the message go unread. After which I pulled up the Extended MAPI data within Outlook Spy and well, it didn't go as I expected.

When I looked at the last modification I found this

Which is showing that even though the message was marked unread and read again that the last modification time didn't change from the time it was originally. In fact going through all the dates i didn't find any updates made at all.

I think next I need to retrieve the message directly to test it again but tomorrow I'll be doing more Outlook testing.

Tuesday, July 3, 2018

Daily Blog #412: The importance of blogging,,, daily

Hello Reader,
          I'm up in the air on my way to Bangkok, Thailand at the moment. I was planning on doing some attachment testing by changing file system timestamps but leaving the internal metadata timestamps in place to see what happens. BTW Emirates Wifi is good enough for googling and blog posting. However I've also been reading, or trying to read, what other people have been writing as well and I thought I'd reference what I've been seeing.

If you've seen Brett Shavers most recent post he made the point that of all of the quick publishing methods available to the examiner/researcher/enthusiast that the blog is still the longest live form of documentation we could make. I agree with Brett on this as I regularly google blog posts, including my own, to find details of things I've seen in the past. I find that googling a blog is much more reliable than trying to find a tweet or a slack message.

If you have been following my cohorts in the Zeltser challenge (knowledgebean and archerforensics) you would see that both are putting out content they think is relevant and helpful based on their own interests. Between the three of us we've covered iOS backups, getting into DFIR and my own journal into Extended MAPI (again). What I want to point out here is that each one of us is focusing on what we think is interesting, if you the reader agrees you'll follow.... if you don't it's ok there are other blogs out there for you.

What's important to me as the person who is finding time to write a blog post everyday even when traveling around the world and losing days (its a good thing I number these!) is that doing this pushes me to keep researching and publishing. While I appreciate everyone who reads this in the end I do the blog and the work within it because it makes me stay curious about DFIR. Every time I find or validate an artifact or technique I'm pushing myself to stay current and relevant.

If you noticed prior to daily blogging my posts were sparse and far between. In that time I didn't stop working on cases, far from it. Instead what happened was that I made it OK not to focus on anything that wasn't case work. Not forcing myself to look at new things means eventually I won't be prepared for the case that needs those answers, or to answer a question one of you or a student has. That is what pushes me, trying to know as much as possible and staying on the edge of what possible.

That I believe is the real point of the Zeltser challenge and its why what really inspired to do it in the first place was Lenny's comment when I first heard about it. After doing it for 16 months in a row (Lenny holds the record btw, maybe this time I'll go for two years) I mentioned he most feel some relief. Instead he looked at me and said 'Actually, I miss it'. At the time I didn't fully understand what he meant but after doing my own year and then taking a multi year break in between, I get it. Pushing yourself to do researching SOMETHING, write SOMETHING, think about SOMETHING every day makes you better no matter what that SOMETHING is.

So what I would say to my compatriots in the daily blog challenge. the point isn't writing a blog every day. The point is to never stop pushing yourself, because no matter who you are and how long or short you've been in DFIR we all have more to learn and things are always changing. So if you missed a day, SO WHAT! No one is keeping score, instead we are all hoping you keep going so we can keep learning from each other. If you are thinking about doing it, just go for it. Even if you just write one or more posts and stop, you still did more than 99% of the people out there and someday someone is going to be helped by what you wrote.

So reader, remember this. Just by reading this, we are friends. You share a common passion for finding the unknown in our field. Whether your interests lie in memory, malware, reverse engineering, mobile, windows, osx, linux or even car forensics we share a need to solve the unknown and answer the questions that need answering.

Want to know what you can do to help? Leave a comment, like a tweet, say hello in person to anyone you read. Everyone thinks that we must be overwhelmed with messages and don't want to be bothered but the truth is most of the time I'm just looking at a glowing screen writing to who I assume is reading this by view count hoping that it helps someone today or in the future.

Tomorrow, back to technical posts. But today I thought it was important to just reaffirm what others are saying. Write now. Write Often, Never stop learning.

Monday, July 2, 2018

Daily Blog #411: Exploring Extended MAPI Part 16

Hello Reader,
                 I decided to test a Microsoft Word attachment this time to see if the results would be any different. In the end the results were the same but I need to do one more test tomorrow to see if the internal metadata varies from the file system metadata if their is any difference.

Here is the original file metadata:


This is the Extended MAPI properties of the attachment


Again the creation time is being set to when the message was sent, this is different than Arman's testing so I'm trying to see what I'm doing different. I'll know for sure when he comes on the Forensic Lunch this month.

Here is the resulting metadata of the saved file:

More testing to come!

Sunday, July 1, 2018

Daily Blog #410: Sunday Funday 7/1/18

Hello Reader,
             Another great week of reading your submissions. I'm loving how the extra time is really letting people push the 'most complete answer' portion of the rules. Every week I'm hard pressed to decide who should win but there is always one thing within the answer that pushes it over the top and makes it a winner. Last week it was not just testing the timezone's set but how the dates themselves are set for accuracy on a per operating system basis. Let's see what happens this week!


I taught a great FOR500 class in Canberra this week and when I teach I always get a new question that needs an answer. So here is this week's bitlocker based Sunday Funday.

The Prize:
$100 Amazon Giftcard

The Rules:

  1. You must post your answer before Friday 6/29/18 7PM CST (GMT -5)
  2. The most complete answer wins
  3. You are allowed to edit your answer after posting
  4. If two answers are too similar for one to win, the one with the earlier posting time wins
  5. Be specific and be thoughtful 
  6. Anonymous entries are allowed, please email them to dcowen@g-cpartners.com. Please state in your email if you would like to be anonymous or not if you win.
  7. In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post



The Challenge:
A computer without TPM and has Windows 10 with a bitlocker encrypted drive is being upgraded. When it reboots in the upgrade process it does not prompt for the bitlocker password and it appears as though during the upgrade process the system is not protected. Your challenge is determine what level of access an examiner has during the upgrade process on a windows 10 system that is bitlocker encrypted during the reboot. 

1. Can you access the contents of the disk?
2. Can you boot to alternative media while it boots?
3. Can you access the drive if you prevent the reboot process from completing?
4. What is the mechanism that Windows is using to do this?
5. Can you force an update without logging in or while it is locked?
6. Can you reboot for an upgrade without logging in?

Saturday, June 30, 2018

Daily Blog #409: Solution Saturday 6/30/18

Hello Reader,
      Another contest has completed and changing the time frame of the contest seems to have benefited all of us. It benefits the people playing as they get more time to complete their answer, it benefits me as I get to ask more in depth questions and it benefits you the reader as you get even more information!

The Challenge:
ExFAT is documented to have a timezone field to document which timezone a timestamp was populated with. However most tools just see it as FAT and ignore it. For this challenge document for the following operating systems how they populate ExFAT timestamps and which utility will properly show the correct values.

Operating systems:
Windows 7
Windows 10
OSX High Sierre
Ubuntu Linux 16.04 

This weeks' winning answer from Paul Bryant, Senior Lecturer at  Wellington Institute of Technology (WelTec) can be downloaded here as there is no way I can embed this into the post:
https://www.dropbox.com/s/h8omup03bxoblkp/exfat_os_dir_entries.pdf?dl=0

Enjoy and great work Paul!

Daily Blog #408: Exploring Extended MAPI Part 15

Hello Reader,
            Another Friday where I'm not able to get a forensic test kitchen done due to my travel and teaching schedule but next week should be better!

Instead lets continue our outlook attachment testing, in the prior post I tested a png file. Let's test an Microsoft Excel document now to see how a file with a metadata structure Outlook would know effects our testing.

First here is the metadata on the file on the disk





Here is the extended mapi properties of the attachment when I sent the message a minute after creating the file.



As you can see the last modification time is being preserved again but the creation time is actually being set to the message creation time as seen in the delivery time below.


I then made sure it wasn't just a rounding issue by sending the same attachment the next day


which shows that the creation time is being sent to the date the message was sent and the modification time of the file is being preserved.


Saving the attachment back to the disk gives the following dates



As we can see the creation time is being set to when the message was sent and the modification time is being reapplied. The Access date appears to be updated but really that's just the real creation time before Microsoft Outlook rolled back the date.

More to come as we test other formats!