Last month the FBI posted ALERT AC-000113-TT, which mentions an increase in unidentified cyber actors exploiting a known SharePoint vulnerability to gain access to unprotected networks. The CVE-2019-1491 vulnerability was found late last year and Microsoft posted an out-of-band patch soon after. The FBI soon raised the alert after it received reports that multiple municipalities here in the states had been compromised.
“An unpatched SharePoint server was utilized to gain access to a US municipality’s network, steal the Active Directory (AD) database, compromise administrative credentials, and drop webshells for remote/backdoor access to the compromised servers.” — via ZDNET
From what I understand, the threat actors can upload tools to the webshell. These tools range from legitimate applications such as cURL to post-exploitation tools such as Mimikatz. The threat actors also uploaded other tools to scan for and exploit potential network vulnerabilities like EternalBlue, which moves laterally to other systems on the network. Reports also show the actors are uploading custom backdoors. Basically, the threat actors breach the SharePoint servers as a starting point and then attempt to move laterally across the network via stolen credentials and exploited vulnerabilities.
Sadly, I’m only touching the surface with how this vulnerability operates. The good news is that my buddies over at Palo Alto Networks wrote a detailed study on how to exploit the SharePoint vulnerability and replicate this type of attack, the IOC involved, and methods of detection.
What is the solution?
The first step is to apply the out-of-band SharePoint patch from Microsoft. The next step is getting a better idea of what traffic on your network is related to SharePoint. In this situation, detecting and monitoring the lateral traffic is important before and after the fact.
So how do you do this? After you apply the patch, I would use metadata analysis to determine who was talking to your SharePoint servers and monitor their future activity. The ability to be alerted if a host outside of whitelist has come on the scene or baseline intelligence would be a big plus.
One of the interesting challenges when trying to troubleshoot remotely connected systems is figuring out what they’re saying to each other. In addition, one of the difficulties in troubleshooting is that a good portion of the traffic travels over SSL. In most cases, this leaves you blind to what is going on.
To get around that, you can use flow technology like deep packet inspection that injects Layer-7 information into your flow, or DNS elements that inject the Fully Qualified Domain Name (FQDN) into your metadata flow. The DPI technology has been around for a few years now and many flow vendors support it. Monitoring DNS traffic and adding the FQDNs to the flow is now starting to get a foothold. We are now seeing flow exports from companies like Gigamon and our own FlowPro Defender give you visibility at this level. Want to learn more about using DNS with your metadata? You’re in luck! Joanna Buckley, who is a brilliant co-worker of mine, wrote an interesting blog on the subject titled NetFlow Cloud Monitoring with Scrutinizer.
In today’s world, there isn’t a one-stop solution to network security. Being able to easily view and monitor conversations related to a security breach is an important tool for your SecOps kit. Are you looking for conversation-rich visibility along with the flexibility to integrate that data into your current environment? Why not evaluate Scrutinizer?
Related
What is network traffic intelligence?
With the onslaught of malware and cloud applications increasing, network traffic intelligence has become increasingly important. When an infection is unearthed and the incident
::
