Category Archives: Puzzling discussions

Discussions about IT security issues really puzzling me.

Triton: Dangerous and Puzzling – Part II

11 March 2017

Part II: Some thoughts on the access vector

For preparation of the attack the attacker had to gain in-depth knowledge about the victim’s network and SIS installation.

SIS installation

According to Schneider Electric such attack could only be successful for Triconex Tricon controllers configured with the model 3008 Main Processor and firmware versions 10.0 to 10.4.(1) Only this controller family seems to use PowerPC processors. Older Tricon controllers use National Semiconductor, newer systems use ARM processors.(2)

Since the binary malware components inject.bin and imain.bin were compiled in PowerPC byte code the attacker hat detailed knowledge about the installation, in particular the controller version. Without this knowledge about the controller version the attack would have failed because of a code mismatch.

Network

If the SIS controller and engineering station are operated in an isolated SIS network this attack is not possible. For remote control, the Remote Access Trojan (RAT) needs to open at least an outgoing connection to its Command and Control server (C&C) outside the production network.

Blocking incoming traffic to SIS network but allowing outgoing traffic from the SIS network to applications, e.g. a historian, in other production network partitions is industry standard (ISA-99). Unfortunately, the latter recommendation is often misunderstood. Instead of opening only connections to dedicated systems / ports in adjacent partitions the security devices are often opened for all outgoing network traffic, sometimes across partitions.

With this, once the RAT is installed on the engineering station a weak implemented industry standard fosters the connection with the attacker’s C&C server.

Attack vector: Compromised Supply Chain

At first sight this sounds like a bad thriller. But it gives some good answers to some important questions.

How did the attacker get the knowledge of the victim’s facilities?

  1. In-depth knowledge of the plant network and the SIS installation can be extracted from documentation stored on the plant operators computer systems or on the Engineering Service Providers (ESP) computer systems.
  2. An ESP network is in general less well protected against cyber-attacks than a highly secured production network.

Conclusion: It is very likely that the attacker compromised the ESP network and the systems used for developing the SIS software.

How could the attacker develop such mature code?

Once the attacker hijacked the ESP network he was able to develop and test his attack framework on a system very similar to the production SIS.

How was the SIS network / engineering station infected?

With the next project update the ESP transferred the compromised code, e.g. by USB stick, to the production network.

Have a great week.


  1. Hand A. Triton Gone Wild | Automation World [Internet]. Automation World. 2018 [cited 2018 Mar 3]. Available from: https://www.automationworld.com/triton-gone-wild
  2. Analyzing the TRITON industrial malware [Internet]. Midnight Blue Labs. 2018 [cited 2018 Mar 5]. Available from: https://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware
Advertisements

Triton: Dangerous and Puzzling – Part I

4 March 2018

Jim Finkle’s report ‘Hackers halt plant operations in watershed cyber attack’ (1) published on December 14th, 2017 on Reuters made me curious and nervous at the same time.

The report deals with a cyber-attack on Safety Instrumented Systems (SIS). SIS work independently of the Process Control Systems (PCS). They guarantee that the industrial process, e.g. a reactor or a cracker, can be safely shutdown if the PCS can no longer control the process. Since compromising an SIS may cause significant negative effects on people and environment, the most important task in Production IT Security is to prevent cyber-attacks on SIS.

Although the attack was intensively discussed in the media and by security researchers many questions are still open. With this three-part blog series I like to examine some details more closely. A detailed attack analysis gives IT security strategists the chance to derive improved means for protection of SIS.

Part I: Some facts about the Triton attack

Malware naming

FireEye named the malware TRITON (2). Triton is an attack framework created to interact with Schneider Electric Triconex Safety Instrumented Systems. Other sources name the malware TRISIS (3) or HATMAN (4).

Indicators of Compromise

“In the incident, hackers used sophisticated malware to take remote control of a workstation running a Schneider Electric Triconex safety shutdown system, then sought to reprogram controllers used to identify safety issues. Some controllers entered a fail safe mode, which caused related processes to shut down and caused the plant to identify the attack, FireEye said.” (1)

