One of the cool things I like about my job is hearing about what our customers do as a business and how they are using our products to improve their security posture. Unfortunately, due to the nature of corporate network security, these stories rarely get told publically, and even when they are, it’s rare we get to hear from the actual end user. That’s why I am excited about several of the sessions happening next week at VMworld that involve Palo Alto Networks and our partners and customers. I want to draw your attention to two in particular.
In the first session, Novamedia, the Dutch Postcode Lottery, will talk about how they are securing financial transactions measured in the millions of Euros using our VM-Series and VMware NSX. Now the cool thing here is what Novamedia does for a business, which is to generate and distribute funds to charities around the world.
From their CEO, Boudewijn Poelmann, “The opportunities for development are distributed unevenly throughout the world. Many people are threatened by hunger and disease and nature and the environment are hit hard by human activity. Fortunately, there are many non-profit organizations and people throughout the world who work to change this. They are worthy of our support and in need of funding and publicity for their work. It was from this perspective that the Nationale Postcode Loterij was launched in 1989.” (You can read more about Novamedia’s mission here.)
To attend the Novamedia session, look for the session titled How Novamedia protects their software Defined Datacenter with Palo Alto Networks (#SEC5452) on Tuesday from 3:30-4:30.
In the second session, Novamedia will compete with Telstra, Tribune Media and California Department of Water Resources for the title of Best Software Defined Data Center (SDDC) Project. In this case, the cool factor lies not only in the customer use cases but also the fact that the winner will be one of our customers. How can I say that with such confidence? All four of the Best SDDC competitors use our products to protect their network in one way or another. TheBest SDDC Project session happens on Monday from 4:30-5:30 (#SDDC6254-S).
Roughly two years ago when we first released virtualized version of our next-generation firewall, Lee Klarich, our SVP of Product Management, made the statement that our customers were embracing virtualization at a rapid pace and the VM-Series was going to help them solve their cloud security challenges. Next week, at VMworld you can hear how this is happening first hand. And that is wicked cool.
Unit 42 for the past three months has been tracking a banking Trojan targeting victims in Brazil and the United States. Escelar originally surfaced in January of this year, and has since had roughly 100,000 instances of attempted infections.
Attackers deliver the Trojan using generic Portuguese language phishing emails and are currently targeting seven Brazilian banks. Once delivered, Escelar has multiple installation stages where malware is downloaded using direct connections to multiple Microsoft SQL servers. These SQL servers are also used for command and control (C2) functionality.
The most recently discovered Microsoft SQL server being used as Escalar infrastructure contained records of 1660 infections that all connected in a two-day time frame.
The malware is able to control banking transactions conducted using Internet Explorer, and harvest email credentials, which are in turn used to spread the malware further.
Figure 1. AutoFocus map of victims receiving Escalar Trojan
Infection
Escelar is distributed almost exclusively through phishing emails. A large number of emails were originally seen in the January 2015 period, and more e-mails have continued coming since then at a somewhat slower rate.
Figure 2. Graph of sessions carrying Escalar each week in 2015
These emails are often labeled using the current date, and contain a generic message to entice the victim into running the attachment.
Figure 3. Example email containing Escelar
The following top file names have been observed in attempted infections against Palo Alto Networks customers. Many of them include resume/curriculum vitae themes using female names.
Name
Count
Curriclo_2015.exe
10227
Curriculum_Vitae_Bruna.exe
9110
Curriculum_Fernanda _Paiva.exe
6310
Curriculum_Izadora.exe
4242
Curriclo_Ana_Caroline2015.exe
2435
Seg-via-Boleto.exe
1880
Imprimir_2015.exe
1556
Curriculum_Laura.exe
1547
Curriculu_VItae-2015.exe
1453
Currculo_2015.exe
1428
Escalar Execution – Stage 1
After the victim unzips and executes the attached file, an executable written in .NET will be run. These executables are often obfuscated to thwart reverse engineers and any security controls that may be in place on the victim’s machine.
Important string names within Escelar samples are obfuscated using various cryptographic libraries. We have identified samples using both RijndaelEnhance and TripleDES.
Figure 4. Cryptographic function contained in Escelar
Figure 5. Encrypted string and decrypted version stored as a comment
This executable has limited functionality, and is only responsible for downloading an additional executable and establishing persistence via the Run registry key.
It begins by generating a random path of 8 alphabetic characters in the %APPDATA% directory. An executable name of 15 random alphabetic characters will hold to a soon-to-be-downloaded file. Escelar then makes a direct connection to a remote Microsoft SQL server and downloads a raw binary file to this local location.
Figure 6. Microsoft SQL connection
Figure 7. Acquiring raw binary image from Microsoft SQL server
Figure 8. Raw binary image
After this file successfully downloads, the following registry key is written to ensure persistence across reboots.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run [Computer Name] : [Path to Executable]
Finally, the downloaded malware is executed via a call to Interaction.Shell().
Escelar Execution – Stage 2
The second stage of the Escelar malware family shares many characteristics with the first stage. Both samples make use of direct Microsoft SQL connections, as well as encryption of important strings within the binary. They’re also both written in .NET and are often obfuscated.
This sample is once again another downloader, grabbing a raw binary image from a remote Microsoft SQL server and storing it to the following path:
Finally, the malware is executed via a call to Interaction.Shell().
Escelar Execution – Stage 3
The third stage of the malware contains the banking Trojan itself. Once again this binary is written in .NET and makes direct connections to Microsoft SQL servers. It begins by droppingJCS.Components.NeroBar.dll in the Startup folder. This DLL is used to generate progress bars and is used when the attacker chooses to generate a ‘blocker’ on the victim’s banking webpage, which we discuss later in this section.
The malware proceeds to identify the following DLLs, which are used by various Brazilian banks to prevent malicious activity. The identifier is stored in the Microsoft SQL database in order to alert the attacker as to what plugins are installed.
File
Identifier
%ProgramFiles%\\GbPlugin\\gbieh.dll
B.B
%ProgramFiles%\\GbPlugin\\gbiehcef.dll
C.E.F
%ProgramFiles%\\GbPlugin\\gbiehuni.dll
I.T.A
%ProgramFiles%\\GbPlugin\\gbiehabn.dll
S.A.N.T.A
%ProgramFiles%\\GbPlugin\\gbiehscd.dll
S.I.C.R.E.D
%ProgramFiles%\\Scpad\\scpLIB.dll
B.R.A.D.A
The IdPC identifier in the following image is made up of the following data.
Computer Name
Processor ID
HD Serial
Physical Memory
Virtual Memory
Figure 10. Victim infections of Escelar listed in the Database
The malware monitors the victim’s browser activity. In the event they user attempts to navigate to one of the following Brazilian banking websites, the malware takes action.
Should the victim try to open any of these banking websites in a browser other than Internet Explorer, the malware will generate a false error, close the current browser, and re-open the link in Internet Explorer.
Figure 11. False error displayed to the victim when viewing a targeted page in Google Chrome
The attacker has the ability to send a number of different commands in the ‘fun’ column of the Microsoft SQL server.
Figure 12. Commands being sent to victims
Escalar can accept the commands show below (with their translations).
Command
Translation
xclick
click
xclick2
click 2
xtexto
text
xtextopost
text post
xtexto2
text 2
xtextopost2
text post 2
xtexto3
text 3
xtextopost3
text post 3
xmultiplotexto
multiple text
xBloq
locked
xdesbloq
unlocked
xAss1
unknown
xAss2
unknown
xreiniciar
reset
xapagartexto
delete text
xsetacima
up arrow
xsetabaixo
down arrow
xtab
tab
xtab2
tab 2
xcenter
center
xcenter2
center 2
xfecharie
ie close
xsenhacert
cert password
xtoken
token
xcelular
cell
These commands allow the attacker to manipulate a victim’s banking web session and perform fraudulent transactions among other functions.
The following screenshot shows an image that is used by the malware in order to trick victims into entering the unique authentication code sent by banks to the victim’s cellular telephone. This data is uploaded to the attackers in order to conduct fraudulent transactions.
Figure 13. Escelar tricking a victim into entering the authentication code sent to their cell phone
The following screenshot shows examples of an attacker blocking a victim’s banking web session in Internet Explorer.
Figure 14. Blocking of victim’s banking web session
These pages are specific to the bank the victim is using, as we can see in the following second example.
Figure 15. Blocking of victim’s banking web session
E-mail Harvesting and Spreading
Escelar includes a component that is responsible for harvesting credentials from the following web services.
Gmail
Hotmail
Webmail (any website containing the string “webmail” in the URL)
These credentials are stored in a remote Microsoft SQL server. The harvested email credentials are then used by the attackers to send additional e-mails containing Escelar. The total sum of emails in the database displayed below indicated that 3,057 emails had been sent from these addresses. The SQL server keeps track of the number of emails sent by each email address.
Figure 16. Table containing email addresses and tallies of spam emails sent
By harvesting email credentials from Escelar victims, the malware authors are able to further propagate Escelar in the event a portion of the email senders are blocked.
Conclusion
The Escelar threat has been active for approximately seven months, targeting primarily Brazil- and US-based users. We have collected over 600 variants of to date, with roughly 100,000 attempted infections. The malware provides the attacker with multiple capabilities, including the ability to harvest email credentials and manipulate banking transaction sessions. Additionally, due to the way the malware is architected, it can easily update itself, along with the infrastructure supporting it.
Users located in Brazil and the United States that use Brazilian banking services should be aware of this threat and take necessary precautions against it, such as ensuring that suspicious emails are not opened.
Palo Alto Networks customers who are using the WildFire service are protected against this threat. Users who are using Traps with WildFire integration are protected as well. Organizations should monitor their networks for unexpected outbound Microsoft SQL traffic (App-ID mssql) that may indicate an Escalar infection.
For a list of SHA256 hashes of identified instances of Escelar and identified Microsoft SQL server domains being used by Escelar, please refer to this link.
Managing financial information is a dangerous business, and the past year has been marked by a number of significant data breaches. Large companies with the money and power to best protect credit information, such as Target, Home Depot, and Urban Outfitters, have all been affected, leaving smaller companies with less robust security infrastructure feeling like a breach is bound to occur, posing a risk to their customers.
Financial data management does not need to be this stressful. Many of these smaller businesses, however, rely on third-party companies to perform their payment processing and data management, further complicating risk assessment. Here are some issues to consider when dealing with external payment management for your business.
Keeping Networks Separate
One of the greatest problems that data security professionals are encountering today is that networks and servers are increasingly interlinked. These connections make outside infiltration easier than ever, as the links between the private and the public become more numerous. Information thieves are now just a link away from confidential information.
Your payment management company is responsible for making sure that these kinds of connections are minimized, and that those links that do exist are appropriately protected. Ask your third-party provider how they handle network privacy. This includes asking questions about employees’ use of mobile technology in the workplace that could pose a security issue.
Assessing Public Relations
A look at your digital security management company’s public relations (PR) practices could prove very revealing. How does the PR branch of the company talk about security breaches? For many PR offices, any information breach affecting fewer than 10 million people is small. If this kind of minimizing is happening on a regular basis, you may want to turn to a different company to handle your customers’ data.
Categories Are Valuable
Running a business means balancing an array of concerns and connections. So, while you should be extra concerned about the security procedures of any company handling sensitive information, there are other factors to be considered. One system for managing security issues is to rank different companies by risk level. What kind of data are they handling and what is their reputation? Companies with greater risk can be placed under more significant observation and should have their practices audited more frequently.
Reconsider Vulnerability Management
Does your third-party payment manager use an automated vulnerability management system to protect their data? As Gordon Mackay points out, these systems can lull companies into a false sense of security and can be an unwise use of resources. Steer clear of companies using these systems in favor of those that take a more active approach to handling data. Poorly functioning vulnerability management software has been behind a number of breaches, making it far more costly than most realize.
Pay Attention to Staffing
There is a serious shortage of great Internet and data security professionals on the market today. Does the external company doing your payment management employ enough of the best minds out there? And does your third-party company do appropriate background checks on those employees? It is important that you do not just have a single link with a company representative, but rather that you understand the larger atmosphere of the company. Know who is handling your data.
While third-party payment management is often the best solution for small businesses, that does not mean you can take a backseat and leave the whole project up to them. Business owners should always be proactive in their relationships with any company handling sensitive information. Be vigilant about breaches and take responsibility for your data, even when it is not in your hands.
Unit 42 researchers have observed a new Remote Access Tool (RAT) constructed by an unknown actor of Italian origin. This RAT, referred to as uWarrior because of embedded PDB strings, has been previously described by an independent researcher who noted a potentially unknown exploit being used against Microsoft Office.
Initial research into the exploit by Unit 42 indicates that this actor has opted to include multiple exploits. One is CVE-2012-1856, reinvigorated with a novel ROP chain to bypass ASLR and deliver the uWarrior payload. The other appears to be CVE-2015-1770. The malware itself is a fully featured RAT, which uses a compressed, (optionally) encrypted, raw TCP socket and binary message protocol for command and control communications.
During the course of our research, it became evident that this actor had not built uWarrior from scratch, but rather opted to borrow components from several off-the-shelf tools. Linkages between older RATs are explored later in this blog.
RTF Exploitation and ASLR Bypass
The weaponized RTF document used by this actor contains multiple OLE objects. In this instance, we see two different exploits, as well as two methods of bypassing ASLR exploit mitigations. The first method was published in 2014 by Parvez Anwar. The method he describes involves creating an embedded OLE object which contains a ProgID for “otkloadr.WRAssembly.1”. This causes MSVCR71.DLL to be loaded, a library which is not compiled with /DYNAMICBASE.
When using OLE to perform exploitation, ActiveX objects can be used to cite specific CLSID values. This is useful to an attacker as many of these CLSID values map to DLLs on the system. Attackers can deliberately use this to load any DLL they desire into the affected application so long as it maps to a valid CLSID.
This method was actually described at Black Hat USA 2015 in the talk: “Attacking Interoperability: An OLE Edition” by researchers Haifei Li and Bing Sun of Intel Security.
As a result of this method, it is possible for the attacker to force the loading of less secure libraries which were not compiled with the /DYNAMICBASE compiler flag (enables ASLR at compile time), or other libraries which further enable the corruption and manipulation of memory.
From the RTF document, we can use oletools to extract each OLE object. Thus far, we have encountered two weaponized RTF documents.
Interestingly, both documents contained identical OLE objects:
Once carved and unzipped, we can see a small directory structure. Within the word/activex directory, we can see ActiveX binaries, as well as XML documents associated with them. The XML files themselves are mostly identical; duplicates of only two particularly unique ones. The contents of these two files are as follows:
From this we can see that ActiveX objects are calling specific CLSIDs. From this, two relatively known exploits can likely be identified, based on both payloads, and the CLSIDs used.
CLSID
Target Component
Patch
Associated Vulnerability
1EFB6596-857C-11D1-B16A-00C0F0283628
MSCOMCTL TabStrip control
MS12-060
CVE-2012-1856
CDDBCC7C-BE18-4A58-9CBF-D62A012272CE
OSF.DLL (memory corruption in ActiveX use cases)
MS15-059
CVE-2015-1770
As a result of MSVCR71 being loaded via Parvez Anwar’s method, it would appear that exploitation of CVE-2012-1856 could be re-invigorated by the use of ROP gadgets (now with non-randomized gadget addresses) located within its address space, making a VirtualProtect() call and stage 2 shellcode trivial. At this time it is unclear whether the original patch was designed to correct memory mismanagement of the affected TabStrip control, or if the components to load it were simply changed to operate with ASLR enabled to limit the vectors of introducing arbitrary code. At any rate, the ActiveX binary from OLE object 0x000000E6 has the following approximate structure:
1
2
3
4
5
[WordDocument Header]
[HeapSpray of address0x7c342404(aRET instruction)]
[ROP Chain of gadgets inside the MSVCR71 address space]
[NOP Sled]
[Stage1shellcode]
Figure 1: We can see the end of the RET heap spray leading into a ROP chain and stage 1 shellcode
Keeping in mind that (of course) the addresses are backwards due to little endian byte ordering, we can observe the following ROP chain after the ret gadget 0x7c342404, and prior to actual shellcode:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
7C3651EB
7C3651EB
7C372B02
00000201
7C344364
00000040
7C35A128
7C342E9E
7C34A40F
7C3650DC
7C3415A3
7C347F97
7C37A151
7C378C4D
7C345C30
In the OLE object 0x0002802C, there are more XML files containing the CVE-2012-1856 CLSID, however 2 files (activeX39.xml and activeX40.xml), contain the CLSID for CVE-2015-1770, which does in fact, cause OSF.DLL to load. Examining the ActiveX binary reveals a not-too-dissimilar structure to the first one:
1
2
3
4
[WordDocument Header]
[HeapSpray of0xCCbyte]
[series of0x08and0x41marker bytes]
[stage1shellcode]
Figure 2: We can observe the end of the 0xCC heap spray, the 0x08 and 0x41 memory markers as well as stage 1 code here.
Stage 2 shellcode in both cases is decoded and inserted from memory (rather than statically included in a file) and triggers a download of the uWarrior RAT itself. When executing this payload on systems with 64-bit version of Office, things may not quite go as the author intended. For example, on 64-bit systems, msvcr71.dll is part of the SysWOW64 libraries and not available in the Office15 native add-ons folder. Instead, MSVCR100.dll is loaded for those calls and the 64-bit edition of otkloadr.WRAssembly.1 is loaded as well. Furthermore this breaks many of the hard-coded addresses and ROP gadgets, landing at the following error:
The address 0x7c38bd50 is a reference back into the aforementioned, msvcr71 library which is not in memory.
It is important to note that analysis of the exploitation itself is on-going and many researchers around the industry have suggested differing vulnerabilities as a root cause; however, conclusive evidence is lacking and the combination of methods and affected code is both new and complex.
uWarrior Malware Analysis
After successful exploitation, a payload is saved to the system at “%AppData%\Roaming\TEST\WindowsUpdate.exe” and executed. The WindowsUpdate.exe application contains several artifacts that suggest that the malware author calls this Trojan uWarrior, one of which is the following debugging symbol path found in the sample:
uWarrior begins by copying itself to a second location, which in this case was “%AppData%\Local\svchost.exe” and saves the path to this copied executable within the following file:
%AppData%\Roaming\warriors.dat
During execution, uWarrior logs its activities to a file located at “%AppData%\Local\Temp\bootloader.dec”, however, our team is aware of other uWarrior samples saving their logs to “C:\bootloader.dec” instead. We found that uWarrior has a configuration that follows the structure:
1
2
3
4
5
6
7
8
9
10
structsettings{
stringHost;
shortPort;
stringID;
boolStartup;
boolBlueScreenOnTermination;
stringGUID;
stringStartupPath;
boolSaveExePath;
};
The settings structure found in this sample of uWarrior has the domain “login.collegefan.org” set as the C2 host, and 2020 for the communications port. When communicating with the C2 server, the uWarrior Trojan uses AES to encrypt the data sent to the C2, using the key and initialization vector (IV) seen in Figure 3.
uWarrior will receive commands from the C2 using this communication channel and will process the commands using a command handler.
Figure 3 AES Encryption Key and IV used by uWarrior
The C2 will send numerical values that the uWarrior Trojan will parse to determine which command to carry out. Fortunately, the author of uWarrior included an enumeration (a data type in programming that maps a constant value to a defined name), which applies a human-readable string to each command’s numerical value. This enumeration makes analyzing the commands available within the malware much easier. The functionality within many of the commands are handled by a helper DLL that the uWarrior will extract from its resource section named Windows_Update.UtilityWarrior.dll and load.
Unit 42 analyzed the command handler to determine uWarrior’s capabilities and found the following commands available:
EnumValue
Command
Description
10
Handshake
Instructs the Trojan to use a new key and initialization vector (IV) to encrypt network communications. The Trojan will then creates a thread that it will use in an attempt to establish communications using the new key.
14
ShutdownClient
Exits the current instance of the Trojan.
15
RestartClient
Restarts the Trojan and exits the current instance of the Trojan.
16
UninstallClient
Creates a batch script with a temporary filename that deletes the Trojan and then the batch script. The script contains the following::Repeat:DEL \”<executable path>\”if exists \”<executable path>\” goto RepeatDEL \”<batch script path>\””One interesting thing to note is that there is a flag called “BlueScreenOnTermination”, which if set in the configuration will set the Trojan’s process to be system critical by calling the SetProcessIsCritical function. After the batch script deletes the files, the Trojan exits itself and causes a Windows error due to the fact the process was system critical.
17
RestartPC
Restarts the system using the command line “shutdown.exe -r -f”.
18
ClosePC
Shuts down the system using the command line “shutdown.exe -p -f”.
19
GetSoftware
Handled by the helper DLL, which opens a specified registry key in the HKLM hive and enumerates its sub keys looking for “DisplayName” and gathers all software packages that do not have “Hotfix”, “Security Update” or “Update for” within their “DisplayName”. It responds to the C2 with a list of software packages delimited by the string “|A|”.
21
unistallSoftware
Handled by the helper DLL, which enumerates the “Software\Microsoft\Windows\CurrentVersion\Uninstall” registry key looking for the software package provided with the command and will uninstall it. It responds to the C2 with “Unistall is running” if successful or the exception if it fails.
22
GetDriver
Handled by the helper DLL, which enumerates the mounted storage devices, their total size and the available space left on them. The command concatenates this information into the following structure and sends it to the C2: “<drive number>|H|<drive’s total size>/<drive’s available space>|Q|”. For systems with multiple mounted storage volumes, the command will concatenate the additional data following the same structure above.
23
GetFiles
Handled by the helper DLL, which lists the contents of a directory of a provided path. Each folder in the directory are added to a string, which is sent to the C2 in the a format of “<folder name>|G|Floader|G||G|<provided path>|H|”. Each file in the directory are added to a string that is sent to the C2 in the format of “<filename>|G|<file extension>|G|<file size>|G|<provided path>|H|”.
24
SearchFolder
Searches the filesystem for a specified folder. If it finds the folder, the Trojan will enumerate its contents using the same code as the “GetFiles” command.
25
RunFile
Starts a process using a specified file. Does not respond to the C2 with any messages.
26
DeleteFile
Deletes a specified file. If the command has “E” switch provided, it will delete a specified directory and all of its contents.
27
RenameFile
Renames a specified file. If the command has “A” switch provided, it will rename a specified directory.
28
DownloadTCP
Reads a specified file and sends it to the C2 server.
29
UploadTCP
Writes data provided by the C2 to a specified file.
30
DownloadURL
Downloads a file from a specified URL. The C2 will provide the URL to download from in the format “<domain or IP>|A|<filename>|A|<file extension>|A|<path/URL>”.
31
RefreshLog
Sends the contents of the log file at “C:\bootloader.dec” to the C2 server.
32
ClearLog
Deletes the log file at “C:\bootloader.dec” from the system.
36
MonitorCounts
Uses the GetSystemMetrics API function to determine how many monitors are connected to the system.
37
PcBounds
Sends the height and width of a specified monitor to the C2.
38
ShortLinkFolder
Lists the contents of a special folder based on a value between 1 and 4: 1) Lists Desktop 2) Lists %TEMP% folder 3) Lists Cookies Folder 4) Lists My Documents folder
Some of the values within the previously mentioned enumeration are not within the command handler. Unit 42 found only two of these specific values and found in the malware, specifically “Pipe” and “Status”, which were used in network communications to designate the type of response the Trojan was sending to the C2. It does not appear that uWarrior uses the “Plugin”, “ErSoftware”, “RemoteDesktop”, “UnblockEverything”, “BlockEverything” values from within the enumeration, suggesting that the malware author did not remove these values from the enumeration even though their functionality was removed from the Trojan.
No Honor Amongst Thieves
Unit 42 researchers’ examination of uWarrior has led to the discovery of suspected progenitor samples. These samples, identified as the for-sale ctOS RAT, contain similar configuration structures and share several functions with uWarrior samples. The ctOS RAT contains a significant amount of functionality compared to the uWarrior command set, suggesting that uWarrior could be a stripped down alternative.
uWarrior’s configuration contains all of the same fields as ctOS, as well as an additional field (bool_2 in GStruct2 stucture in Figure 4), used to toggle whether “warrior.dat” should be utilized to store the path on the file system to the executable. Samples of both RATs contain a GUID field (string_2 fields in Figure 4), “TEST”, which is used to define the path where the executable will be dropped.
Figure 4 Comparison of uWarrior (GStruct2) and ctOS (Struct4) Configurations
In addition to sharing similar configurations, it appears that the uWarrior author borrowed code from the ctOS RAT. uWarrior’s helper DLL (used to handle several of uWarriors functionality) has two functions that directly overlap with functions from ctOS source code, specifically one that gets the size of a specified file and the second that enumerates the mounted storage volumes.
Static analysis of ctOS and uWarrior samples reveals Italian language strings. These Italian strings are part of PDB paths and are prevalent throughout .net manifest data. This lends additional strength to the linkage between ctOS and uWarrior, as the former’s control panel demos are also in Italian.
Palo Alto Networks WildFire identifies the exploit files and malware used in these attacks as malicious. Palo Alto Networks AutoFocus users can view the analysis related to these files using the uWarrior tag.