Year: 2016

(This blog post is also available in Japanese.)

Palo Alto Networks has identified a malware family known as ‘Aveo’ that is being used to target Japanese speaking users. The ‘Aveo’ malware name comes from an embedded debug string within the binary file. The Aveo malware family has close ties to the previously discussed FormerFirstRAT malware family, which was also witnessed being used against Japanese targets. Aveo is disguised as a Microsoft Excel document, and drops a decoy document upon execution. The decoy document in question is related to a research initiative led by the Ido Laboratory at the Saitama Institute of Technology. Upon execution, the Aveo malware accepts a number of commands, allowing attackers to take full control over the victim machine.

Deployment

The Aveo malware sample disguises itself as a Microsoft Excel document, as the icon below demonstrates. Note that the filename of ‘malware.exe’ is simply a placeholder, as the original filename is unknown.

Figure 1 Microsoft Excel icon used by Aveo malware

The executable is in fact a WinRAR self-extracting executable file, which will drop the decoy document and Aveo Trojan upon execution. The following decoy document is dropped and subsequently opened when run.

Figure 2 Decoy document used with Aveo malware

This decoy document is hosted on the Ido Laboratory and contains information about a 2016 research initiative. The document lists participants in the 16^th CAVE workshop, including names, affiliations, and email addresses of those involved. The document, written in Japanese, as well as the filename of this document, “CAVE研究会参加者.xls”, indicates that this malware was used to target one or more Japanese speaking individuals. Additionally, the similarities between the Aveo and FormerFirstRAT malware families, which will be discussed later in the post, further add evidence that Japanese speakers are being targeted.

Infrastructure

The Aveo Trojan is configured to communicate with the following domain name over HTTP.

• snoozetime[.]info

This domain was first registered in May 2015 to ‘jack.ondo@mail.com’. Since that time, it has since been associated with the following three IP addresses:

• 104.202.173[.]82
• 107.180.36[.]179
• 50.63.202[.]38

All IP addresses in question are located within the United States.

Figure 3 PassiveTotal screenshot showing associated IP addresses with snoozetime[.]info

The WHOIS information for snoozetime[.]info lists a registrant email address of ‘jack.ondo@mail[.]com’ and a name of ‘aygt5ruhrj aygt5ruhrj gerhjrt’. Pivoting off of these two pieces of information to domains that share the same yields the following additional domains and email addresses.

• bluepaint[.]info
• coinpack[.]info
• 7b7p[.]info
• donkeyhaws[.]info
• europcubit[.]com
• jhmiyh.ny@gmail[.]com
• 844148030@qq[.]com

Malware Analysis

After running the self-extracting executable, a number of files are dropped to the file system and the following execution flow is witnessed:

Figure 4 Malware execution flow

When the mshelp32.exe executable runs, it begins by reading in the setting32.ini file, which contains the name of the decoy document. This information is used to build a batch script, such as the following.

This batch script is executed within a new process, and acts as a simple cleanup script that runs after Aveo and the decoy document are executed.

Aveo Malware Family

The Aveo malware initially runs an install routine, which will copy itself to the following location:

• %APPDATA%\MMC\MMC.exe

If for any reason the %APPDATA%\MMC directory is unable to be created, Aveo will use %TEMP% instead of %APPDATA%.

After the malware copies itself, it will execute MMC.exe in a new process with an argument of the original filename. When executed, if this single argument is provided, the malware will delete the file path provided.

After the installation routine completes, Aveo will exfiltrate the following victim information to a remote server via HTTP.

• Unique victim hash
• IP Address
• Microsoft Windows version
• Username
• ANSI code page identifier

This information is exfiltrated to the ‘snoozetime[.]info’ domain, as seen in the following example HTTP request:

To encrypt the provided data, the malware makes use of the RC4 algorithm, using a key of ‘hello’. As shown in the following image, the encryption routines between Aveo and FormerFirstRAT are almost identical, with only the algorithms and keys being changed.

Figure 5 Comparison of encryption function between Aveo and FormerFirstRAT