From the FireEye report, we learn: “The attacker gained remote access to an SIS engineering station and deployed the TRITON attack framework to reprogram the SIS controllers. During the incident, some SIS controllers entered a failed safe state, which automatically shutdown the industrial process and prompted the asset owner to initiate an investigation. The investigation found that the SIS controllers initiated a safe shutdown when application code between redundant processing units failed a validation check — resulting in an MP diagnostic failure message.” (2)

With this, the IoC was: A production process was shutdown by the SIS although no indicators for a failure condition were signaled by the PCS.

Preconditions for a successful attack

At least the SIS Engineering Station must be accessible from the network. The FireEye (2) and Dragos (3) report confirmed that this was the case.

The Triconex memory protection key switch must be left in Program mode long enough to allow the attacker to run the attack. The FireEye (2) report confirmed that this was the case:

“The attacker could have caused a process shutdown by issuing a halt command or intentionally uploading flawed code to the SIS controller to cause it to fail. Instead, the attacker made several attempts over a period of time to develop and deliver functioning control logic for the SIS controllers in this target environment. While these attempts appear to have failed due one of the attack scripts’ conditional checks, the attacker persisted with their efforts.”

The code is publicly available from GitHub. (5)

Threat Actor

From the FireEye (2) and Dragos (3) analysis it is clear, that this was a sophisticated attack. In-depth knowledge of Schneider Electric Triconex SIS and network intrusion technology is required to perform such kind of attack and stay undetected for a while. This indicates a state-sponsored threat actor.

What does this really mean?

Production Network Reference Architecture

Production Network Reference Architecture

The cyber attacker worked his way through the business DMZ, the business network, the production DMZ and the production partition 1 to the SIS engineering station in zone 2 of production partition 2, without being noticed by any security device, SIEM or endpoint protection. That is truly amazing.

It seems like some basic protective measures were either not fully in place or misconfigured or no one checked the logs regarding IoC and IoA.

 

From my point of view this sounds very unlikely and mysterious. I will present some alternative access scenarios in part II.

Have a good weekend.


  1. Finkle J. Hackers halt plant operations in watershed cyber attack. Reuters [Internet]. 2018 Dec 14 [cited 2018 Feb 4]; Available from: https://www.reuters.com/article/us-cyber-infrastructure-attack/hackers-shut-down-infrastructure-safety-system-in-attack-fireeye-idUSKBN1E8271

  2. Caban D, Krotofil M, Scali D, Brubacker N, Glyer C, Johnson B. Attackers Deploy New ICS Attack Framework “TRITON” and Cause Operational Disruption to Critical Infrastructure [Internet]. FireEye Threat Research Blog. 2017 [cited 2018 Feb 12]. Available from: https://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html

  3. TRISIS-01.pdf [Internet]. [cited 2018 Mar 3]. Available from: https://dragos.com/blog/trisis/TRISIS-01.pdf

  4. MAR-17-352-01 HatMan—Safety System Targeted Malware_S508C.pdf [Internet]. [cited 2018 Mar 3]. Available from: https://ics-cert.us-cert.gov/sites/default/files/documents/MAR-17-352-01%20HatMan%E2%80%94Safety%20System%20Targeted%20Malware_S508C.pdf

  5. ICSrepo. TRISIS-TRITON-HATMAN: Repository containting original and decompiled files of TRISIS/TRITON/HATMAN malware [Internet]. 2018 [cited 2018 Feb 5]. Available from: https://github.com/ICSrepo/TRISIS-TRITON-HATMAN

Dutch banks hit by massive DDoS attacks – Blaming is difficult in the case of cyber-attacks

24 February 2018

Huib Modderkolk’s report ‘Dutch agencies provide crucial intel about Russia’s interference in US-elections’ [1] dated 25 February 2018 is one of the best spy stories I ever read. Hackers from the Dutch intelligence service AVID spied on the Russian hacker group Cozy Bear for some years. They watched them hacking the Democratic Party and manipulating the U.S. elections in 2016. [2]

