Sofacy Uses DealersChoice to Target European Government Agency .


Back in October 2016 , Unit 42 published an initial analysis on a Flash exploitation framework used by the Sofacy threat group called DealersChoice .


The attack consisted of Microsoft Word delivery documents that contained Adobe Flash objects capable of loading additional malicious Flash objects embedded in the file or directly provided by a command and control server .


Sofacy continued to use DealersChoice throughout the fall of 2016 , which we also documented in our December 2016 publication discussing Sofacy ’s larger campaign .


On March 12 and March 14 , we observed the Sofacy group carrying out an attack on a European government agency involving an updated variant of DealersChoice .


The updated DealersChoice documents used a similar process to obtain a malicious Flash object from a C2 server , but the inner mechanics of the Flash object contained significant differences in comparison to the original samples we analyzed .


One of the differences was a particularly clever evasion technique : to our knowledge this has never been observed in use .


With the previous iterations of DealersChoice samples , the Flash object would immediately load and begin malicious tasks .


In the March attacks , the Flash object is only loaded if the user scrolls through the entire content of the delivery document and views the specific page the Flash object is embedded on .


Also , DealersChoice requires multiple interactions with an active C2 server to successfully exploit an end system .


The overall process to result in a successful exploitation is :


User must open the Microsoft Word email attachment ;


User must scroll to page three of the document , which will run the DealersChoice Flash object ;


The Flash object must contact an active C2 server to download an additional Flash object containing exploit code ;


The initial Flash object must contact the same C2 server to download a secondary payload ;


Victim host must have a vulnerable version of Flash installed .


The attack involving this updated variant of DealersChoice was targeting a European government organization .


The attack relied on a spear-phishing email with a subject of “ Defence & Security 2018 Conference Agenda ” that had an attachment with a filename of “ Defence&Security_2018_Conference_Agenda.docx ” .


The attached document contains a conference agenda that the Sofacy group appears to have copied directly from the website for the “ Underwater Defence & Security 2018 Conference ” here .


Opening the attached “ Defence & Security 2018 Conference Agenda.docx ” file does not immediately run malicious code to exploit the system .


Instead , the user must scroll to the third page of the document , which will load a Flash object that contains ActionScript that will attempt to exploit the user ’s system to install a malicious payload .


The Flash object embedded within this delivery document is a variant of an exploit tool that we call DealersChoice .


This suggests that the Sofacy group is confident that the targeted individuals would be interested enough in the content to peruse through it .


We analyzed the document to determine the reason that the malicious Flash object only ran when the user scrolled to the third page .


According to the document.xml file , the DealersChoice loader SWF exists after the “ covert-shores-small.png ” image file within the delivery document .


This image file exists on the third page of the document , so the user would have to scroll down in the document to this third page to get the SWF file to run .


The user may not notice the Flash object on the page , as Word displays it as a tiny black box in the document , as seen in Figure 1 .


This is an interesting anti-sandbox technique , as it requires human interaction prior to the document exhibiting any malicious activity .


This DealersChoice Flash object shares a similar process to previous variants ; however , it appears that the Sofacy actors have made slight changes to its internal code .


Also , it appears that the actors used ActionScript from an open source video player called “ f4player ” , which is freely available on GitHub .


The Sofacy developer modified the f4player ’s ActionScript to include additional code to load an embedded Flash object .


The additions include code to decrypt an embedded Flash object and an event handler that calls a newly added function ( “ skinEvent2 ” ) that plays the decrypted object .


The above code allows DealersChoice to load a second SWF object , specifically loading it with an argument that includes a C2 URL of “ http://ndpmedia24.com/0pq6m4f.m3u8 ” .


The embedded SWF extracts the domain from the C2 URL passed to it and uses it to craft a URL to get the server ’s ‘ crossdomain.xml ’ file in order to obtain permissions to load additional Flash objects from the C2 domain .


The ActionScript relies on event listeners to call specific functions when the event “ Event.COMPLETE ” is triggered after successful HTTP requests are issued to the C2 server .


The event handlers call functions with the following names , which includes an incrementing number that represents the order in which the functions are called : onload1 , onload2 , onload3 , onload5 .


With these event handlers created , the ActionScript starts by gathering system data from the flash.system.Capabilities.serverString property ( just like in the original DealersChoice.B samples ) and issues an HTTP GET with the system data as a parameter to the C2 URL that was passed as an argument to the embedded SWF when it was initially loaded .


When this HTTP request completes , the event listener will call the ‘ onload1 ’ function .


The ‘ onload1 ’ function parses the response data from the request to the C2 URL using regular expressions .


The regular expressions suggest that the C2 server responds with content that is meant to resemble HTTP Live Steaming ( HLS ) traffic , which is a protocol that uses HTTP to deliver audio and video files for streaming .


The use of HLS coincides with the use of ActionScript code from the f4player to make the traffic seem legitimate .


The variables storing the results of the regular expression matches are used within the ActionScript for further interaction with the C2 server .


The ‘ onload1 ’ function then sends an HTTP GET request to the C2 domain using the value stored in the ‘ r3 ’ variable as a URL .


When this HTTP request completes , the event listener will call the ‘ onload2 ’ function .


The ‘ onload2 ’ function decrypts the response received from the HTTP request issued in ‘ onload1 ’ function .


It does so by calling a sub-function to decrypt the content , using the value stored in the ‘ r1 ’ variable as a key .


The sub-function to decrypt the content skips the first 4 bytes , suggesting that the first four bytes of the downloaded content is in cleartext ( most likely the “ FWS ” or “ CWS ” header to look legitimate ) .


After decrypting the content , the ‘ onload2 ’ function will issue another HTTP GET request with the system data as a parameter , but this time to the C2 using a URL from the ‘ r4 ’ variable .


When this request completes , the event listener will call the ‘ onload3 ’ function .


The ‘ onload3 ’ function will take the response to the HTTP request in ‘ onload2 ’ and treat it as the payload .


The ActionScript will read each byte of the C2 response and get the hexadecimal value .


This hexadecimal string will most likely be a string of shellcode that will contain and decrypt the ultimate portable executable ( PE ) payload .


The string of comma separated hexadecimal values is passed as a parameter when loading the SWF file downloaded in ‘ onload2 ’ .


This function creates an event listener for when the SWF file is successfully loaded , which will call the ‘ onload5 ’ function .


The ‘ onload5 ’ function is responsible for adding the newly loaded SWF object as a child object .


This loads the SWF file , effectively running the malicious code on the system .


During our analysis , we were unable to coerce the C2 into providing a malicious SWF or payload .


As mentioned in our previous blogs on DealersChoice , the payload of choice for previous variants was SofacyCarberp ( Seduploader ) , but we have no evidence to suggest this tool was used in this attack .


We are actively researching and will update this blog in the event we discover the malicious Flash object and payload delivered in this attack .


The delivery document used in this attack was last modified by a user named ‘ Nick Daemoji ’ , which provides a linkage to previous Sofacy related delivery documents .


The previous documents that used this user name were macro-laden delivery documents that installed SofacyCarberp S-MAL/Seduploader payloads , as discussed in Talos ’ blog .


This overlap also points to a similar social engineering theme between these two campaigns , as both used content from upcoming military and defense conferences as a lure .


The Sofacy threat group continues to use their DealersChoice framework to exploit Flash vulnerabilities in their attack campaigns .


In the most recent variant , Sofacy modified the internals of the malicious scripts , but continues to follow the same process used by previous variants by obtaining a malicious Flash object and payload directly from the C2 server .


Unlike previous samples , this DealersChoice used a DOCX delivery document that required the user to scroll through the document to trigger the malicious Flash object .


DealersChoice :


0cd9ac328d858d8d83c9eb73bfdc59a958873b3d71b24c888d7408d9512a41d7 ( Defence&Security_2018_Conference_Agenda.docx ) ndpmedia24.com .


Corporate IoT – a path to intrusion .


Several sources estimate that by the year 2020 some 50 billion IoT devices will be deployed worldwide .


IoT devices are purposefully designed to connect to a network and many are simply connected to the internet with little management or oversight .


Such devices still must be identifiable , maintained , and monitored by security teams , especially in large complex enterprises .


Some IoT devices may even communicate basic telemetry back to the device manufacturer or have means to receive software updates .


In most cases however , the customers ’ IT operation center don’t know they exist on the network .


In 2016 , the Mirai botnet was discovered by the malware research group MalwareMustDie .


The botnet initially consisted of IP cameras and basic home routers , two types of IoT devices commonly found in the household .


As more variants of Mirai emerged , so did the list IoT devices it was targeting .


The source code for the malware powering this botnet was eventually leaked online .


In 2018 , hundreds of thousands of home and small business networking and storage devices were compromised and loaded with the so-called “ VPN Filter ” malware .


The FBI has publicly attributed this activity to a nation-state actor and took subsequent actions to disrupt this botnet , although the devices would remain vulnerable to re-infection unless proper firmware or security controls were put in place by the user .


There were also multiple press reports of cyber-attacks on several devices during the opening ceremonies for the 2018 Olympic Games in PyeongChang .


Officials did confirm a few days later that they were a victim of malicious cyber-attacks that prevented attendees from printing their tickets to the Games and televisions and internet access in the main press center simply stopped working .


In April , security researchers in the Microsoft Threat Intelligence Center discovered infrastructure of a known adversary communicating to several external devices .


Further research uncovered attempts by the actor to compromise popular IoT devices ( a VOIP phone , an office printer , and a video decoder ) across multiple customer locations .


The investigation uncovered that an actor had used these devices to gain initial access to corporate networks .


In two of the cases , the passwords for the devices were deployed without changing the default manufacturer ’s passwords and in the third instance the latest security update had not been applied to the device .


These devices became points of ingress from which the actor established a presence on the network and continued looking for further access .


Once the actor had successfully established access to the network , a simple network scan to look for other insecure devices allowed them to discover and move across the network in search of higher-privileged accounts that would grant access to higher-value data .


After gaining access to each of the IoT devices , the actor ran tcpdump to sniff network traffic on local subnets .


