The last few blog posts I’ve made have been more informative or educational, but this is my cybercorner so I will post what I want.
I mentioned in my last post which was my guide to investigating 365 BEC that I was working on changing my process due to Microsoft expanding Audit Premium (or at least portions of it? I’m not certain) “sometime in September”, although AFAIK it currently hasn’t happened. I’ve had a slow month so far, so I figured I would prepare for the expanded logging so I wasn’t stuck in the middle of an incident with double the record volume that I usually have.
I’m going to cover how I did my testing, what I found, and my assorted thoughts and gripes.
How I Prepped
I have some form of admin to the 365 tenant for my job, so I asked my boss if I could use our tenant to do some testing to prepare for the expanded logging. He gave me the OK and I got started. We don’t have E5 licenses where I work, so I did some research to determine the easiest and cheapest way to get the extended auditing. After some research, I decided that the best way would be to use the E5 eDiscovery and Audit add-on license as it got me the feature for the least amount of money. Then I discovered that Microsoft would give me 25 trial licenses for 90 days, so I did that instead. I applied the licenses to a handful of accounts in the tenant that I assumed would have a large volume of emails.
But, before I applied the licenses I did some preliminary investigation. I generally do 90 days of records during my BEC investigations, unless I am certain that there is less access. So, I queued 90 days of UAL for several accounts, and also ran HAWK on those same accounts. When I pull UAL from GUI (the only good way, fight me) I do all activity because it’s painful to select individual records. Pre-expanded logging, my account for example had 60k records in 90 days. A bit more than the 50k export limit, so I’d already be annoyed trying to investigate it. A large amount of the records were SharePoint files, mind. HAWK also took a long time to run on my account and ran into some errors that I see when running it on accounts with lots of activity. After pulling data on some other accounts, I had some benchmark data that I would use to compare to the expanded logging.
What I Discovered
I waited a week before I reran the UAL export and HAWK on the same accounts, as well as some shared mailboxes. 90 day UAL for my account now showed 65k records. When I queried for just mailitemsaccessed, it game me 577 in a week. Not bad, but I also don’t tend to get a lot of emails. Others at the company with higher email usage had up to 2500 in a week. Ouch.
Using a calculator and rounding up to 600, this told me that in 90 days my account would have an extra 7500 records in it, just from mailitemsaccessed alone. Others would have many more, but I don’t think it would be double the amount like I feared. HAWK still took some time to run, but it also encountered more errors that I’m not certain the cause of.
Unfortunately I quickly discovered something that has disappointed me greatly. To me and many others, it seems like the mailitemsaccessed record would be a massive help for investigating BEC and understanding the scope of the incident. Finally I could tell with certainty what emails were accessed, which means I also have more certainty on what personal or sensitive data was accessed.
Yeah, turns out that’s incorrect.
Something Something Assumptions
After reading a few articles about this, I remember making a comment on LinkedIn saying how great this would be for SMB’s who couldn’t afford E5. I had gone into this assuming the record would be similar to Update, where you can see information such as the folder and email subject accessed. Turns out, the most you see about the email from the record is the internet message ID. Cool, so how can I turn that into a subject? Turns out, not easily.
The best way is via message trace, but those only have 90 days of records. So if a threat actor accessed emails from 2 years ago, I would have no visibility via message trace.
Once I realized this I started looking into Graph API. I haven’t used it much, but after some time (and help) I decided that the time it would take and skill required to do what I wanted was unreasonable for me. It was difficult enough to do it on my own account, in my own tenant. I have to be realistic about this, as much as it pains me to let this go.
I assumed that this record would be more useful for me and other SMB’s then it actually is. It seems like you need a SIEM to actually make use out of it, which is very disappointing. Why does Microsoft not have these records give the email subject? I don’t know, but posts online about this issue said it was likely an attempt at privacy. If it is, then it’s a stupid attempt when records like Update or basically any SharePoint records give you email subject or document names. I don’t expect Microsoft to “fix” this, as I don’t think it’s broken. This is just the way someone at Microsoft designed it.
Maybe someday someone will put out a tool that’s useful for matching these records to any email in an inbox. I’ve tried some current options and they either only work with the last ~10 days of message trace data, or they’re old and broken.
I think the only meaningful way that my investigation will change is that I will have to deal with more records, and I will need to find some method of matching Internet Message ID from the UAL to the 90 day message trace, which I’ll likely just do in Excel with some formatting and highlighting.
Etc.
I hate being bored but I also hate that whenever I’m bored there’s always a crisis close behind. I’m going to just have to wait for a massive incident and then adjust my process on the fly. If anyone has any suggestions then hit me up.
I don’t have a funny meme for this one, I’ve expanded most of my brain power on figuring out all the bullshit around car purchasing and ownership. Absolute hell.
Bye! :3