HUNTING FOR NETWORK SHARE RECON

This post was originally published here by Matthew Hosburgh.

There’s a strong chance you know what your organization is trying to protect. In many cases, this is probably in the form of data. It could be customer data, trade secrets, and forms of classified information. This data can be stored in many places: databases, email, and file shares to name a few. From advanced adversaries to ransomware, data is a target. The largest data breaches of 2017 were discovered after the fact—meaning, the data had already been lost. In this post, the goal is to go on a threat hunt for network share recon. In particular, the objective is to find early signs of abnormal network reconnaissance before catastrophe strikes.

What is a Network Share?

In the context of a corporate environment, data is generally hosted either internally or externally (thank you captain obvious). You might need to look at developing a method to detect recon against a cloud hosting provider’s system, but that is a topic for a later discussion. Again, knowing what you’re trying to protect can really shed light on where you should focus your effort as a hunter. This is important because as you start to quantify what actually constitutes a file share, the list could be lengthy. Does SFTP count? What about that old web server that has a ton of customer data in an HTML table? For the sake of this argument, we’ll only be looking at internally hosted data and in particular, a Windows network share.

File Share Types

If you’re a frequent reader of this blog, I’m not trying to insult your intelligence. I need to point out a few generalities about network shares before moving forward.

Most commonly, there are two types of file server share-grade protocols in use:

1. Network File System (NFS) – created by Sun Microsystems and usually synonymous with *nix systems, although Microsoft can interface with it.
2. Server Message Block (SMB) – originally designed to run on top of NetBIOS, it is synonymous with Windows file shares.

With SMB, it can be run in several ways. The most common occurrence with newer OS’ is:

In legacy environments or where NetBIOS is still leveraged, the network footprint is greater for SMB:

There are religions based around which protocol provides better performance, etc. That’s not the goal here.  The point is that if you know what you’re protecting (data), where it’s stored (Windows file share), you will have an idea of what to look for in terms of a network protocol (SMB).

Discovering Network Shares

As mentioned already, adversaries, insiders, and malware often look for network shares to gather or to deny access to the data. Before this can occur, there must be some sort of presence on the network or system. As there are a million and one ways this can occur, the assumption for this scenario will be that a “user” system was compromised and then used for subsequent network reconnaissance. An overview of the scenario can be found in figure 1.

Steps 2 are where the hunter can focus some effort. The goal is to identify and contain this behavior before stages 3 and 4 occur.

Network Data

In this scenario, one of the easiest ways to detect network share reconnaissance is via the network. That is, of course, if you have a way of observing east – west, or internal, network traffic and if you know what normal looks like. Examining traffic destined to the file server over TCP port 445 is worse than looking for a needle in a stack of needles. It’s like looking for a needle in a swimming pool filled with needles and then filled with Jell-O. If access is limited to the file server to a particular group of users or departments, denied access could be more interesting. Put another way if Mark from accounting was trying to connect to the file share and only marketing had access to the server, subsequent hunting or investigation could be warranted.  Or if anyone was trying to connect to a share on the CEO’s laptop, that most certainly would be interesting to investigate.

Auditing Requirements for the Host

This scenario takes into account that there is some form of central logging enabled to that can be used for hunting. Additionally, before certain log entries are created, certain auditing settings are required. If you need a great starting place, head over to Malware Archaeology’s Cheat Sheets. When talking about file shares, Audit File Share should be set to success and failure to produce very detailed events that can point to a source IP and user that has accessed the share. Figure 3 outlines the recommendation; however, it should be thoroughly tested before implementing. On Domain Controllers (DC), this event could be too noisy to be of value. Also, it is not advised to co-mingle your file server and DC.

According to MITRE’s ATT&CK Windows Technique Matrix, the Discovery phase, and specifically, Network Share Discovery focuses on examples of the net view commands (figure 4). Within Windows these can be used to remotely discover shares hosted by a file server

Also of concern, PowerShell (figure 5) can be used to enumerate shares both locally and remotely.

These commands could be common place in your environment, but maybe not. Looking into a combination of both the network and host data could lead to early detection of anomalous behavior.

Conclusion

Network share reconnaissance can be indicative of an attack to come. The earlier this can be detected the better chance defenders have to contain an adversary or malware looking for your organization’s data. File shares come in many shapes and sizes. It is very important to understand where the data is and what data is truly valuable to the organization and from and adversary’s perspective. As always, the environment needs to be prepped in order to accommodate overall security and to support threat hunting. Knowing what resources are at your disposal can help narrow the focus during a hunt.