They were also seen enumerating administrative groups to attempt further exploitation .


As the actor moved from one device to another , they would drop a simple shell script to establish persistence on the network which allowed extended access to continue hunting .


Analysis of network traffic showed the devices were also communicating with an external command and control ( C2 ) server .


The following IP addresses are believed to have been used by the actor for command and control ( C2 ) during these intrusions :


167.114.153.55 94.237.37.28 82.118.242.171 31.220.61.251 128.199.199.187 .


We attribute the attacks on these customers using three popular IoT devices to an activity group that Microsoft refers to as STRONTIUM .


Since we identified these attacks in the early stages , we have not been able to conclusively determine what STRONTIUM ’s ultimate objectives were in these intrusions .


Over the last twelve months , Microsoft has delivered nearly 1400 nation-state notifications to those who have been targeted or compromised by STRONTIUM .


One in five notifications of STRONTIUM activity were tied to attacks against non-governmental organizations , think tanks , or politically affiliated organizations around the world .


The remaining 80% of STRONTIUM attacks have largely targeted organizations in the following sectors : government , IT , military , defense , medicine , education , and engineering .


We have also observed and notified STRONTIUM attacks against Olympic organizing committees , anti-doping agencies , and the hospitality industry .


The “ VPN Filter ” malware has also been attributed to STRONTIUM by the FBI .


Today we are sharing this information to raise awareness of these risks across the industry and calling for better enterprise integration of IoT devices , particularly the ability to monitor IoT device telemetry within enterprise networks .


Today , the number of deployed IoT devices outnumber the population of personal computers and mobile phones , combined .


With each networked IoT device having its own separate network stack , it ’s quite easy to see the need for better enterprise management , especially in today ’s “ bring your own device ” world .


While much of the industry focuses on the threats of hardware implants , we can see in this example that adversaries are happy to exploit simpler configuration and security issues to achieve their objectives .


These simple attacks taking advantage of weak device management are likely to expand as more IoT devices are deployed in corporate environments .


Upon conclusion of our investigation , we shared this information with the manufacturers of the specific devices involved and they have used this event to explore new protections in their products .


However , there is a need for broader focus across IoT in general , both from security teams at organizations that need to be more aware of these types of threats , as well as from IoT device makers who need to provide better enterprise support and monitoring capabilities to make it easier for security teams to defend their networks .


Below are a series of indicators Microsoft has observed as active during the STRONTIUM activity discussed in this article .


Command-and-Control ( C2 ) IP addresses :


167.114.153.55 94.237.37.28 82.118.242.171 31.220.61.251 128.199.199.187 .


Operation RussianDoll : Adobe & Windows Zero-Day Exploits Likely Leveraged by Russia ’s APT28 in Highly-Targeted Attack .


FireEye Labs recently detected a limited APT campaign exploiting zero-day vulnerabilities in Adobe Flash and a brand-new one in Microsoft Windows .


Using the Dynamic Threat Intelligence Cloud ( DTI ) , FireEye researchers detected a pattern of attacks beginning on April 13th , 2015 .


Adobe independently patched the vulnerability ( CVE-2015-3043 ) in APSB15-06 .


Through correlation of technical indicators and command and control infrastructure , FireEye assess that APT28 is probably responsible for this activity .


Microsoft is aware of the outstanding local privilege escalation vulnerability in Windows ( CVE-2015-1701 ) .


While there is not yet a patch available for the Windows vulnerability , updating Adobe Flash to the latest version will render this in-the-wild exploit innocuous .


We have only seen CVE-2015-1701 in use in conjunction with the Adobe Flash exploit for CVE-2015-3043 .


The Microsoft Security Team is working on a fix for CVE-2015-1701 .


The high level flow of the exploit is as follows :


User clicks link to attacker controlled website .


HTML/JS launcher page serves Flash exploit .


Flash exploit triggers CVE-2015-3043 , executes shellcode .


Shellcode downloads and runs executable payload .


Executable payload exploits local privilege escalation ( CVE-2015-1701 ) to steal System token .


The Flash exploit is served from unobfuscated HTML/JS .


The launcher page picks one of two Flash files to deliver depending upon the target ’s platform ( Windows 32 versus 64bits ) .


The Flash exploit is mostly unobfuscated with only some light variable name mangling .


The attackers relied heavily on the CVE-2014-0515 Metasploit module , which is well documented .


It is ROPless , and instead constructs a fake vtable for a FileReference object that is modified for each call to a Windows API .


The payload exploits a local privilege escalation vulnerability in the Windows kernel if it detects that it is running with limited privileges .


It uses the vulnerability to run code from userspace in the context of the kernel , which modifies the attacker ’s process token to have the same privileges as that of the System process .


The primary difference between the CVE-2014-0515 metasploit module and this exploit is , obviously , the vulnerability .


CVE-2014-0515 exploits a vulnerability in Flash ’s Shader processing , whereas CVE-2015-3043 exploits a vulnerability in Flash ’s FLV processing .


The culprit FLV file is embedded within AS3 in two chunks , and is reassembled at runtime .


A buffer overflow vulnerability exists in Adobe Flash Player ( <=17.0.0.134 ) when parsing malformed FLV objects .


Attackers exploiting the vulnerability can corrupt memory and gain remote code execution .


In the exploit , the attacker embeds the FLV object directly in the ActionScript code , and plays the video using NetStream class .


Files of the FLV file format contain a sequence of Tag structures .


Beginning within the data field , all contents of the FLV stream become 0xEE .


Consequently , the data and lastsize fields are mangled .


Since the size is controlled by the attacker , it ’s possible to overflow the fixed size buffer with certain data .


As the previous picture demonstrated , the followed Vector object ’s length field being overflowed as 0x80007fff , which enables the attacker to read/write arbitrary data within user space .


Shellcode is passed to the exploit from HTML in flashvars .


The shellcode downloads the next stage payload , which is an executable passed in plaintext , to the temp directory with UrlDownloadToFileA , which it then runs with WinExec .


This exploit delivers a malware variant that shares characteristics with the APT28 backdoors CHOPSTICK and CORESHELL malware families , both described in our APT28 whitepaper .


The malware uses an RC4 encryption key that was previously used by the CHOPSTICK backdoor .


And the C2 messages include a checksum algorithm that resembles those used in CHOPSTICK backdoor communications .


In addition , the network beacon traffic for the new malware resembles those used by the CORESHELL backdoor .


Like CORESHELL , one of the beacons includes a process listing from the victim host .


And like CORESHELL , the new malware attempts to download a second-stage executable .


One of the C2 locations for the new payload , 87.236.215.246 , also hosts a suspected APT28 domain ssl-icloud.com .


The same subnet ( 87.236.215.0 / 24 ) also hosts several known or suspected APT28 domains .


The payload contains an exploit for the unpatched local privilege escalation vulnerability CVE-2015-1701 in Microsoft Windows .


The exploit uses CVE-2015-1701 to execute a callback in userspace .


The callback gets the EPROCESS structures of the current process and the System process , and copies data from the System token into the token of the current process .


Upon completion , the payload continues execution in usermode with the privileges of the System process .


Because CVE-2015-3043 is already patched , this remote exploit will not succeed on a fully patched system .


If an attacker wanted to exploit CVE-2015-1701 , they would first have to be executing code on the victim ’s machine .


Barring authorized access to the victim ’s machine , the attacker would have to find some other means , such as crafting a new Flash exploit , to deliver a CVE-2015-1701 payload .


Microsoft is aware of CVE-2015-1701 and is working on a fix .


CVE-2015-1701 does not affect Windows 8 and later .


Sofacy Attacks Multiple Government Entities .


Release_Time : 2018-02-28


Report_URL : https://unit42.paloaltonetworks.com/unit42-sofacy-attacks-multiple-government-entities/


The Sofacy group ( AKA APT28 , Fancy Bear , STRONTIUM , Sednit , Tsar Team , Pawn Storm ) is a well-known adversary that remains highly active in the new calendar year of 2018 .


Unit 42 actively monitors this group due to their persistent nature globally across all industry verticals .


Recently , we discovered a campaign launched at various Ministries of Foreign Affairs around the world .


Interestingly , there appear to be two parallel efforts within the campaign , with each effort using a completely different toolset for the attacks .


In this blog , we will discuss one of the efforts which leveraged tools that have been known to be associated with the Sofacy group .


At the beginning of February 2018 , we discovered an attack targeting two government institutions related to foreign affairs .


These entities are not regionally congruent , and the only shared victimology involves their organizational functions .


Specifically , one organization is geographically located in Europe and the other in North America .


The initial attack vector leveraged a phishing email , using the subject line of Upcoming Defense events February 2018 and a sender address claiming to be from Jane ’s 360 defense events events@ihsmarkit.com .


Jane ’s by IHSMarkit is a well-known supplier of information and analysis often times associated with the defense and government sector .


Analysis of the email header data showed that the sender address was spoofed and did not originate from IHSMarkit at all .


The lure text in the phishing email claims the attachment is a calendar of events relevant to the targeted organizations and contained specific instructions regarding the actions the victim would have to take if they had “ trouble viewing the document ” .


The attachment itself is an Microsoft Excel XLS document that contains malicious macro script .


The document presents itself as a standard macro document but has all of its text hidden until the victim enables macros .


Notably , all of the content text is accessible to the victim even before macros are enabled .


However , a white font color is applied to the text to make it appear that the victim must enable macros to access the content .


The code above changes the font color to black within the specified cell range and presents the content to the user .


On initial inspection , the content appears to be the expected legitimate content , however , closer examination of the document shows several abnormal artifacts that would not exist in a legitimate document .


Figure 2 below shows how the delivery document initially looks and the transformation the content undergoes as the macro runs .


As mentioned in a recent ISC diary entry , the macro gets the contents of cells in column 170 in rows 2227 to 2248 to obtain the base64 encoded payload .


The macro prepends the string —–BEGIN CERTIFICATE—– to the beginning of the base64 encoded payload and appends —–END CERTIFICATE—– to the end of the data .


The macro then writes this data to a text file in the C:\Programdata folder using a random filename with the .txt extension .


