Recent news reports of widespread infiltration of IT systems and the possibility of exfiltration of data are very concerning, and always brings up the questions:
How did this happen?
What can be done to prevent this from happening to us?
How can we monitor our own systems to ensure they are not currently compromised?
In case you haven’t already seen a description, “Sunburst” is malicious code which attaches itself to legitimate libraries, installs itself as a service, then reaches out to command-and-control remote network infrastructure to prepare a second stage of attack: to move throughout the environment and compromise or exfiltrate data. Pretty nasty stuff, and we should all be concerned.
IT security is an ever-evolving space, as attackers evolve, our efforts to monitor the state of our IT systems and mitigate risk of intrusion must also evolve.
Our answers are the subject of this blog, in the form of best practices and practical steps. There are many ways GroundWork Monitor can assist with helping to monitor and manage such situations. Of course, we can’t set your security policies for you, so let’s focus on one of these key questions, how to monitor our own systems to ensure they aren’t currently compromised. We cover just one of the indicators for this purpose.
GroundWork Monitor can assist you in countering threats like this as well. We have methods for detection of the network Indicators of Compromise, allowing you to more quickly engage cybersecurity professionals to contain the malware. In general, we believe “you can’t manage what you don’t measure”, so we decided to describe one way to use GroundWork Monitor to detect and measure some signs your installed software is being actively exploited. The same methods can be applied to other exploits.
Detecting Network Indicators of Compromise
GroundWork Monitor provides the capability to capture and decode packets, and to monitor NetFlow and sFlow traffic on the network. From these sources you can then create “policies”, or actions for the system to take if there is traffic on the network matching a filter. Policy filters follow tcpdump syntax; anything that can be detected with a tcpdump expression can be turned into a policy. You can choose to have GroundWork Monitor send you an alert should traffic matching a policy filter come across the wire.
Malwarebytes™ has aggregated a list of possible IP addresses and domains used to host the command-and-control portions of this malware. We will add these to monitoring:
avsvmcloud[.]com – 13.59.205[.]66
deftsecurity[.]com – 54.193.127[.]66
freescanonline[.]com – 54.215.192[.]52
Thedoccloud[.]com – 34.203.203[.]23
Websitetheme[.]com – 139.99.115[.]204
Highdatabase[.]com – 5.252.177[.]25
Incomeupdate[.]com – 5.252.177[.]21
Databasegalore[.]com – 204.188.205[.]176
Panhardware[.]com – 51.89.125[.]18
Zupertech[.]com – 167.114.213[.]199
Of course, this list is meant as an example. It will evolve with the threat, but is current with the latest report of the malware as of this writing.
First, within the Network Discovery (NeDi) system in GroundWork Monitor, we’ll need to enable nfdumpd for NetFlow or sFlow monitoring, following the procedure outlined in the documentation GroundWork as a NetFlow Collector.
Once you are capturing data, you can set policies using any tcpdump based filters. One (of numerous) ways to detect traffic to specific IP addresses is called traffic bytes, where we can set a policy to get an alert should traffic exceed the thresholds we specify. This can be extremely useful not only in this instance, where we will give it a low setting, but also if we give it a higher setting which could be useful in to detect events where data is flowing, such as data exfiltration.
With that, let’s create our first policy. We can do this by:
Navigating within the GroundWork Monitor UI to Configuration > Network Discovery, then go to System > Policy.
Set your policy up to look like the example here, then click Add:
With this policy, we will trigger an alarm if traffic greater than 1 byte for the specified filter (ip x.x.x.x) is present in our captures.
Now, all we need to do is change the IP address in the filter to the next IP we want to add, and click Add again, and repeat the process until all IP addresses are added. The result will be a policy table below the policy configuration, and look something like this:
Then, if you want to be alerted on the events (of course you do!), enable the NeDi Cloud Hub connector in Configuration > Cloud Hub, described in the documentation referred to above.
While you’re in the Cloud Hub configuration, it may make sense to give your new services a name to identify their purpose. You can do this (once the connector is active) by clicking on the Modify button of the NeDi connector, click Load Policies, then Next. In the nedipolicy accordion you can give your new services a display name, here is how we’ve set ours up:
A good security policy is essential to the success of any organization, but you need to monitor it’s efficacy, as with any measure taken to prevent catastrophe.
At GroundWork, we of course monitor our own infrastructure. We also include best practices such as:
Scans of our code before it is available for an update (we do not perform automatic updates)
Scans of any dependencies we pull in to our builds
Manual verification of code pulls and commits
MD5 checksum verification of built packages, these are also provided for customers to verify they are downloading only versions released by us
As you can tell (and probably already know if you’re reading this), the security space is always evolving and there’s always some new vulnerability out there to tackle. If you are already familiar with how to monitor the general indicators of compromise (such as network traffic), you can be ahead of the game and respond much faster should the need arise.
Thanks for reading our Blog.
Monitoring Oracle Database
December 15, 2020
Monitoring Oracle Database with Linux GDMA
GroundWork Monitor makes it simple to monitor the health of Oracle databases, whether the need is simple monitoring of availability or for capacity planning purposes.
Oracle databases may be monitored either directly on the Oracle host or from a different host, using the GroundWork Distributed Monitoring Agent (GDMA). In both scenarios, SQL queries are used to provide the data from the database. This offers flexibility in that any Oracle query you create that returns a numerical result can be monitored as well as measured. As database monitoring needs vary on the organizational level – and even the database level, this flexibility is important.
Case Study: High-Availability SLAs with GroundWork
December 11, 2020
Amoeba Networks & GroundWork Monitor Enterprise
Amoeba Networks’ customers have on-premise and cloud infrastructure that cannot be allowed to go down under any circumstances. For this reason, the team at Amoeba holds themselves to an almost impossible standard of excellence. Through the use of strict, high-availability Service Level Agreements (SLA) they give “ their customers peace-of-mind that their systems will always be up and running. Their monitoring software is a critical piece of their operations because even a couple of minutes of downtime per year would break their SLA…
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.