In order to decrypt the data provided via HTTP, the following code may be used:

Running the code above yields the following results:

After the initial victim information is exfiltrated, the malware expects a response of ‘OK’. Afterwards, Aveo will spawn a new thread that is responsible for handling interactive command requests received by the command and control (C2) server, as well as requests to spawn an interactive shell.

Aveo proceeds to set the following registry key to point towards the malware’s path, thus ensuring persistence across reboots:

HKCU\software\microsoft\windows\currentversion\run\msnetbridge

A command handler loop is then entered, where Aveo will accept commands from the remote C2. While the Aveo malware family awaits a response, it will perform sleep delays of randomly chosen intervals between 0 and 3276 milliseconds. Should the C2 server respond with ‘toyota’, it will set that interval to 60 seconds. Aveo accepts the following commands, shown with their associated function.

• 1 : Execute command in interactive shell
• 2 : Get file attributes
• 3 : Write file
• 4 : Read file
• 5 : List drives
• 6 : Execute DIR command against path

The following example request demonstrates the C2 server sending the ‘ipconfig’ command to the Aveo malware.

C2 Request

Aveo Response

Conclusion

Aveo shares a number of characteristics with FormerFirstRAT, including encryption routines, code reuse, and similarities in C2 functionality. Aveo is far from the most sophisticated malware family around. As witnessed in the previously discussed FormerFirstRAT sample, this related malware family also looks to be targeting Japanese speaking users. Using a self-extracting WinRAR file, the malware drops a decoy document, a copy of the Aveo malware, and a cleanup script.

Palo Alto Networks customers are protected from this threat in the following ways:

• An AutoFocus tag has been created to track and monitor this threat
• WildFire classifies Aveo samples as malicious
• C2 domains listed in this report are blocked through Threat Prevention.

Indicators of Compromise

SHA256 Hashes

9dccfdd2a503ef8614189225bbbac11ee6027590c577afcaada7e042e18625e2
8101c298a33d91a985a5150d0254cf426601e4632250f5a03ddac39375e7fb4d

C2 Domains

snoozetime[.]info

Registry Keys

HKCU\software\microsoft\windows\currentversion\run\msnetbridge

File Paths

%APPDATA%\MMC\MMC.exe
%TEMP%\MMC\MMC.exe

Josh Grunzweig and Robert Falcone

[Palo Alto Networks Research Center]

Threat actors tend to reuse certain tools, a trend we observed during recent Unit 42 research published on MNKit. In this post, we will discuss a fresh toolkit, which on the surface, appeared similar to MNKit, but functionally was found to be quite different.

This toolkit, which we named “HOMEKit”, is similar to MNKit in that it is also designed to generate weaponized Microsoft Word documents containing an exploit for CVE-2012-0158, but it uses OLE instead of MHTML files. In addition, we have been able to track the use of HOMEKit by its operators since 2013 across a variety of campaigns, using several different variants of the toolkit. For this post, we will be focusing on the most recent example of the HOMEKit toolkit, in addition to an interesting overlap we discovered with the well-known attack campaign DarkHotel. In a follow-up post, we will discuss the other campaigns associated with HOMEKit, along with other variants of HOMEKit that we discovered.

In addition to analysis of HOMEKit, we will also examine a new payload we discovered embedded in one of the malicious documents created by HOMEKit, which we have named “Cookle.” It is a fairly simple downloader tool, but until now has not been publicly discussed. Cookle deploys some interesting tactics to obfuscate its activity.

Telemetry

In late June 2016, we collected an e-mail file (Figure 1) that appeared to carry a phishing attack with a malicious file attached. The sender address was spoofed, using the identity of a coordination associate for the United Nations Environment Programme (UNEP). The content of the email seemed legitimate, using the subject line of “Pyongyang International Phonebook and Mailing lists – JUNE,” attempting to appear as a global directory for residents of the Democratic People’s Republic of Korea under UNEP. To further increase the legitimacy of the phishing attack, the threat actor copied the coordination associate’s signature block as well.

Figure 1 Phishing email carrying HOMEKit exploit file