Some days later Dutch banks and the Dutch Tax Agency [3] were hit by massive DDoS attacks with a peak volume of 40 Gbps. The alleged nation-state threat actor responsible behind these attacks was rapidly found because the timing of the attacks was just too coincidental. In addition, it is widely assumed that only nation-state actors have the resources to run attacks of this size. Janene Pieters reported on 29 January 2018 that according to ESET the attacks came from servers in Russia. [4]

But blaming is difficult in the case of cyber-attacks.

On 6 February 2017 Janene Pieters reported that an 18-year-old man from Oosterhout was arrested in connection with the DDoS attacks. [5] Tijs Hofmans report [6] in ComputerWeekly.com reveals some remarkable background details:

“In messages to the Tweakers systems administrator, Jelle S claimed to have bought a ready-made “stresser” DDoS package on the dark web for which he had paid €50 a week to send 50-100Gb/s of data to victims.”

Crazy world! A script kiddie misused a professional tool for running stress tests against web sites to do the DDoS attacks. And for a very reasonable price.

Blaming becomes a big issue when it comes to DDoS on critical infrastructures. According to the new U.S. nuclear strategy [7] such kind of attack on the U.S. homeland could, in the worst case, result in a counter strike with nuclear weapons.

Have a great weekend.


    1.  Modderkolk H. Dutch agencies provide crucial intel about Russia’s interference in US-elections – Tech – Voor nieuws, achtergronden en columns [Internet]. De Volkskrant. 2018 [cited 2018 Jan 30]. Available from: https://www.volkskrant.nl/tech/dutch-agencies-provide-crucial-intel-about-russia-s-interference-in-us-elections~a4561913/
    2.  Cluley G. How Dutch intelligence spied on the Russian hackers attacking the DNC [Internet]. Graham Cluley. 2018 [cited 2018 Jan 30]. Available from: https://www.grahamcluley.com/dutch-intelligence-spied-russia-hackers-attacking-dnc/
    3. Cimpanu C. Dutch Banks, Tax Agency Under DDoS Attacks a Week After Big Russian Hack Reveal [Internet]. BleepingComputer. 2018 [cited 2018 Feb 24]. Available from: https://www.bleepingcomputer.com/news/security/dutch-banks-tax-agency-under-ddos-attacks-a-week-after-big-russian-hack-reveal/
    4. Pieters J. Russian servers linked to DDoS attack on Netherlands financial network: Report [Internet]. NL Times. 2018 [cited 2018 Feb 24]. Available from: https://nltimes.nl/2018/01/29/russian-servers-linked-ddos-attack-netherlands-financial-network-report
    5. Pieters J. Suspect arrested for cyber attacks on Dutch tax service; Bunq [Internet]. NL Times. 2018 [cited 2018 Feb 24]. Available from: https://nltimes.nl/2018/02/06/suspect-arrested-cyber-attacks-dutch-tax-service-bunq
    6. Hofmans T. Teenager suspected of crippling Dutch banks with DDoS attacks [Internet]. ComputerWeekly.com. 2018 [cited 2018 Feb 24]. Available from: http://www.computerweekly.com/news/252434665/Teenager-suspected-of-crippling-Dutch-banks-with-DDoS-attacks
    7. Sanger DE, Broad WJ. Pentagon Suggests Countering Devastating Cyberattacks With Nuclear Arms. The New York Times [Internet]. 2018 Jan 16 [cited 2018 Jan 30]; Available from: https://www.nytimes.com/2018/01/16/us/politics/pentagon-nuclear-review-cyberattack-trump.html

Critical vulnerability in Skype updater – Don’t panic!

17 February 2018

Media reported on a new vulnerability in the Skype updater service this week. Due to ZDNET (1), Security researcher Stefan Kanthak found that the Skype update installer could be exploited with a DLL hijacking technique.