The macro then uses the command certutil -decode to decode the contents of this text file and outputs the decoded content to a randomly named file with a .exe extension in the C:\Programdata folder .


The macro sleeps for two seconds and then executes the newly dropped executable .


The newly dropped executable is a loader Trojan responsible for installing and running the payload of this attack .


We performed a more detailed analysis on this loader Trojan , which readers can view in this report ’s appendix .


Upon execution , the loader will decrypt the embedded payload ( DLL ) using a custom algorithm , decompress it and save it to the following file : %LOCALAPPDATA%\cdnver.dll .


The loader will then create the batch file %LOCALAPPDATA%\cdnver.bat , which it will write the following :


start rundll32.exe “ C:\Users\user\AppData\Local\cdnver.dll ” .


The loader Trojan uses this batch file to run the embedded DLL payload .


For persistence , the loader will write the path to this batch file to the following registry key .


The cdnver.dll payload installed by the loader executable is a variant of the SofacyCarberp payload , which is used extensively by the Sofacy threat group .


Overall , SofacyCarberp does initial reconnaissance by gathering system information and sending it to the C2 server prior to downloading additional tools to the system .


This variant of SofacyCarberp was configured to use the following domain as its C2 server : cdnverify.net .


The loader and the SofacyCarberp sample delivered in this attack is similar to samples we have analyzed in the past but contains marked differences .


These differences include a new hashing algorithm to resolve API functions and to find running browser processes for injection , as well as changes to the C2 communication mechanisms .


It appears that Sofacy may have used an open-source tool called Luckystrike to generate the delivery document and/or the macro used in this attack .


Luckystrike , which was presented at DerbyCon 6 in September 2016 , is a Microsoft PowerShell based tool that generates malicious delivery documents by allowing a user to add a macro to an Excel or Word document to execute an embedded payload .


We believe Sofacy used this tool , as the macro within their delivery document closely resembles the macros found within Luckystrike .


To confirm our suspicions , we generated a malicious Excel file with Luckystrike and compared its macro to the macro found within Sofacy ’s delivery document .


We found that there was only one difference between the macros besides the random function name and random cell values that the Luckystrike tool generates for each created payload .


The one non-random string difference was the path to the “ .txt ” and “ .exe ” files within the command “ certutil -decode ” , as the Sofacy document used “ C:\Programdata\ ” for the path whereas the Luckystrike document used the path stored in the Application.UserLibraryPath environment variable .


Figure 3 below shows a diff with the LuckyStrike macro on the left and Sofacy macro on the right , where everything except the file path and randomly generated values in the macro are exactly the same , including the obfuscation attempts that use concatenation to build strings .


With much of our research , our initial direction and discovery of emerging threats is generally some combination of previously observed behavioral rulesets or relationships .


In this case , we had observed a strange pattern emerging from the Sofacy group over the past year within their command and control infrastructure .


Patterning such as reuse of WHOIS artifacts , IP reuse , or even domain name themes are common and regularly used to group attacks to specific campaigns .


In this case , we had observed the Sofacy group registering new domains , then placing a default landing page which they then used repeatedly over the course of the year .


No other parts of the C2 infrastructure amongst these domains contained any overlapping artifacts .


Instead , the actual content within the body of the websites was an exact match in each instance .


Specifically , the strings 866-593-54352 ( notice it is one digit too long ) , 403-965-2341 , or the address 522 Clematis .


Suite 3000 was repeatedly found in each instance .


ThreatConnect had made the same observation regarding this patterning in September 2017 .


Hotfixmsupload.com is particularly interesting as it has been identified as a Sofacy C2 domain repeatedly , and was also brought forth by Microsoft in a legal complaint against STRONTIUM ( Sofacy ) as documented here .


Leveraging this intelligence allowed us to begin predicting potential C2 domains that would eventually be used by the Sofacy group .


In this scenario , the domain cdnverify.net was registered on January 30 , 2018 and just two days later , an attack was launched using this domain as a C2 .


The Sofacy group should no longer be an unfamiliar threat at this stage .


They have been well documented and well researched with much of their attack methodologies exposed .


They continue to be persistent in their attack campaigns and continue to use similar tooling as in the past .


This leads us to believe that their attack attempts are likely still succeeding , even with the wealth of threat intelligence available in the public domain .


Application of the data remains challenging , and so to continue our initiative of establishing playbooks for adversary groups , we have added this attack campaign as the next playbook in our dataset .


Palo Alto Networks customers are protected from this threat by :


WildFire detects all SofacyCarberp payloads with malicious verdicts .


AutoFocus customers can track these tools with the Sofacy , SofacyMacro and SofacyCarberp .


Traps blocks the Sofacy delivery documents and the SofacyCarberp payload .


SHA256 : ff808d0a12676bfac88fd26f955154f8884f2bb7c534b9936510fd6296c543e8 SHA256 : 12e6642cf6413bdf5388bee663080fa299591b2ba023d069286f3be9647547c8 SHA256 : cb85072e6ca66a29cb0b73659a0fe5ba2456d9ba0b52e3a4c89e86549bc6e2c7 SHA256 : 23411bb30042c9357ac4928dc6fca6955390361e660fec7ac238bbdcc8b83701 Sofacy : Cdnverify.net Sofacy Filename : Upcoming_Events_February_2018.xls .


APT28 Targets Hospitality Sector , Presents Threat to Travelers .


Release_Time : 2017-08-11 Report_URL : https://www.fireeye.com/blog/threat-research/2017/08/apt28-targets-hospitality-sector.html


FireEye has moderate confidence that a campaign targeting the hospitality sector is attributed to Russian actor APT28 .


We believe this activity , which dates back to at least July 2017 , was intended to target travelers to hotels throughout Europe and the Middle East .


The actor has used several notable techniques in these incidents such as sniffing passwords from Wi-Fi traffic , poisoning the NetBIOS Name Service , and spreading laterally via the EternalBlue exploit .


FireEye has uncovered a malicious document sent in spear phishing emails to multiple companies in the hospitality industry , including hotels in at least seven European countries and one Middle Eastern country in early July .


Successful execution of the macro within the malicious document results in the installation of APT28 ’s signature GAMEFISH malware .


The malicious document – Hotel_Reservation_Form.doc ( MD5 : 9b10685b774a783eabfecdb6119a8aa3 ) , contains a macro that base64 decodes a dropper that then deploys APT28 ’s signature GAMEFISH malware ( MD5 : 1421419d1be31f1f9ea60e8ed87277db ) , which uses mvband.net and mvtband.net as command and control ( C2 ) domains .


APT28 is using novel techniques involving the EternalBlue exploit and the open source tool Responder to spread laterally through networks and likely target travelers .


Once inside the network of a hospitality company , APT28 sought out machines that controlled both guest and internal Wi-Fi networks .


No guest credentials were observed being stolen at the compromised hotels ; however , in a separate incident that occurred in Fall 2016 , APT28 gained initial access to a victim ’s network via credentials likely stolen from a hotel Wi-Fi network .


Upon gaining access to the machines connected to corporate and guest Wi-Fi networks , APT28 deployed Responder .


Responder facilitates NetBIOS Name Service ( NBT-NS ) poisoning .


This technique listens for NBT-NS ( UDP ) broadcasts from victim computers attempting to connect to network resources .


Once received , Responder masquerades as the sought-out resource and causes the victim computer to send the username and hashed password to the attacker-controlled machine .


APT28 used this technique to steal usernames and hashed passwords that allowed escalation of privileges in the victim network .


To spread through the hospitality company ’s network , APT28 used a version of the EternalBlue SMB exploit .


This was combined with the heavy use of py2exe to compile Python scripts .


This is the first time we have seen APT28 incorporate this exploit into their intrusions .


In the 2016 incident , the victim was compromised after connecting to a hotel Wi-Fi network .


Twelve hours after the victim initially connected to the publicly available Wi-Fi network , APT28 logged into the machine with stolen credentials .


These 12 hours could have been used to crack a hashed password offline .


After successfully accessing the machine , the attacker deployed tools on the machine , spread laterally through the victim's network , and accessed the victim's OWA account .


The login originated from a computer on the same subnet , indicating that the attacker machine was physically close to the victim and on the same Wi-Fi network .


We cannot confirm how the initial credentials were stolen in the 2016 incident ; however , later in the intrusion , Responder was deployed .


Since this tool allows an attacker to sniff passwords from network traffic , it could have been used on the hotel Wi-Fi network to obtain a user ’s credentials .


Cyber espionage activity against the hospitality industry is typically focused on collecting information on or from hotel guests of interest rather than on the hotel industry itself , though actors may also collect information on the hotel as a means of facilitating operations .


Business and government personnel who are traveling , especially in a foreign country , often rely on systems to conduct business other than those at their home office , and may be unfamiliar with threats posed while abroad .


APT28 isn’t the only group targeting travelers .


South Korea nexus Fallout Team ( aka Darkhotel ) has used spoofed software updates on infected Wi-Fi networks in Asian hotels , and Duqu 2.0 malware has been found on the networks of European hotels used by participants in the Iranian nuclear negotiations .


Additionally , open sources have reported for several years that in Russia and China , high-profile hotel guests may expect their hotel rooms to be accessed and their laptops and other electronic devices accessed .


These incidents show a novel infection vector being used by APT28 .


The group is leveraging less secure hotel Wi-Fi networks to steal credentials and a NetBIOS Name Service poisoning utility to escalate privileges .


APT28 ’s already wide-ranging capabilities and tactics are continuing to grow and refine as the group expands its infection vectors .


Travelers must be aware of the threats posed when traveling – especially to foreign countries – and take extra precautions to secure their systems and data .


Publicly accessible Wi-Fi networks present a significant threat and should be avoided whenever possible .


Sofacy Continues Global Attacks and Wheels Out New Cannon Trojan .


Release_Time : 2018-11-20


Report_URL : https://unit42.paloaltonetworks.com/unit42-sofacy-continues-global-attacks-wheels-new-cannon-trojan/


