You might have heard about the ransomware attack on Arizona Beverage Company a few weeks ago. Since the attack, the company has needed several weeks of network remediation to recover. They have thrown hundreds of thousands of dollars to bring in experts to respond to the attack, based on recent reports. They made their decision about whether to pay the ransom (it is best to not pay, of course). Damage was assessed. Decisions were made for next steps. The network was vulnerable, which led to the attack, and unless the company wants to go through it all again very soon, network security improvements must be implemented to prevent future attacks. If investing in a more secure network seemed low priority before the attack, it is high priority now.

Incident Management: Scope, Containment, Remediation

This is the ‘After’ portion of the CyberAttack Continuum. In this final stage, the company assesses the Scope of the attack, Containment of the threat, and Remediation of the network.

Scope of the Malware Attack

Looking at all the attributes of the breach, it is important to understand the scope of the attack and assess the following:

1. How did the malware gain access to the system?
2. What was the method of the attack?
3. What can be done to improve the armor of the network and prevent similar attacks in the future?

In the case of Arizona Beverage Company, their ransomware infection was a particularly bad one. As it has been reported by several sources, the ransomware virus they caught is called iEncrypt, a particularly heinous ransomware virus with no known decryption tool. But how did the virus gain access to the system?

We only know what has been reported by Arizona Beverage Company, which is only the basic facts. But for the sake of argument, let’s conjecture a little and go through these three Scope steps:

How did the ransomware gain access? It is possible that the portal for infection of the iEncrypt was a previous Dridex malware infection. The FBI had just discovered Dridex on the Arizona Beverage Company network, just a few weeks prior to the ransomware attack. Might it have been lurking in the network for a few months, ready to play gatekeeper to the iEncrypt keymaster? Absolutely.

It is not yet known how iEncrypt is proliferated, but whether this particular cryptovirus distributes through a spoof/phishing email, or a fake software update tool found on a website, it is important to investigate it. In the case of Arizona, evidence suggests this incident was a targeted attack. This means that the method used was likely through a phishing email sent to employees, or the network had been prepped for the ransomware attack by a previously installed virus. The prospect that Dridex malware is related to the iEncrypt attack is a plausible theory. Dridex spreads via email attachment, so phishing is likely involved as a step for IEncrypt to gain access to the network.

Any information gathered that can help identify markers of iEncrypt, and how it proliferates, is information that can be used to detect it, obliterate it, and prevent malware like it in the future.

What was the method of attack? Once activated, the ransomware first hit one area of the network, and then spread to other areas. More than 200 computers and servers were ultimately affected. Learning how the ransomware was able to spread through the networks provides intelligence for correcting network architecture and permissions to make it more capable of containing infections in the future.

What can be done to protect against future threats? It seems that Arizona had a list of network security problems that made them vulnerable to attack, one problem being the old age of their computers and servers, running old operating systems. It is crucial to assess all network vulnerabilities, not just the one that turned out to be used for the cyber attack. If you plug only one of the leaking holes in the dam you are not doing much good. It is important to assess all the holes, and patch them all.

Containment of the Malware Threat

Malware can contain more than one payload, and the prevention of re-infection is a critical concern in aftermath procedures. If the particular brand of malware is a root kit embedded into the kernel level of the operating system, the malware will be more difficult to remove. The malware will be harder to identify, too. Also, a malware of this sort is more capable of re-infecting a network with a whole new level of data breach, should a computer be unwittingly rebooted by an un-informed employee before the bug is contained. Therefore, it is essential to communicate with employees and all potential network operators. This is the purpose of the Incident Response Plan referenced in the first part of this series, Defenses To Have Before The Attack Happens. The IT department needs to clearly explain what not to do in regards to the computer system while it is under investigation. This is also the time when the IT department must comb through all the browser-accessed executables and the kernel mode driver, to find the infection, isolate it, and extricate it.

Arizona’s network was completely down for about two weeks after their attack. How many millions were lost in sales and recovery efforts is anybody’s guess. But had they had up-to-date systems and servers, proper visibility of the network that had been tested for security, proper backups, and staff trained to respond, the iEncrypt incident might have never happened. Or at the very least, the breach would have been much less devastating.

To be forewarned is to be forearmed. To invest in proper cybersecurity is expensive, but to refuse to make the investment can put a business out of business.

Call Secure Networkers at (281) 651.2254 with your questions. We are experts in incident management – and incident prevention. Our job is to help you select a network defense solution that will keep your business healthy and at the peak of performance.