Latest Ransomware Techniques Show Need for Layered Security

I think everyone that touches security has had multiple conversations about the hardened edge and soft center, commonly found in networks. This usually accompanies some discussion around the overlapping concepts of difference in depth, layered security and security ecosystems. It seems like many of the recent exploits have used a C2 connection for instructions. In those cases, assuming a perfect NGFW product and configuration actually existed that caught 100% of the malicious traffic, it would have the capability to impact those attacks.

However on June 27, Cisco Talos published an article about a ransomware variant known as Nyetya. As of today, Talos has been able to find no evidence of the more common initial infection vehicles. Both Cisco and Microsoft have cited the upgrade process for a tax accounting package as the initial point of infection.

Per Cisco Talos:

The identification of the initial vector is still under investigation. We have observed no use of email or Office documents as a delivery mechanism for this malware. We believe that infections are associated with software update systems for a Ukrainian tax accounting package called MeDoc. Talos is investigating this currently.

So what does this mean to the majority of the world that doesn’t use MeDoc? Can they be affected too? And if so, how could defenders prevent the rampant distribution into their environments?

Expanding on these questions:

Does this mean the majority of the world that doesn’t use MeDoc cannot be impacted? Can they be affected too?

The short answer is that environments without MeDoc can absolutely be impacted. While this may have been initially introduced somewhere through a MeDoc update process, it spreads using SMBv1 by attacking a vulnerability that was patched in MS17-010. So if an un-patched system makes its way into hostile territory and is subsequently returned on to the network, that system can attack other un-patched systems on the network. The same is true for compromised systems that are brought on to the network.

How could defenders prevent the rampant distribution into their environments?

Astute readers will quickly conclude that there are many cases where the Internet edge firewall won’t even see any traffic in the above scenarios. This is an excellent example that illustrates the need for pervasive security. In addition to having a good NGFW for Internet Edge (which is just a basic requirement), there are many other components that are required to properly secure an internal network.

Some Thoughts (in no particular order)

  • Build a policy for acceptable use of network and technology equipment
  • Implement 802.1x Authentication for Wired and Wireless to control who is attaching to the network
  • Implement Machine Level Authentication for 802.1x
  • Proper Patch Management and Technology Lifecycle
  • Prevent unnecessary host to host communication (AAA-DACL, SGACL, etc)
  • Gain visibility into host to host communication using netflow
  • Compulsory VPN+Firewall for off-net devices
  • Internal segmentation between different security enclaves (Trustsec, VLANs, etc)
  • Controlled Isolation for un-patchable devices
  • Advanced Host-based Malware Protection
  • Have a disaster recovery plan for all critical data/systems
  • Consider the impact of encryption on the security controls
  • If the SMB ports are allowed through an Internet Edge Firewall and accessible to the world, I’m not sure why a Firewall was deployed in that role

Pervasive Security is Key

Some might look at Nyetya and conclude it is a one-off scenario. I would immediately counter that argument with–maybe, but the need for hardening the internal environment is certainly justified. I mentioned that a NGFW product that caught 100% of malicious traffic could impact many of the other recent ransomeware attacks. Unfortunately the Edge NGFW doesn’t see all traffic and there are other challenges. First, nothing is 100% effective and this is even more pronounced with very new exploitation techniques. When this protection fails, internal visibility and ability to react is the difference between event and catastrophe.

One more point I like to make is that security issues (with a few exceptions) are actually in the software on the hosts. It might be desirable to be able to look at the network as plumbing and properly push security back to the system owners. I even ask myself how network operators can be expected to determine what is good and bad for an application or service when the application developer couldn’t even do it. With that being said, the network is uniquely positioned to see things. So from a network operators standpoint, providing telemetry is value that must be leveraged. From a SecOps perspective, network derived data is a critical component to their day to day function of protecting their organization.

Internal propagation using SMB is not new. I recall working with worms using similar techniques in the early 2000’s. However, the worming techniques with Nyetya seem to be much more surgical and less noisy.

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Other. Bookmark the permalink.