In late October and early November 2018 , Unit 42 intercepted a series of weaponized documents that use a technique to load remote templates containing a malicious macro .


These types of weaponized documents are not uncommon but are more difficult to identify as malicious by automated analysis systems due to their modular nature .


Specific to this technique , if the C2 server is not available at the time of execution , the malicious code cannot be retrieved , rendering the delivery document largely benign .


The weaponized documents targeted several government entities around the globe , including North America , Europe , and a former USSR state .


Fortunately for us , the C2 servers for several of these documents were still operational allowing for retrieval of the malicious macro and the subsequent payloads .


Analysis revealed a consistent first-stage payload of the well-documented Zebrocy Trojan .


Additional collection of related documents revealed a second first-stage payload that we have named ‘ Cannon ’ .


Cannon has not been previously observed in use by the Sofacy group and contains a novel email-based C2 communication channel .


email as a C2 channel is not a new tactic , but it is generally not observed in the wild as often as HTTP or HTTPS .


Using email as a C2 channel may also decrease the chance of detection , as sending email via non-sanctioned email providers may not necessarily construe suspicious or even malicious activity in many enterprises .


The activity discussed in this blog revolves around two of the multitude of weaponized documents that we collected .


These two documents shared multiple data artifacts , such as a shared C2 IP , shared author name , and shared tactics .


Details of the extended attack campaign associated with the Cannon Trojan will be discussed in a later blog .


A particularly interesting aspect of one of the two documents we analyzed was the filename used , crash list ( Lion Air Boeing 737 ).docx .


This is not the first instance of an adversary group using recent current events as a lure , but it is interesting to see this group attempt to capitalize on the attention of a catastrophic event to execute their attack .


The initial sample we intercepted was a Microsoft Word document ( SHA256 : 2cfc4b3686511f959f14889d26d3d9a0d06e27ee2bb54c9afb1ada6b8205c55f ) with the filename crash list ( Lion Air Boeing 737 ).docx using the author name Joohn .


This document appeared to be targeting a government organization dealing with foreign affairs in Europe via spear-phishing .


Once the user attempts to open the document , Microsoft Word immediately attempts to load the remote template containing a malicious macro and payload from the location specified within the settings.xml.rels file of the DOCX document .


If the C2 has already been taken offline the document will still open , but Word will be unable to retrieve the remote template and thus Word will not load a macro .


In this situation , Word will present the same lure document to the victim as seen in Figure 2 , but without the ability to enable macros via an Enable Content button .


Assuming the C2 is still operational however , Word loads the remote template ( SHA256 : f1e2bceae81ccd54777f7862c616f22b581b47e0dda5cb02d0a722168ef194a5 ) and the user is presented with the screen .


Once the victim presses the Enable content button , the embedded macro is executed .


The macros used for these delivery documents use a less common method of using the AutoClose function .


This is a form of anti-analysis as Word will not fully execute the malicious code until the user closes the document .


If an automated sandbox exits its analysis session without specifically closing out the document , the sandbox may miss the malicious activity entirely .


Once successfully executed , the macro will install a payload and save a document to the system .


Typically , we expect to see a decoy document saved to the system and later displayed to make the victim less suspicious of malicious activity ; however , in this case the document saved to the system was never displayed and does not contain any pertinent content to the Lion Air tragedy theme seen in the filename .


The macro obtains the document saved to the system from within the document stored as UserForm1.Label1.Caption and will write it to : %TEMP%\~temp.docm .


The macro obtains the payload saved to the system from within the document stored as UserForm1.Label2.Caption and will write it to : %APPDATA%\MSDN\~msdn.exe .


The macro executes this payload in a rather interesting way by loading the dropped ~temp.docm document and calling a function within its embedded macro to run the payload .


We believe the creator of this delivery document chose to run the payload from the dropped file as an evasion technique .


Also , the fact the initial macro uses this dropped document for the execution of the payload may also explain why the document did not contain any decoy contents .


To carry out this functionality , after writing the


~temp.docm and ~msdn.exe files to the system , the initial macro will load the ~temp.docm file as a Word Document object and attempts to run the function Proc1 in the Module1 macro within the ~temp.docm file .


The Proc1 function within the Module1 does nothing more than build the %APPDATA%\MSDN\~msdn.exe path to the dropped payload and executes it using the built-in Shell function .


The payload dropped to the system ( SHA256 : 6ad3eb8b5622145a70bec67b3d14868a1c13864864afd651fe70689c95b1399a ) is a UPX packed Zebrocy variant written in the Delphi language .


This variant of Zebrocy is functionally very similar to the Delphi based payloads discussed in our previous publication on Sofacy attacks using Zebrocy earlier this year .


The developer of this particular payload configured it to use the following URL to communicate with as its C2 : http://188.241.58.170/local/s3/filters.php .


The Zebrocy Trojan gathers system specific information that it will send to the C2 server via an HTTP POST request to the above URL .


Like other Zebrocy samples , this Trojan collects system specific information it will send to the C2 server by running the command SYSTEMINFO & TASKLIST on the command line and by enumerating information about connected storage devices .


This specific variant of Zebrocy will also send a screenshot of the victim host as a JPEG image to the C2 server .


The C2 server will then provide a secondary payload to the beacon in ASCII hexadecimal representation , which the Trojan will decode and write to the following location : %APPDATA%\Roaming\Audio\soundfix.exe .


During our analysis , the C2 server provided a secondary payload that functionally appeared similar to the initial Zebrocy sample .


The secondary payload was also written in Delphi and its developer configured it to communicate with its C2 server using HTTPS via the following URL : https://200.122.181.25/catalog/products/books.php .


We were able to collect a second delivery document that shared the Joohn author from the crash list ( Lion Air Boeing 737 ).docx document , as well as the 188.241.58.170 C2 IP to host its remote template .


Structurally this sample was very similar to the initially analyzed document , but the payload turned out to be a completely new tool which we have named Cannon .


The tool is written in C# whose malicious code exists in a namespace called cannon , which is the basis of the Trojan ’s name .


The Trojan functions primarily as a downloader that relies on emails to communicate between the Trojan and the C2 server .


To communicate with the C2 server , the Trojan will send emails to specific email addresses via SMTPS over TCP port 587 .


This tool also has a heavy reliance on EventHandlers with timers to run its methods in a specific order and potentially increase its evasion capability .


The overall purpose of Cannon is to use several email accounts to send system data ( system information and screenshot ) to the threat actors and to ultimately obtain a payload from an email from the actors .


In addition to the following step-by-step process illustrates how Cannon communicates with the actor-controlled C2 email address to obtain a secondary payload .


Cannon gathers system information and saves it to a file named ini .


The Trojan sends an email to sahro.bella7@post.cz with i.ini as the attachment , S_inf within the body and a subject with a unique system identifier via SMTPS from one of the following accounts : Bishtr.cam47 , Lobrek.chizh , Cervot.woprov .


Cannon takes a screenshot and saves it to a file named ops .


The Trojan sends an email to sahro.bella7@post.cz with sysscr.ops as the attachment , the string SCreen within the body and a subject with the unique system identifier via SMTPS from one of three previously used accounts .


The actors likely log into sahro.bella7@post.cz and process the system information and screenshot sent by the Trojan to determine if the compromised host is of interest .


If the actor wishes to download an additional payload to the compromised host , they will respond by sending emails in the following steps .


The actor sends an email to trala.cosh2@post.cz with the unique system identifier as a subject with a secondary email account and credentials in ASCII hexadecimal format within the message body .


This secondary email account is unknown at this time , so we will refer to it as “ secondary email account ” in future steps .


The actor sends an email to the secondary email account with the unique system identifier as a subject with a secondary payload attached with a filename of txt .


Cannon logs into the trala.cosh2@post.cz account via POP3S looking for emails with a subject that matches the unique system identifier .


Cannon opens the email with the correct subject and decodes the hexadecimal data in the body of the message to obtain the secondary email account .


Cannon acknowledges the receipt of the secondary email address by sending an email to sahro.bella7@post.cz with s.txt ( contains {SysPar = 65} string ) as the attachment , ok within the body and a subject with the unique system identifier via SMTPS from one of the three accounts from Step 1 .


The actor sends an email to trala.cosh2@post.cz with the unique system identifier as a subject with a file path that the Cannon Trojan will use to save the secondary payload .


Cannon logs into the secondary email account via POP3S looking for emails with a subject that matches the unique system identifier .


Cannon opens the email with the correct subject and saves the attachment named auddevc.txt .


Cannon acknowledges the receipt of file download by sending an email to sahro.bella7@post.cz with l.txt ( contains 090 string ) as the attachment , ok2 within the body and a subject with the unique system identifier via SMTPS from one of the three accounts from Step 1 .


Cannon opens the email with the correct subject and decodes the hexadecimal data in the body of the message to obtain the file path that it will use to move the downloaded auddevc.txt file .


Cannon acknowledges the receipt of file path by sending an email to sahro.bella7@post.cz with s.txt ( contains {SysPar = 65} string ) as the attachment , ok3 within the body and a subject with the unique system identifier via SMTPS from one of the three accounts from Step 1 .


Cannon moves the downloaded file to the specified path .


Cannon acknowledges the successful move by sending an email to sahro.bella7@post.cz with l.txt ( contains 090 string ) as the attachment , ok4 within the body and a subject with the unique system identifier via SMTPS from one of the three accounts from Step 1 .


Cannon runs the downloaded file from the specified path .


Cannon acknowledges the successful execution by sending an email to sahro.bella7@post.cz with s.txt ( contains {SysPar = 65} string ) as the attachment , ok5 within the body and a subject with the unique system identifier via SMTPS from one of the three accounts from Step 1 .


The Sofacy threat group continues to target government organizations in the EU , US , and former Soviet states to deliver the Zebrocy tool as a payload .


In these attacks , the delivery documents used to install Zebrocy used remote templates , which increases the difficulty to analyze the attack as an active C2 server is needed to obtain the macro-enabled document .


The Sofacy group also leveraged the recent Lion Air disaster as a lure in one of these attacks , which continues to show a willingness to use current events in their social engineering themes .


