Nuances in the Audit Logs

In a previous post I discussed the benefit of the Windows Filtering Platform audit logs and how the Windows Firewall logs were not as useful because they did not include the process information with the log entry. Things have been swamped at work, so I am just now getting around to enhancing some of the alerting that is generated from these WFP event logs. I was excited to dig into this information, my imagination going wild with the idea that nearly every workstation on my network could serve as a sensor.

Using SIEM rules based off of data collected from a large volume of endpoints is one of my favorite ways to test a theory or a set of rules with low risk of impact. My initial thought was to detect and alert on traffic anomalies based off of the username. IT person #1 might need to be using PowerShell between workstations, but Phone Operator 599 does not. If I could alert on this, I thought maybe I could get to the point of writing rules to further limit what applications were talking back and forth on the network. Easy enough, the data is in the logs. To the logs!

“You keep using that word. I do not think it means what you think it means.”
– Inigo Montoya, The Princess Bride

I quickly found out that even though there is a user field in the log entry, it was blank... on every log file I looked at. Not only was this a huge problem for my proposal for some really useful SIEM alerts, I actually had to go back to my previous post and edit it with a correction.

Strike 1. But wait, there's more...

Since I wasn't getting username information, it was time to move on to my next use case. I thought it would be really helpful to detect anomalous traffic between hosts. This would give visibility into traffic flows that I don't get from traditional sources like network boundary firewalls. I relished the idea of being able to use these logs to trigger on large volumes of addresses or ports scanned from a workstation. I even thought I could be sneaky and detect traffic leaving from a compromised host by collecting logs in unexpected ways and forwarding them off box before the attacker knew what I was doing and then using that in creative and innovative ways.

I went about programming SIEM rules to pick up on a handful of scanning scenarios. These rules would be fairly easy to test too... I started off with a quick PowerShell "Test-NetConnection" and saw the results in the SIEM. Success!

I wanted to prove this out on a larger scale, so I fired up some quick nmap scans that would meet my scenarios and then waited for the alerts to fly. And waited... and waited. They didn't happen. I was getting alerts for other things, but nothing for my scans. After reviewing my alert logic I went straight for the events. There were a few UDP packets, but that was it. I looked at my nmap results and there were thousands of packets being sent... why the disconnect?

I dug into the Windows security log on the test machine and saw the exact same thing as in the SIEM. A few UDP packets, but nothing else. Where were the thousands of TCP connections? I knew for sure that TCP packets were leaving my test machine and data was coming back to populate my nmap scan, but why weren't the WFP logs showing this? Were the logs not logging what I thought they were logging? Inconceivable!

I decided to dig into what exactly constituted a connection and find out. After a bit more testing and searching, I stumbled across this page and the following quotes:

"ALE is a set of Windows Filtering Platform (WFP) kernel-mode layers that are used for stateful filtering.
"Stateful filtering keeps track of the state of network connections and allows only packets that match a known connection state.
...
"Filters in the ALE layers authorize inbound and outbound connection creation, port assignments, socket operations such as listen(), raw socket creation, and promiscuous mode receiving.
"Traffic at the ALE layers is classified either per-connection or per-socket operation. At non-ALE layers, filters can only classify traffic on a per-packet basis.
"ALE layers are the only WFP layers where network traffic can be filtered based on the application identity—using a normalized file name—and based on the user identity—using a security descriptor.
...
"For this reason, policies that enforce who (for example, "administrator") and/or which application (for example, "Internet Explorer") are allowed to perform the network operations mentioned above are authored at the ALE layers.
"Traffic at the ALE layers is classified either per-connection or per-socket operation. At non-ALE layers, filters can only classify traffic on a per-packet basis."

After reading this things started to make a little more sense. When I executed nmap it was running as an administrator and it was configured to perform a TCP SYN scan. Since it was being run as an administrator, nmap could create raw sockets and was only sending a SYN packet and moving on without completing the handshake. Since the handshake was never completed, a stateful "connection" was never made. I believe WFP is auditing based off of the ALE layer information. If the TCP handshake isn't completed, a connection isn't made, if a connection isn't made, a WFP Audit Log isn't created, if a WFP Audit Logs isn't created, my super cool SIEM alerts never fire.

To further prove this, I re-ran the nmap scans with the "-sT" option, forcing it to use the OS stack and complete the handshake. My SIEM blew up with the alerts that I had configured. Things worked as expected.

I haven't yet found proof of this other than the events I have described. I have two theories for this:

1. Since a TCP connection isn't fully established, the ALE layer doesn't classify a SYN scan as a connection and doesn't log it, but UDP and ICMP show every packet (or at a minimum the first packet in every sourceIP/port and destinationIP/port combo) because they are not stateful.
2. The raw sockets somehow bypass the filtering drivers.

I am currently leaning towards the first theory.

I had a brief glimmer of hope that maybe the firewall logging that I disabled would provide different data and be more helpful - maybe it captured the Transport or Network layer data. But, it doesn't appear to be so. It was very similar to the auditing logs.

Somewhat deflated, I have had to temper my excitement for my network of sensors, at least for detecting outbound connection scenarios. When I tested Sysmon with the "-n" option, it appeared to have the same problem with with outbound detections of SYN scans. I haven't yet verified all of the scenarios around inbound SYN scans with WFP Audit logs. 

