Episode 8 - Hidden digital forensic logging for Cybersecurity on Any Budget: Practical Strategies for Enhanced Detection and Prevention Using Sysmon, Blocking Data Exfil with group policy and printer forensics

In this episode, Clint Marsden goes straight into 4 practical strategies that enable better forensics and stop data exfiltration, no matter the size of your budget.

Clint covers deploying Sysmon for enhanced monitoring, and using Group Policy to tighten print and USB security. 

Event log cleared: Event ID 1102
ACSC Sysmon: https://github.com/AustralianCyberSecurityCentre/windows_event_logging
Swift on security Sysmon: https://github.com/SwiftOnSecurity/sysmon-config
Printer forensics: https://eventlogxp.com/blog/how-to-track-printer-usage-with-event-logs/

Transcript

Welcome to another episode of TLP, Traffic Light Protocol, the digital forensics podcast, where we talk about what it's really like day-to-day responding to incidents using forensic tools, threat hunting and staying on top of everything in the DFIR space. I'm your host Clint Marsden and today we're focusing on improving your detective and preventative capabilities for forensic analysis in security, with a special emphasis on empowering organizations of varying sizes and varying budgets. Jake Williams, the former SANS instructor and NSA employee, has released a talk on YouTube recently called Security for Have and Have Not Organizations.

And what Jake's referring to here is the disparities of cyber security resources between well-funded and less funded or underfunded organizations from a cyber security standpoint. And this is just reality. Sometimes there is no money in the budget or they say that there is no money in the budget for cyber security or to enhance your existing cyber security capabilities, as we know, until there is a breach and then money becomes available sometimes.

But we have been hired for our skills and we have a responsibility to just get it done with whatever we've got. So maybe there's money allocated in next year's budget, but for right now we've got to do what we can with what we've got. This isn't as bad as it sounds. 

So, you know, resources are tight. It's all about thinking about the blue sky mindset. So in an ideal world, what would we do? And one of the ways that we can get past the lack of cyber investment or that injection of funds is to work with other teams and to help us get the most out of what we have. 

And it might surprise you how much help you can get from other teams just by asking. But you need to think of this as a two-way street. If you're asking a team for assistance in configuring things or giving you server resources or something else, there might be a time where they come back and ask you. 

So this is a bit of a quid pro quo moment, right? Don't forget them when they've looked after you. Also, it's good to remember that you're in one organization. You might have heard the term one team, one dream. 

This is true. You're all working towards a common goal. We'll assume that the culture is good. 

And that is to, you know, the companies in business that is serving your customers. And this way is just another representation of how internally we still serve our customers, whether we're serving other teams or we're working towards a greater function of serving our public-facing customers. So let's kick off with a look at how organizations with varying budgets approach cybersecurity. 

I'm going to go for the low-hanging fruit first. And we probably don't need to talk about organizations that have plenty of cash to spend on tooling and training. You could assume that, well, they just have enough money to get all the latest tools. 

Everyone is trained on the best training courses available. And they technically shouldn't have any problems. They've got EDR. 

Everything's tuned. Just because there's money available, that doesn't mean everything is configured how it should be. I've seen plenty of organizations that don't have things switched on in the most effective way. 

And that's because priorities shift. And when those tools were initially implemented, they may not have been configured to best practice. I've spoken about before, some clients, when I was deploying Tenable, would only have a certain amount of money to purchase the tool, purchase the amount of licenses that they needed, and then they only had X dollars for deployment. 

What that meant is that the package that we were delivering had to be customized to that budget. So if they had a big budget and a large environment, I might be on site for five days, which means I have enough time to deploy the system itself. That might be vulnerability scanning. 

That might be packet monitoring. It might be a bit of log collection, building dashboards, tuning, setting up reports, configuring it to the absolute nth degree, the best way possible, so that the client would get the most amount of value. Yet other clients, well, we only have enough for a thousand licenses. 

And in some cases, it was really difficult. We can only afford one day of consulting. So it was get in there, get as much done as possible, roll it out. 