Of note , we also discovered the Sofacy group using a very similar delivery document to deliver a new Trojan called Cannon .


Cannon uses SMTPS and POP3S as its C2 channel compared to Zebrocy that uses a more commonly observed HTTP or HTTPS based C2 .


This is not a new tactic but may be more effective at evading detection as the external hosts involved are a legitimate email service provider .


Add the layer of encryption that the SMTPS and POP3S protocols provide to the legitimate web-based service and you have a very difficult C2 channel to block While Sofacy ’s campaign delivering Zebrocy and Cannon remains active , Palo Alto Networks customers are protected from this threat in the following ways :


AutoFocus customers can track these samples with the Zebrocy and Cannon WildFire detects the delivery documents , Zebrocy and Cannon payloads discussed in this blog with malicious verdicts .


Traps blocks the macro-ladened remote templates as Suspicious macro detected , as well as Zebrocy and Cannon payloads as Suspicious executable detected .


The IP addresses hosting remote templates and C2 services in these attacks are classified as Command and Control .


Delivery Hashes :


2cfc4b3686511f959f14889d26d3d9a0d06e27ee2bb54c9afb1ada6b8205c55f af77e845f1b0a3ae32cb5cfa53ff22cc9dae883f05200e18ad8e10d7a8106392 .


Remote Template Hashes :


f1e2bceae81ccd54777f7862c616f22b581b47e0dda5cb02d0a722168ef194a5 fc69fb278e12fc7f9c49a020eff9f84c58b71e680a9e18f78d4e6540693f557d .


Remote Templates :


http://188.241.58.170/live/owa/office.dotm .


Zebrocy Hashes :


6ad3eb8b5622145a70bec67b3d14868a1c13864864afd651fe70689c95b1399a .


Zebrocy C2 URLs :


http://188.241.58.170/local/s3/filters.php https://200.122.181.25/catalog/products/books.php .


Cannon Hashes :


61a1f3b4fb4dbd2877c91e81db4b1af8395547eab199bf920e9dd11a1127221e .


Cannon email Accounts :


sahro.bella7@post.cz trala.cosh2@post.cz bishtr.cam47@post.cz lobrek.chizh@post.cz cervot.woprov@post.cz .


THE DUKES 7 YEARS OF RUSSIAN CYBERESPIONAGE .


The Dukes are a well-resourced , highly dedicated and organized cyberespionage group that we believe has been working for the Russian Federation since at least 2008 to collect intelligence in support of foreign and security policy decision-making .


The Dukes primarily target Western governments and related organizations , such as government ministries and agencies , political think tanks , and governmental subcontractors .


Their targets have also included the governments of members of the Commonwealth of Independent States ; Asian , African , and Middle Eastern governments ; organizations associated with Chechen extremism ; and Russian speakers engaged in the illicit trade of controlled substances and drugs .


The Dukes are known to employ a vast arsenal of malware toolsets , which we identify as MiniDuke , CosmicDuke , OnionDuke , CozyDuke , CloudDuke , SeaDuke , HammerDuke , PinchDuke , and GeminiDuke .


In recent years , the Dukes have engaged in apparently biannual large-scale spear-phishing campaigns against hundreds or even thousands of recipients associated with governmental institutions and affiliated organizations .


The earliest activity we have been able to definitively attribute to the Dukes are two PinchDuke campaigns from November 2008 .


These campaigns use PinchDuke samples that were , according to their compilation timestamps , created on the 5th and 12th of November 2008 .


The campaign identifiers found in these two samples are respectively , “ alkavkaz.com20081105 ” and “ cihaderi.net20081112 ” .


The first campaign identifier , found in the sample compiled on the 5th , references alkavkaz.com , a domain associated with a Turkish website proclaiming to be the “ Chechan [sic] Informational Center ” .


The second campaign identifier , from the sample compiled on the 12th , references cihaderi.net , another Turkish website that claims to provide “ news from the jihad world ” and which dedicates a section of its site to Chechnya .


Due to a lack of other PinchDuke samples from 2008 or earlier , we are unable to estimate when the Duke operation originally began .


Based on our technical analysis of the known PinchDuke samples from 2008 however , we believe PinchDuke to have been under development by the summer of 2008 .


In fact , we believe that by the autumn of 2008 , the Dukes were already developing not one but at least two distinct malware toolsets .


This assertion is based on the oldest currently known sample of another Duke related toolset , GeminiDuke , which was compiled on the 26th of January 2009 .


This sample , like the early PinchDuke samples , appears to already be a “ fully-grown ” sample , which is why we believe GeminiDuke was under development by the autumn of 2008 .


That the Dukes were already developing and operating at least two distinct malware toolsets by the second half of 2008 suggests to us that either the size of their cyberespionage operation was already large enough to warrant such an arsenal of tools , or that they expected their operation to grow significantly enough in the foreseeable future to warrant the development of such an arsenal .


The origins of the Duke toolset names can be traced back to when researchers at Kaspersky Labs coined the term “ MiniDuke ” to identify the first Duke related malware they found .


As explained in their whitepaper , the researchers observed the surprisingly small MiniDuke backdoor being spread via the same exploit that was being used by a malware that they had already named ItaDuke ; the “ Duke ” part of this malware ’s name had in turn come about because it reminded the researchers of the notable Duqu threat .


Despite the shared history of the name itself however , it is important to note that there is no reason to believe that the Duke toolsets themselves are in any way related to the ItaDuke malware , or to Duqu for that matter .


As researchers continued discovering new toolsets that were created and used by the same group that had been operating MiniDuke , the new toolsets were also given “ Duke ” -derived names , and thus the threat actor operating the toolsets started to be commonly referred to as “ the Dukes ” .


The only other publicly used name for the threat actor that we are aware of is “ APT29 ” .


Based on the campaign identifiers found in PinchDuke samples discovered from 2009 , the targets of the Dukes group during that year included organizations such as the Ministry of Defense of Georgia and the ministries of foreign affairs of Turkey and Uganda .


Campaign identifiers from 2009 also reveal that by that time , the Dukes were already actively interested in political matters related to the United States ( US ) and the North Atlantic Treaty Organization ( NATO ) , as they ran campaigns targeting ( among other organizations ) a US based foreign policy think tank , another set of campaigns related to a NATO exercise held in Europe , and a third set apparently targeting what was then known as the Georgian “ Information Centre on NATO ” .


Of these campaigns , two clusters in particular stand out .


The first is a set of campaigns from the 16th and 17th of April , 2009 , that targeted a US based foreign policy think tank , as well as government institutions in Poland and the Czech Republic .


These campaigns utilized specially-crafted malicious Microsoft Word documents and PDF files , which were sent as e-mail attachments to various personnel in an attempt to infiltrate the targeted organizations .


We believe this cluster of campaigns had a joint goal of gathering intelligence on the sentiments of the targeted 5 countries with respect to the plans being discussed at the time for the US to locate their “ European Interceptor Site ” missile defense base in Poland , with a related radar station that was intended to be located in the Czech Republic .


Regarding the timing of these campaigns , it is curious to note that they began only 11 days after President Barack Obama gave a speech on the 5th of April declaring his intention to proceed with the deployment of these missile defenses .


The second notable cluster comprises of two campaigns that were possibly aimed at gathering information on Georgia S-LOC-NATO relations .


The first of these runs used the campaign identifier “ natoinfo_ge ” , an apparent reference to the www.natoinfo.ge website belonging to a Georgian political body that has since been renamed “ Information Centre on NATO and EU ” .


Although the campaign identifier itself doesn’t contain a date , we believe the campaign to have originated around the 7th of June 2009 , which was when the PinchDuke sample in question was compiled .


This belief is based on the observation that in all of the other PinchDuke samples we have analyzed , the date of the campaign identifier has been within a day of the compilation date .


The second campaign identifier , which we suspect may be related , is “ mod_ge_2009_07_03 ” from a month later and apparently targeting the Ministry of Defense of Georgia .


The spring of 2010 saw continued PinchDuke campaigns against Turkey and Georgia , but also numerous campaigns against other members of the Commonwealth of Independent States such as Kazakhstan , Kyrgyzstan , Azerbaijan and Uzbekistan .


Of these , the campaign with the identifier “ kaz_2010_07_30 ” , which possibly targeted Kazakhstan , is of note because it is the last PinchDuke campaign we have observed .


We believe that during the first half of 2010 , the Dukes slowly migrated from PinchDuke and started using a new infostealer malware toolset that we call CosmicDuke .


The first known sample of the CosmicDuke toolset was compiled on the 16th of January 2010 .


Back then , CosmicDuke still lacked most of the credential-stealing functionality found in later samples .


We believe that during the spring of 2010 , the credential and file stealing capabilities of PinchDuke were slowly ported to CosmicDuke , effectively making PinchDuke obsolete .


During this period of transition , CosmicDuke would often embed PinchDuke so that , upon execution , CosmicDuke would write to disk and execute PinchDuke .


Both PinchDuke and CosmicDuke would then operate independently on the same compromised host , including performing separate information gathering , data Exfiltration and communication with a command and control ( C&C ) server - although both malware would often use the same C&C server .


We believe the purpose of this parallel use was to ‘ fieldtest ’ the new CosmicDuke tool , while at the same time ensuring operational success with the tried-and-tested PinchDuke .


During this period of CosmicDuke testing and development , the Duke authors also started experimenting with the use of privilege escalation vulnerabilities .


Specifically , on the 19th of January 2010 security researcher Tavis Ormandy disclosed a local privilege escalation vulnerability ( CVE-2010-0232 ) affecting Microsoft Windows .


As part of the disclosure , Ormandy also included the source code for a proof-of- concept exploit for the vulnerability .


Just 7 days later , on the 26th of January , a component for CosmicDuke was compiled that exploited the vulnerability and allowed the tool to operate with higher privileges .


During 2011 , the Dukes appear to have significantly expanded both their arsenal of malware toolsets and their C&C infrastructure .


While the Dukes employed both hacked websites and purposely rented servers for their C&C infrastructure , the group rarely registered their own domain names , preferring instead to connect to their self- operated servers via IP addresses .