The email contained two file attachments, a Microsoft Word document and a Microsoft Excel document. The Excel document proved to be benign, but the Word document exploited the CVE-2012-0158 vulnerability. If the victim were to open the Word document, it would silently install the Cookle Trojan, while opening a decoy document in Word (Figure 2), displaying the expected content to the victim.

Figure 2 Decoy document containing message intended for residents of Pyongyang

The benign Excel document and the Word document used as decoys both appeared to be legitimate, internal documents; the Word document containing the email addresses of all DPRK UNEP residents, along with mailing lists to use for specific topics. The Excel document contained additional contacts for other related agencies, in addition to emergency contact information for the DPRK UNEP residents. Examination of the metadata of the two files revealed the Excel document was last modified by the spoofed sender’s identity on June 22, 2016, while the decoy Word document showed the original author as the Coordination Officer in 2012, with a creation timestamp of July 19, 2012. The “last modified” field of the decoy document though revealed its true nature, showing that it was last modified on April 5, 2016, by “Windows User” indicating the decoy document was likely to be last modified by the threat actor.

By using the specific documents observed in this attack, the threat actor demonstrated that he or she may have already gained unauthorized access to some extent. Also, the contents of these internal documents show that the threat actor currently has access to data that could be further leveraged to craft additional phishing attacks at related targets.

HOMEKit

The HOMEKit toolkit creates Microsoft Word documents (OLE) that exploit the CVE-2012-0158 vulnerability. All malicious documents created by the HOMEKit toolkit have the same metadata within the SummaryInformation and DocumentSummaryInformation streams of the OLE document, as seen in Figure 3.

Figure 3 HOMEKit Meta Data

HOMEKit creates documents designed to exploit a vulnerability within the TreeView ActiveX control, specifically the CLSID of 9368265E-85FE-11d1-8BE3-0000F8754DA1. Upon successful exploitation, the malicious document will execute shellcode to open a decoy document (~.doc) while it installs and executes a payload on the system (~.dat).

The shellcode executed by this variant of HOMEKit begins with a decryption stub that is responsible for decrypting the functional shellcode. The decryption stub uses a combination of right bit shifting (ROR 3) and an XOR operation (key of 0xAF) on each byte of ciphertext.

The functional shellcode exposed by the decryption stub starts by enumerating open file handles looking for files that have a file size greater than zero. It then reads the last 20 bytes of each file looking for the value “0xDEADFOOD” at the very end of the file to find the delivery document. Once it finds the appropriate file, it parses the last 20 bytes of the file to locate the payload and decoy document using the following structure:

To decrypt the payload and decoy, the shellcode uses an algorithm that starts from the end of the ciphertext, using the lowest byte of the initial value of “0xDEADFOOD” to XOR the first byte and then rotating the key value by 1 for each subsequent operation. The shellcode will save the payload to %TEMP%\~.dat and the decoy to %TEMP%\~.doc after the decryption routines are finished. Once the payload and decoy are saved to the system, the shellcode creates a process with %TEMP%\~.dat to execute the payload and creates a process with the following command line to open the decoy document:

cmd.exe /c dir /s %windir%\system32\*.sys&&taskkill /im winword.exe /f&dir /a /s %windir%\system32\*.msc && DOCUME~1\ADMINI~1\LOCALS~1\Temp\~.doc

When creating the processes to run the payload and open the decoy, the shellcode calls GetCurrentProcess to get a handle to the current Word process, then OpenProcessToken to access the Word process’s token. Finally, it uses this token to call CreateProcessAsUserA to run the payload and the decoy with the same context as the current Word process.

Cookle Trojan

At a high level, the payload delivered in this attack is a downloader Trojan that we are tracking as “Cookle” based on a header value in HTTP requests made by the malware.

After initial execution, the Trojan creates the mutex “LDE_160425” and copies itself from %TEMP%\~.dat to %APPDATA%\Microsoft\WindowsUpdate\~.exe. For persistence, the Trojan creates the following registry key with a path to the newly copied Trojan:

SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Startup

