Here are three ways to think about public cloud security as we head into 2016.
“Cloud First” Will Acclerate Public Cloud Adoption
I believe that customers have concluded that the public cloud is ready to support their business requirements and they have accepted — and hopefully understand — the shared security model for protecting their applications and data. With that in mind, I predict that 2016 will see a rapid acceleration of public cloud adoption, driven by an application development mindset that is geared towards cloud first and cloud native. Cloud first and cloud native means that the applications are developed with the agility, scalability, and resiliency of the public cloud in mind; and using (reusing) smaller components that are a combination of open-source and internally developed.
Public cloud initiative success may hinge upon security
Gartner predicts that by 2020, a staggering 95 percent of public cloud failures will be the customer’s fault. We can only hope this prediction never comes true. Undoubtedly, some of the public cloud failures will be the direct result of poor security, resulting in the loss of customer data. One could argue that security in the public cloud should be tighter than network security because the public cloud is more “exposed”, be it real or perceived. Traditional IT will be challenged to secure these assets as the architecture in public cloud evolves and increases in complexity, forcing them to look beyond the basic visibility and security features offered by the cloud providers. Enterprises should treat their public cloud deployment as a greenfield opportunity to implement the tightest security possible, encompassing better SOC tools for improved visibility and control over the applications, users and traffic across their various “cloud islands”.
Prevention alliances will expand beyond networking and security
Our interaction with customers has shown that public cloud projects are driven by groups that fall outside of traditionally-defined networking and security teams. Examples we have seen include Cloud, DevOps, Infrastructure, and Virtualization. As public cloud initiatives accelerate, the concept of security first will expand beyond the security team into the other groups, thereby expanding the working relationships and resources focused on the task of network and data protection. This particular prediction is critical to the protection of cloud-based apps and data and, possibly, the success of the public cloud deployments as a whole. In fact, many public (and private) cloud projects have been successful because of the close working relationship between security and cloud teams. In some cases, the groups have been combined under the same management “roof.” I expect to see more of that happening next year.
Want to explore more of our top 2016 cybersecurity predictions? Register now for Ignite 2016.
Palo Alto Networks recently identified a new campaign targeting the transportation sector in Europe with ties to the Dark Seoul and Operation Troy campaigns that took place in 2013. This new campaign used updated instances of the Tdrop malware family discovered in the Operation Troy campaign. For more information on the new campaign discovered by Unit 42, please refer to our recent blog post.
In this attack, attackers embedded the TDrop2 malware inside a legitimate video software package hosted on the software distributor’s website. By doing this, they were able to target organizations that relied on the distributor’s security camera solution and infect their systems with malware. They created a true Trojan horse, which sneaks into a network as a gift, but when opened, the attacker’s army leaps out.
Trojanized Video Player (Stage 1)
The malware used for the attempted infection purported to be a legitimate video player, providing viewing software for security camera solutions. The following two unique file names were involved in the attack.
[redacted]Player_full.exe
[redacted]Player_light.exe
The difference between the files involves the specific video player that was dropped and executed during runtime. Each file would drop and execute the full or light version of the legitimate video player respective to the file name.
Both the legitimate copy of the video player, as well as a malicious executable were bundled into a single executable. These files were added to the end of the Trojan executable, as seen below.
Figure 1 Layout of Trojan video player
When initially run, the malware checks to see if its parent process is either explorer.exe or cmd.exe. In the event the malware is not running in the context of either of these processes, it will exit. This check exists in a number of the subsequent processes/executables used by the TDrop2 malware variant.
Figure 2 Function identifying and checking parent process
Subsequently, the malware proceeds to extract both the video player and the embedded malware using a series of calls to CreateFile, CreateFileMapping, GetFileSize, andMapViewOfFile. Once extracted, the file writes it to a new file on disk prior to executing it. The video player is written to one of the following locations, based on the original filename:
%TEMP%\[redacted]Player_full.exe
%TEMP%\[redacted]Player_light.exe
The malware itself is written to the %TEMP% directory as well. The filename is derived by randomly choosing an executable name from the system32 directory. The randomly chosen executable must not contain any of the following strings:
setup
install
update
Dropped Malware (Stage 2)
This dropped malware begins by performing the same parent process check witnessed in the original sample. In the event the malware is not running within the parent process of cmd.exe or explorer.exe, it will exit immediately. This malware sample will also dynamically load a number of functions and libraries. After the kernel32.dll and ntdll.dll libraries are loaded via calls toGetModuleHandle, the following process takes place:
Create a char array containing the desired function name and store this array to a variable
Figure 3 Malware dynamically loading functions at runtime
In total, the following 14 functions are loaded during runtime:
CreateFileA
GetFileSize
CloseHandle
VirtualAlloc
GetModuleFileNameA
CreateProcessA
NtUnmapViewOfSection
VirtualAllocEx
WriteProcessMemory
GetThreadContext
SetThreadContext
ResumeThread
TerminateProcess
TerminateThread
After these functions are loaded, the malware will randomly select an executable from the system32 using the same routine witnessed in the earlier sample. The malware proceeds to spawn a new process of the selected executable and performs a technique called process hollowing to hide itself inside a legitimate executable. This leads us to the next stage of our malware
Injected Malware (Stage 3)
This particular stage of malware acts as a downloader. The parent process check is not used in this particular sample. The malware initially attempts to download a file from the following location:
The downloaded file has the first two bytes of the PE file format replaced with the characters ‘DW’, instead of the usual ‘MZ’. After the download occurs, the malware immediately corrects the first two bytes with the ‘MZ’ characters prior to writing the file to disk.
Figure 5 Malware overwriting first two bytes of downloaded file
The downloaded file is dropped to the system32 folder. The malware selects a randomly chosen DLL from this directory. The base name of this DLL is used to write the downloaded file. As an example, in the event apcups.dll was selected, the malware would write the downloaded file to apcups.exe in the same folder. The downloader then proceeds to execute this downloaded file in a new process.
JPG Executable (Stage 4)
As we’ve seen in previous samples, this executable file begins by checking the parent process for the presence of ‘cmd.exe’ or ‘explorer.exe’. It proceeds to randomly select an executable file in the system32 folder, and performs process hollowing against it. The injected executable contains the last stage of the TDrop2 malware variant.
Final Payload (Stage 5)
Upon execution, we once again see the parent process check to determine if the malware is running within the ‘cmd.exe’ or ‘explorer.exe’ parent process. It continues to dynamically load a number of libraries and functions for later use. A feature that has yet to be seen is that of string encryption. Strings are encrypted using the following function, represented in Python:
1
2
3
4
5
6
7
8
def decrypt(data):
length=len(data)
c=1
o=“”
whilec<length:
o+=chr(ord(data[0])^ord(data[c]))
c+=1
returno
After dynamically loading functions and libraries, the malware iterates through the running processes and attempts to determine if the ‘V3lite.exe’ process is running. This process name is associated with the South Korean-based AhnLab security software provider. In the event this process is running, the malware will attempt to kill the process’ class window.
The final payload proceeds to generate the following mutex to ensure only one copy of the malware is running concurrently:
Global\SPPLMUTEX
The payload then spawns two threads—one to maintain persistence and another to gather victim information and perform command and control operations. Persistence is achieved by setting the following registry key:
The name of the registry key in the above instances is derived from the basename of the supplied argument. In the event the supplied argument was C:\malware.exe, the registry key would be named ‘malware’, and the path for this key would be ‘C:\malware.exe’.
The persistence thread runs in a loop where the registry keys are set every 60 seconds, ensuring persistence even in the event an administrator manually deletes the registry keys.
The other thread begins by collecting information about the victim, such as the following:
Computer Name
IP Address
Registered Owner
Registered Organization
Installation Date
These data points are used to generate a unique victim ID, which is stored in the following registry key:
HKCU\SOFTWARE\Microsoft\HY08A\Build
The malware will continue to decrypt and store embedded C2 URLs. The following URLs have been identified:
The final payload proceeds to enter its command and control loop. It initially performs a DNS check against microsoft.com to ensure it has Internet connectivity. After this check is performed, it enters an infinite loop, with a sleep interval set at a default of 30 minutes. The malware will periodically poll the C2 server and determine if any commands are received. The initial POST request contains a unique victim identifier that was previously generated.
Figure 6 Malware connecting to C2 server
The optional response by the C2 server is both encoded and encrypted.
Figure 7 C2 server response to malware request
The data is first encrypted using an unidentified algorithm. The two keys used for this encryption are generated using another unidentified algorithm. The following Python script can be used to generate the keys. A default salt of ‘FFFFFFFF’ is used.
When the previously mentioned C2 response is both decoded and decrypted, we are presented with the following data:
1
2
3
4
def key_generation(rounds=8,buf=FFFFFFFF“):
tick 7880
systeminfo & net view & netstat -naop tcp & tasklist & dir /a “%userprofile%\AppData\Local\Microsoft\Outlook” & dir /a “%temp%\*.exe” & dir “%ProgramFiles%” & dir “%ProgramFiles%\Microsoft Office“
1018;60
The command structure of the C2 response always begins with the string ‘tick’. The number following this string is most likely a unique command identifier. The malware will store these command identifiers in the following files:
%TEMP%\MSI2001.LOG
%TEMP%\MSI2002.LOG
In the event the number after the tick was previously witnessed, the command from the C2 will be ignored. The remaining lines are then parsed. The following commands are supported:
Command
Description
1001
Modify C2 URLs
1003
Download
1013
Download/execute malware in other process
1018
Modify wait interval time
1025
Download/execute and return response
Default
Execute command and return results
Once again, using the previous example, the malware will first ensure that the command was not previously parsed/executed. In the event it is new, it will proceed to execute the various reconnaissance commands found on line #2. The results of these commands are uploaded to the C2 server.
Figure 8 Malware uploading command results to C2 server
As we can see in the above network traffic, the malware attempts to disguise the data as a .gif image. Finally, the malware will parse the third line, which instructs the malware to modify the wait interval to a value of ‘60’. This interval value is set in the following registry key:
HKCU\Software\Microsoft\HY08A\Policy
Additionally, in the event the C2 response instructs the malware to update C2 URLs, it will be in the following format:
1001; [unique_identifier] [url]
The malware will encrypt the URL string with a 4-byte XOR key of “\x01\x02\x03\x04” and store this data in the following registry key:
HKCU\Software\Microsoft\HY08A\[unique_identifier]
Conclusion
The TDrop2 malware family that was witnessed in a recent attack against a European transportation company provided a minimal set of commands to the attackers. It was most likely used to establish a foothold, perform reconnaissance and deploy further malware into the victim’s network. While the malware lacked a large set of capabilities, it had a wealth of interesting and advanced features, such as the custom encryption/encoding witnessed in the network traffic, the use of process hollowing against a randomly selected Microsoft Windows binary, and the downloading component that attempted to bypass network security measures by modifying the executable header.
We created the AutoFocus tag TDrop2 to identify samples of this new variant and added known C2 domains and hash values to the Threat Prevention product set. At this time, WildFire is able to correctly identify the samples associated with this campaign as malicious.
Malware authors must constantly iterate on their techniques in order to stay relevant in today’s fast moving Information Security environment. The Upatre downloader has been around for nearly three years and has consistently evolved its anti-analysis capabilities to better ensure payload delivery. Using Palo Alto Networks AutoFocus, we identified several thousand functionally identical Upatre binaries with unique hashes that exhibited unusual anti-analysis behaviors. We dove into the most recent phishing campaign to identify the new anti-analysis routines designed to maneuver around behavioral analysis systems.
Diving In
Upatre’s new technique takes advantage of undocumented NtQuerySystemInformation structures. It attempts to call the ZwQuerySystemInformation API a few times to determine the idle time of the system. The ZwQuerySystemInformation API takes a SYSTEM_INFORMATION_CLASS as an argument for what to query. There are several options to query for, all with respective structures.
ZwQuerySystemInformation Function Specification
Upatre first calls ZwQuerySystemInformation querying for the SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION with a value of 0x0008.
SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION Struct
Screenshot Showing Upatre’s Anti-Analysis Technique in Assembly
The first call returns 0xC0000004 for STATUS_INFO_LENGTH_MISMATCH. On Windows 7 this successfully returns the size of the buffer required for the structure on the top of the stack. On Windows XP it returns 0 on the top of the stack for the ReturnLength. Upatre checks the ReturnLength by performing a shift-right by 2 and testing if the resulting value is 0.
Windows 7 returning the ReturnLength on the top of the stack
On Windows 7 Upatre calls ZwQuerySystemInformation again with the same SYSTEM_INFORMATION_CLASS 0x0008 and including the appropriate parameters to receive the structure into a buffer. If the function fails, Upatre exits.
Windows 7 Second Call to ZwQuerySystemInformation
Upatre then checks the second dword of the IdleTime to see if it is above 1 and if it is not, it exits. This value is the processor’s “total idle time, measured in units of 100-nanoseconds”[1] This check is designed to make sure that the system Upatre is running on has had a sufficient amount of idle time like a real system might have and not an analysis system.
Windows7 Comparing IdleTime to 1
On Windows XP Upatre uses a different SYSTEM_INFORMATION_CLASS for the second call. It queries for the SYSTEM_PERFORMANCE_INFORMATION with a value of 0x0002 and tests to make sure the API successfully completed. If it doesn’t complete, Upatre exits.
Upatre Querying ZwQuerySystemInformation for SYSTEM_PERFORMANCE_INFORMATION on WindowsXP
The SystemPerformanceInformation is an undocumented structure, but thanks to Matt Graeber’s research we can see that it holds the following information:
Snippet of SYSTEM_PERFORMANCE_INFORMATION Struct
Upatre checks the second dword of idleProcessTime to make sure that the IdleProcessTime is above 2.
Each of the techniques described above attempts to identify hosts which exhibit evidence of being part of a malware analysis system. WildFire, the Palo Alto Networks behavioral analysis system identifies these techniques and properly executes the malware to determine a malicious verdict.
Upatre continues to be distributed through mass phishing campaigns and relies heavily upon social engineering tactics to fool users into opening malicious attachments. Users should always be suspicious of all e-mail attachments, but especially those that they have received from senders they do not regularly communicate with.
November 16th Phishing Campaign: the subject and filename of this campaign were unique per recipient.
As we look toward 2016, I think there’s good reason to consider several shifts that we’ve seen in tactics used in recent attacks. Developments in several of these areas will play a significant role in mobile workforce security planning strategies for the year to come.
Inverting the Hierarchy of Policy Enforcement
While many organizations are primarily concerned with perimeter security: controlling what people on the outside can do to the organization, there’s still a lot of work to be done about the flip side of the equation: controlling what people on the inside can do to the organization. It is all too common to think of internal security as a matter of what can attach to the network, rather than asking the deeper questions of what those people and devices connected to the network should be able to do.
Twenty years ago, organizations relied on physical security to secure their network (no access unless you can get into the building). This notion started to crumble with wireless networking, in which authentication became the gating factor to control who was on the inside.
In both cases, however, these measures stop short of addressing the questions of what can a person or machine do once connected, and which applications can they access. This is particularly true when looking at the lifecycle of a cyberattack, where compromised endpoints are often employed to conduct lateral movement and exfiltrate information, all because many organizations do not have controls that inspect traffic inside the organization.
Network segmentation provides a part of the answer because compartmentalization can establish borders. However, while segmentation is a good first step, more needs to be done to control what traffic crosses the boundaries between segments.
These changes have been a long time coming, but, in 2016, I foresee significantly more emphasis on these issues, driven by the growing diversity of mobile devices in use. It has never been sufficient to simply allow or block devices from connecting. The next step is making sure we know what these devices are doing, and that’s going to take better enforcement of security policy inside the network.
Attacking the Person Behind the App
When taking a look at some of the attacks employed against mobile devices – such as recent iOS attacks like XcodeGhost and WireLurker – what’s interesting is that the techniques were far more nuanced than they might appear. Instead of just developing a piece of malware, the people behind these attacks customized the delivery system that would get the malware onto the mobile device.
In the case of WireLurker, it was a matter of infecting the owner’s laptop – hijacking the process for synchronizing and backing up the mobile phone’s content. The attacker was able to insert the malicious content into the host and transfer the app via USB onto the mobile device.
In the case of XcodeGhost, the attackers went up the food chain and attacked the app developers themselves by distributing a modified version of the coding tools for building iOS apps. The resulting apps had dormant functionalities inside them that were not immediately visible to either the developer or the end user.
Both attacks were capable of inserting malware into non-jailbroken mobile devices. This is possible because mobile devices do not exist on an island. They are always connected to an interface with a variety of systems, some of which they inherently trust. When attackers are capable of inserting themselves into, and abusing these trusts, new threat vectors emerge.
With this in mind, in 2016, security teams will need to think about what they need to protect (e.g., endpoint, network and mobile devices) in a blended effort, rather than counting on each one separately. This is because the intelligence and protection in one area serves as the compensating control for the other. If it’s unknown whether a mobile device is compromised, then securing network traffic serves as a compensating control to catch malicious behavior. If malicious command and control traffic emerges from an endpoint, then any such traffic from a mobile device should also be closely scrutinized.
Pushing the Boundaries of Gray
Categorically, there is a growing amount of software that isn’t so easily defined as being safe or malicious. These grayware applications fall between the lines because the software typically interacts with a third party, and that third party’s motivations, intent, and even identity may be unknown to the end user. At times, the end user may not know there’s a third party involved at all. One person’s remote desktop application is another person’s remote access tool.
The prevalence of grayware in mobile app stores has weighed toward adware, especially from third-party ad networks. These packages include functions that the end user (and the developer in many cases) does not know about. In the haste to use an app, a user may not scrutinize the permissions given, thus providing advertisers with access to a treasure trove of data. These ad networks slip into the realm of grayware because, even though they may have the permission to access the data, there is no guarantee that the data will be used in an ethical manner.
It’s my belief that more apps will use the cloudy edges of the grayware definition to slip in more malicious activity than advertising. Early signs of this activity can already be felt from the discovery of Gunpoder. When an app store evaluates an app for security risks, it is often done without the full view of the dynamics of how the functionality branches in the real world. In addition, without the context of threat intelligence, other clues about the activity conducted by the third party may not be clear. The only way to truly understand how an app operates is to see what it’s doing on the network in real world conditions when it’s being used, and that’s the role of network security.
Want to explore more of our top 2016 cybersecurity predictions? Register now for Ignite 2016.
While researching new, unknown threats collected by WildFire, we discovered the apparent re-emergence of a cyber espionage campaign thought to be dormant after its public disclosure in June 2013. The tools and tactics discovered, while not identical to the previous Dark Seoul campaign, showed extreme similarities in their functions, structure, and tools. In this post, we will provide an overview of the original Dark Seoul campaign in 2013, the similarities and differences in tactics, the malware used, as well as attempt to answer the question of ‘why now’?
Overview
In March 2013, the country of South Korea experienced a major cyberattack, affecting tens of thousands of computer systems in the financial and broadcasting industries. This attack was dubbed ‘Dark Seoul’; it involved wreaking havoc on affected systems by wiping their hard drives, in addition to seeking military intelligence.
The attack was initially thought to be attributed to North Korea, by way of a Chinese IP found during the attack, but no other strong evidence of North Korea’s involvement has been produced since then. In June 2013, McAfee published a report detailing the chronology and variance of the Dark Seoul campaign, but renamed it ‘Operation Troy’. The report analyzed the entirety of the purported attack campaign, beginning in 2009 using a family of tools dubbed ‘Troy’. McAfee further attributed two groups to the campaign: the NewRomanic Cyber Army Team and The Whois Hacking Team; both groups believed to be state sponsored. Since the publication of that report, no other activity involving either group or the tools have been detected or shared publically.
That is, until now.
Dark Seoul Returns
Using the Palo Alto Networks AutoFocus threat intelligence platform, we identified several samples of malicious code with behavior similar to the aforementioned Operation Troy campaign dating back to June 2015, over two years after the original attacks in South Korea. Session data revealed a live attack targeting the transportation and logistics sector in Europe. The initial attack was likely a spear-phishing email, which leveraged a trojanized version of a legitimate software installation executable hosted by a company in the industrial control systems sector. The modified executable still installs the legitimate video player software it claims to contain, but also infects the system. Based on deep analysis of the Trojan’s behavior, binary code, and previous reports of similar attacks, we have concluded that these samples were the same as the original tools used in the Dark Seoul/Operation Troy attacks. It is likely the same adversary group is involved, although there is currently insufficient data to confirm this conclusion.
Malware Overview
The malicious code was delivered via the following two executable names, packaged together in a zip archive file:
[redacted]Player_full.exe
[redacted]Player_light.exe
Both executables present themselves as legitimate installation programs offered by the industrial control systems organization, providing video player software for security camera solutions. When either sample was executed, the malware dropped and subsequently executed the actual video player it disguised itself as.
The new malware variant, which we call TDrop2, proceeds to select a legitimate Microsoft Windows executable in the system32 folder executes it, and then uses the legitimate executable’s process as a container for the malicious code, a technique known as process hollowing. Once successfully executed, the corresponding process then attempts to retrieve the second-stage payload.
The second-stage instruction attempts to obfuscate its activity by retrieving a payload that appears to be an image file, but upon further inspection appears actually to be a portable executable.
The C2 server replaces the first two bytes, which are normally ‘MZ’, with the characters ‘DW’, which may allow this C2 activity to evade rudimentary network security solutions and thus increase the success rate of retrieval.
Once downloaded, the dropper will replace the initial two bytes prior to executing it. This second stage payload will once again perform process hollowing against a randomly selected Windows executable located in the system32 folder. The overall workflow of this malware is visualized below:
The final payload provides the following capabilities to attackers:
Command
Description
1001
Modify C2 URLs
1003
Download
1013
Download/execute malware in other process
1018
Modify wait interval time
1025
Download/execute and return response
Default
Execute command and return results
These commands are encrypted/encoded when transferred over the network, as we can see below.
The malware uses an unidentified cryptographic routine for encryption. Additionally, the following custom alphabet is used for base64 encoding that takes place after the encryption of the data:
Once decoded and decrypted, we see the following command being provided:
tick 7880 systeminfo & net view & netstat -naop tcp & tasklist & dir /a “%userprofile%\AppData\Local\Microsoft\Outlook” & dir /a “%temp%\*.exe” & dir “%ProgramFiles%” & dir “%ProgramFiles%\Microsoft Office” 1018; 60
The initial ‘tick’ string is hardcoded and must be present for the malware to accept the subsequent command(s). In this case, the initial commands are used to perform basic reconnaissance on the infected host and return the results to the attacker, then initialize a sleep period of 60 seconds.
We will publish more details about the TDrop2 malware variant in a follow up blog.
Malware Similarities
Analysis of the malicious code identified reveals the distinct similarities in behavior and functionality to the original Dark Seoul/Operation Troy toolset.
The use of the custom base64 alphabet was observed in the following twelve samples that were specified within the Operation Troy whitepaper:
The majority of these samples had debug strings that referenced the ‘TDrop’ malware family, which is likely the predecessor to the malware observed in this campaign and the source of the name ‘TDrop2’.
The new variant also uses a distinct string decryption routine, which was also observed in a number of Operation Troy samples.
The same string decryption routine was also observed in 64-bit samples from the Operation Troy campaign. The following samples were found to have this decryption routine present:
Network communications appeared identical to that described in a Korean blog post written in June 2013 regarding what appears to be a partial analysis of the Dark Seoul attack. The behavior of the analyzed malicious code made references to decoding a PE file from both a .gif and .jpg URL. Additionally, a unique POST separator string is identified (6e8fad908fe13c), which also matches the malware payload observed in TDrop2 samples.
The command and control (C2) servers used in these recent attacks are compromised websites located in South Korea and Europe. It’s not clear what led to the compromise of these four web servers (listed in the IOC section below), but they all appear to use shared hosting providers and operate on out-of-date software that may contain vulnerabilities and/or misconfigurations.
The Attackers
At this time, it is unclear if this attack is attributed to the same two groups previously outlined in McAfee’s 2013 report. There are obvious similarities in the malware used, as well as other tactics, but there are also some obvious differences. The targeting for example, is completely different in that this observed attack is not aimed at military, government, or financial institutions in the South Korea region. In addition, there has been no evidence of destructive functionality in the samples analyzed by Unit 42, although the malware is capable of downloading additional components so those simply may not yet have been observed.
The similarities in tactics however, do seem to outweigh the differences, and it is highly likely this is the same group or groups responsible for the original Dark Seoul/Operation Troy attacks, but with a new target and a new campaign.
Conclusion
It is not uncommon for threat actors to become dormant for some period of time, especially after public unveiling as the groups behind Dark Seoul/Operation Troy experienced. What we do know is that changing infrastructure and toolsets can be challenging, and it is not nearly as common that a very specialized tool developed for specific teams would be shared amongst threat actors.
There is insufficient data at this time to clearly state why Dark Seoul/Operation Troy would resurface at this time, but Unit 42 will continue to monitor the activity as the situation develops.
We have created the AutoFocus tag TDrop2 to identify samples of this new variant and have added known C2 domains and hash values to the Threat Prevention product set. At this time, WildFire is able to correctly identify the samples associated with this campaign as malicious.