The beginning of 2011 however saw a significant break from that routine , when a large grouping of domain names was registered by the Dukes in two batches ; the first batch was registered on the 29th of January and the second on the 13th of February .


All the domains in both batches were initially registered with the same alias : “ John Kasai of Klagenfurt , Austria ” .


These domains were used by the Dukes in campaigns involving many of their different malware toolsets all the way until 2014 .


Like the “ MiniDuke loader ” , these “ John Kasai ” domains also provide a common thread tying together much of the tools and infrastructure of the Dukes .


By 2011 , the Dukes had already developed at least 3 distinct malware toolsets , including a plethora of supporting components such as loaders and persistence modules .


In fact , as a sign of their arsenal ’s breadth , they had already decided to retire one of these malware toolsets as obsolete after developing a replacement for it , seemingly from scratch .


The Dukes continued the expansion of their arsenal in 2011 with the addition of two more toolsets : MiniDuke and CozyDuke .


While all of the earlier toolsets – GeminiDuke , PinchDuke , and CosmicDuke – were designed around a core infostealer component , MiniDuke is centered on a simplistic backdoor component whose purpose is to enable the remote execution of commands on the compromised system .


The first observed samples of the MiniDuke backdoor component are from May 2011 .


This backdoor component however is technically very closely related to GeminiDuke , to the extent that we believe them to share parts of their source code .


The origins of MiniDuke can thus be traced back to the origins of GeminiDuke , of which the earliest observed sample was compiled in January of 2009 .


Unlike the simplistic MiniDuke toolset , CozyDuke is a highly versatile , modular , malware “ platform ” whose functionality lies not in a single core component but in an array of modules that it may be instructed to download from its C&C server .


These modules are used to selectively provide CozyDuke with just the functionality deemed necessary for the mission at hand .


CozyDuke ’s modular platform approach is a clear break from the designs of the previous Duke toolsets .


The stylistic differences between CozyDuke and its older siblings are further exemplified by the way it was coded .


All of the 4 previously mentioned toolsets were written in a minimalistic style commonly seen with malware ; MiniDuke even goes as far as having many components written in Assembly language .


CozyDuke however represents the complete opposite .


Instead of being written in Assembly or C , it was written in C++ , which provides added layers of abstraction for the developer ’s perusal , at the cost of added complexity .


Contrary to what might be expected from malware , early CozyDuke versions also lacked any attempt at obfuscating or hiding their true nature .


In fact , they were extremely open and verbose about their functionality - for example , early samples contained a plethora of logging messages in unencrypted form .


In comparison , even the earliest known GeminiDuke samples encrypted any strings that might have given away the malware ’s true nature .


Finally , early CozyDuke versions also featured other elements that one would associate more with a traditional software development project than with malware .


For instance , the earliest known CozyDuke version utilized a feature of the Microsoft Visual C++ compiler known as run-time error checking .


This feature added automatic error checking to critical parts of the program ’s execution at the cost , from a malware perspective , of providing additional hints that make the malware ’s functionality easier for reverse engineers to understand .


Based on these and other similar stylistic differences observed between CozyDuke and its older siblings , we speculate that while the older Duke families appear to be the work of someone with a background in malware writing ( or at the least in hacking ) , CozyDuke ’s author or authors more likely came from a software development background .


We still know surprisingly few specifics about the Dukes group ’s activities during 2012 .


Based on samples of Duke malware from 2012 , the Dukes do appear to have continued actively using and developing all of their tools .


Of these , CosmicDuke and MiniDuke appear to have been in more active use , while receiving only minor updates .


GeminiDuke and CozyDuke on the other hand appear to have been less used in actual operations , but did undergo much more significant development .


On the 12th of February 2013 , FireEye published a blogpost alerting readers to a combination of new Adobe Reader 0-day vulnerabilities , CVE-2013-0640 and CVE-2013-0641 , that were being actively exploited in the wild . 8 days after FireEye ’s initial alert , Kaspersky spotted the same exploit being used to spread an entirely different malware family from the one mentioned in the original report .


On 27th February , Kaspersky and CrySyS Lab published research on this previously unidentified malware family , dubbing it MiniDuke .


As we now know , by February 2013 the Dukes group had been operating MiniDuke and other toolsets for at least 4 and a half years .


Their malware had not stayed undetected for those 4 and a half years .


In fact , in 2009 a PinchDuke sample had been included in the malware set used by the AV-Test security product testing organization to perform anti-virus product comparison reviews .


Until 2013 however , earlier Duke toolsets had not been put in a proper context .


That finally started to change in 2013 .


The MiniDuke samples that were spread using these exploits were compiled on the 20th of February , after the exploit was already publicly known .


One might argue that since this took place after the exploits were publicly mentioned , the Dukes simply copied them .


We however do not believe so .


As mentioned by Kaspersky , even though the exploits used for these MiniDuke campaigns were near-identical to those described by FireEye , there were nevertheless small differences .


Of these , the crucial one is the presence of PDB strings in the MiniDuke exploits .


These strings , which are generated by the compiler when using specific compilation settings , means that the components of the exploits used with MiniDuke had to have been compiled independently from those described by FireEye .


We do not know whether the Dukes compiled the components themselves or whether someone else compiled the components before handing them to the group .


This does however still rule out the possibility that the Dukes simply obtained copies of the exploit binaries described by FireEye and repurposed them .


In our opinion , this insistence on using exploits that are already under heightened scrutiny suggests the existence of at least one of three circumstances .


Firstly , the Dukes may have been confident enough in their own abilities ( and in the slowness of their opponents to react to new threats ) that they did not care if their targets may already be on the lookout for anyone exploiting these vulnerabilities .


Secondly , the value the Dukes intended to gain from these MiniDuke campaigns may have been so great that they deemed it worth the risk of getting noticed .


Or thirdly , the Dukes may have invested so much into these campaigns that by the time FireEye published their alert , the Dukes felt they could not afford to halt the campaigns .


We believe all three circumstances to have coexisted at least to some extent .


As will become evident in this report , this was not a one-off case but a recurring theme with the Dukes , in that they would rather continue with their operations as planned than retreat from operating under the spotlight .


As originally detailed in Kaspersky ’s whitepaper , the MiniDuke campaigns from February 2013 employed spear-phishing emails with malicious PDF file attachments .


These PDFs would attempt to silently infect the recipient with MiniDuke , while distracting them by displaying a decoy document .


The headings of these documents included “ Ukraine ’s NATO Membership Action Plan ( MAP ) Debates ” , “ The Informal Asia-Europe Meeting ( ASEM ) Seminar on Human Rights ” , and “ Ukraine ’s Search for a Regional Foreign Policy ” .


The targets of these campaigns , according to Kaspersky , were located variously in Belgium , Hungary , Luxembourg and Spain .


Kaspersky goes on to state that by obtaining log files from the MiniDuke command and control servers , they were able to identify high-profile victims from Ukraine , Belgium , Portugal , Romania , the Czech Republic , Ireland , the United States and Hungary .


After the February campaigns , MiniDuke activity appeared to quiet down , although it did not fully stop , for the rest of 2013 .


The Dukes group as a whole however showed no sign of slowing down .


In fact , we saw yet another Duke malware toolset , OnionDuke , appear first in 2013 .


Like CozyDuke , OnionDuke appears to have been designed with versatility in mind , and takes a similarly modular platform approach .


The OnionDuke toolset includes various modules for purposes such as password stealing , information gathering , denial of service ( DoS ) attacks , and even posting spam to the Russian social media network , VKontakte .


The OnionDuke toolset also includes a dropper , an information stealer variant and multiple distinct versions of the core component that is responsible for interacting with the various modules .


What makes OnionDuke especially curious is an infection vector it began using during the summer of 2013 .


To spread the toolset , the Dukes used a wrapper to combine OnionDuke with legitimate applications , created torrent files containing these trojanized applications , then uploaded them to websites hosting torrent files .


Victims who used the torrent files to download the applications would end up getting infected with OnionDuke .


For most of the OnionDuke components we observed , the first versions that we are aware of were compiled during the summer of 2013 , suggesting that this was a period of active development around this toolset .


Critically however , the first sample of the OnionDuke dropper , which we have observed being used only with components of this toolset , was compiled on the 17th of February 2013 .


This is significant because it suggests that OnionDuke was under development before any part of the Duke operation became public .


OnionDuke ’s development therefore could not have been simply a response to the outing of one of the other Duke malware , but was instead intended for use alongside the other toolsets .


This indication that the Dukes planned to use an arsenal of 5 malware toolsets in parallel suggests that they were operating with both significant resources and capacity .


In 2013 , many of the decoy documents employed by the Dukes in their campaigns were related to Ukraine ; examples include a letter undersigned by the First Deputy Minister for Foreign Affairs of Ukraine , a letter from the embassy of the Netherlands in Ukraine to the Ukrainian Ministry of Foreign affairs and a document titled “ Ukraine ’s Search for a Regional Foreign Policy ” .


These decoy documents however were written before the start of the November 2013 Euromaidan protests in Ukraine and the subsequent upheaval .


It is therefore important to note that , contrary to what might be assumed , we have actually observed a drop instead of an increase in Ukraine related campaigns from the Dukes following the country ’s political crisis .


This is in stark contrast to some other suspected Russian threat actors ( such as Operation Pawn Storm ) who appear to have increased their targeting of Ukraine following the crisis .


This supports our analysis that the overarching theme in the Dukes ’ targeting is the collection of intelligence to support diplomatic efforts .


The Dukes actively targeted Ukraine before the crisis , at a time when Russia was still weighing her options , but once Russia moved from diplomacy to direct action , Ukraine was no longer relevant to the Dukes in the same way .


In a surprising turn of events , in September 2013 a CosmicDuke campaign was observed targeting Russian speakers involved in the trade of illegal and controlled substances .


Kaspersky Labs , who sometimes refer to CosmicDuke as ‘ Bot Gen Studio ’ , speculated that “ one possibility is that ‘ Bot Gen Studio ’ is a malware platform also available as a so-called ‘ legal spyware ’ tool ” ;