A majority of the pertinent strings embedded within the Trojan are encoded, which the Trojan decodes using a modified base64 decoding function that swaps the uppercase letters in the base64 alphabet with lowercase letters, and vice versa. It uses this custom base64 decoder to decode the following strings:

The Trojan contains two command and control (C2) domains within the encoded strings listed above, dyn.kaleebso[.]com and dyn.pwnz[.]org. The Trojan sets a sleep timer of 20 minutes to wait before generating and sending network beacons to the C2 servers. The initial beacon seen in Figure 4 contains a misspelled “Cookie” field that includes the same value the Trojan uses as a mutex.

Figure 4 C2 Beacon sent from Cookle Trojan

If the Trojan receives a response to this beacon from the C2 server, it runs several system commands, specifically systeminfo, tasklist, netstat /ano, and ipconfig /all. It will then take the output from those system commands and save the output to a text file in the %TEMP% folder with a filename of “<year><month><day><hour><minute><second>.tmp”. The Trojan will then send the contents of this file to the C2 server as cleartext within a HTTP POST request that will resemble the following:

Figure 5 HTTP POST request issued by Cookle that sends system information to C2 server

The C2 server will respond to this request with a command that the Trojan will parse. The Trojan’s command handler has three available commands:

Figure 6 Commands within Cookle’s Command Handler

The functionality available within the Trojan is limited, however, it allows the actor to perform system reconnaissance before delivering a secondary payload. The secondary payload is delivered via the ‘d’ command, wherein the Trojan will decrypt an executable using the XOR operation on each byte in the C2’s response with 0xA7. During the analysis period, the C2 servers did not respond with a secondary payload.

Overlap with DarkHotel

Collection of additional HOMEKit delivery documents revealed use of this toolkit by its operators since at least 2013 and most recently, late June 2016. Each of these malicious documents created by the HOMEKit toolkit installed different payloads including PlugX, Sutr, and HIMAN/Mirage, among others. As mentioned earlier, we will be publishing a follow up to this post that contains details of these prior attacks.

As part of the collected sample set, we found two documents that have a very similar structure as the delivery document used in the attack delivering the Cookle payload but with very slight variations in the exploit code. The most curious aspect of these two documents was the payload embedded in them.

Both of the additional HOMEKit samples have the same functional shellcode and install a downloader associated with the Tapaoux Trojan, a tool related to the DarkHotel threat group. We compared the shellcode embedded in the HOMEKit delivery documents with previous samples associated with DarkHotel and found striking similarities (Figure 7).

Figure 7 Comparison of notable static attributes within HOMEKit documents installing Cookle and DarkHotel

The major difference between the HOMEKit documents dropping Cookle and DarkHotel begins with the stub decrypter, as seen in Figure 7. The stub decrypter decrypts a second piece of shellcode that carries out the main functionality as mentioned previously in this post. The decryption routines themselves differ, as seen in the green highlighted instructions in Figure 8. The size of the decrypted shellcode differs between the two samples as well, as seen in the yellow highlighted “mov cx” instructions in Figure 8.

Figure 8 Comparison of stub decrypters found in the shellcode within Cookle and DarkHotel samples

Even though the size of the shellcode differs between the Cookle and DarkHotel samples, the shellcode itself is extremely similar. A simple binary difference between the two functional shellcodes result in over a 90 percent similarity. Static analysis determined that the two shellcodes resolve the same API functions and store them on the stack in the same order. Also, many identical code blocks exist between the two shellcodes that results in significant code overlap. The similarities in shellcode suggest that the author of the HOMEKit toolkit variant used to deliver the Cookle Trojan had access to the same shellcode as the HOMEKit toolkit used to install DarkHotel.

The difference between the functional shellcode that installs Cookle and DarkHotel lies in the way a process is created to execute the payload and to open the decoy document. While the difference between the two is very minor, it is worth discussing as it suggests the author of the Cookle shellcode intentionally modified the DarkHotel shellcode, possibly as an anti-analysis technique. Figure 9 shows a side-by-side comparison of the process creation functionality within the DarkHotel and Cookle shellcodes, which highlights the differences between the two (red and blue highlighted instructions and two new gray code blocks).

