Thursday, June 21, 2018

Daily Blog #400 - Forensic challenge image for the Magnet User Summit

Hello Reader,
        If you watched last Friday's Forensic Lunch you would have heard that we are releasing the forensic image we used for the Magnet User Summit challenge so you can try it for yourself.


Here is the a dropbox link to the images:
https://www.dropbox.com/sh/85v4wsawyijxd9r/AAAa75lptg8oF0tpO2zPnXSna?dl=0

Download the images and we are going to work on getting the scoreboard open so you can see the questions and attempt to get a perfect score.


Wednesday, June 20, 2018

Daily Blog #399: Exploring Extended MAPI part 10

Hello Reader,
          In yesterdays post, i'm in the middle of a 37 hour journey to Sydney so its all a blur to me, we talked about the ClientInfo propert within the extended MAPI data. I was talking about how this property could be found in sent messages but didn't consider that MAPI data from a sender would be carried over to the receiver in terms of how the message was sent.

Well, I was wrong! It turns out in my testing that atleast messages sent within an exchange server retain the ClientInfo property of the sender on the messages received and stored by the recipients. I went though emails I received from my coworkers and when I did I found a range of ClientInfo strings two of which I'm going to talk about in the post.

The first is one of my coworkers emailing me from his phone:


As you can see not only did it provide the method of connection, in this case ActiveSync meaning it was sent from a phone, but also the email address associated with the ActiveSync connection.

In this example one of coworkers was using OWA and rather than try to make a screenshot of a long string I just copied it out of the property:

"Client=OWA;Mozilla/5.0(WindowsNT10.0;Win64;x64)AppleWebKit/537.36(KHTML,likeGecko)Chrome/66.0.3359.181Safari/537.36;"

Here I can tell it was sent via Webmail (OWA) the version of Windows (Windows 10) and what web browser (Chrome) and profile all the messages they've sent me. 

My first instinct was this must be some new X-mpailer entry and this data must be in the header. So I loaded up the header and did not find a X-mailer header entry or any entry that appears to store this data. I saw this but there are multiple base64 encoded entries in the headers now that I will start going through tomorrow, but on its face this ClientInfo property is not in the headers and it is being populated/provided within an Exchange server organization.

So how would I use this in a case? Let's say I'm trying to identify when an internal user stared sending emails from an attacker who lets just say was trying to get a wire transfer sent out. Well alot of the good attackers will delete their sent messages, so now you can get through all the messages the employees received and identify even faster which ones came from the attacker by isolating which Clients which employees were using and which the attacker was using.

As this series continues I'll be writing python code to automate this analysis and I'm looking forward to finding out what all we can mine out!





Tuesday, June 19, 2018

Daily Blog #398: Exploring Extended MAPI part 9

Hello Reader,
           As I write this I'm flying over Canada and on my way to Sydney via Dubai. Satellite inflight internet really is an amazing thing!

In this post I was going to talk about what was set on the message I forwarded and received yesterday but as I was looking at the extended MAPI fields in OutlookSpy I noticed that several had no description next to them but had dates:



This was interesting to say the least which sent me on some extensive Googling where I ran across yet another interesting piece of data. There is a MAPI property only set on sent messages that records the type of Client connection that existed when the message was sent.

This was the Client connection type for the message I forwarded to myself sitting in my sent box:

I found an exchange blog from 2016 about this field: https://gsexdev.blogspot.com/2016/02/mining-clientinfo-property-in-messages.html?view=classic

Now what is interesting to me is three fold:
1. The property tag has changed since 2016 from 0x866F to 0x84A6, which means some reading up on MSDN is order to figure out if there was a reason why
2. My ClientInfo property is showing I sent this using the ExchangeRPC connection from Outlook.
3. The blog post I referenced above showed not just Exchange or OWA but also useragent data from web browsers!

I think this is something we could profile sent messages in a mailbox from. Not only to see messages sent via mobile versus desktop, but also to profile and find all the messages an attacker forwarded or replied to when they were accessing someones mailbox.

I plan to do some testing on this property this week, but I'll need a bit more bandwidth than what this satellite wifi connection can do to do so. So until tomorrow, thanks for reading!


Daily Blog #397: Exploring Extended MAPI part 8

Hello Reader,
                   In this post I wanted to look at more actions and their effect on Extended MAPI. Today I'm looking at what a forward does to a message.