therefore , those using CosmicDuke to target drug dealers and those targeting governments are two separate entities .


We however feel it is unlikely that the CosmicDuke operators targeting drug dealers and those targeting governments could be two entirely independent entities .


A shared supplier of malware would explain the overlap in tools , but it would not explain the significant overlap we have also observed in operational techniques related to command and control infrastructure .


Instead , we feel the targeting of drug dealers was a new task for a subset of the Dukes group , possibly due to the drug trade ’s relevance to security policy issues .


We also believe the tasking to have been temporary , because we have not observed any further similar targeting from the Dukes after the spring of 2014 .


While MiniDuke activity decreased significantly during the rest of 2013 following the attention it garnered from researchers , the beginning of 2014 saw the toolset back in full force .


All MiniDuke components , from the loader and downloader to the backdoor , had been slightly updated and modified during the downtime .


Interestingly , the nature of these modifications suggests that their primary purpose was to regain the element of stealth and undetectability that had been lost almost a year earlier .


Of these modifications , arguably the most important were the ones done to the loader .


These resulted in a loader version that would later become known as the “ Nemesis Gemina loader ” due to PDB strings found in many of the samples .


It is however still only an iteration on earlier versions of the MiniDuke loader .


The first observed samples of the Nemesis Gemina loader ( compiled on 14th December 2013 ) were used to load the updated MiniDuke backdoor , but by the spring of 2014 the Nemesis Gemina loader was also observed in use with CosmicDuke .


Following the MiniDuke expose , CosmicDuke in turn got its moment of fame when F-Secure published a whitepaper about it on 2nd July 2014 .


The next day , Kaspersky also published their own research on the malware .


It should be noted that until this point , even though CosmicDuke had been in active use for over 4 years , and had undergone minor modifications and updates during that time , even the most recent CosmicDuke samples would often embed persistence components that date back to 2012 .


These samples would also contain artefacts of functionality from the earliest CosmicDuke samples from 2010 .


It is therefore valuable to observe how the Dukes reacted to CosmicDuke ’s outing at the beginning of July .


By the end of that month , CosmicDuke samples we found that had been compiled on the 30th of July had shed unused parts of their code that had essentially just been relics of the past .


Similarly , some of the hardcoded values that had remained unaltered in CosmicDuke samples for many years had been changed .


We believe these edits were an attempt at evading detection by modifying or removing parts of the toolset that the authors believed might be helpful in identifying and detecting it .


Concurrently with the alterations to CosmicDuke , the Dukes were also hard at work modifying their trusted loader .


Much like the CosmicDuke toolset , the loader used by both MiniDuke and CosmicDuke had previously only undergone one major update ( the Nemesis Gemina upgrade ) since the first known samples from 2010 .


Again , much of the modification work focused on removing redundant code in an attempt to appear different from earlier versions of the loader .


Interestingly however , another apparent evasion trick was also attempted - forging of the loaders ’ compilation timestamps .


The first CosmicDuke sample we observed after the initial research on CosmicDuke was a sample compiled on the 30th of July 2014 .


The loader used by the sample purported to have been compiled on the 25th of March 2010 .


Due to artefacts left in the loader during compilation time however , we know that it used a specific version of the Boost library , 1.54.0 , that was only published on the 1st of July 2013 .


The compilation timestamp therefore had to have been faked .


F-Secure ’s whitepaper on CosmicDuke includes a timeline of the loader ’s usage , based on compilation timestamps .


Perhaps the Dukes group thought that by faking a timestamp from before the earliest one cited in the whitepaper , they might be able to confuse researchers .


During the rest of 2014 and the spring of 2015 , the Dukes continued making similar evasionfocused modifications to CosmicDuke , as well as experimenting with ways to obfuscate the loader .


In the latter case however , the group appear to have also simultaneously developed an entirely new loader , which we first observed being used in conjunction with CosmicDuke during the spring of 2015 .


While it is not surprising that the Dukes reacted to multiple companies publishing extensive reports on one of their key toolsets , it is valuable to note the manner in which they responded .


Much like the MiniDuke expose in February 2013 , the Dukes again appeared to prioritize continuing operations over staying hidden .


They could have ceased all use of CosmicDuke ( at least until they had developed a new loader ) or retired it entirely , since they still had other toolsets available .


Instead , they opted for minimal downtime and attempted to continue operations , with only minor modifications to the toolset .


While we now know that CozyDuke had been under development since at least the end of 2011 , it was not until the early days of July 2014 that the first large-scale CozyDuke campaign that we are aware of took place .


This campaign , like later CozyDuke campaigns , began with spear-phishing emails that tried to impersonate commonly seen spam emails .


These spear-phishing emails would contain links that eventually lead the victim to becoming infected with CozyDuke .


Some of the CozyDuke spear-phishing emails from early July posed as e-fax arrival notifications , a popular theme for spam emails , and used the same “ US letter fax test page ” decoy document that was used a year later by CloudDuke .


In at least one case however , the email instead contained a link to a zip archive file named “ Office Monkeys LOL Video.zip ” , which was hosted on the DropBox cloud storage service .


What made this particular case interesting was that instead of the usual dull PDF file , the decoy was a Flash video file , more specifically a Super Bowl advertisement from 2007 purporting to show monkeys at an office .


THE DUKES 7 YEARS OF RUSSIAN CYBERESPIONAGE .


Release_Time : 2015-09


Report_URL : https://blog-assets.f-secure.com/wp-content/uploads/2020/03/18122307/F-Secure_Dukes_Whitepaper.pdf


2014 : OnionDuke gets caught using a malicious Tor node .


On the 23rd of October 2014 , Leviathan Security Group published a blog post describing a malicious Tor exit node they had found .


They noted that this node appeared to be maliciously modifying any executables that were downloaded through it over a HTTP connection .


Executing the modified applications obtained this way would result in the victim being infected with unidentified malware .


On the 14th of November , F-Secure published a blog post naming the malware OnionDuke and associating it with MiniDuke and CosmicDuke , the other Duke toolsets known at the time .


Based on our investigations into OnionDuke , we believe that for about 7 months , from April 2014 to when Leviathan published their blog post in October 2014 , the Tor exit node identified by the researchers was being used to wrap executables on-the-fly with OnionDuke ( image 7 , page 13 ) .


This is similar to the way in which the toolset was being spread via trojanized applications in torrent files during the summer of 2013 .


While investigating the OnionDuke variant being spread by the malicious Tor node , we also identified another OnionDuke variant that appeared to have successfully compromised multiple victims in the ministry of foreign affairs of an Eastern European country during the spring of 2014 .


This variant differed significantly in functionality from the one being spread via the Tor node , further suggesting that different OnionDuke variants are intended for different kinds of victims .


We believe that , unusually , the purpose of the OnionDuke variant spread via the Tor node was not to pursue targeted attacks but instead to form a small botnet for later use .


This OnionDuke variant is related to the one seen during the summer of 2013 being spread via torrent files .


Both of these infection vectors are highly indiscriminate and untargeted when compared to spearphishing , the usual infection vector of choice for the Dukes .


Further , the functionality of the OnionDuke variant is derived from a number of modules .


While one of these modules gathers system information and another attempts to steal the victim ’s usernames and passwords , as one would expect from a malware used for a targeted attack , the other two known OnionDuke modules are quite the opposite ; one is designed for use in DoS S-TOOL attacks and the other for posting predetermined messages to the Russian VKontakte social media site .


This sort of functionality is more common in criminality-oriented botnets , not statesponsored targeted attacks .


We have since been able to identify at least two separate OnionDuke botnets .


We believe the formation of the first of these botnets began in January 2014 , using both unidentified infection vectors and the known malicious Tor node , and continued until our blogpost was published in November .


We believe the formation of the second botnet began in August 2014 and continued until January 2015 .


We have been unable to identify the infection vectors used for this second botnet , but the C&C servers it used had open directory listings , allowing us to retrieve files containing listings of victim IP addresses .


The geographic distribution of these IP addresses ( image 8 , page 13 ) further supports our theory that the purpose of this OnionDuke variant was not targeted attacks against high-profile targets .


One theory is that the botnets were a criminal side business for the Dukes group .


The size of the botnet however ( about 1400 bots ) is very small if its intended use is for commercial DoS attacks or spam-sending .


Alternatively , OnionDuke also steals user credentials from its victims , providing another potential revenue source .


The counter to that argument however is that the value of stolen credentials from users in the countries with the highest percentage of OnionDuke bots ( Mongolia and India ) are among the lowest on underground markets . 2015 : The Dukes up the ante .


The end of January 2015 saw the start of the most high- volume Duke campaign seen thus far , with thousands of recipients being sent spear-phishing emails that contained links to compromised websites hosting CozyDuke .


Curiously , the spear-phishing emails were strikingly similar to the e-fax themed spam usually seen spreading ransomware and other common crimeware .


Due to the sheer number of recipients , it may not have been possible to customize the emails in the same way as was possible with lower-volume campaigns .


The similarity to common spam may however also serve a more devious purpose .


It is easy to imagine a security analyst , burdened by the amount of attacks against their network , dismissing such common-looking spam as “ just another crimeware spam run ” , allowing the campaign to , in essence , hide in the masses .


The CozyDuke activity continues one of the long-running trends of the Dukes operations , the use of multiple malware toolsets against a single target .


In this case , the Dukes first attempted to infect large numbers of potential targets with CozyDuke ( and in a more obvious manner than previously seen ) .


They would then use the toolset to gather initial information on the victims , before deciding which ones to pursue further .


For the victims deemed interesting enough , the Dukes would then deploy a different toolset .


We believe the primary purpose of this tactic is an attempt at evading detection in the targeted network .


Even if the noisy initial CozyDuke campaign is noticed by the victim organization , or by someone else who then makes it publicly known , defenders will begin by first looking for indicators of compromise ( IOCs ) related to the CozyDuke toolset .


If however by that time the Dukes are already operating within the victim ’s network , using an another toolset with different IOCs , then it is reasonable to assume that it will take much longer for the victim organization to notice the infiltration .