Figure 9 Side-by-side comparison of the shellcode dropping DarkHotel and Cookle, specifically code used to create a process

The comparison in Figure 9 shows the differences between the two functions using highlighted instructions and additional boxes, but it does not explain what the changes mean from a functionality standpoint. We will explain how the two functions go about creating a process and how they differ.

The DarkHotel shellcode first uses the GetCurrentProcess function to get a handle to the Word process, then uses OpenProcessToken and finally CreateProcessAsUserA to open the decoy and execute the payload just like the Cookle shellcode. However, the DarkHotel shellcode calls the API functions in a very straightforward manner, specifically using CALL instructions (highlighted red in Figure 9).

In contrast, the Cookle shellcode uses CALL instructions to call the GetCurrentProcess and OpenProcessToken functions, but jumps to the CreateProcessAsUserA function using a JMP instruction. To allow the use of JMP in place of a CALL, the shellcode must provide a way to return to the function that called it, as the JMP instruction does not automatically handle this like the CALL instruction. Instead, it references a specific location (top four blue highlighted instructions) and starts looking for the value “0xC3” (first gray box in Figure 9), which is the value for the instruction “RETN”. Once found, the shellcode will push to the stack so the JMP instruction can be used to call the CreateProcessAsUserA function and return to the original calling function.

The similarities between the delivery documents dropping Cookle and DarkHotel payloads suggest that both were generated by the HOMEKit toolkit, albeit using slightly different versions. The slight differences between the stub decrypters and the functional shellcode within the malicious documents hints that the actor may have used the same codebase to create a modified version of HOMEKit for use in the Cookle attack.

Conclusion

As we have highlighted several times in the past, the reuse of tools is quite common amongst various threat actor groups. Our next post will further map out the various campaigns associated with HOMEKit, along with the multiple variants discovered in the span of several years. The DarkHotel payload however, is a curious outlier in the grouping of payloads we were able to identify. It is possible that the DarkHotel threat actors were able to obtain a copy of the HOMEKit codebase somehow, or even possible that the Tapaoux Trojan was obtained by operators with access to HOMEKit. It is also possible that HOMEKit is a toolkit available to multiple threat actors, via a connected intermediary. Unfortunately, at this time, a lack of data does not allow us to come to a definitive answer. Regardless, it is yet another example of tool sharing and overlap, this time with surprising results.

• Palo Alto Networks customers are protected and can learn more via the following resources:
• All samples of this HOMEKit variant and Cookle are detected as malicious by WildFire
• All domains described in this post are classified as malicious
• HOMEKit and Cookle AutoFocus tags created

Indicators of Compromise

HOMEKit SHA256

ed676d191684fa03b2b57925fe081cf32d5d6b074637f6f2a6401dd891818752
ab7b5c35786813ed874483d388edbee3736eb6af7bc4946c41794209026eeac4
f9bf645a3a7d506136132fcfa18ddf057778d641ff71d175afd86f1a4fed7ee9

Cookle SHA256

4a5807bab603d3a0a5d36aaec75729310928a9a57375b7440298fb3f3e4a2279

Cookle C2s

dyn.kaleebso[.]com
dyn.pwnz[.]org

DarkHotel SHA256

2437d0a9cc019e33fe8306fceed99605dd5ab67a8023da65fa20b9815ec19d06
bb06bfad96535ad04a6e65a6e68f34cb51f311cae48a2ff1c305f3957b2c8a4b

DarkHotel C2s

apply-wsu.ebizx[.]net
apply.ebizx[.]net

Bryan Lee and Robert Falcone

[Palo Alto Networks Research Center]

It’s time to be reminded once again how critical the security of our endpoints is to our overall network’s security and risk posture. We all read the bad news headlines about how fast the “bad guys” are advancing. But it’s also a good time to note: so are the “good guys.”