It doesn't feel great, but that's reality. So if we think about, hey, when your organization purchased this tool, were they in one of those situations? Were they in a situation where they had huge budget and it's configured perfectly and has been regularly checked, health checks are running, latest configurations as that operating system or as the software is updated, making sure that all those functions are turned on? Worked in an environment previously where they were getting absolutely smashed with ransomware and malware. They were complaining to us. 

One of my colleagues did a bit of a health check, figured out some new ransomware protection hadn't been switched on. They were on the latest version of the software, but that configuration hadn't been enabled. So it was as good as leaving the front door open when it's raining. 

I might have experienced that myself earlier in the year. Let's kick off with the top four. And these have no relation to the ASD top four, which was a dissemination of the ASD35 whittled down into the essential eight and then the top four, whittled down to the top four and then brought back to the essential eight. 

A bit of a tangent. Let's go. The first thing that you want to do, this is great for no or low budget in the cyber team, is increase the size of your event logs from 20 meg. 

So by default on Windows, this goes for endpoints. Believe it's servers as well. The default log size is 20 megabytes.

The three options that you've got when the 20 megabyte limit is hit is overwrite events as needed and the oldest events will be overwritten first. Then you've got archive the log when it's don't overwrite events and do not overwrite events, clear logs manually. So all you want to do is just increase that maximum log size to at least 20 meg and that should be done for absolute minimum, the security log, but you've got the original three, application, security and system. 

Modern versions of Windows, you've got something like over about a hundred individual logs that you can turn on and you can review. Not everything is enabled by default and we'll get to that coming up when we talk about printer logs. There is something that you will need to enable and we'll hit that next. 

What I do want to mention is, and it might be top of mind right now, well if my system gets compromised isn't the first thing that a threat actor does is delete the logs? Not always and I would probably say in most cases they don't for whatever reason. Not all threat actors are the same but it doesn't always occur. One way that you can know if it has occurred is in Windows there will be an event id of 1102 in the security log. 

When that event log is cleared this is excluding the method of access that the NSA were using as part of the Edward Snowden leaks. They were doing some fairly funky stuff with the Windows event log. Just in general if it's a basic log clearing all this does is it just flicks that over in Windows to be unallocated on the disk. 

So at a disk forensics level when something is marked as unallocated this is what happens when you delete a file. You might have heard people say when you delete something it's actually gone. Well that's true and that's why there were different standards from the DOD, the Department of Defense years and years ago and we'll get into this just for a second.

Basically I'll just wrap this up. When you delete a file it gets marked as unallocated and it sits on the drive. What can happen is that can be recovered if it hasn't been overwritten. 

So depending on how much activity is occurring on the system, now you might not use this computer much at all and the way that Windows works is when you are opening and closing files it's opening them and throwing them back randomly on the disk. This is what causes disk fragmentation and over time the file would be overwritten but early on when there's heaps of extra free space it's probably unlikely that it would be overwritten. So it's not a sure thing but it's just a bit of a backup plan and a bit of a second chance in case you experience event log clearing with event ID 1102.

Next up we've got print monitoring. So this is the log that isn't turned on by default it's actually print server operational monitoring and it turns out there's quite a bit there. So what you'll get when you enable this log and I'll get to how to turn it on in a second, you get all print jobs whether they're on the network or the printer is connected via USB and the best part is this is really easy to switch on. 

So all you need to do is go into your event logs as in open up eventviewer.msc from the run box, drill down into the application and applications and service logs, Microsoft, Windows, print service operational. So that's multiple levels of expanding those folders to get down to that operational log. Right click on that, hit properties, tick the box to enable it and it's on. 

Something worth noting is that the default log size is only one megabyte so you're going to want to increase that as well maybe start with 20 meg it's not going to hurt. In this log file what you will get on this system is the user who printed the job, the file name of what was printed, the printer it went to, so the device name and the number of pages that were printed and this also works for people printing to PDF so that might be something that we can pivot on in an IP theft investigation because the next point I have for you is how to disable USB writing using group policy. So this is a classic, this is how Snowden walked out with that classified material, he saved it to a USB. 