Well, at least there isn't an easy way to use TCP SYN to exfil data to hide it from my logs, like programs up to no good like this, or this, or standards that would allow anything to do it like this. :-( Looks like I have some testing to do to see if my network devices are picking up data in SYN packets. From a workstation perspective, it may be that the best option for this kind of data is in the massive data source known as ETW, but probably for other reasons.

I know that using logs from a machine that I am assuming is compromised is a weak and error-prone option, but I was hoping the element of surprise would work in my favor. It looks I am headed back to the drawing board, with this data set limited to applications that play nice with the OS, which is a lot, but know has an important caveat. One more reason to limit administrative accounts for end users and patch to prevent privilege escalation, just in case you needed one.

I hope to move on from Windows Firewall with Advanced Security on my next series of blog posts and focus on Windows Event Forwarding or a recent adventure... AppLocker!

Until then, work hard and spend time with your family.
Branden
@limpidweb

What It Isn't

It has been over a month since my last post - life has been very busy at work and at home! I still have 3 posts left on my Windows Firewall with Advanced Security to-do list, and a building list of posts about Windows Event Forwarding, or "How I learned to stop worrying and love endpoint logs". So, with that said, let's chip off another topic from my WFwAS list.

I have hinted at this a few times through several posts, but there are several things that Windows Firewall with Advanced Security doesn't do well. Let's face it - the technology is more or less 10 years old. Aside from the ability to tie traffic to a specific application (which is a big deal by the way, in case you haven't read my other posts) it is essentially a basic layer 4 firewall. There are some significant scenarios where WFwAS starts to show its age. It is still useful, applicable, and with the right tools to assist even manageable. But there are a few limitations that have to be worked around if it is going to be used successfully. Here are a few specifics, in no particular order, of things that it doesn't do well.

1. When writing rules there are often limitations encountered when needing to allow or block CDNs with huge swaths of IP space. The internet started using DNS oh, something like 1984 - a mere 32 years ago. Why? Because IP addresses don't scale!

<rant>
Yet this firewall, sitting there humming away happily next to the DNS resolver client behaves in a very anti social manner and instead of asking a few simple questions that the DNS resolver would be happy to answer it goes on its own and instead is based simply off of IP address ranges.
     <sarcasm>
     I'm not bitter - not at all.
     </sarcasm>
Don't even get me started on IPv6. Pity the poor being that has to use this to limit access to IP6 and the think of the massive amounts of electrons that would have to be inconvenienced to make it happen. Or not - because even though it can be used with IPv6, I doubt it is very much.
</rant>

Because of DNS, resource to IP addresses mapping can be umm, dynamic. They can change quickly, they can be load balanced, etc. Static lists of IPs don't always map to a resource I want to allow or deny and if it does now, it might not later, and then might all over again.

Network firewall vendors have heard this loud and clear from their customers and adapted to stay relevant, but WFwAS hasn't. Something like PowerShell can be used to create more dynamic lists that are then imported into the configuration (a topic for a future post), and the firewall itself seems to handle very large lists with ease, but this is bolting on a compensation and can be clunky.

Mitigating control: Use a web proxy or more advanced edge firewall to assist with this where it can.

2. Applications with dynamic names are difficult to manage. Applications have to be explicitly defined, there are no options for wildcards in the path. This makes it difficult to write rules for applications that might need to be allowed, like notorious collaboration "meeting go to" apps or "web ex perience" executables that are saved to temp folders with seemingly random executable names connecting to seemingly random IP addresses. Either a full firewall allow list has to be implemented, denying anything unknown (which can be a management headache); or a block list has to be configured and any unknown application has to be allowed.

Mitigating control: Use application controls (such as AppLocker or better, Device Guard or a 3rd party application control tool if you have it available) to limit what applications can be run on a system and use WFwAS to mitigate the most commonly allowed and abused apps.

3. Some applications seem to use addresses scattered all over the entirety of the IPv4 address space! For example, web browsers and HTML email clients connect to seemingly random IP addresses all day long. This is related to item #1. I wouldn't recommend limiting these applications with WFwAS in any but the most restrictive environments, and even then they are probably sufficiently covered by egress allow lists at the network edge.

Mitigating control: Allow any destination IP for apps that are required to interact with the internet as part of their primary functionality. WFwAS can be used to control the ports that these apps have access to, but I wouldn't recommend anything beyond that. Rely on other defenses to help you here.

4. What if there was this scenario where someone could use crazy archaic technology X [such as - oh I don't know - using something like PowerShell to instantiate a COM call to IE to masquerade as an application allowed to get to any IP to do my CnC] to skirt through your list of allowed applications and Endpoint Firewall all in one fell swoop? Ha! All your base are belong to us!

Mitigating control: Don't allow COM capable apps outside of your internal IP range. Like Internet Explorer. Seriously - use a different browser for web browsing. That said, I understand that a stunt like enforcing this policy would raise a few eyebrows at a corporate scrum or change control meeting. I am still investigating other ways to interrupt COM calls where they are not needed, but haven't found anything magical yet. If anyone has, I would love to hear it.

All these things said I still think that this is an effective control that I have been able to demonstrate in a lab and production environments stops malware and malicious activity that few other tools can. This control doesn't function as a "silver bullet" to solve almost all security needs. It solves one or two things very well, but must exist in an ecosystem of other tools to provide a layered approach of security.

I hope to discuss some of these mitigating controls much more in depth in a future post.

Until then, work hard and spend time with your family.
Branden
@limpidweb