If you look at some of the biggest government attacks over the last two years, two consistent themes arise. There were vulnerabilities in the operating system or an app on the endpoint that was used to gain entry – and that app, of course, hadn’t been patched. And once the attacker got onto the network, using that endpoint as a beachhead, they had unfettered access to move across it – ultimately, in many cases, getting to exactly what they wanted. You know the drill because you’ve heard it repeated more times than you’d prefer. But we don’t have to stop there.There really is good news – and we’re adding to that good news with some recent updates to Traps advanced endpoint protection, a cornerstone of our next-generation security platform.

Take one of our government customers as an example. Their employees are highly mobile. They’re highly targeted. They know there are great risks on their endpoints. They understand what’s at stake. But, luckily, they don’t put their heads in the sand and wait to be told antivirus is dead – and that’s despite government guidance which often still calls for this dying solution to the problem. They’re proactively addressing the multiple risks – both exploits and zero-day malware – with our Traps advanced endpoint protection. I’ll explain a bit more about how it works below. Especially in highly targeted government environments, you need this multi-method breach prevention. What we mean by “multi-method” is that you have to address bothunknown malware and exploits that take advantage of those vulnerable operating systems and applications I mentioned previously, using multiple methods for each.

What can you do about exploits without disrupting the user or using a lot of your resources to address them? Many people still believe that addressing exploits is really difficult, disruptive to the end user, and not worth the effort. (In case you’re unfamiliar with exploits, more than 30 percent of recent CryptoWall ransomware attacks were delivered using exploit kits that leveraged unpatched vulnerabilities. You can check out our Cyber Threat Alliance CrytoWall Report, 2016 to learn more about this example of how exploits are being used today).

Actually, the good news is that we can detect an exploit as soon as it attempts to execute, and we do so seamlessly. Traps does not perform any system scanning, so the footprint is extremely small, and the CPU utilization and disk I/O are minimal. While actively preventing security breaches, Traps remains essentially transparent to users. And as far as the exploits, there are actually core exploit techniques that are used by all exploit-based attacks. So, yes, there are many thousands of exploits, but the truth is that they all rely on a small set of core exploit techniques, and those techniques don’t change often. We can actually break that chain and block the techniques the second they’re attempted. Here’s a bit more insight into this good news that Traps uses multiple methods for exploit prevention:

• Memory Corruption/Manipulation Prevention: These exploit techniques manipulate the operating system’s normal memory management mechanisms for the application opening the weaponized data file that contains the exploit. This method recognizes and stops these exploit techniques before they have a chance to subvert the application.
• Logic Flaw Prevention: These exploit techniques allow the exploit to manipulate the operating system’s normal processes that are used to support and execute the target application opening the weaponized data file. For example, the exploit may alter the location where dynamic link libraries (DLLs) are loaded from into an application’s execution environment so that the exploit’s malicious DLLs can replace legitimate ones. This method recognizes these exploit techniques and stops them before they succeed.
• Malicious Code Execution Prevention: This prevention method recognizes the exploit techniques that allow the attacker’s malicious code to execute and blocks them before they succeed.

What can you do to address unknown malware or zero-days on the endpoint?Traditionally, you’d try to get antivirus to address the issue. But that ship has sailed – AV simply can’t deal with the volume and sophistication of the zero-day (aka “unknown”) threats today. And the first thing attackers do today is make sure their attack shuts off antivirus. In fact, theNTT 2015 Global Threat intelligence report estimates that approximately 54 percent of new cyberattacks go undetected by traditional endpoint protection, but it is likely even higher. Thegood news is that we have multiple methods we use to thwart unknown malware on the endpoint, including several new features we’ve just announced:

• Static Analysis via Machine Learning: provides an instantaneous verdict on any executable file before it is allowed to run. By examining hundreds of the file’s characteristics in a fraction of a second, this method determines if it is likely to be malicious or benign without relying on signatures, scanning or behavioral analysis. The threat intelligence available through WildFire is used to train a machine learning model to autonomously recognize malware, especially variants that have never been seen before, with unmatched effectiveness and accuracy.
• Quarantine of malicious executables: Traps version 3.4 now immediately removes malicious files to prevent further propagation or execution attempts of infected files.
• WildFire Inspection and Analysis: This method works because of the ability to automatically reprogram the endpoint protection based on real-time insights from WildFire about the unknown files it’s assessing. An attacker can use each piece of malware once, at most, anywhere in the world, and only has seconds to carry out an attack before WildFire renders it entirely ineffective.
• Trusted Publisher Execution Restrictions: Now we can use another verification method on files digitally signed by trusted publishers that Palo Alto Networks recognizes as reputable software publishers.
• Policy-Based Execution Restrictions: You can define policies to restrict specific execution scenarios that further reduce your attack surface. For example, Traps can prevent the execution of files from the Outlook temp directory or the execution of a particular file type directly from a USB drive.
• Admin Override Policies: You can define other policies, based on the hash of an executable file, for additional control over what is allowed to run in any environment.

You can read more about any of these capabilities in more detail.

Other things you want to consider:

• Patching – I know that patching your most critical assets goes without saying, and some government agencies are doing a great job with this. For those that can’t be patched, leverage compensating controls like the ones we’ve talked about above. With Windows XP, Windows Server 2003, and versions of Internet Explorer (IE) older than version 11 having reached end-of-life (i.e., support), agencies still running these legacy systems and software are going to be vulnerable. Security patches are no longer available so the risks to them are going to be tough to tackle. And as I’ve mentioned, think about both your IT and OT networks here.
• Get visibility today of every user, device and application running on your network —You can’t protect what you don’t know or understand. As an example, read more about how governments are employing user identification to understand their users and contextually whitelist not only certain applications by user or user group but also specify which capabilitieswithin the app (think of chat or file sharing within WebEx or file downloads from Dropbox) they will allow.
• Regardless of which cyber model you use – the Gartner attack lifecycle or the Lockheed Martin Cyber Kill Chain – ensure you’ve done a meaningful gap analysis and understand precisely where you’re vulnerable at each stage of that lifecycle. By the way, this is critical on your SCADA systems today, too. These systems notoriously run end-of-life operating systems, and there’s no simple way to patch them. (If you’re interested in how Palo Alto Networks does that, you can read more about our Prevention Gap Analysis tool.)
• Virtually segment your network – This means creating zones to limit users per zone, strictly control flows between security zones, and limit types of flows that can move between those segments. This goes back to the cyberattack lifecycle – all you need to do is block them at one place in the chain, and you’ve made their campaign unsuccessful. Think of whitelisting – where specific applications are allowed and other traffic is blocked, contextual to your user base – that’s what we mean here by segmentation.
• Don’t let your teams or your security enforcement points and products operate in silos. Do your endpoint and network security capabilities complement and inform one another? If not, what will it take for this to happen? Endpoint-to-network security correlation is available and improves the time to prevent an attack. When the network sees a new piece of malware, it grabs all of the indicators and can share relevant information to thwart the attack on the endpoint.

As our “endpoints” change, and we find ourselves at the dawn of the era of the internet of things (IoT), we need to be careful to keep apace with devices that are added to our networks – both IT and OT. Consider your endpoint as a critical point in the cyberattack life cycle. For those of you in the U.S., you can start with the Cyber Security Strategy and Implementation Plan (CSIP)– what are your most critical assets and what are the many ways, through the cyberattack lifecycle, the adversary can get to that critical data? And then ask yourself in the context of your overall security posture, what gaps do you have amid that attack lifecycle? It’s important to consider our endpoint practices, as I’ve described, before our networks become even more complicated with more devices. Build your endpoint security programs to plan for swiftly changing endpoints. That’s our “new normal.” It’s hard to believe that one day we’ll think of our communications with (and vulnerable access from) our security systems and thermostats just like we do our laptops today. Yes, that’s progress – let’s not be afraid to embrace it.

For more information in modernizing your endpoint security strategies:

• Read our Government Endpoint Use Case
• Listen to our MeriTalk Government Endpoint Epidemic Webinar
• Learn more about Traps

Pamela Warren

[Palo Alto Networks Research Center]