After forwarding the message you can see that within Outlook it is notifying me that the message was forwarded and when.



This data we know is stored in the PR_LAST_VERB_EXECUTED extended mapi flag and inspecting those values does confirm this



Notice that this time is being stored UTC within the extended mapi property but displayed to the user in local time.

The same is true for the other timestamp that has been updated which is PR_LAST_MODIFICATION_TIME



PR_LAST_MODIFICATION_TIME is also reflecting that it is stored in UTC and is being updated because the LAST_VERB_EXECUTED values have been set.

In my review of the message I forwarded those were the only two timestamps that were altered. Tomorrow let's look at the received message to see if anything was retained.

Sunday, June 17, 2018

Daily Blog #396: Sunday Funday 6/17/18

Hello Reader,
             We had a large number of great submissions last week and I hope we continue that trend this week! You will have a five days to try to complete this challenge now that answers are not due till Friday. Send in your answer as you have it and you are allowed to update your submission if you find new information.

Zone.Identifiers have come up on conversations recently both in my time teaching SANS FOR500 and in Phil Moore's recent tweets. Let's see what you know about them.


The Prize:
$100 Amazon Giftcard

The Rules:

  1. You must post your answer before Friday 6/22/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:
Zone.Identifier alternate data streams have been around for awhile please answer the following questions.
1. What version of Windows introduced zone.identifier
2. What data is contained with in a zone.identifier
3. What sets the zone.identifier
4. what conditions causes them to be created
5. What are the limitations of zone.identifier

Saturday, June 16, 2018

Daily Blog #395: Solution Saturday 6/16/18

Hello Reader,
         Well this weeks challenge had a lot of submissions! It was very tough picking a winner but as the rules state the most complete answer wins. When it comes to complete answers this week Kevin Pagano did the most testing of extended mapi attributes in his testing with screenshots and a follow up email to fill in even more.

What I liked about Kevin's answer that put him over the top is that he not only submitted PR_CLIENT_SUBMIT_TIME as most people did. He also went in and found other Extended MAPI entries that could be related even testing a deferred delivery mechanism I haven't even thought to test yet!

So well done Kevin Pagano you are this weeks winner.

Here was this weeks challenge:

The Challenge:
 Extended MAPI records metadata around what actions occur against an email message inside of Exchange and Outlook. What within an email message sent from Outlook and connected to an Exchange server would allow an examiner to determine when an email was sent from the system they are examining presuming they found the message in the sent folder within the mailbox. 

Here is Kevin Pagano's winning submission. 
 

In a test by sending an email to myself, the PR_LAST_MODIFICATION_TIME matched that of the PR_CREATION_TIME field. Since sending an email creates a brand new email entry in your mailbox, thus syncing the creation time of the email with when it was last modified before it being sent out. All of these times are in UTC.

In another test marking a Sent email to unread this did update the PR_LAST_MODIFICATION_TIME field to reflect when it was set to unread.


A third test for curiosity sake was done. While selecting to do a delay delivery of an email, we see that the PR_MESSAGE_DELIVERY_TIME is set to when the user hit send on the email, while the PR_CREATION_TIME is set to when the email was created in the Sent Folder (2 minutes later). You can also see the PR_DEFERRED_DELIVERY_TIME as well when the user set it to be sent.



This would seem to indicate that the PR_MESSAGE_DELIVER_TIME is when the user hit send in Outlook while the PR_CREATION_TIME would be your closest match to when the email was officially sent through Exchange creating the Sent email in the Inbox.


In doing more research, the PR_CLIENT_SUBMIT_TIME field seems to be a better indicator when the user submits an email to be sent. While the PR_MESSAGE_DELIVERY_TIME matched times when the emails were sent this could be different in other instances where the network connection is slower and has more hops to jump between Exchange servers.
 



Friday, June 15, 2018

Daily Blog #394: Forensic Lunch 6/15/18

Hello Reader,
            Today we had another episode of the Forensic Lunch! This week Matthew and I talked to Jaco_ZA about the Magnet User Summit CTF he won and we created. Watch below to see how Jaco approached the problems and ultimately clutched victory with seconds left!

If you are interested in playing our next CTF make sure to come to Defcon where we will be running another Unofficial DFIR CTF!