Kanthak describes in his post (2) on SECLIST.org how the attack works:

“An unprivileged (local) user who is able to place UXTheme.dll or any of the other DLLs loaded by the vulnerable executable in %SystemRoot%\Temp\ gains escalation of privilege to the SYSTEM account.”

Escalation of privilege to the SYSTEM account sounds dangerous. Why should Microsoft not care on this vulnerability?

From my point of view, Microsoft does not care, because this vulnerability is easy to mitigate. Let us look at the access vectors.

Access Vector: Local

An unprivileged local user is not able to place something in %SystemRoot%\Temp. I checked this on Windows 7 Enterprise Edition and Windows 10 Pro. In either case I got the error message “You don’t currently have permissions to access this folder.”

"Permissions denied" message

“Permissions denied” message

And in either case User Account Control prompts for the password of an administrator’s account to change the settings.

With this, the local version works only if the user works permanently with administrative privileges.

Access Vector: Network

ZDNET (1) reports that the vulnerability is remotely exploitable:

“The attack reads on the clunky side, but Kanthak told ZDNet in an email that the attack could be easily weaponized. He explained, providing two command line examples, how a script or malware could remotely transfer a malicious DLL into that temporary folder.”

That sounds strange. From the discussion above we know that under normal conditions access to %SystemRoot%\Temp\ is limited to members of the administrators group. To access this folder remotely an attacker needs access to e.g. the \\systemname\c$ share. For this, either a local administrative account or a network account which is member of the local administrators group is required. In either case this mean that your network is already compromised.

Conclusion: In a Windows network with basic standard of cyber hygiene the likelihood is low that this vulnerability is easy exploitable.  

But the most important reason for Microsoft not caring of this is that an updated version of Skype exists where the bug is fixed. (3)

To say it with Shakespeare: Much ado about Nothing.

Have a good weekend.


1. Whittaker Z. Skype can’t fix a nasty security bug without a massive code rewrite [Internet]. ZDNet. 2018 [cited 2018 Feb 17]. Available from: http://www.zdnet.com/article/skype-cannot-fix-security-bug-without-a-massive-code-rewrite/

2. Kanthak S. Full Disclosure: Defense in depth — the Microsoft way (part 51): Skype’s home-grown updater allows escalation of privilege to SYSTEM [Internet]. 2018 [cited 2018 Feb 17]. Available from: http://seclists.org/fulldisclosure/2018/Feb/33

3. Kilbourne E. Update on Skype for Windows desktop installer – version 7.40 and lower [Internet]. Microsoft Skype Forum. 2018 [cited 2018 Feb 17]. Available from: https://answers.microsoft.com/en-us/skype/forum/skype_newsms/update-on-installer-for-skype-for-windows-desktop/242f1415-1399-42e1-a6a2-cd535c8b7ff8?tm=1518635969608&auth=1

How to defeat antivirus evasion and privilege escalation techniques

4 February 2018

Last weekend I read two very informative posts on Antivirus Evasion by Mattia Campagnano. But part 2 [1] puzzled me somewhat.

“Following up to my previous post Tips for an Information Security Analyst/Pentester career – Ep. 43: AV Evasion (pt. 1), we’re going now to perform the same attack on a genuine Windows 10 machine, where all latest updates have been installed.”

For a moment I thought ‘a security professional mistakes compliance for security’ because ‘fully patched’ means not that the system is resilient against cyber-attacks. But both posts show that even the most secure Windows ever is vulnerable against privilege escalation and AV evasion if the basic configuration is not changed and fundamental elements of cyber hygiene are missing.

Why are such attacks successful?

First, the user was logged in with permanent administrative privileges. This makes life easy for attackers and fosters lateral movement.

Revoking permanent administrative privileges on workstations and servers must be a basic element of any cyber security program. Under normal conditions, standard users should not have any administrative privileges for their devices at all. If needed, they can be temporarily granted through User Account Control (UAC).

