 Jesse himself is a hardcore malware researcher, reverse engineer, and he also likes to break code, and my voice is breaking too. I'm sorry for that. So, Stage is open to Jesse. Let's visit the Dareben. Thank you very much. So, yes, I'm a malware researcher working at ESET Montreal. And during the past two years, we have been monitoring a group called SEDNIT with my two colleagues, Jean and Thomas. They can be here. They can be with me here today, sadly. And this talk is based on a technical white paper publicly available on our blog, if you want to read it. So, as I said, we call this group SEDNIT, but depending on the researchers, they have other names like APT28, Fancy Bear, Sophacy. And this is a group of attackers doing targeted attacks since at least 2004. And their interest is mainly about geopolitics. As you might have seen in the news, they are very famous at the moment. They are supposedly behind the hack of the Democratic National Committee and also the World Anti-Doping Agency. And in this presentation, I will start by giving you some context around this group. After that, I will describe a textbook case of their current operations during which we will dig into their tool set. And after that, I will present a different and strange operation also run by the SEDNIT group during the last few years. And finally, I will conclude with some lesson learned and open questions. So, let's start with some context around the SEDNIT group. So what kind of people are they after? And for once, we know very precisely some of their targets because they made a mistake during one of their phishing campaigns. The operators used the Bitly service to shorten their phishing URLs but forgot to say the Bitly profile private. So we had access to around 4,000 shortened URLs during six months in 2015. Here is an example of a URL that was shortened. It contains the email address of the target and also its real name. So at this point, identifying the targets was pretty easy. In this list, there are embassies and ministries of more than 40 countries. There is NATO and EU institutions. And finally, there is a lot of individuals involved in Eastern Europe politics. To infect those targets, they pulled out several zero days. Here you can see a timeline with the SEDNIT zero days exploit for 2015 only. And all these vulnerabilities have been reported since. And I'm not even talking here about the revamped exploit they use. There are many of them also, and we are going to see that later. The story doesn't end in 2016. Just as an example, the Google threat analysis group disclosed vulnerabilities in Flash and in the Windows kernel like a month ago, I think. And the exploit was using the Flash vulnerability to gain control on the remote computer and the Win32K vulnerability to escalate its privileges and bypass the sandbox. I won't describe the exploit here. There is enough information on the Internet. But this shows the SEDNIT group is quite resourceful. Also, this is the kind of group that deployed many custom softwares over the past 10 years from droppers to encryption proxy tools, including different types of backdoors. In short, they developed quite a lot. And before going further, I want to mention a few disclaimers. First, even if we tracked the SEDNIT group pretty closely during the last two years, we might be missing part of the pictures. And as malware researchers, we call it a group based on their toolkit. Even they might be divided in sub-teams. And finally, we are not competent to do any sort of attribution. But our research might provide you hints that may be used for that. So let's start our journey in the SEDNIT toolkit with Serge. Serge is actually a codename for a fictional SEDNIT target. He works for a government and has access to sensitive information. The chain of events and the timings that I am going to describe are in line with several real cases we've investigated during the last two years. And we use Serge as a textbook case to present part of the SEDNIT toolkit. So somewhere recently, it's Monday, 9.30 a.m., and Serge arrives at work and he opens an email. This email supposedly came from Stratfor, which provides regular reports and geopolitics, except that if we look closely at the URL, we will notice that the domain mimics the legitimate Stratfor domain, but also the URI is the same as an article on the legitimate Stratfor website, except that an ID was inserted in the middle probably to identify the target. But let's say Serge clicks on the URL and this is when Serge meets SEDNIT, which is the SEDNIT exploit kit and it is only used for targeted attacks. As we just saw, its entry point is usually URLs mimicking legitimate websites and the exploit kit infection usually starts from targeted phishing emails, but we've also seen iframe redirection from hacked websites. We found SEDNIT in September 2014 for the first time and it is still in use. So as a classic exploit kit, when you visit it, you receive a landing page that will build a reconnaissance report on the machine. The SEDNIT landing page contains around 200 lines of JavaScript and the code stayed the same over the last year. You can see here a beautified extract of this landing page. First it will retrieve the time zone and then it will enumerate the properties of JavaScript object called navigator and screens. And finally, it will enumerate the plugin installed in the browser. As you can see, there is a special case for Internet Explorer where Java and Flash are detected by special methods. By the way, the comments here are from the developers. So to give you an idea, here is the report from Search Computer. It's a JSON file and you can see it contains a lot of information such that the server can select the targets very precisely, not only based on their configuration but also based on the language they speak and the time zones they are in. However, we don't know precisely what the operators are looking for. We crawl the exploit kit with various configurations and different IP addresses. Sometimes it works, sometimes it doesn't work and so far we don't really know why. But let's say that search is selected to be exploited. And this is when search visits the send it exploit factory. So here is the list of exploit that we saw from search kit since its beginning. And as you can see, three of them were already exploited at the time they were used. Also interestingly, there was an exploit for MacKeeper, which is a cleaning tool for OS 10 made by a company from Ukraine and it is probably mainly used by people from Eastern Europe. And the other exploits are revamped exploits and I am going to describe one of them right now. So this exploit targets the CV 2014 6332 and this vulnerability is an integral overflow in the Internet Explorer VBScript engine that allows arbitrary read-write operations. We saw search kit delivering an exploit for this CV in October 2015 and in this case it was only reusing a POC to disable the safe mode and to download a payload with PowerShell. But at the beginning of the year, we found a very different version of this exploit, a more complex one that was used in February 2016. This exploit didn't disable the safe mode but directly executed a rub chain. The code is pretty big, around 400 lines of VBScript and interestingly it's custom. So don't try to read everything, but here is the beautify code of the function building the rub chain. And just to give you an example, you can see here a function to retrieve the code section address of DRL on Windows 7. As you can see, that's a lot of effort. Turns out that part of this code is actually based or inspired by a presentation made at Black Hat USA 2014 and once again the same group are not afraid of digging into complex exploits to make use of them in real life examples. Back to search case now. Let's say the exploit downloads the payload This is when search meets setup loader. So the setup loader is usually downloaded by setkit, like in search case and this component actually includes two binaries, a dropper and its embedded payload. It is generally the first component deployed on the victim and we dated the operation of setup loader in March 2015. So let's start with the dropper now. You can see here is very simple workflow, but it contains some interesting features. The first one is a weird anti-analysis trick. So here's the snippet extract from x-rays. So first it will allocate a 10 byte buffer and it set the last byte to the value 42 and then it will create a file with a very specific name. It will then write one million time in this file and then read one million time in the same file. After that it will check if the last byte of the 10 byte buffer still contains the value 42. If it doesn't, setup loader terminates its execution. So this code looks kind of strange, but we believe this is an anti-emulation trick because they replaced it with a more common one in the most recent sample and also it might create intensive hard drive operation that may delay the execution of the software. Also it may detect emulators wrongly implementing the memory management. So the next step is to decrypt the payload and to decompress it. These operations are implemented in a C++ class named uploader by the developers. You can see it here on the screen. After that the dropper may use a local privilege escalation exploit depending on the sample one of these two CVs may be used. The first one was a zero day at the time they used it and the second one is another gift from the hacking team leaks. And finally the dropper made the payload persistent on the system. Interestingly we saw many different techniques used over the past month. Some of them only used when the dropper runs with system privileges. You can see here just a few of them like the windows com object hijacking and the JavaScript code executed with the rendi.l42. Those two techniques were first seen in other malware and seeking inspiration in crimeware is something very common for the Zenit group. At this moment the payload is running on search computer and the payload is actually a reconnaissance malware and you can see here a simplified workflow again. Establishing the network connection with the CNC server will be the first step. It changed several times in the last few months but the first it will try to reach google.com and if it works it moves on. However if it doesn't work it will retrieve the proxy credentials. For instance for Firefox the payload looks for the profile file and it will pass it. If it succeeds it will contact the CNC server via the proxy using those credentials. And then if all the previous techniques didn't work it will wait for the user to launch a browser in order to inject into it. The next step is to send a first stage report to the CNC server. This report begins with an ID generated to identify the computer and also it will send the process list, some information on the disk, a build number which is hardcoded in the binary and then it sends this encrypted through the networking that was previously established. It is rather a small report but it is probably in order to filter out security researchers and automated sandboxes. The final step is retrieving a configuration file from the CNC server. Here are different values handled by the last version of said uploader payload. I will not go through them, they are quite explicit, but the main purpose is to download another binary and to execute it as an executable or a DLL. Now let's go back to our channel of events. We are still day one and Search Computer is infected with said uploader. Same day, 30 minutes later the operator are now sure that Search is not a malware researcher. Celerico is downloaded on Search Computer by said uploader. So this is a classic backdoor with numerous commands and interestingly it has the ability to extend its behavior by loading external plugins. It is usually deployed after a successful infection like in Search case and while this component may be old, we know for a fact that it is still in use today. So Celerico arrived on a system embedded in a dropper which usually installed the payload and its configuration. It will drop the configuration at two places on the disk. The first place will be in a file named msd and it will also copy the exact same data in the Windows registry. And of course, since the configuration is installed by the payload, if you only have the payload you won't be able to determine the configuration used with it. So now let's talk about the configuration. You can see here the encrypted version. It comes with a small header and the data is absorbed with a six byte key located at the beginning of the header and it is randomly generated by the dropper. Following the key you have 20 bytes, each byte representing the size of a field in the data. Everything else is the encrypted data. Now we have the content once decrypted and here is the better representation of the extracted fields. So those values are just various timeouts. I don't find them really interesting. Here is the search computer name. Here you have a flag to specify whether or not the kilogear should be enabled. Here are the three CNC servers. The first one is the main one, the two others are fallbacks. Here is what we believe to be an operation name. We have found several of them during the investigation. Some of them are shown on the screen. And as I mentioned before, Celerico has the ability to load external plugins. When loading one plugin it will store the path of this plugin at the end of the configuration. There is room for 10 plugins and in the initial configuration all those fields are empty because the payload is dropped without any plugins. Now let's have a look at this payload. It comes with 26 commands and each command is identified by a unique number. Those commands are registered during the runtime using an exported function named register new command. And you can see here the registration of a few commands like for example Celerico can read, write and define on the disk. It can also list all running processes. It can manipulate the registry. Also it can update itself, its configuration or load or unload external plugins. Speaking of plugins, they come as DLL and they will be loaded in the same address space than the payload. And thanks to that they can use any function of the main payload. So as shown in the picture, here is what happens when the payload initializes a plugin. It calls the plugin in its export passing some function addresses as arguments. In particular it provides the addresses of the function handling the output formatting and also the command registration so the plugin can register any additional command if needed. And here is an example of a plugin used in parallel with Celerico. This module was just registering a new command this time opening an HTTP channel with the CNC server. And also while Celerico is terminating it will unload every plugin by calling the underneath export. In this case the export only deletes the previously registered command. Let's go back to our channel event now. We are still day one and Celerico was deployed 30 minutes after the initial infection. Same day, four hours later, Serge meets Xagent which was downloaded by Celerico like Celerico. Xagent is a modular backdoor written in C++ and for each there is at least a Windows, a Linux, an iOS and an Android version. Xagent is the flagship backdoor of the Senate group. They used it in most of their operation over the last few years and usually after the reconnaissance phase like in Serge case. We dated Xagent apparition around November 2012 and it is still in use. So at this point you might expect some C++ reverse engineering on Xagent binaries right except that due to a mistake from the operators we recently got access to the source code of Xagent and here is the extract of the source files we found. It is a fully working C++ project corresponding to the Linux version of Xagent and it was compiled in July 2015 which we know because there is a bin folder with a binary in it which was created at this date and the source code contains around 18k lines of code among 59 classes so it is pretty big. We believe this new source code derives from the Windows version of Xagent because at several places the developers just commented out some Win32 API calls to replace them by Linux API calls like in this case for thread termination and there are several versions of Xagent. The source code is major version 2 and the currently used binaries are version 3 but it still matches the core logic of the V3 binaries. As you will expect in such a big project the source code is heavily commented. The comments are a mix of badly written English with some Russian and sometimes some ASCII art to describe the structures but with that being said let's look at the communication workflow. So here we got a simplified view of the communication workflow in Xagent. To give you an idea at the center on the Xagent infected computer the kernel run method is an infinite loop which fetches the messages from the module. Notice that the kernel is in itself a module. Those messages are encrypted C++ objects which are serialized and encrypted by the kernel and then given to the channel controller. The channel controller is the interface to contact the CNC server and it forwards the messages to the CNC server. In the other direction the channel controller regularly asks the CNC server for an encrypted message for each module and the message is then given to the kernel which serializes and decrypts it and then gives it to the internal module. One of the beauty behind this simple design is that the channel controller is unaware of the current actual implementation of the network channel which can be based on HTTP or emails and in fact the channel controller will switch automatically to a different channel if the currently used one is not working. And now let's dig a little bit into the email channel. How is it working? So the workflow is quite simple. When the channel controller I just described sends a message for the CNC server the mail channel sends an email with the message as an attachment to an inbox. Depending on the sample the inbox can be a free mail address a send-it address or a hacked email address. And the CNC server then retrieves the email from the inbox and processes the attachment. In the other direction if the CNC server has a message for one ex-agent module the ex-agent message has an attachment in an email to a different inbox from which ex-agent mail channel retrieves the email. So that sounds easy right? But the thing is when you use emails to implement a command and control channel first you need to have a way to distinguish your email from unrelated emails like spam or legitimate emails in the inbox. And second you need to bypass spam filters on your way to the inbox. And for those reasons send-it developers implemented what they call the P2 scheme which they describe as a level 2 protocol. This protocol defines how ex-agent emails are built and here is an example of an email following the protocol. So the protocol defines the subject of the email as the best 64 encoding of a value following this format which starts with a random key then a value called sub-stocken and finally the agent ID with the same key. The sub-stocken is known by both the CNC server and the ex-agent and that's how they can distinguish their emails from unrelated emails. They decode the subject and check if the sub-stocken is here. In practice in many ex-agent samples sub-stocken is a 7 byte values that strangely contains the string China. The P2 protocol also defines the body of the emails and the attachment name remember that the attachment contains the actual message so those are simply the basic 64 encoding of some random values. So that's the P2 protocol but actually in our Linux source code the developers replaced the P2 protocol with some hard-coded values. We call it the Georgian protocol because those values are worn in the Georgian language. For example the email subject is set to Alina Mary which refers to a national ID number in Georgian and the body is set to GammaJobba which means Hello and the attachment name begins with DetailUri which means Detailed in Georgian followed by a timestamp. This was probably done in order to not attract attention in the Georgian infrastructures or maybe in a hacked Georgian inbox. And to conclude the next agent now and has a bonus I just want to say a few words on ex-agent CNC infrastructures because once again we got access to some source code and the source code this time was left in an open directory on a senate server and it was indexed by Google such that we found it by some queries for the P2 protocol previously described. So the source code is actually a proxy server for a backend CNC server and you can see from the source files here that it is developed in Python and it was used between April and June 2015 which we know because there are some log files with timestamps in it. It contains around 12K lines of code because this is actually more than a simple really. What it does is it will translate the email protocol from ex-agent infected computers into requests over HTTP protocol for the backend CNC server. Those HTTP requests follow a specific format called the P3 protocol level 3 protocol and by the way we believe they use the same kind of setup for the HTTP channel rather than the email channel even if this particular proxy is just for the mail channel. So enough with ex-agent now. Let's come back to the channel event. We are still day one after the initial infection cell record was deployed ex-agent was deployed and at this point said it got two spying backdoors on the target at the same time such that if one of them is detected they don't lose access to the computer. And the next days are going to be the time for information ex-filtration and lateral movement. So during the next three days Zenit is going to drop and search computers and password extractor tools. They often use a set of tools called security exploded that are freely available on the internet. And those tools can extract passwords from a variety of software such like browser or email clients. The problem is they are well known and they are often detected by antivirus. So Zenit developed their own password extractor tools in particular there is one for Windows live mail that is dropped on search computer. It has been compiled specifically for him as it searches for the password in a hard-coded path that only exists on search computer. Of course the operators try to retrieve the password on search computer. For that they got some custom tools to dump Windows passwords from registry hives and without surprise they use Mimikats a lot. And the output is often stored in a file named py.log. All these tools may be deployed with the LP exploit depending on the target configuration. Serge may also meet the screenshotter which is a small custom tool they made to take screenshots. When it is executed it takes 15 times in a row. And finally Serge meets external which is a custom network proxy tool to contact computers that are normally unreachable from internet using the infected computer as a pivot. This component appeared in May 2013 and it is still in use. So how does it work exactly? Here is the initial situation. The Zenit CNC server is on internet. Search computer is in its organization network and is infected with external. Computer A and computer B are in the same network but they are not reachable from internet and they are not under the Zenit control. But they are reachable from search computer. So external begins an encryption handshake with the CNC server and the purpose of this handshake is to share RC4 key to encrypt the communication between the two of them. To do so external and the CNC server both have a copy of a big table filled with random looking bytes. Let's call this table T. Then external randomly picks an offset O in the table T and the 32 byte row starting at this offset O is the key that external wants to share with its CNC server. But external does not send the key of course it sends the offset O plus a proof that external really knows the table T. This proof is another row of T located at a fixed offset this time and encrypted with the chosen key. The CNC server checks the proof and if it's correct that is if it gives the expected value once decrypted it answers ok and sets its RC4 key to the 32 byte row starting at the offset O. So at this point all the data exchange between the CNC server and external will be RC4 encrypted with the chosen key. Notice that sending the offset and not the key prevents the decryption of the traffic by hip dropper. Also since 2014 this encrypted link is encapsulated into TLS which is not a bad idea except that external does not verify the certificate of the CNC server. And now the next step once the encrypted link has been established the CNC server is to open external with a target computer using an IP address or domain name and a TCP port number. External then opens the TCP connection with the target computer here computer A and starts relaying data between computer A and the CNC server in both directions. Notice that the link between external and computer A is not encrypted so that any kind of TCP data can be forwarded to the target computer. We don't know exactly what kind of traffic they are the operator are usually sent through the external but it has been reported to be used with PS exec like tools that allows the execution of command on a remote computer without having an agent running on this computer. Finally each tunnel is identified by an ID such that external can manage several of them and so for example another tunnel can be open with the computer B and external will take care of the routing of the traffic in the correct tunnel. So to summarize the send it CNC server can now reach computer A and computer B over TCP using search computer as a pivot. Enough with external now let's go back to our channel event we just had 3 days of information exfiltration and lateral movement the last action from the operator during this first week will be to set up an additional persistence method on search computer for long term monitoring. So Friday around 11 am the long term persistence method consists in a special exigent binary copied in the Microsoft office folder under the name MSI.DLM this copy operation is done by another binary dropped on the machine you can see it here and to write in the office folder this binary needs to have administrative writes and for that it first executes a local privilege escalation exploit and then it copies the exigent binary named MSI.DLM in the office folder to understand what will happen next first you need to know that there is a legitimate WindowsDLM named MSI.DLM stored in the system 32 folder this DLM is usually used by office application in particular and also you need to know that the exigent binary exports the exact same function names than this legitimate DLM so at this point you certainly guessed what happened next each time search start office exigent MSI.DLM is loaded and not the legitimate MSI.DLM because it is in the local folder of office and thus it is found before the system 32 file exigent then loads the real MSI.DLM from the system 32 folder and it fills its own export table with the addresses of the function of the legitimate DLM such that each call to exigent export will actually go to the legitimate DLM and the application won't crash finally it starts its malicious logic in other words it's a simple search order hijacking based on the fact that they can write into the office folder and by the way we have also seen recently this search order hijacking technique with a linking folder DLM dropped into the Windows folder so that concludes the story of search this textbook case what happened to the Zenit target during the first day of infection and now we have a pretty good idea of what the Zenit ecosystem look like let's have a look at the weird case we found last year some day in September 2015 we received an unusual sample it was a dropper previously used by Zenit and it was showing this document as a decoy as you can see it is a legitimate invitation for a geopolitics conference and this document is actually publicly available on the internet sadly the payload is just a downloader and even worse it is written in Delphi and since we are good at naming things we named it Dandel the workflow is simple though it downloads a configuration file and based on this configuration it will download and execute another payload the person method was just the run registry key so nothing really exciting so far except that we found another Dandel deployment in 2013 this time and this graph describes the deployment at the time you can see we had Dandel embedded in the same dropper and this time with a small helper and a bootkit installer so even if this bootkit only infect MBR based system this installer will infect multiple versions of windows running on an x86 processor so here are the first sector of the disk after a successful infection the first sector is the a new malicious MBR the second sector is the original MBR code XORed with a 1 byte key and starting at the third sector we have the core of the bootkit code also XORed at last we have a RC4 encrypted driver and the installer also hides 2DLL in the registry but I will come to that later so let's describe a very simplified version of this workflow first the malicious MBR is executed in a very classic way it will hook the interrupt 0x13 which handles all low-level read and write operations and by doing that the bootkit is able to intercept every byte right from the disk during the loading thanks to that the bootkit searches the memory for some specific bytes in order to patch them those bytes belong to boot MBR which is the next step into the boot chain as explained before so at this point boot MBR is patched and then the bootkit takes control again and this time it will patch the function osll transfer to kernel located in winload.exe which is the next step in the boot chain like the name suggests this function will call the kernel entry point so winload is now patched and the bootkit takes control of the execution before the kernel is executed at this point the kernel and all its basic drivers are mapped into the virtual memory and the integrated checks are already performed so what this bootkit does now is it will locate the function mmmap.iospace and it will set the resource section of the ACPI driver to executable before hiding some code in it it will also hook the ACPI driver entry point to execute this code the bootkit need to save all those important addresses somewhere because the bootkit physical address won't be accessible after the kernel initialization so it will save everything in the kernel header you can see here we have the bootkit base address the address of the function mmmap.iospace and also the original bytes of the ACPI entry point and now the driver is patched and when the driver is loaded the hook will be executed so first the code hidden in the resource section will hide back the original entry point instructions to avoid being detected by the kernel patch protection and this is where the bootkit will map its safe physical address into the virtual address space by calling the function mmmap.iospace and after that it will be able to decrypt the hidden driver so there is three components involved at this moment the bootkit driver will decrypt a first dll name the user-mod component by the developers and then they will simply map it into explore.exe then this user-mod component will decrypt and load dll itself hidden in the registry as well but this workflow was kind of odd because the driver could have loaded dll directly and looking at the user-mod components we have found evidences that dll wasn't the intended payload used with this bootkit at first more precisely when injecting dll it sets this specific exported variable to true but the variable doesn't exist in any known samples of dll so dll was probably not the original payload we believe that the bootkit or at least the driver is connected to the black energy malware because we have found several shared features between the two families the user-mod component is manually mapped into the explorer's memory and all this code is shared between dll and some early samples of black energy and to do so there is three exports used in the driver to load the user-mod component respectively entry, e-p data and dummy those exports are also present in black energy and used in the exact same way so this might indicate that the developers have access to black energy source code or however we are not aware of any bootkit coming with black energy toolkit anyway enough with this bootkit let's go back to dll looking at some other samples of dll we have found another deployment in 2014 and this time dll came with a kernel-mod bootkit so the bootkit proposes to ensure dll persistence on the system by injecting it into explorer.exe and also to hide everything related to dll to the user and to the system so you can't see anything on the disk thanks to the developer they just left all kind of debugging information in the samples so here is the exact debugging output during the driver loading we can see the folder and the registry key to hide the driver to load and the dll to inject we have two variants of this bootkit the first version the rootkit was targeting windows xp computers and was doing some simple ssdt hooking and the other version is a main filter driver it was targeting more recent version of windows and it is based on an open source example made by Microsoft also we have found a 64-bit sample in the wild but we are missing the dropper so we don't really know how it managed to bypass the driver signing policy and interestingly it looks like some driver are made for specific configuration like this one probably targeting a computer running kaspersky internet security so to summarize we have found a few samples of Dunder used during the past three years which is not a lot they were very careful with it maybe they only used it for some specific targets the cnc server those samples were reporting on was active during two years it went under the radar for quite a long time and they used the bootkit working on xp and more recent version of windows they made a multiple rootkit for the same operating system versions in short they worked very hard on the persistence methods which is unusual in such cases and finally we know Dunder was used to download cellrico external and ex agent mentioned earlier so this is definitely connected to sendnet so it is now time to conclude with some speculative membranes because after looking at so many sendnet binaries the temptation is big to draw some general conclusions and I am not talking about their software talking about attribution but more about their software in particular there is a question we were often arguing between us as we try to show in this presentation the diversity of the sendnet software is quite impressive if you think about it there is a delphi downloader a complete windows bootkit a modular c++ backdoor and there is an exploit kit infrastructure with a lot of javascript and custom exploits and the list goes on so this diversity is good for them as it makes tracking and detection harder but the question is how did they come up with this vast of an ecosystem do they develop themselves or do they outsource development and we have a few hints regarding that question first the sendnet binaries are often compiled specifically for a target and after it has been infected the basic example of that is this ex agent sample containing the login and password of employees in the ministry internal affairs of georgia and they were used in the mail channel this sample was made specifically to be run inside this ministry network and more generally sendnet malware are in constant evolution in particular external set uploader and ex agent changed a lot since their first version in other word developers are part of a team not outside are paid for a one time job also among the variety of the sendnet software there are some shared techniques like building a rc4 key as the concatenation of a hard-coded value and a random value or using hard-coded tokens in network messages these are just two example of techniques present in several sendnet software developed in different languages so this is not a copy pasted code but more like a re-implementation of the same idea so this may indicate that we are behind all these softwares another remark on the development process is that there are some basic programming mistakes in the sendnet software for example, here in Linux ex agent a thread handle named handle get packet is terminated with petred exit but it should be handle send packet as you can see from the condition before and the commented windows code so probably a wrong copy paste in the Linux version here in external there is a report message which is built for the CNC server when the tunnel has been opened with the target computer the IP address and the port number of the target are written in a 6 byte buffer except that the memory pointer is not incremented between the two writes and thus the port overwrites the IP address and we can assume the CNC does not even check the report so the mistake has gone unnoticed and these are just two quick examples of mistakes you can find in the sendnet code so the developer does not have a code review process and overall sendnet code often feels really hack-ish following this idea the sendnet software seems sometimes inspired by classic crimeware for example, set uploader reduced persistence methods from crimeware and shares some code with Carver and on the off bootkit code bears some similarities with some earliest sample of black energy we may be tempted to conclude that the developer are connected in some way with some classic crimeware communities and finally the exploit kit developer use funny names like Frodo and Lowell for HTML tags or Messi.Leonel which is a soccer player for the binary to download from an exploit so if they are able to use those names in production we can guess that they are not working in a very formal environment to say the least so to summarize this speculation we believe that sendnet has some in-house skilled developers working with little supervision and those guys have ties with crimeware underground which is not so common for this kind of group and if you don't agree I would be glad to discuss about that enough speculation now it's time to conclude sendnet activity increased a lot during the last two years they are doing targeted attacks on a lot of different targets now and their toolkit is in constant evolution so there is definitely more fun to come for malware researchers so thank you very much for your attention now as I said there is a lot of time for talks we don't have unfortunately microphones that we can pass around to the audience please go to the microphone stand over there or here let's start with the internet do we have questions from the internet one question is this russian state malware I want to answer this question I can discuss about that we don't do any sort of attribution because this is very difficult to do another question from the internet no more serious questions from the internet just now when you exit please be quiet respect that there are some people in here who just want to know a little bit more there is one question over there to the right I have a question in the malware period that you found a lot of allegedly US malware or NSA malware was found do you see any development in code based upon the ideas that they get from these malware analysis that have been made in those periods I would say yes I didn't talk about it in this presentation but for example external wasn't obfuscated before at some point and then they started to obfuscate some more recent samples so I would say yes okay thanks more questions yeah there is one question over there hello I have like maybe obvious question maybe speculative do you think this group has some ties to like Russian government or Russian secret services or something I already told you I won't answer this question because we know they can use Russian language but that doesn't mean anything sorry I didn't understand the we didn't see anything sorry sorry I need to repeat the question so your question was was there any reaction of your research on their side is that right? like I said before when we started to analyze external we've seen some obfuscation techniques implemented in the in the software also the research is quite young we've published it like a few months ago so I would wait until so I would wait a little to see if they are actively switching things up but they are definitely reading the papers I would say I think so there is one question the back over there have you found any patterns in the targets they attacked sorry I didn't have you found any patterns in the targets they attacked have they reacted to some of the when the targets probably they that was the first question the second is have they reacted to any of the reactions of the targets what do you mean? well have they did they have follow up hacks on different targets because they found some information on the first ones well like yeah because the second stage backdoors are usually not dropped before the reconnaissance phase if the target isn't interesting you won't see them on the computer so is this what you wanted to know? no I mean they have targeted they had some attacks on specific targets you told us and so you've probably talked to the targets and no why not because well some targets as you can see it's like embassies so that's not a very specific people so we can try to reach them but they don't obviously answer us every time sometimes people try to reach us and they are doing like the middle I would say but I never hear about anything from the targets like when I give them the report or there is one question over there in the back one more the work you are doing are you concerned about your personal safety? I mean I started this work a few years ago so we'll see more questions? internet so one more from the internet what do you think of the crowd strike report two people are asking which one? they made multiple reports the one about the democratic national committee hack I have no further information right now I thought so they made quite a few they still got enough time for questions so here we got one did you find any vulnerabilities when you investigated the code? I think my colleagues did found some like also when the Google threat analysis team released the advisories about flash and the winter case I found the samples right after that they wanted public but some other companies published something about that so sometimes you can find it's rare but you can find them and follow up did you find any vulnerabilities in the communication to the command control server or anything else? we don't look about stuff like this I mean they made some programming mistakes in the client side of the softwares but they don't know about the CNC servers and everything more questions? one from the internet are there any patterns to the fun names that are used? I don't think so that's an interesting question anything more from the internet? could you use the microphone please or that would be great thanks do you believe that the US agencies that have done some sort of attribution that they have more information than you? than me? more information than me? more than you presented today? probably like I said at the beginning we might be missing part of the picture and this is why some other companies are publishing very good reports so definitely there's a question over there again this might be a dumb question but you said the targets don't usually contact you so how do you know about the targets? well we have telemetry system this is very difficult I can't identify targets like I know we have hits we have binaries we have samples we are analyzing them we find some similarities we when he told me about targets I was thinking about the bit.ly list we found and this is why we didn't contact any emails like I said if you think you are targeted you can come see me and I will look into this list if there is some TLDs that might interest you you're welcome more questions internet? yeah please have there been any mass deployments of this type of malware or is it only very individual attacks? yeah it's very targeted there is not like widespread infections or anything anything more? internet? sorry clarification on the previous question specifically interested in the report that attributes Russia to the DNC and then there's another related question asking are there differences between crowd strikes reports and yours? I don't believe we are talking about the same things because when we when we see something published like the recent exploits we are not like adding this to our paper since it's already on the internet our white paper is a technical breakdown of their toolkit like and external and I don't think they talked about this one more questions internet audience we still got time internet sure internet go ahead internet is asking if the targets are any better protected now if they are a bit more predicted well we are detecting the samples so if they are running e-sets more security maybe the goal of the white paper is to provide IOCs also for the sysadmins or people that are managing infrastructures so if you are looking for that you can download the white paper on the blog and there is a pretty extensive list if you want to protect your infrastructure auto incident response of course because we are not doing that is there any questions in here still internet something there no it's getting quiet well then there is one more question over there hello it seems that a lot of the texts are focused on windows machines yeah like I said they have a second stage back door for iOS android the source code of xagent is the next version we also have seen set up other samples for os 10 I think if I recall correctly so they have like a big arsenal welcome ok we got one question over there if there are no further questions this is my first visit to ccc does anyone have a good tip for a good bar in the end guys I think social life we can discuss a little bit later so once again merci beaucoup big applause