Verizon Details Breaches: ICS Attack

Tuesday, September 11, 2018 @ 04:09 PM gHale

It was late in the evening when I got the call. “We’re going to need you to come into the office.” As the Security Operations Center (SOC) lead analyst in critical infrastructure protection (CIP), I was used to getting calls after hours. However, what was unusual was the next statement. “Law Enforcement (LE) called and they believe we may be compromised.”

“When I arrived, the office was in a frenzied state since it was not clear how (or even if) we’d been compromised. We assumed the worst and avoided communicating through typical corporate channels. This made information sharing with colleagues not physically present in the office difficult.”

RELATED STORIES
Suspect Discovered in British Airways Breach
British Airways Hit by Breach
ICSJWG: Solid Solutions ‘Not Rocket Science’
ICSJWG: ‘If it Isn’t Secure, it Isn’t Safe’

This is just one excerpt Verizon is sharing about different breaches its Threat Research Advisory Center team was called to investigate.

Last year, Verizon released a Data Breach Digest that gathered 16 cybercrime case studies. This year, the company released 18 case studies separately.

Each story is told from a different perspective, and from a different business sector. Each of them details the lessons learned and offers advice on detection, response, mitigation and prevention.

The Eclectic Slide incident describes an attack against an organization in the energy sector that started with a spear phishing email carrying a Microsoft Word document that downloaded a malicious payload and ended with the company identifying a number of improvements that can help them be more prepared for future attacks.

Case History
The case history went on to say, we were also informed any new information we found or received from the FBI was “TLP Red” and couldn’t be shared publicly.

The first indicator of compromise (IoC) we were given was an email address which LE believed was involved in a spear phishing attack against various organizations within the energy sector.

Sure enough, after searching through our email appliance we found the specific address had sent several emails. Each targeted an executive or lead engineer at our electrical plant.

The emails came with an attached Word “resume” for recipients to review. I reviewed the attachment in our malware analysis environment and saw nothing out of the ordinary – no web links, no macros, and no child processes being spawned. I called the VTRAC | Investigative Response Team to assist.

VTRAC investigators examined the suspicious attachments and presented their findings soon after. They found the threat actor was using a Microsoft Word template hosted on the Internet and communicating with a command and control server. This technique, later coined “Template Injection,” was a novel way of leveraging Microsoft Word to download a malicious payload.

Attack Details
When opened, the Word document “searched” for a specific, malicious template via the server message block (SMB) protocol hosted on the threat actor’s server. Once downloaded, the malicious template used macros to spawn a Microsoft PowerShell (command prompt) instance to steal user account credentials.

It turned out the targeted users had not corresponded with the threat actor. However, they all had very public profiles on a popular professional networking social media website. The threat actors likely used these profiles in selecting their targets.

Armed with this additional information, we immediately asked targeted users to change their account passwords. We then forensically collected the systems and volatile data associated with these users.

Some engineers had access to highly privileged operational technology (OT) systems within the plant. This was an issue as none of the SOC analysts had taken the North American Electric Reliability Corporation (NERC) CIP training required to access the plant systems.

With time of the essence, and no SOC analyst being able to access these systems, we created a PowerShell script to search for the IoCs that we then loaded on a USB device.

We identified a plant engineer with the appropriate level of system access, made a one-time exception and had him plug the USB device into the OT systems to run the script and scan for any IoCs.

Lessons Learned
While we found no additional IoCs, we identified several improvements to make regarding our incident response approach. During our after action review, we set out to accomplish the following actions as soon as possible:
1. First, we set up an alternate communication means separate from the corporate network. This provided the SOC analysts with “secure comms” should our corporate network be compromised.
2. Next, we educated our end users to be careful with the information they share online as threat actors can use this information to identify “high-priority” attack targets.
3. Then, we implemented firewall rules to block external SMB connections to unknown public addresses.
4. Last, but not least, we made it a requirement that all SOC analysts and cybersecurity incident responders take the required NERC CIP training and undergo additional background screening as an added security measure.

Mitigation and prevention
• Isolate OT networks; use dedicated OT systems; disable email and internet access, and access to networks at security-levels lower than the OT environment
• Implement firewall rules blocking SMB connections to unknown public internet spaces; add detections for Microsoft Office and other user applications spawning PowerShell child processes
• Sensitize employees to the security implications of posting sensitive information on social networking sites

Detection and response
• Establish a method for reliable, secure, alternative communications before a cybersecurity incident occurs; incorporate this into the Incident Response (IR) Plan
• Increase logging and alerting for configuration changes, to include user account creation and modification; enable enhanced logging for PowerShell script triggered actions
• Comply with industry training and certification requirements; familiarize SOC analysts and incident responders with the industrial control system (ICS) environment; train them to respond to ICS related cybersecurity incidents



Leave a Reply

You must be logged in to post a comment.