Article Content In this blog, we will take a closer look at the powerful, versatile backdoor known as CARBANAK (aka Anunak) Specifically, we will focus on the operational details of its use over the past few years, including its configuration, the minor variations observed from sample to sample, and its evolution With these details, we will then draw some conclusions about the operators of CARBANAK For some additional background on the CARBANAK backdoor, see the papers by Kaspersky and Group-IB and Fox-It Technical Analysis Before we dive into the meat of this blog, a brief technical analysis of the backdoor is necessary to provide some context CARBANAK is a full-featured backdoor with data-stealing capabilities and a plugin architecture Some of its capabilities include key logging, desktop video capture, VNC, HTTP form grabbing, file system management, file transfer, TCP tunneling, HTTP proxy, OS destruction, POS and Outlook data theft and reverse shell Most of these data-stealing capabilities were present in the oldest variants of CARBANAK that we have seen and some were added over time Monitoring Threads The backdoor may optionally start one or more threads that perform continuous monitoring for various purposes, as described in Table 1 Table 2 lists these commands 0x007AA8A5  state  Updates the state value (see the Configuration section) It contains commands in the same form as those listed in Table 2 that are automatically executed by the backdoor when it is started This file can be likened to a startup script for the backdoor Some of these values indicate which C2 protocol to use, whether the backdoor has been installed, and whether the PST monitoring thread is running or not Other than the state command, all commands in the configuration file are identified by their hash’s decimal value instead of their plain text name Certain commands, when executed, add themselves to the configuration so they will persist across (or be part of) reboots Figure 1 and Figure 2 illustrate some sample, decoded configuration files we have come across in our investigations A message starts with a host ID composed by concatenating a hash value generated from the computer’s hostname and MAC address to a string likely used as a campaign code Once the message has been formatted, it is sandwiched between an additional two fields of randomly generated strings of upper and lower case alphabet characters An example of a command polling message and a response to the listprocess command are given in Figure 3 and Figure 4, respectively Figure 3: Example command polling message   Figure 4: Example command response message Messages are encrypted using Microsoft’s implementation of RC2 in CBC mode with PKCS#5 padding The eight-byte initialization vector (IV) is a randomly generated string consisting of upper and lower case alphabet characters This URI is then used in a GET or POST request A sample GET request is shown in Figure 5 The backdoor also searches for proxy configurations to use in the registry at HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings and for each profile in the Mozilla Firefox configuration file at %AppData%\Mozilla\Firefox\<ProfileName>\prefs.js Custom Binary Protocol Figure 6 describes the structure of the malware’s custom binary protocol If a message is larger than 150 bytes, it is compressed with an unidentified algorithm If a message is larger than 4096 bytes, it is broken into compressed chunks This protocol has undergone several changes over the years, each version building upon the previous version in some way These changes were likely introduced to render existing network signatures ineffective and to make signature creation more difficult Figure 6: Binary protocol message format  Version 1 In the earliest version of the binary protocol, we have discovered that the message bodies that are stored in the <chunkData> field are simply XORed with the host ID The initial message is not encrypted and contains the host ID This key is sent in the initial message Version 3 Version 3 adds encryption to the headers The first 19 bytes of the message headers (up to the <hdrXORKey2> field) are XORed with a five-byte key that is randomly generated per message and stored in the <hdrXORKey2> field Version 4 This version adds a bit more complexity to the header encryption scheme Version 5 Version 5 is the most sophisticated of the binary protocols we have seen The use of public key cryptography makes decryption of the session key infeasible without the C2 server’s private key The Roundup We have rounded up 220 samples of the CARBANAK backdoor and compiled a table that highlights some interesting details that we were able to extract The MD5 hash is for the original executable file that eventually launches CARBANAK, but the details of each sample were extracted from memory during execution This data provides us with a unique insight into the operational aspect of CARBANAK and can be downloaded here Protocol Evolution As described earlier, CARBANAK’s binary protocol has undergone several significant changes over the years Figure 7 illustrates a rough timeline of this evolution based on the compile times of samples we have in our collection This may not be entirely accurate because our visibility is not complete, but it gives us a general idea as to when the changes occurred It has been observed that some builds of this data-stealing backdoor use outdated versions of the protocol This may suggest multiple groups of operators compiling their own builds of this data-stealing backdoor independently Figure 7: Timeline of binary protocol versions *It is likely that we are missing an earlier build that utilized version 3 We have observed that the key and the cipher texts for all the encrypted strings are changed for each sample that we have encountered, even amongst samples with the same compile time The RC2 key used for the HTTP protocol has also been observed to change among samples with the same compile time These observations paired with the use of campaign codes that must be configured denote the likely existence of a build tool Rapid Builds Despite the likelihood of a build tool, we have found 57 unique compile times in our sample set, with some of the compile times being quite close in proximity For example, on May 20, 2014, two builds were compiled approximately four hours apart and were configured to use the same C2 servers Again, on July 30, 2015, two builds were compiled approximately 12 hours apart This command downloads an executable from the C2 and directly runs it in memory In another case, one build was programmed to check for the existence of the domain blizko.net in the trusted sites list for Internet Explorer while the other was not Blizko is an online money transfer service We have also seen that different monitoring threads from Table 1 are enabled from build to build These minor changes suggest that the code is quickly modified and compiled to adapt to the needs of the operator for particular targets Figure 8 shows some of the relationships that can be observed in our data set Campaign Code   Compile Date    Aug  7/30/15    dec  12/8/14    julyc  7/2/16    jun  5/9/15    june  5/25/14    june  6/7/14    junevnc  6/20/14    juspam  7/13/14    juupd  7/13/14    may  5/20/14    may  5/19/15    ndjun  6/7/16    SeP  9/12/14    spamaug  8/1/14    spaug  8/1/14    Figure 8: Campaign code to compile time relationships Recent Updates Recently, 64 bit variants of the backdoor have been discovered We shared details about such variants in a recent blog post Some of these variants are programmed to sleep until a configured activation date when they will become active History The “Carbanak Group” Much of the publicly released reporting surrounding the CARBANAK malware refers to a corresponding “Carbanak Group”, who appears to be behind the malicious activity associated with this data-stealing backdoor FireEye iSIGHT Intelligence has tracked several separate overarching campaigns employing the CARBANAK tool and other associated backdoors, such as DRIFTPIN (aka Toshliph) With the data available at this time, it is unclear how interconnected these campaigns are – if they are all directly orchestrated by the same criminal group, or if these campaigns were perpetrated by loosely affiliated actors sharing malware and techniques FIN7 In all Mandiant investigations to date where the CARBANAK backdoor has been discovered, the activity has been attributed to the FIN7 threat group FIN7 has been extremely active against the U.S restaurant and hospitality industries since mid-2015 Finally, FIN7 has leveraged several new techniques that we have not observed in other CARBANAK related activity Widespread Bank Targeting Throughout the U.S., Middle East and Asia Proofpoint initially reported on a widespread campaign targeting banks and financial organizations throughout the U.S and Middle East in early 2016 We identified several additional organizations in these regions, as well as in Southeast Asia and Southwest Asia being targeted by the same attackers This cluster of activity persisted from late 2014 into early 2016 Most notably, the infrastructure utilized in this campaign overlapped with LAZIOK, NETWIRE and other malware targeting similar financial entities in these regions DRIFTPIN DRIFTPIN (aka Spy.Agent.ORM, and Toshliph) has been previously associated with CARBANAK in various campaigns We have seen it deployed in initial spear phishing by FIN7 in the first half of 2016 Also, in late 2015, ESET reported on CARBANAK associated attacks, detailing a spear phishing campaign targeting Russian and Eastern European banks using DRIFTPIN as the malicious payload Cyphort Labs also revealed that variants of DRIFTPIN associated with this cluster of activity had been deployed via the RIG exploit kit placed on two compromised Ukrainian banks’ websites FireEye iSIGHT Intelligence observed this wave of spear phishing aimed at a large array of targets, including U.S financial institutions and companies associated with Bitcoin trading and mining activities This cluster of activity continues to be active now to this day, targeting similar entities Additional details on this latest activity are available on the FireEye iSIGHT Intelligence MySIGHT Portal Earlier CARBANAK Activity In December 2014, Group-IB and Fox-IT released a report about an organized criminal group using malware called "Anunak" that has targeted Eastern European banks, U.S and European point-of-sale systems and other entities Kaspersky released a similar report about the same group under the name "Carbanak" in February 2015 The name “Carbanak” was coined by Kaspersky in this report – the malware authors refer to the backdoor as Anunak This activity was further linked to the 2014 exploitation of ATMs in Ukraine Conclusion The details that can be extracted from CARBANAK provide us with a unique insight into the operational details behind this data-stealing malware Several inferences can be made when looking at such data in bulk as we discussed above and are summarized as follows:  Based upon the information we have observed, we believe that at least some of the operators of CARBANAK either have access to the source code directly with knowledge on how to modify it or have a close relationship to the developer(s) Some of the operators may be compiling their own builds of the backdoor independently Varying campaign codes indicate that independent or loosely affiliated criminal actors are employing CARBANAK in a wide-range of intrusions that target a variety of industries but are especially directed at financial institutions across the globe, as well as the restaurant and hospitality sectors within the U.S 
Below is an instruction that describes a task, paired with an input that provides further context. Write a response that appropriately completes the request. ### Instruction: List the MITRE techniques contained in the text. ### Input: Article Content In this blog, we will take a closer look at the powerful, versatile backdoor known as CARBANAK (aka Anunak) Specifically, we will focus on the operational details of its use over the past few years, including its configuration, the minor variations observed from sample to sample, and its evolution With these details, we will then draw some conclusions about the operators of CARBANAK For some additional background on the CARBANAK backdoor, see the papers by Kaspersky and Group-IB and Fox-It Technical Analysis Before we dive into the meat of this blog, a brief technical analysis of the backdoor is necessary to provide some context CARBANAK is a full-featured backdoor with data-stealing capabilities and a plugin architecture Some of its capabilities include key logging, desktop video capture, VNC, HTTP form grabbing, file system management, file transfer, TCP tunneling, HTTP proxy, OS destruction, POS and Outlook data theft and reverse shell Most of these data-stealing capabilities were present in the oldest variants of CARBANAK that we have seen and some were added over time Monitoring Threads The backdoor may optionally start one or more threads that perform continuous monitoring for various purposes, as described in Table 1 Table 2 lists these commands 0x007AA8A5  state  Updates the state value (see the Configuration section) It contains commands in the same form as those listed in Table 2 that are automatically executed by the backdoor when it is started This file can be likened to a startup script for the backdoor Some of these values indicate which C2 protocol to use, whether the backdoor has been installed, and whether the PST monitoring thread is running or not Other than the state command, all commands in the configuration file are identified by their hash’s decimal value instead of their plain text name Certain commands, when executed, add themselves to the configuration so they will persist across (or be part of) reboots Figure 1 and Figure 2 illustrate some sample, decoded configuration files we have come across in our investigations A message starts with a host ID composed by concatenating a hash value generated from the computer’s hostname and MAC address to a string likely used as a campaign code Once the message has been formatted, it is sandwiched between an additional two fields of randomly generated strings of upper and lower case alphabet characters An example of a command polling message and a response to the listprocess command are given in Figure 3 and Figure 4, respectively Figure 3: Example command polling message   Figure 4: Example command response message Messages are encrypted using Microsoft’s implementation of RC2 in CBC mode with PKCS#5 padding The eight-byte initialization vector (IV) is a randomly generated string consisting of upper and lower case alphabet characters This URI is then used in a GET or POST request A sample GET request is shown in Figure 5 The backdoor also searches for proxy configurations to use in the registry at HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings and for each profile in the Mozilla Firefox configuration file at %AppData%\Mozilla\Firefox\<ProfileName>\prefs.js Custom Binary Protocol Figure 6 describes the structure of the malware’s custom binary protocol If a message is larger than 150 bytes, it is compressed with an unidentified algorithm If a message is larger than 4096 bytes, it is broken into compressed chunks This protocol has undergone several changes over the years, each version building upon the previous version in some way These changes were likely introduced to render existing network signatures ineffective and to make signature creation more difficult Figure 6: Binary protocol message format  Version 1 In the earliest version of the binary protocol, we have discovered that the message bodies that are stored in the <chunkData> field are simply XORed with the host ID The initial message is not encrypted and contains the host ID This key is sent in the initial message Version 3 Version 3 adds encryption to the headers The first 19 bytes of the message headers (up to the <hdrXORKey2> field) are XORed with a five-byte key that is randomly generated per message and stored in the <hdrXORKey2> field Version 4 This version adds a bit more complexity to the header encryption scheme Version 5 Version 5 is the most sophisticated of the binary protocols we have seen The use of public key cryptography makes decryption of the session key infeasible without the C2 server’s private key The Roundup We have rounded up 220 samples of the CARBANAK backdoor and compiled a table that highlights some interesting details that we were able to extract The MD5 hash is for the original executable file that eventually launches CARBANAK, but the details of each sample were extracted from memory during execution This data provides us with a unique insight into the operational aspect of CARBANAK and can be downloaded here Protocol Evolution As described earlier, CARBANAK’s binary protocol has undergone several significant changes over the years Figure 7 illustrates a rough timeline of this evolution based on the compile times of samples we have in our collection This may not be entirely accurate because our visibility is not complete, but it gives us a general idea as to when the changes occurred It has been observed that some builds of this data-stealing backdoor use outdated versions of the protocol This may suggest multiple groups of operators compiling their own builds of this data-stealing backdoor independently Figure 7: Timeline of binary protocol versions *It is likely that we are missing an earlier build that utilized version 3 We have observed that the key and the cipher texts for all the encrypted strings are changed for each sample that we have encountered, even amongst samples with the same compile time The RC2 key used for the HTTP protocol has also been observed to change among samples with the same compile time These observations paired with the use of campaign codes that must be configured denote the likely existence of a build tool Rapid Builds Despite the likelihood of a build tool, we have found 57 unique compile times in our sample set, with some of the compile times being quite close in proximity For example, on May 20, 2014, two builds were compiled approximately four hours apart and were configured to use the same C2 servers Again, on July 30, 2015, two builds were compiled approximately 12 hours apart This command downloads an executable from the C2 and directly runs it in memory In another case, one build was programmed to check for the existence of the domain blizko.net in the trusted sites list for Internet Explorer while the other was not Blizko is an online money transfer service We have also seen that different monitoring threads from Table 1 are enabled from build to build These minor changes suggest that the code is quickly modified and compiled to adapt to the needs of the operator for particular targets Figure 8 shows some of the relationships that can be observed in our data set Campaign Code   Compile Date    Aug  7/30/15    dec  12/8/14    julyc  7/2/16    jun  5/9/15    june  5/25/14    june  6/7/14    junevnc  6/20/14    juspam  7/13/14    juupd  7/13/14    may  5/20/14    may  5/19/15    ndjun  6/7/16    SeP  9/12/14    spamaug  8/1/14    spaug  8/1/14    Figure 8: Campaign code to compile time relationships Recent Updates Recently, 64 bit variants of the backdoor have been discovered We shared details about such variants in a recent blog post Some of these variants are programmed to sleep until a configured activation date when they will become active History The “Carbanak Group” Much of the publicly released reporting surrounding the CARBANAK malware refers to a corresponding “Carbanak Group”, who appears to be behind the malicious activity associated with this data-stealing backdoor FireEye iSIGHT Intelligence has tracked several separate overarching campaigns employing the CARBANAK tool and other associated backdoors, such as DRIFTPIN (aka Toshliph) With the data available at this time, it is unclear how interconnected these campaigns are – if they are all directly orchestrated by the same criminal group, or if these campaigns were perpetrated by loosely affiliated actors sharing malware and techniques FIN7 In all Mandiant investigations to date where the CARBANAK backdoor has been discovered, the activity has been attributed to the FIN7 threat group FIN7 has been extremely active against the U.S restaurant and hospitality industries since mid-2015 Finally, FIN7 has leveraged several new techniques that we have not observed in other CARBANAK related activity Widespread Bank Targeting Throughout the U.S., Middle East and Asia Proofpoint initially reported on a widespread campaign targeting banks and financial organizations throughout the U.S and Middle East in early 2016 We identified several additional organizations in these regions, as well as in Southeast Asia and Southwest Asia being targeted by the same attackers This cluster of activity persisted from late 2014 into early 2016 Most notably, the infrastructure utilized in this campaign overlapped with LAZIOK, NETWIRE and other malware targeting similar financial entities in these regions DRIFTPIN DRIFTPIN (aka Spy.Agent.ORM, and Toshliph) has been previously associated with CARBANAK in various campaigns We have seen it deployed in initial spear phishing by FIN7 in the first half of 2016 Also, in late 2015, ESET reported on CARBANAK associated attacks, detailing a spear phishing campaign targeting Russian and Eastern European banks using DRIFTPIN as the malicious payload Cyphort Labs also revealed that variants of DRIFTPIN associated with this cluster of activity had been deployed via the RIG exploit kit placed on two compromised Ukrainian banks’ websites FireEye iSIGHT Intelligence observed this wave of spear phishing aimed at a large array of targets, including U.S financial institutions and companies associated with Bitcoin trading and mining activities This cluster of activity continues to be active now to this day, targeting similar entities Additional details on this latest activity are available on the FireEye iSIGHT Intelligence MySIGHT Portal Earlier CARBANAK Activity In December 2014, Group-IB and Fox-IT released a report about an organized criminal group using malware called "Anunak" that has targeted Eastern European banks, U.S and European point-of-sale systems and other entities Kaspersky released a similar report about the same group under the name "Carbanak" in February 2015 The name “Carbanak” was coined by Kaspersky in this report – the malware authors refer to the backdoor as Anunak This activity was further linked to the 2014 exploitation of ATMs in Ukraine Conclusion The details that can be extracted from CARBANAK provide us with a unique insight into the operational details behind this data-stealing malware Several inferences can be made when looking at such data in bulk as we discussed above and are summarized as follows:  Based upon the information we have observed, we believe that at least some of the operators of CARBANAK either have access to the source code directly with knowledge on how to modify it or have a close relationship to the developer(s) Some of the operators may be compiling their own builds of the backdoor independently Varying campaign codes indicate that independent or loosely affiliated criminal actors are employing CARBANAK in a wide-range of intrusions that target a variety of industries but are especially directed at financial institutions across the globe, as well as the restaurant and hospitality sectors within the U.S  ### Response: .