SANS: ‘Unique’ Safety System Attack

Wednesday, March 21, 2018 @ 05:03 PM gHale

Dragos’ graphic on architecting a SIS defense.

By Gregory Hale
An attack against a Saudi Arabian gas facility that occurred in August last year was a deliberate targeting of a safety instrumented system (SIS) that could have caused physical damage, potential injury or loss of life.

Attackers against a Triconex safety system at that facility in Saudi Arabia had “a capability that implied an explicit knowledge of the Triconex SIS,” said Jimmy Wylie, adversary hunter at industrial security provider Dragos, during his presentation at the SANS ICS Security Summit and Training in Orlando, FL, Monday.

RELATED STORIES
SANS: ‘We Can Do This’
Feds Alert on Russian Cyber Activity Targeting ICS
Hacking Robots with Ease
ARC: Holistic Plan to Secure Safety

Wylie and Joe Slowik, also an adversary hunter at Dragos, gave an in-depth technical presentation on some the main aspects behind the attack.

The Trisis attack was a very unique attack against a specific system against a very specific victim, so the attack code was only good for this one incident.

“Trisis will never happen again, but the methods will,” Slowik said.

He then said to protect against this type of attack requires users to take a threat-focused approach.

As Wylie said, this was a deliberate targeting of a SIS.

The potential Trisis attack scenario was to establish access on the SIS connecting system, transfer the Trisis package to system, use the Trisis base EXE to upload Tristation program, then the Tristation program compromises the SIS, and then leverage access on the SIS to cause ICS disruption.

What comes into play is not all the code was perfect and the attackers either messed up and the system caught then and then shut down where the end users then discovered the attack or it was a test gone back.

“These attackers are like anyone else, man,” Wylie said. “They are just programmers that make mistakes like anyone else. Some of the programming is what would cause the workstation to crash. There was some shoddy programming. This would not cause the safety system to crash, but it could crash the workstation.”

Here is Dragos’ timeline for events following the Trisis discovery:

November 17
• Dragos finds Trisis and begins high-level analysis.

Late November
• Dragos confirms the malicious nature of Trisis with the understanding that it has been used at least at one victim site.
• Dragos coordinates with DoE and DHS to confirm there are not considerable sensitivities giving the focus of the malware and that notifications would not ruin ongoing investigations.
• FireEye learns that Dragos has copies of the malware; coordination is done through interested parties to ensure sensitivities are respected.

December 6
• Initial advisory is sent to Dragos’ ICS WorldView customers

December 8
• In-depth technical report was completed and sent to Dragos’ ICS WorldView customers

December 10
• Dragos prepares public report to have available for whenever the information is leaked to the public or in case someone else publishes; focus is on nuance and defense.

December 12
• FireEye publishes report on Triton (Trisis). Dragos follows up with its own publication.

Some of the open questions Slowik and Wylie are still investigating are if the rootkit bypassed the keyswitch setting once installed, what was the nature of the exploit since no CVE published, and what crashed the SIS?

The following is some guidance Wylie and Slowik mentioned:
• Uncertain if keyswitch can mitigate existing infection
• Network isolation may not be possible
• Proper function likely requires some connectivity
• Scanning introduced media will use standard antivirus, which is not effective against new, ICS-specific threats

Slowik talked about some of the things users could do to protect against an attack like Trisis, which included minimizing IT-ICS communications to known monitored paths, look for suspicious artifacts and develop knowledge from the data.



Leave a Reply

You must be logged in to post a comment.