Second, UAC was not set to the highest level “Always notify me”. Unfortunately this is the standard setting after a fresh installation of Windows. With this, privilege escalation is possible without user notification. If configured properly, UAC will notify the user even if he works with administrative privileges.

The BypassUAC method in the meterpreter attack framework will fail, if UAC is set to the highest level. The following excerpt of the code [2] makes this clear

case get_uac_level
 when UAC_PROMPT_CREDS_IF_SECURE_DESKTOP,
      UAC_PROMPT_CONSENT_IF_SECURE_DESKTOP,
      UAC_PROMPT_CREDS, UAC_PROMPT_CONSENT
 fail_with(Failure::NotVulnerable,
  "UAC is set to 'Always Notify'. This module does not bypass this setting, exiting..."
 )
 when UAC_DEFAULT
    print_good('UAC is set to Default')
    print_good('BypassUAC can bypass this setting, continuing...')
 when UAC_NO_PROMPT
    print_warning('UAC set to DoNotPrompt - using ShellExecute "runas" method instead')
    shell_execute_exe
  return
end

Standards like the DISA STIG for Windows 10 [3] activate all UAC features to make life for the attackers as difficult as possible. From my point of view, the STIGs should be considered also in industry to create workplaces resilient against cyber-attacks. And Microsoft should raise the Windows default for UAC to “Always notify me” for all versions. If a user wants to reduce the security level, he should do this on his own responsibility.

Besides the secure configuration of IT systems and cyber hygiene is user awareness training the third essential pillar of a security program. Users and help desk staff must take proper actions if their system unexpectedly enters the secure desktop and asks for permissions of an action they never asked.

Have a good weekend.


  1. Campagnano, M. Tips for an Information Security Analyst/Pentester career – Ep. 44: AV Evasion (pt 2). The S@vvy_Geek Tips Tech Blog
  2. Rapid7 bypassuac_vbs.rb  Metasploit Framework. (Accessed: 3rd February 2018)
  3. Windows 10 Security Technical Implementation Guide. STIG Viewer | Unified Compliance Framework® Available at: https://www.stigviewer.com/stig/windows_10/. (Accessed: 3rd February 2018)
  4. Campagnano, M. Tips for an Information Security Analyst/Pentester career – Ep. 43: AV Evasion (pt.1). The S@vvy_Geek Tips Tech Blog

Concerns about using open source libraries from an IT security point of view

18 December 2017

Some days ago I participated in a discussion about the necessity of using open source libraries in industrial software development and the data scientist workbench. IT security is often perceived as spoil sport in such discussions …

To be honest, I like open software. I prefer for example Firefox on Windows 10 because the configuration of Edge is really annoying. However, when it comes to the use of open software libraries in scientific or industrial software development projects or by data scientists I have two major concerns:

1. I have just no clue what the open software libraries do in addition to their intended use.

This sounds a bit paranoid. The question is:

Can we make sure, that no malicious code snippets are hidden in an open software library which send the company’s secrets to a cyber criminal’s command and control server, or which encrypt all data?

In my opinion this is not possible. Reviewing e.g. the 300 thousand lines of code of the OpenSSL-1.0.2 project is a herculean task, which has to be repeated for every patch and release. We can automate the software review process with advanced code analyzers. With such analyzers, we can make sure that open source code has no or few critical errors. But analyzers cannot find malicious code snippets, they just make sure that such snippets cause no critical errors during program execution.

Advanced Persistent Threat (APT) solutions may detect malicious behavior. But when a developer or data scientist includes open software into his code, the threat type changes from external to insider threat, thus APT solutions are no longer effective.

Eventually, we have to trust the developers of open software. Thus, the use of open software depends largely on the risk appetite of an organization.

2. I have no idea how to fix vulnerabilities in software which uses open software libraries.

Firefox gets security patches immediately after vulnerabilities are published. For example, the remote code execution vulnerability CVE-2017-7827, published 11/15/2017, was patched on the morning of 11/17/2017. When I logged in to my Linux box in the evening, even a patch for the Firefox ESR version was installed.