In previous cases , the group used their malware toolsets interchangeably , as either the initial or a later-stage toolset in a campaign .


For these CozyDuke campaigns however , the Dukes appear to have employed two particular later-stage toolsets , SeaDuke and HammerDuke , that were purposely designed to leave a persistent backdoor on the compromised network .


HammerDuke is a set of backdoors that was first seen in the wild in February 2015 , while SeaDuke is a crossplatform backdoor that was , according to Symantec , first spotted in the wild in October 2014 .


Both toolsets were originally spotted being deployed by CozyDuke to its victims .


What makes SeaDuke special is that it was written in Python and designed to work on both Windows and Linux systems ; it is the first cross-platform tool we have seen from the Dukes .


One plausible reason for developing such a flexible malware might be that the group were increasingly encountering victim environments where users were using Linux as their desktop operating system .


Meanwhile , HammerDuke is a Windows only malware ( written in .NET ) and comes in two variants .


The simpler one will connect to a hardcoded C&C server over HTTP or HTTPS to download commands to execute .


The more advanced variant , on the other hand , will use an algorithm to generate a periodically-changing Twitter account name and will then attempt to find tweets from that account containing links to the actual download location of the commands to execute .


In this way , the advanced HammerDuke variant attempts to hide its network traffic in more legitimate use of Twitter .


This method is not unique to HammerDuke , as MiniDuke , OnionDuke , and CozyDuke all support similar use of Twitter ( image 9 , page 18 ) to retrieve links to additional payloads or commands . 2015 : CloudDuke .


In the beginning of July 2015 , the Dukes embarked on yet another large-scale phishing campaign .


The malware toolset used for this campaign was the previously unseen CloudDuke and we believe that the July campaign marks the first time that this toolset was deployed by the Dukes , other than possible small-scale testing .


The CloudDuke toolset consists of at least a loader , a downloader , and two backdoor variants .


Both backdoors ( internally referred to by their authors as “ BastionSolution ” and “ OneDriveSolution ” ) essentially allow the operator to remotely execute commands on the compromised machine .


The way in which each backdoor does so however is significantly different .


While the BastionSolution variant simply retrieves commands from a hard-coded C&C server controlled by the Dukes , the OneDriveSolution utilizes Microsoft ’s OneDrive cloud storage service for communicating with its masters , making it significantly harder for defenders to notice the traffic and block the communication channel .


What is most significant about the July 2015 CloudDuke campaign is the timeline .


The campaign appeared to consist of two distinct waves of spear-phishing , one during the first days of July and the other starting from the 20th of the month .


Details of the first wave , including a thorough technical analysis of CloudDuke , was published by Palo Alto Networks on 14th July .


This was followed by additional details from Kaspersky in a blog post published on 16th July .


Both publications happened before the second wave took place and received notable publicity .


Despite the attention and public exposure of the toolset ’s technical details ( including IOCs ) to defenders , the Dukes still continued with their second wave of spear-phishing , including the continued use of CloudDuke .


The group did change the contents of the spear-phishing emails they sent , but they didn’t switch to a new email format ; instead , they reverted to the same efaxthemed format that they had previously employed , even to the point of reusing the exact same decoy document that they had used in the CozyDuke campaign a year earlier ( July 2014 ) .


This once more highlights two crucial behavioral elements of the Dukes group .


Firstly , as with the MiniDuke campaigns of February 2013 and CosmicDuke campaigns in the summer of 2014 , again the group clearly prioritized the continuation of their operations over maintaining stealth .


Secondly , it underlines their boldness , arrogance and self-confidence ; they are clearly confident in both their ability to compromise their targets even when their tools and techniques are already publicly known , and critically , they appear to be extremely confident in their ability to act with impunity . 2015 : Continuing surgical strikes with CosmicDuke .


In addition to the notably overt and large-scale campaigns with CozyDuke and CloudDuke , the Dukes also continued to engage in more covert , surgical campaigns using CosmicDuke .


The latest of these campaigns that we are aware of occurred during the spring and early summer of 2015 .


As their infection vectors , these campaigns used malicious documents exploiting recently fixed vulnerabilities .


Two of these campaigns were detailed in separate blog posts by the Polish security company Prevenity , who said that both campaigns targeted Polish entities with spear- phishing emails containing malicious attachments with relevant Polish language names .


A third , similar , CosmicDuke campaign was observed presumably targeting Georgian entities since it used an attachment with a Georgian-language name that translates to “ NATO consolidates control of the Black Sea.docx ” .


Based on this , we do not believe that the Dukes are replacing their covert and targeted campaigns with the overt and opportunistic CozyDuke and CloudDuke style of campaigns .


Instead , we believe that they are simply expanding their activities by adding new tools and techniques .


A XENOTIME to Remember : Veles in the Wild .


FireEye recently published a blog covering the tactics , techniques , and procedures ( TTPs ) for the “ TRITON actor ” when preparing to deploy the TRITON / TRISIS malware framework in 2017 .


Overall , the post does a commendable job in making public findings previously only privately shared ( presumably by FireEye , and in several reports I authored for my employer , Dragos ) to threat intelligence customers .


As such , the blog continues to push forward the narrative of how ICS attacks are enabled through prepositioning and initial intrusion operations – an item I have discussed at length .


Yet one point of confusion in the blog comes at the very start : referring to the entity responsible for TRITON as the “ TRITON actor ” .


This seems confusing as FireEye earlier publicly declared the “ TRITON actor ” as a discrete entity , linked to a Russian research institution , and christened it as “ TEMP.Veles ” .


In the 2018 public posting announcing TEMP.Veles , FireEye researchers noted that the institute in question at least supported TEMP.Veles activity in deploying TRITON , with subsequent public presentations at Cyberwarcon and the Kaspersky Lab sponsored Security Analyst Summit essentially linking TRITON and the research institute ( and therefore TEMP.Veles ) as one in the same .


Yet the most-recent posting covering TTPs from initial access through prerequisites to enable final delivery of effects on target ( deploying TRITON / TRISIS ) avoids the use of the TEMP.Veles term entirely .


In subsequent discussion , FireEye personnel indicate that there was not “ an avalanche of evidence to substantiate ” anything more than “ TRITON actor ” – summing matters by indicating this term “ is the best we ’ve got for the public for now ” .


Meanwhile , parallel work at Dragos ( my employer , where I have performed significant work on the activity described above ) uncovered similar conclusions concerning TTPs and behaviors , for both the 2017 event and subsequent activity in other industrial sectors .


Utilizing Diamond Model methodology for characterizing activity by behaviors attached to victims , we began tracking TRITON / TRISIS and immediate enabling activity as a distinct activity group ( collection of behaviors , infrastructure , and victimology ) designated XENOTIME .


Based on information gained from discussion with the initial TRITON / TRISIS responders and subsequent work on follow-on activity by this entity , Dragos developed a comprehensive ( public ) picture of adversary activity roughly matching FireEye ’s analysis published in April 2019 , described in various media .


At this stage , we have two similar , parallel constructions of events – the how behind the immediate deployment and execution of TRITON / TRISIS – yet dramatically different responses in terms of attribution and labeling .


Since late 2018 , based upon the most-recent posting , FireEye appears to have “ walked back ” the previously-used terminology of TEMP.Veles and instead refers rather cryptically to the “ TRITON actor ” , while Dragos leveraged identified behaviors to consistently refer to an activity group , XENOTIME .


Given that both organizations appear to describe similar ( if not identical ) activity , any reasonable person could ( and should ) ask – why the inconsistency in naming and identification .


Aside from the competitive vendor naming landscape ( which I am not a fan of in cases on direct overlap , but which has more to say for itself when different methodologies are employed around similar observations ) , the distinction between FireEye and Dragos ’ approaches with respect to the “ TRITON actor ” comes down to fundamental philosophical differences in methodology .


As wonderfully described in a recent public posting , FireEye adheres to a naming convention based upon extensive data collection and activity comparison , designed to yield the identification of a discrete , identifiable entity responsible for a given collection of activity .


This technique is precise and praiseworthy – yet at the same time , appears so rigorous as to impose limitations on the ability to dynamically adjust and adapt to emerging adversary activity . ( Or for that matter , even categorize otherwise well-known historical actors operating to the present day , such as Turla . ) FireEye ’s methodology may have particular limitations in instances where adversaries ( such as XENOTIME and presumably TEMP.Veles ) rely upon extensive use of publicly-available , commonly-used tools with limited amounts of customization .


In such cases , utilizing purely technical approaches for differentiation ( an issue I lightly touched on in a recent post ) becomes problematic , especially when trying to define attribution to specific , “ who-based ” entities ( such as a Russian research institute ) .


My understanding is FireEye labels entities where definitive attribution is not yet possible with the “ TEMP ” moniker ( hence , TEMP.Veles ) – yet in this case FireEye developed and deployed the label , then appeared to move away from it in subsequent reporting .


Based on the public blog post – which also indicated that FireEye is responding to an intrusion at a second facility featuring the same or similar observations – this is presumably not for lack of evidence , yet the “ downgrade ” occurs all the same .


In comparison , XENOTIME was defined based on principles of infrastructure ( compromised third-party infrastructure and various networks associated with several Russian research institutions ) , capabilities ( publicly- and commercially-available tools with varying levels of customization ) and targeting ( an issue not meant for discussion in this blog ) .


In personally responding to several incidents across multiple industry sectors since early 2018 matching TTPs from the TRITON / TRISIS event , these items proved consistent and supported the creation of the XENOTIME activity group .


This naming decision was founded upon the underlying methodology described in the Diamond Model of intrusion analysis .


As such , this decision does not necessarily refer to a specific institution , but rather a collection of observations and behaviors observed across multiple , similarly-situated victims .


Of note , this methodology of naming abstracts away the “ who ” element – XENOTIME may represent a single discrete entity ( such as a Russian research institution ) or several entities working in coordination in a roughly repeatable , similar manner across multiple events .


Ultimately , the epistemic foundation of the behavior-based naming approach makes this irrelevant for tracking ( and labeling for convenience sake ) observations .