| This is the second post in an ongoing series that examines documented/public breaches with a special focus on Canary and Canarytoken deployment. The posts do not intend to imply that we would have been a silver bullet and prevented the breach; rather, our approach has been to help detect breaches. These posts are primarily intended to give our customers and users ideas for possible deployment options. |
In this 2nd blog post, we’ll look at:
- why attackers just can’t ignore a file share;
- touch on SMB enumeration;
- and how Canaries can be configured to detect techniques attackers use to discover, enumerate and access content on file shares.
Why do attackers like file shares?
A file share is pretty irresistible to an attacker. Not only are they easy to identify (by running scripts like Invoke-ShareFinder), but once identified, they act as an open door into your data. A share with read and write access configured? An attacker can’t ignore that; it’s just too tempting. Even a “limited” access file share can provide them with useful information that they can use for badness.
For example, when write access is granted on a file share, an attacker can inject ransomware or upload malicious files onto the share – potentially giving them further access into your network.
SMB itself has even been a target for attackers over the years (e.g., MS07-063, MS17-010), presenting yet another reason for attackers to probe file shares for potential exploitation
The alluring target presented by a file share is one of our Canaries sweet-spots – let’s look at how they can be used to easily detect these attacks.
So, what about Canaries?
With file shares being such an alluring target for attackers, being able to protect yourself should be a logical next step too. However, with so much legitimate SMB traffic on networks, most detection tools are quickly flooded with false positives/ noisy alerts. And so, being able to actually detect malicious behaviour takes effort.
That’s where we come in. Our Canaries, deployed as a Windows personality, with a well-named file share, have caught attackers all over the world. Giving you a high-fidelity signal that lets you know that there is badness on your network. (It helps that setting them up this way takes under 60 seconds).
Below we’ll expand on some of the techniques attackers use (as explained in the DFIR Report) and how Canaries detect and alert on them.
Discovery
According to The DFIR report, in 40% of intrusion cases, attackers made use of ShareFinder for file share discovery. (In the context of this post, discovery simply means identifying an accessible file share.)
Attacker Technique #1: File share Discovery
Attackers can discover file shares by scanning for open ports and by querying other data sources such as Active Directory via LDAP. ShareFinder uses LDAP to identify hosts (11) on the network and then performs discovery on the active hosts (4).
Sharefinder, as well as other tools like smbmap, also attempt to connect to hidden shares (admin$, C$, etc.) during discovery.
Canary Defense #1: Domain-joined Canary with file share and system shares enabled
If your Canary is setup with a “Windows Personality”, you are able to trivially join the Canary to your domain, and a single toggle will turn on Windows default hidden shares.
And.. of course, if an attacker executes ShareFinder you’ll receive an alert notifying you that someone is accessing the hidden ADMIN$ share.
Enumeration
Typically, once an attacker has discovered your file shares, they would then want to find out more about your network (enumeration). Through a single command (from netexec enumeration) – attackers can get some pretty useful information:
$ nxc smb 192.168.20.0/24
SMB 192.168.20.100 445 WIN-VUC9IK50LH2 [*] Windows 10.0 Build 20348 x64 (name:WIN-VUC9IK50LH2) (domain:WIN-VUC9IK50LH2) (signing:False) (SMBv1:False)
SMB 192.168.20.101 445 FS01 [*] Windows Server 2012 R2 Standard 9600 (name:FS01) (domain:) (signing:False) (SMBv1:True)
SMB 192.168.20.102 445 FS10 [*] Windows Server 2019 Standard 17763 (name:FS10) (domain:hacklab.local) (signing:False) (SMBv1:True)
SMB 192.168.20.104 445 DESKTOP-DAGBQ62 [*] Windows 10.0 Build 19041 x64 (name:DESKTOP-DAGBQ62) (domain:hacklab.local) (signing:False) (SMBv1:False)
SMB 192.168.20.106 445 BKPSERVER10 [*] Windows Server 2019 Standard 17763 (name:BKPSERVER10) (domain:) (signing:False) (SMBv1:True)
SMB 192.168.20.140 445 WIN-6U2O5JJU4MR [*] Windows 10.0 Build 20348 x64 (name:WIN-6U2O5JJU4MR) (domain:hacklab.local) (signing:True) (SMBv1:False)
From the output above, the attacker can observe:
- which hosts are, and which are not, domain joined;
- which hosts have SMB signing enabled/disabled
Attacker Technique #2: Enumerate endpoint domain membership
Attackers will further curate their findings by connecting directly to shares and searching for keywords or phrases for data or files they are interested in. Examples can include common files that may contain credentials (see Stored Credentials, configuration files, or interesting file extensions).
The attacker could then dive a little deeper by using smbmap:
$ smbmap -H 192.168.20.101 -r "IT/Incident Response"
[*] Detected 1 hosts serving SMB
[*] Established 1 SMB session(s)
[+] IP: 192.168.20.101:445 Name: 192.168.20.101 Status: Authenticated
Disk Permissions Comment
---- ----------- -------
IT READ ONLY Office Documents
./ITIncident Response
dr--r--r-- 0 Wed May 8 09:42:00 2024 .
dr--r--r-- 0 Fri Apr 26 06:13:52 2024 ..
fr--r--r-- 80371 Sun May 12 18:36:30 2024 incident-response-plan.docx
fr--r--r-- 65258 Wed May 15 16:13:50 2024 data-breach-notification-procedure.xlsx
fr--r--r-- 14101 Tue May 14 23:36:52 2024 forensic-investigation-checklist.pdf
Why does this matter?
A non-domain joined machine could be missing some updates, or perhaps have a weak or default vendor password, which could be brute-forced without raising suspicion. Sounds like a good spot for a Canary 🙂
Canary Defense #2: Canary with file share enabled
Your Thinkst Canaries can auto-generate industry-specific Windows file shares… with the click of a button! Finance, healthcare and automotive industries are examples of just some of the options. By allowing teams to quickly create believable file and folder structures, deployment is kept easy and simple. Simply pick an industry and we’ll create the entire share for you! Teams can also customize a generated structure they’ve created, by adding their own folders and uploading your own documents.
An attacker observing an endpoint that “had been forgotten” will investigate whether controls are more relaxed. Attackers don’t just ignore the passwords.txt file, they count on them. And once they copy (or open) it – you get an alert.
Attacker Technique #3: SMB Relay attacks
Attackers are able to relay legitimate connection attempts from you (their victim) to their target endpoints.
A well known technique used by attackers is to answer an incorrect name resolution attempt by acting as a legitimate server. When a user erroneously attempts to connect to “filessharee.company.local” the attacker responds, and redirects the initial connection to a target endpoint. Tools like Responder and Inveigh are well known for this, and go hand in hand with SMB relay attacks
In the first stage of this attack, the attacker needs to identify endpoints that are vulnerable to relay attacks. In other words, endpoints with SMB signing disabled. (Generally in computing, signing is used as an integrity checking mechanism and validates that data transfer has not been tampered with. Similarly, signing can be configured on network protocols, to ensure that data streams had not been tampered with and truthfully originates from the intended sender).
Summary of SMB-relay-attack Flow:
- Victim (192.168.20.101) attempts to access a network resource.
- Attacker (192.168.20.103) intercepts the authentication request using network poisoning.
- Attacker (192.168.20.103) relays the authentication request to the Target File Server (192.168.20.102).
- Target File Server (192.168.20.102) accepts the authentication and grants access.
- Attacker (192.168.20.103) gains unauthorized access to the Target File Server (192.168.20.102) using the victim’s credentials (the socks session).
Canary Defense #3: Canary with File share enabled
Below we’ll demonstrate how an attacker configures a relay and subsequently how the relay is used to authenticate to an endpoint (Your Canary) with SMB signing disabled.
The attacker identifies a file share that has SMB signing disabled (aka your Canary). Using ntlmrelayx, the Canary’s IP address and the “-socks” flag, the attacker is able to interact with the relayed connection via a socks proxy.
Once a connection from the victim machine is established, we can observe the active socks session within ntlmrelayx.
Leveraging the socks session above, the attacker is able to connect to the share using proxychains without knowing the user’s password.
Now the Canary is ready to alert when the attacker exfiltrates their loot. As soon as the attacker exfiltrates their loot, your Canary will alert.
Same defense? No way? Yes way…
The alert will provide you with:
- The attacker’s IP address (Source IP)
- The username that had been relayed to the Canary (SMB User)
- The victim machine (Remote SMB Name)
When an attacker connects to a file share, the source IP would correlate to the “Remote SMB Name”. In other words, if we were to perform a netbios lookup for “192.168.20.103” it would reveal the attackers hostname.
In this example, when the connection is relayed, the “Remote SMB Name” reveals the victim machine. This means that the share had been accessed via a proxy.
Conclusion:
File shares, and their underlying protocols, remain an attractive target for attackers. Instead of trying to build complex detections for specific attacks, you can deploy Thinkst Canaries that will sit silently on your network providing you with that 1, high-fidelity alert, when it matters.
Additional References:
https://warroom.rsmus.com/how-to-perform-ntlm-relay/
https://trustedsec.com/blog/a-comprehensive-guide-on-relaying-anno-2022