The OpenSSL-1.0.2 library mentioned above can be used potentially in many applications, in the worst case, some of them may be connected directly to the internet. The developers of Firefox take care of security bugs in this library. Who cares in the case of self-developed software? And how fast? Just remember the Equifax data breach some months ago. The reason for this really costly data breach was an unpatched vulnerability in the Apache Struts framework …

The focus of open software developers is innovation. Thus, the use of open software will be a major driver in the digital transformation, and we should foster this use to stay at the cutting edge of digital transformation.

Nevertheless, we must be aware of the risks of this use and take proper precautions for their mitigation.

Have a great week.

Puzzling: Five years old critical vulnerabilities exploited in November 2017

26 November 2017

Section Exploited Vulnerabilities of the Recorded Future Cyber Daily is sometimes really frightening. On November 9th, 2017, 249 successful exploits of CVE-2012-1823, a vulnerability in PHP, were recorded. This is hard to believe because CVE-2012-1823 was published on May 11th, 2012. Although a patch was available at the date of publication, it seems that the operators of this systems were not able to implement them within the past five years.

However, it would have been of urgent need in this case. CVE-2012-1823 is a so-called RCE (Remote Code Execution) vulnerability, which allows remote attackers to execute arbitrary code on a victim’s computer, and, in the worst case, to hijack the victim’s network.

RCE vulnerabilities are included in the critical vulnerabilities. Critical vulnerabilities are

  • exploitable from the network
  • need only low or medium skills to exploit
  • need no authentication
  • cause great damage, have high severity
  • allow remote attackers to execute arbitrary code on the victims computer

If an application system is operated in the DMZ, critical vulnerabilities must be patched directly upon publication to prevent attackers from getting onto your network. Or at least, between the time of publication and an exploit or proof of concept shows up. Since examples of how to exploit this PHP vulnerability were available in early May 2012, immediate action was required.

The big question is: Why were this vulnerable PHP versions not directly patched?

Exploitation of older vulnerabilities is not an isolated case. The HPE 2016 Cyber Risk Report shows, that in 2016

  • 47% of successful exploits use five or more years old vulnerabilities.
  • 68% of successful exploits use three or more years old vulnerabilities, 47% of them were critical vulnerabilities.
  • Stuxnet, CVE-2010-2568, was used in 29% of successful exploits.

An analysis of the critical vulnerabilities by vendors shows, that more critical vulnerabilities were found in non-Microsoft products than in Microsoft products.

Critical vulnerabilities 2010 - 2016

Critical vulnerabilities 2010 – 2016 by vendors. Click to enlarge.

But automated patch management is only available for Microsoft and few of the other vendors’ (e.g. Adobe, Oracle, SAP) products. Thus, we can expect that many critical vulnerabilities remain unpatched, which results in an ever-growing pool of opportunities for cyber criminals.

An ever growing pool of opportunities

An ever-growing pool of opportunities. Click to enlarge.

1) For the chart above I assumed that 50% of critical vulnerabilities remain unpatched. This assumption is based on the analysis of the 2017 NIST NVD data as of August 31st, 2017.

Since no automated patch management exists for PHP we can expect, that CVE-2012-1823 was rarely patched. But the worst is yet to come: From the HPE 2016 Cyber Risk Report we learn, that even six years old Microsoft vulnerabilities (Stuxnet, CVE-2010-2568) are not patched.

How to tackle this issue? From my point of view, the cause is compliance driven security. We often do patching of everything to meet compliance with a certain standard, instead of focusing on the real important issues, e.g., the critical vulnerabilities. Or, in other words, we close a lot of mouse holes while the barn door remains wide open.

WIth this, we must move from patching to vulnerability management, and priority patching for the critical vulnerabilities. Through a differentiated inspection of vulnerabilities we get out of the patch treadmill and can start working on the important cyber security issues.

By the way, if you haven’t subscribed to the Recorded Future Cyber Daily yet, consider to do it this week.

Have a great week.