SecuritySynapse: June 2019

Friday, June 21, 2019

Microsoft Bug? Shift + Delete does not generate 4660 Event

By Tony Lee

If you have ever searched for anything along the lines of: "How do I discover who deleted a file", you will probably find a dozen articles or more telling you to check for Windows Event ID 4660.

Some examples of excellent search results and resources can be found below (lmgtfy):

Then the article will most likely mention that Event ID 4660 lacks the object name (son of a biscuit!) and you will need to map the event using the handle ID to Event ID 4656 or Event ID 4663 (with an Accesses=DELETE). No problem, we've got this. But what do you do if 4660 is not always created? This can happen! (Dun... dun... duuuuunn.....)

Discovery

There are obviously multiple ways to delete a file such as the following:

Delete key
Right Click > Delete
"del" from a command prompt
Shift + Delete

Every single method above generates a 4660 (and 4663) except the last one, Shift + Delete, which happens to be my personal favorite way to to delete a file. :-( Delete it like you mean it...

Test Methodology

The discovery was frustrating and quite accidental. While deleting files, we noticed that no 4660 (or even 4663) logs were being created when we used Shift + Delete. In utter disbelief, we set up the following to prove our sanity:

Enable all necessary auditing (lots of articles on this)
Open Event Viewer > Windows Logs > Security > Filter Current Log > 4660 in the filter box
Create 4 text files in which you will delete using the methods above
Delete one file at a time and wait for Event Viewer to notify you of a new log
Notice that Shift + Delete DOES NOT GENERATE A 4660!

Figure 1: Test methodology shown above with Event Viewer, filters, notifications, and four files to delete

Conclusion

We all know that Windows logging is horrible, but this one takes the cake. It just seems scary that holding down shift while pressing delete will omit the log whose entry starts with: "An object was deleted." One possible work around is enabling the ever noisy Event ID 4656 and filtering that down--which still has its own pitfalls. Anyway, we hope this article helped debunk the myth that using Event ID 4660 for detecting file deletes is reliable (regardless of the name of the log entry).

Sample Logs

Some sample logs from our friend Randy Franklin Smith:

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4663#examples

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4660#examples

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4656#examples

Wednesday, June 19, 2019

Parsing and Displaying Windows Firewall data in Splunk

By Tony Lee

Have you ever wondered what it would be like to harness all of the Windows firewall data in your environment and crunch that activity using big data analytics? What you find might shock you.

Fortunately for us Splunk heads, Andreas Roth has already completed most of the work to send the logs to Splunk and even parse them. https://splunkbase.splunk.com/app/3300/#/details

Figure 1: TA to collect and parse the logs already exists!

Big shout out to Andreas for the jump start. However, we added some parsing to get the layer 4 transport protocol and then created a dashboard (shown below) that we are going to share here.

Figure 2: Dashboard provided in this article

Prerequisites

There are some things you will need to do before we can make use of the Windows Firewall logs:
1) Enable Windows Firewall Logging
Tip: Use the link in the Log Location section below to enable and configure the firewall via GPO

2) Forward the logs (written to disk) to Splunk via a Splunk UF, beats agent, etc.
Tip: This is made "easy" by installing the TA mentioned above on your forwarders

3) Parse the logs
Tip: This is made easy by installing the TA mentioned above on your indexers

4) Display the logs
Tip: This is made easy by using our dashboard code found at the end of this article

Log Location

The first thing we need to do is discover where those logs are located. After a bit of research, you will find that by default they should be located here:

%systemroot%\Windows\system32\LogFiles\Firewall\pfirewall.log

However, when I tried searching my machine for any sign of the logs, I discovered that they were turned off. In fact, Windows does not log these to disk by default.

Figure 1: Windows Firewall Logs off by default

To enable Windows Firewall logging, see the following article: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/configure-the-windows-firewall-log#to-configure-the-windows-firewall-log

Raw Log

What do these logs look like once they are written to disk? Well, they are short sweet and to the point. See the example log below:

2018-07-03 14:19:55 DROP UDP 192.168.2.1 224.0.0.252 50859 5355 56 - - - - - - - RECEIVE

There are a lot of fields there, but Microsoft kindly places a header in the log file to indicate the field names:

date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsym tcpack tcpwin icmptype icmpcode info path

As mentioned before, if you installed the TA-winfw on your search head and universal forwarders most of the parsing will be performed for you. Although, there was one field which did not seem to be parsed for us. No biggie, we don't have to do the real heavy lifting.

Parsing

Using our example event from earlier, the transport field did not seem to be parsed for us which typically indicates if the packet was UDP or TCP, etc.. Instead the protocol field just displayed "ip".

2018-07-03 14:19:55 DROP UDP 192.168.2.1 224.0.0.252 50859 5355 56 - - - - - - - RECEIVE

To correct this, we added the following regex generated from the Splunk field extractor for our sourcetype of winfw:

^(?:[^ \n]* ){3}(?P<transport>\w+)

Search String

After parsing out the "transport" field, we can now form our search string:

index=winfw | table _time, dvc, direction, action, transport, src_ip, src_port, dest_ip, dest_port

Taking this a step farther, we created a dashboard which is provided at the bottom of the article.