So whether it's a nation state threat actor or Jimbo in finance they all start with the easiest method of XFIL. So how do we disable people saving files to USB devices? I want to point out that with this change you can still use the keyboard and mouse, you can even read files from USB drives unless you turn that off as well but this just prevents users saving onto those USB drives so thumb drives or external hard drives. Read and execute still work as I said the policy does allow for switching this off too which is a nice option if you're concerned about people plugging in drives from home or elsewhere. 

There's a attack where people were leaving USB thumb drives in people's letter boxes or posting them so it looked all official. It's a common red teaming activity where people will leave USB thumb drives in car parks. If your staff are not undergoing training to let them know that plugging something in that they find even though they're trying to do the right thing, if they're not aware that that is risky behavior you might want to prevent them from burning themselves right. 

Sometimes we have to put in those safeguards to to help us all sometimes we just don't think. I used to call them a before coffee moment first thing in the morning get into the office you might be there early cogs are still turning and that's the moments where things like clicking on a phishing link can happen or oh there's a USB thumb drive here what's this plug it in until it's too late. Finally we've got deploy Sysmon and I've spoken about deploying Sysmon in the past and that was covered under that NIST podcast series on computer incident handling talking about detection. 

So Sysmon is a third-party tool provided by Microsoft originally made by Mark Rosinovich of Sysinternals. Sysinternals was then acquired by Microsoft donkeys years ago. The concept with Sysmon is that you have an answer file which is human readable it's in XML and you basically enable the types of event log data that you want to hear and you enable the types of event log data that you want to see in the logs. 

The default Sysmon config can be pretty noisy and there's a couple of people who have created customized Sysmon configuration files to kind of make things a little bit easier. One Swift on security so Swift on security is a person online who has extensive experience with windows and system administration and they have created this configuration file that's been commented that allows you to kind of plug in you just use that file and the way that it works is that you run the Sysmon.exe executable from command line you pass it a switch I think it's dash i and then the Sysmon.xml file name hit enter and it runs that's that's for the running it on one individual machine at a time. If you're doing this at scale you will probably want to deploy it using your package management tool or intune or whatever you're doing so again it's windows focused. 

The other person or organization I guess has created a Sysmon answer file is the ASD the Australian Signals Directorate and that is available from their github it might actually come from the ACSC the Australian Cyber Security Centre and same deal review that config file see what is in there see what you want to turn on what you want to leave out deploy that and that will give you a lot more telemetry and will assist you in doing incident response. These config files are well commented so just have a read through you will be making a trade-off on a few things what you can do now so if you enable everything that's great it's going to give you a lot of telemetry it will be brilliant for intrusion investigations it will be brilliant for determining what has occurred on a system maybe it's a intellectual property theft case whatever it is but keep in mind this is going to fill up the log more quickly this comes to maybe your maximum log size is not 20 megabytes might be one gigabyte for example these days storage is cheap so we all have crazy hard drive sizes I was in office supply store the other day you can now get 16 terabyte external drives years ago 16 terabyte external was you know not even considered and and now it's so cheap so I know internal drives are a lot smaller but the point is storage is a lot cheaper now and then just remember that the more that you have enabled the better it is for incident response however there can be a bit of a CPU hit with sysmon so this will be commented in those sysmon answer files you might need to do a little bit of testing and measuring to just make sure it's not going to affect the environment too much so these are some quick wins that you can achieve this week to further enable your forensic capabilities across these four areas windows event log storage retention the double banger of data rex fill being printer forensics and preventing intellectual property from going out the door on usb drives and deploying sysmon for the best post incident reports i want to thank you for your patience this week i know that this is being released on sunday i've been on a training course for the past six days but i hope these tips and this information has been helpful for you and as always take a look at the show notes for extra details and of course some links to get additional details on what i've talked about today i'm your host Clint Marsden wrapping up on tlp until next time bye for now

(Transcribed by TurboScribe.ai. Go Unlimited to remove this message.)