32. The Waterbear-er of Bad News
Coming up this week on Breaking Badness. Today we discuss: Siemens No Longer In The Dark About Power Plant Vulnerabilities, Lowering the Bear-ier to Entry: API Hooking and Waterbear Malware, and our fun new game, two truths and a lie.
Here are a few highlights from each article we discussed:
- The over 50 vulnerabilities were discovered by researchers at Kaspersky, Positive Technologies, and Biznet Bilişim. These researchers discovered 19 vulnerabilities in the SPAA-T3000 Application Server, and 35 in the SPAA-T3000 MS3000 Migration Server. These vulnerabilities were responsibly disclosed to Siemens starting over a year ago.
- The most critical flaws could allow an attacker to create a DoS situation or execute arbitrary code, but those weren’t the only vulnerabilities. In addition, there are some that could be used to change user passwords, obtain directory listings and files containing sensitive information, escalate privileges, upload files, read and write files on the local file system, access paths and filenames on the server, enumerate usernames, and access logs and configuration files.
- The application network is where the power plant operator controls the plant and sends commands to the server, which is connected to the automation network with equipment connected to turbines and other field devices. Vulnerabilities in any ICS environment are oftentimes more concerning than regular corporate networks, because ICS environments can have real-world impacts if they’re messed with – sometimes up to and including physical injuries and fatalities. Flaws in this particular Siemens system can result in physical issues such as interrupting electrical generation and causing malfunctions at power plants.
- However, Siemens has expressed that it is not easy for these vulnerabilities to be exploited, as an attacker would have to have access to the Application Highway or the Automation Highway. Siemens has said that these network segments should not be exposed if the system has been set up as specified in the product’s security manual.
- Siemens is working on patching the vulnerabilities, but in the meantime has released a list of “workarounds and mitigations” – the first of which a reminder to users to read the security manual in order to properly set up the Application and Automation Highway to restrict attacker access to these networks. The other mitigations are also mostly just reminders to users to properly set up firewalls and external components to reduce the risk of these vulnerabilities.
- Some of these vulnerabilities are pretty concerning IF attackers are able to exploit them. So far, Siemens says there is no evidence that any of these have been exploited in the wild. However, Valdimir Nazarov – one of the researchers who discovered these vulnerabilities – has made it clear that these can have serious consequences such as disruption of power generation. He’s also said the flaws he discovered would be easy to exploit – but agrees with Siemens that it would require an attacker to have extensive knowledge of the systems they were targeting. This wouldn’t be out of the realm of possibility though… if a well funded (potentially nation state) attacker really wanted to exploit these, they would likely take the time to research the system and fully understand it before attempting to exploit it.
- The 2020 NDAA just passed the House last week and is on its way to being signed into law. It includes the “Securing Energy Infrastructure Bill,” which has a few goals, identifying vulnerabilities and isolating critical grid systems, and implementing analog backups in case of a cyber attack. It would also create a working group to analyze and develop strategies to keep the grid safe. While this isn’t directly related to the Siemens vulnerability we just talked about, it’s certainly in the same vein of thought. Attackers are looking for ways to interrupt power via means like the vulnerabilities discussed above. Having this NDAA in place will help ensure the grid is being looked at critically to ensure it is much more difficult for an attacker to gain access.
- API Hooking isn’t a thing that’s centric to just malware, but is a normal operation for operating systems. At the core of API hooking is when you have code that intercepts and takes some sort of action in response to events such as messages, keystrokes, and mouse inputs. A good real world example of malicious API hooking would be someone writing keylogging software that hooks into the API calls into the Windows Keyboard State function, captures what keystrokes are being input and then writes them to a file for the attacker to retrieve.
- Waterbear specifically leverages API hooking in a way to hide its processes from a handful of security AV solutions and to mask its behavior. There are a handful of shell code payloads with Waterbear. The first-stage shellcode finds a specific security product’s process with a hardcoded name and injects the second-stage shellcode into that process. The second-stage shellcode then performs API hooking inside the targeted process.
- The second stage payload only modifies the functions in the memory of the security product process, hence the original system DLL files remain unchanged which would not trigger some security solutions. So it’s a really interesting means of having malicious code execute.
- TrendMicro has some really great data on the TTP’s of Waterbear associated threat group “BlackTech”. We know they primarily focus on attacking target institutions and companies primarily out of Taiwan, and occasionally Japan. I would say with reasonable confidence based on the political relationships that this is likely a Chinese originated threat group. TrendMicro’s research also really highlights that this threat group is likely well funded based on the complexity of their attacks and toolsets they’ve dropped on their victims machines for data exfiltration and persistence.
- When it comes to attacker motiviations, there’s been some big impact attacks associated with BlackTech. One of BlackTech’s primary goals is stealing of data and intellectual property theft.
- Waterbear is a pretty complex and modular piece of malware.
- The initial stage of Waterbear has two options that have been seen in the wild: DLL Hijacking of a legitimate application to then call the second stage payload of Waterbear, or, DLL Side loading of a legitimate executable. Once either of these techniques are done, Waterbear can run the rest of its operations under whatever privilege those executables were running as which are elevated in this case.
- Waterbear’s first-stage backdoor configuration contains the data required for the rest of the attack process, like the C2 server where data gets exfiltrated to. But all of the API calls, C2 information and whatnot are accessed on runtime, as opposed to a good majority of malware which has this type of information that can be statically accessed.
- Waterbear dynamically loads the DLLs / API’s through the shellcode. Additionally, it hooks security product’s commonly used APIs to detect or evade them. It also does binary padding to evade detections (fills areas of memory with junk data), uses private IP addresses for some of it’s C2 operations.
- I think if I were protecting a company that is based out of East Asia, specifically Taiwan or Japan I would be on high alert about the security controls I have and how to threat model against these types of APT groups. It’s easier said than done, but it needs to happen.
Two Truths and a Lie
Introducing our newest segment on Breaking Badness. We are going to play a game you are all likely familiar with called two truths and a lie, with a fun twist. Each week, one us with come prepared with three article titles, two of which are real, and one is, you guessed it, A LIE.
You’ll have to tune in to find out!
This Week’s Hoodie/Goodie Scale
Siemens No Longer In The Dark About Power Plant Vulnerabilities
[Emily]: 9/10 Hoodies
[Tarik]: 8/10 Hoodies
Lowering the Bear-ier to Entry: API Hooking and Waterbear Malware
[Emily]: 5/10 Hoodies
[Tarik]: 5/10 Hoodies
That’s about all we have for this week, you can find us on Twitter @domaintools, all of the articles mentioned in our podcast will always be included on our podcast recap. Catch us Wednesdays at 9 AM Pacific time when we publish our next podcast and blog.
*A special thanks to John Roderick for our incredible podcast music!