Visiting The Bear Den
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Campos, Jessy
Calvet, Joan
Dupuy, Thomas
Sednit, a.k.a Fancy Bear/APT28/Sofacy, is a group of attackers operating since at least 2004 and whose main objective is to steal confidential information from specific targets. Over the past two years, this group's activity increased significantly, in particular with numerous attacks against foreign affairs ministries and embassies all over the world. They are supposedly behind the DNC hack, and the WADA hack, which happened earlier this year. This talk presents the results of a two-year hunt after Sednit, during which we dug up and analyzed many of their software.
 Jesse himself is a hardcore malware searcher, 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 SEDnits 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 SEDnits, 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 toolset. And after that, I will present a different and strange operation also run by the SEDnits 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 SEDnits 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 SEDnits 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 is 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 standard 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 standard 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 subteams. 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 standard toolkit with Serge. Serge is actually a code name for a fictional send-in 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 send-in toolkit. So somewhere recently, it's Monday, 9.30 AM, 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 Setkit, which is the send-in exploit kit, and it is only used for targeted attacks. As we just saw, its entry point is usually URL's mimicking legitimate websites, and the exploit kit infection usually starts from targeted phishing emails, but we've also seen iframe redirection from Setkit from hacked websites. We found Setkit 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 Setkit landing page contains around 200 lines of JavaScript, and the code stayed the same over the last year. You can see here a beautiful 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 commands 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 it's 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 visit the send it exploit factory. So here is the list of exploit that we saw from setkit 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 X 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 of our flow in the Internet Explorer VBScript engine that allows arbitrary read write operations. We saw setkit 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 a 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 BlackHatch USA 2014. And once again, the same group are not afraid of digging into complex exploit 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 set uploader. So the set uploader 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 set uploader 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, set uploader 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 the 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 techniques. 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 RenderL42. Those two techniques were first seen in other malware's. And seeking inspiration in crimeware is something very common for the Cine group. At this moment, the payload is running on such 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 parse 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 hard-coded 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 CIDO for their 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 chain of events. We are still day one, and Search Computer is infected with CIDOploder. Same day, 30 minutes later, the operator are now sure that Search is not a malware researcher. CIDRICO is downloaded on Search Computer by CIDOploder. 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 CIDRICO arrived on a system embedded in a dropper, which usually installs 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 values time out, so I don't find them really interesting. Here is the search computer name. Here you have a flag to specify if 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. So 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 the 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 plugin. 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's 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. Xagent is a modular backdoor written in C++. As for which, 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 operations over the last few years, and usually after the reconnaissance phase, like in Serge case. We dated Xagent operation 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 threat 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 serialize and decrypts it, and then gives it to the intended 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, has 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, it sends a message as 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, the send it developers implemented what they call the P2Scheme, which they describe as a level two protocol. This protocol defines how ex-agent emails are built. And here's 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 substoken, xord with the key, and finally, the agent ID, xord with the same key. The substoken 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 substoken is here. In practice, in many ex-agent samples, substoken is a seven byte values that strangely contains the string China. The P2Protocol 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 P2Protocol. But actually, in our Linux source code, the developers replaced the P2Protocol with some hard-coded values. We call it the Georgian protocol because those values are word in the Georgian language. For example, the email subject is set to Peralino Mary, which refers to a national ID number in Georgia. And the body is set to GammaJobba, which means hello. And the attachment name begins with data URI, which means detailed in Georgian, followed by a timestamp. So this was probably done in order to not attract attention in the Georgian infrastructures or maybe in a hacked Georgian inbox. And to conclude on ex-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 the send-in server. And it was indexed by Google, such that we found it by some queries for the P2Protocol previously described. So the source code is actually a proxy server for a back-end 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 of HTTP protocol for the back-end CNC server. Those HTTP requests follow a specific format called the P3Protocol, level 3Protocol. 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 ChinF event. We are still day one. After the initial infection, cell record was deployed. Ex-agent was deployed. And at this point, Cednet 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, Cednet 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 Cednet 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 Windows 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 pi.log. All these tools may be deployed with the LPE exploit, depending on the target configuration. Search may also meet the screenshotter, which is a small custom tool they made to take screenshots. When it is executed, it takes 15 screenshots in rapid succession when the mouse moves. And it does that 15 times in a row. And finally, Search 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 CineCNC 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 CineCNC control. But they are reachable from Search Computer. So external begins an encryption handshake with the CineC server. And the purpose of this handshake is to share RC4K to encrypt the communications between the two of them. To do so, external and the CineCNC server both have a copy of a big table filled with random looking bytes. That's called the stable 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 CineC 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 CineC 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 exchanged between the CineC 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 CineC server. And now the next step. Once the encrypted link has been established, the CineC server can order external to open external with a target computer using an IP address or a domain name and a TCP port number. External then opens a TCP connection with the target computer, here computer A, and starts relaying data between computer A and the CineC server in both directions. That is, 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 is usually sent through the external, but it has been reported to be used with PSXAC-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 opened with the computer B. And external will take care of the routing of the traffic in the correct tunnel. So to summarize, the CineC 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 three 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 ex-agent 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 ex-agent binary named MSI.DLM in the Office folder. To understand what will happen next, first, you need to know that there is a legitimate Windows DLL named MSI.DLM stored in the system 32 folder. This DLL is usually used by Office application in particular. And also, you need to know that the ex-agent binary exports the exact same function names than this legitimate DLLM. So at this point, you certainly guessed what happened next. Each time search start office ex-agent 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. Ex-agent 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 DLLM, such that each call to ex-agent export will actually go to the legitimate DLLM 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 DLLM dropped into the Windows folder. So that concludes the story of search, this textbook case of what happened to the CNIT targets during the first day of infection. And now we have a pretty good idea of what the CNIT ecosystem looked 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 CNIT. 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 Dondelf. The workflow is simple, although 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 Dondelf deployment in 2013 this time. And this graph describes the deployment at the time. You can see we had Dondelf embedded in the same dropper, and this time with a small helper and a bootkit installer. So even if this bootkit only infects MBR-based system, this installer will infect multiple versions of windows running on the X86 processor. So here are the first sector of the disk after a successful infection. The first sector is 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 bootMGR, which is the next step into the boot chain, as explained before. So at this point, bootMGR is patched. And then the bootkit takes control again. And this time, it will patch the function osl-arch-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.io space. 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 needs 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.io space, 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 write 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.io space. 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 DLN name, the user mode component, by the developers. And it will manually map it into explore.exe. Then this user mode component will decrypt and load DLN itself, hidden in the registry as well. But this workflow was kind of odd, because the driver could have loaded DLN directly. And looking at the user mode components, we have found evidences that DLN wasn't the intended payload used with this bootkit at first. More precisely, when injecting DLN, it sets this specific exported variable to true. But the variable doesn't exist in any known samples of DLN. So DLN 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 some several shared features between the two families. The user mode component is manually mapped into the explorer's memory. And all this code is shared between DLN and some early samples of black energy. And to do so, there is three exports used in the driver to load the user mode component, respectively entry, EP 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 Dundalf. Looking at some other samples of Dundalf, we have found another deployment in 2014. And this time, Dundalf came with a kernel mode rootkit. So the rootkit purpose is to ensure Dundalf persistence on the system by injecting it into explorer.exe. And also to hide everything related to Dundalf 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 to hide the driver to load and the DLL to inject. We have two variants of this rootkit. The first version, the rootkit was targeting Windows XP computers and was doing some simple SSDT hooking. And the other version is a many 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 drivers are made for specific configuration, like this one probably targeting a computer running Casper's Key Internet Security. So to summarize, we only 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 rootkit 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 Celerico, 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, not 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 of 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 words, 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 an Rc4 key as the concatenation of a hard-coded value and a random value, or using hard-coded tokens in network messages. These are two just, are just two examples 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 the same developers 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 handleGetPacket is terminated with PetredExit. But it should be handleSendPacket, as you can see from the condition before. And the commented Windows code. So probably a wrong copy-paste in the Linux version. Also, there is a, here in external, there is a report message, who 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 six-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-less. Following this idea, the Sendnet software seems sometimes inspired by classic crimeware. For example, set up a reduced persistence methods from crimeware and shares some code with Carbuff, while Dundalf 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 uses funny names like Frodo and Lol for HTML tags, or Messi de Lionel, 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 skill 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 see this. [?]. [?]. [?]. [?]. [?]. [?]. [?]. [?]. [?]. [?]. [?]. [?]. [?]. [?]. [?]. [?]. [?]. [?]. All right. There is a lot of time for talks. We don't have, unfortunately, microphones that we can pass around in the audience. Please go to the microphone stand over there or here. OK, let's start with the internet. Do we have questions from the internet? One question. Is this Russian state malware? No. 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. Please, when you exit, please be quiet. Respect that there are some people in here who just want to know a little bit more. There's one question over there to the right. Yeah, I have a question. In, let's say, the malware period that you found, a lot of allegedly US malware or NSA malware was found. Do you see any development in code that is 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. OK, thanks. More questions? Yeah, there is one question over there. Hello. I have maybe obvious question. Maybe speculative. Do you think this group has some ties to 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. Right? Have they reacted to you researching the malware? Sorry, I didn't understand the. Have they reacted to you researching the malware? 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? OK. Like I said before, when we started to analyze external, we've seen some obfuscation techniques implemented in the software. Also, the research is quite young. We've published it like a few months ago. So I would wait until 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 in 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, well, when the targets, probably 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, 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? Now, I mean, 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's one question over there in the back. Hi. One more. The work you are doing, are you concerned about your personal safety? I mean, I started this work like one year ago, so we'll see. More questions? Internet. So one more from the internet. What do you think of the CrowdStrike 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 that was overcast. They made quite a few. We still got enough time for questions. Yeah, here we got one. Did you find any vulnerabilities when you investigated the code? I think my colleagues did find some. Like also when the Google Threat Analysis team released the adversaries about flash and the winterly case, I found the samples right after that. They weren't public. But some other companies published something about that. So sometimes you can find zero days. It's rare, but you can find them. And a follow up. Did you find any vulnerabilities in the communication to the command control server or something else? We don't look about stuff like this. I mean, they made some programming mistakes in the client side of the software, but they don't know about the efficiency levels and everything. More questions. Yeah, 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? 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? Well, more than you presented today. Yeah, 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, same microphone? 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. And we find some similarities. When he told me about targets, I was thinking about the Bitly list we found. And this is why we didn't contact any emails. And 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 may 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 widespread infections or anything. Anything more? Internet? Well, we saw clarification on the previous question. We were specifically interested in the report that attributes Russia to the DNC. And then there's another related question asking, are there differences between the two? And then there's another related question asking, are there differences between CrowdStrike's reports and yours? I don't believe we are talking about the same things, because when we see something published by the recent exploits, we are not adding this to our paper since it's already on the internet. So our white paper is a technical breakdown of their toolkit, like X-Agent, external, and I don't think they talked about this one. More questions? Internet? Audience? We still got time. Internet is asking if the targets are any better protected now? If they are more protected, well, we are detecting the samples, so if they are running, it's 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. Or do incident response, of course, because we are not doing that. I don't see questions in here. Still? Internet? Something there? No, it's getting quiet. Well then, there is one more question over there. Hello. It seemed that a lot of the texts are focused on Windows machines. Like I said, they have a second stage back door for iOS, Android, Linux, and the source code of X-agent is the Linux version. And we also have seen set up other samples for OS 10, I think, if I recall correctly, so they have a big arsenal. Welcome. Okay. We got one question over there. If there are no further questions, as is my first visit to CCC, does anyone have a good tip for a good bar in Android? Guys. Maybe. I think social life, we can discuss a little bit later. So once again, merci beaucoup. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Once again, merci beaucoup. Thank you. Thank you.
 Jesse himself is a hardcore malware searcher,  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  SEDnits 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 SEDnits,  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 toolset.  And after that, I will present a different and strange  operation also run by the SEDnits 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 SEDnits 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 SEDnits 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 is 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 standard 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 standard 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 subteams.  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 standard toolkit with Serge.  Serge is actually a code name for a fictional send-in 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 send-in toolkit.  So somewhere recently, it's Monday, 9.30 AM,  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 Setkit, which  is the send-in exploit kit, and it is only  used for targeted attacks.  As we just saw, its entry point is usually  URL's mimicking legitimate websites,  and the exploit kit infection usually  starts from targeted phishing emails,  but we've also seen iframe redirection from Setkit  from hacked websites.  We found Setkit 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 Setkit landing page contains around 200 lines  of JavaScript, and the code stayed the same over the last year.  You can see here a beautiful 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 commands 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  it's 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 visit the send it exploit factory.  So here is the list of exploit that we saw from setkit  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 X 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 of our flow  in the Internet Explorer VBScript engine  that allows arbitrary read write operations.  We saw setkit 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 a 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 BlackHatch USA  2014.  And once again, the same group are not  afraid of digging into complex exploit  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 set uploader.  So the set uploader 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 set uploader 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, set uploader 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 the 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 techniques.  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 RenderL42.  Those two techniques were first seen in other malware's.  And seeking inspiration in crimeware  is something very common for the Cine group.  At this moment, the payload is running on such 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 parse 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 hard-coded 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 CIDO for their 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 chain of events.  We are still day one, and Search Computer  is infected with CIDOploder.  Same day, 30 minutes later, the operator  are now sure that Search is not a malware researcher.  CIDRICO is downloaded on Search Computer by CIDOploder.  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 CIDRICO arrived on a system embedded in a dropper, which  usually installs 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 values time out,  so I don't find them really interesting.  Here is the search computer name.  Here you have a flag to specify if 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.  So 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 the 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 plugin.  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's  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.  Xagent is a modular backdoor written in C++.  As for which, 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 operations  over the last few years, and usually  after the reconnaissance phase, like in Serge case.  We dated Xagent operation 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 threat 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 serialize and decrypts it,  and then gives it to the intended 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,  has 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, it sends a message as 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, the send it developers  implemented what they call the P2Scheme, which they describe  as a level two protocol.  This protocol defines how ex-agent emails are built.  And here's 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  substoken, xord with the key, and finally, the agent ID,  xord with the same key.  The substoken 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 substoken is here.  In practice, in many ex-agent samples,  substoken is a seven byte values that strangely  contains the string China.  The P2Protocol 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 P2Protocol.  But actually, in our Linux source code, the developers  replaced the P2Protocol with some hard-coded values.  We call it the Georgian protocol because those values  are word in the Georgian language.  For example, the email subject is  set to Peralino Mary, which refers to a national ID  number in Georgia.  And the body is set to GammaJobba, which means hello.  And the attachment name begins with data URI,  which means detailed in Georgian, followed by a timestamp.  So this was probably done in order  to not attract attention in the Georgian infrastructures  or maybe in a hacked Georgian inbox.  And to conclude on ex-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 the send-in server.  And it was indexed by Google, such that we found it  by some queries for the P2Protocol previously described.  So the source code is actually a proxy server  for a back-end 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 of HTTP protocol for the back-end CNC  server.  Those HTTP requests follow a specific format  called the P3Protocol, level 3Protocol.  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 ChinF event.  We are still day one.  After the initial infection, cell record was deployed.  Ex-agent was deployed.  And at this point, Cednet 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, Cednet  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 Cednet 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 Windows 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 pi.log.  All these tools may be deployed with the LPE exploit,  depending on the target configuration.  Search may also meet the screenshotter, which  is a small custom tool they made to take screenshots.  When it is executed, it takes 15 screenshots  in rapid succession when the mouse moves.  And it does that 15 times in a row.  And finally, Search 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 CineCNC 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 CineCNC control.  But they are reachable from Search Computer.  So external begins an encryption handshake with the CineC  server.  And the purpose of this handshake is to share RC4K  to encrypt the communications between the two of them.  To do so, external and the CineCNC server  both have a copy of a big table filled  with random looking bytes.  That's called the stable 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 CineC 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 CineC 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 exchanged  between the CineC 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 CineC server.  And now the next step.  Once the encrypted link has been established,  the CineC server can order external to open external  with a target computer using an IP address or a domain name  and a TCP port number.  External then opens a TCP connection  with the target computer, here computer A,  and starts relaying data between computer A  and the CineC server in both directions.  That is, 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 is usually sent through the external,  but it has been reported to be used with PSXAC-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 opened with the computer B.  And external will take care of the routing of the traffic  in the correct tunnel.  So to summarize, the CineC 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 three 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 ex-agent 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 ex-agent binary named  MSI.DLM in the Office folder.  To understand what will happen next,  first, you need to know that there is a legitimate Windows  DLL named MSI.DLM stored in the system 32 folder.  This DLL is usually used by Office application in particular.  And also, you need to know that the ex-agent binary exports  the exact same function names than this legitimate DLLM.  So at this point, you certainly guessed what happened next.  Each time search start office ex-agent 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.  Ex-agent 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 DLLM,  such that each call to ex-agent export  will actually go to the legitimate DLLM  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 DLLM  dropped into the Windows folder.  So that concludes the story of search, this textbook case  of what happened to the CNIT targets  during the first day of infection.  And now we have a pretty good idea of what the CNIT ecosystem  looked 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 CNIT.  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 Dondelf.  The workflow is simple, although 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 Dondelf deployment in 2013  this time.  And this graph describes the deployment at the time.  You can see we had Dondelf embedded in the same dropper,  and this time with a small helper and a bootkit installer.  So even if this bootkit only infects MBR-based system,  this installer will infect multiple versions of windows  running on the X86 processor.  So here are the first sector of the disk  after a successful infection.  The first sector is 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 bootMGR, which  is the next step into the boot chain, as explained before.  So at this point, bootMGR is patched.  And then the bootkit takes control again.  And this time, it will patch the function  osl-arch-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.io space.  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 needs 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.io space,  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 write 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.io space.  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 DLN name,  the user mode component, by the developers.  And it will manually map it into explore.exe.  Then this user mode component will decrypt and load  DLN itself, hidden in the registry as well.  But this workflow was kind of odd,  because the driver could have loaded DLN directly.  And looking at the user mode components,  we have found evidences that DLN wasn't the intended payload  used with this bootkit at first.  More precisely, when injecting DLN,  it sets this specific exported variable to true.  But the variable doesn't exist in any known samples of DLN.  So DLN 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 some several shared features  between the two families.  The user mode component is manually mapped into the explorer's  memory.  And all this code is shared between DLN  and some early samples of black energy.  And to do so, there is three exports used in the driver  to load the user mode component, respectively entry,  EP 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 Dundalf.  Looking at some other samples of Dundalf,  we have found another deployment in 2014.  And this time, Dundalf came with a kernel mode rootkit.  So the rootkit purpose is to ensure  Dundalf persistence on the system  by injecting it into explorer.exe.  And also to hide everything related to Dundalf  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  to hide the driver to load and the DLL to inject.  We have two variants of this rootkit.  The first version, the rootkit was targeting Windows XP  computers and was doing some simple SSDT hooking.  And the other version is a many 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 drivers  are made for specific configuration,  like this one probably targeting a computer running  Casper's Key Internet Security.  So to summarize, we only 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 rootkit 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 Celerico, 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,  not 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 of 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 words, 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 an Rc4 key as the concatenation of a hard-coded  value and a random value, or using hard-coded tokens  in network messages.  These are two just, are just two examples 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 the same developers 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 handleGetPacket  is terminated with PetredExit.  But it should be handleSendPacket,  as you can see from the condition before.  And the commented Windows code.  So probably a wrong copy-paste in the Linux version.  Also, there is a, here in external,  there is a report message, who 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 six-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-less.  Following this idea, the Sendnet software  seems sometimes inspired by classic crimeware.  For example, set up a reduced persistence methods  from crimeware and shares some code with Carbuff,  while Dundalf 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  uses funny names like Frodo and Lol for HTML tags,  or Messi de Lionel, 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 skill  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 see this.  [?].  [?].  [?].  [?].  [?].  [?].  [?].  [?].  [?].  [?].  [?].  [?].  [?].  [?].  [?].  [?].  [?].  [?].  All right.  There is a lot of time for talks.  We don't have, unfortunately, microphones  that we can pass around in the audience.  Please go to the microphone stand over there or here.  OK, let's start with the internet.  Do we have questions from the internet?  One question.  Is this Russian state malware?  No.  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.  Please, when you exit, please be quiet.  Respect that there are some people in here who just  want to know a little bit more.  There's one question over there to the right.  Yeah, I have a question.  In, let's say, the malware period that you found,  a lot of allegedly US malware or NSA malware was found.  Do you see any development in code  that is 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.  OK, thanks.  More questions?  Yeah, there is one question over there.  Hello.  I have maybe obvious question.  Maybe speculative.  Do you think this group has some ties to 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.  Right?  Have they reacted to you researching the malware?  Sorry, I didn't understand the.  Have they reacted to you researching the malware?  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?  OK.  Like I said before, when we started to analyze external,  we've seen some obfuscation techniques implemented in the  software.  Also, the research is quite young.  We've published it like a few months ago.  So I would wait until 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 in 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, well, when the targets,  probably 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, 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?  Now, I mean, 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's one question over there in the back.  Hi.  One more.  The work you are doing, are you concerned about your  personal safety?  I mean, I started this work like one year ago, so we'll see.  More questions?  Internet.  So one more from the internet.  What do you think of the CrowdStrike 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 that was overcast.  They made quite a few.  We still got enough time for questions.  Yeah, here we got one.  Did you find any vulnerabilities when you  investigated the code?  I think my colleagues did find some.  Like also when the Google Threat Analysis team released the  adversaries about flash and the winterly case, I found the  samples right after that.  They weren't public.  But some other companies published something about that.  So sometimes you can find zero days.  It's rare, but you can find them.  And a follow up.  Did you find any vulnerabilities in the  communication to the command control server or  something else?  We don't look about stuff like this.  I mean, they made some programming mistakes in the  client side of the software, but they don't know about the  efficiency levels and everything.  More questions.  Yeah, 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?  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?  Well, more than you presented today.  Yeah, 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, same microphone?  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.  And we find some similarities.  When he told me about targets, I was thinking about the  Bitly list we found.  And this is why we didn't contact any emails.  And 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  may 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 widespread infections or anything.  Anything more?  Internet?  Well, we saw clarification on the previous question.  We were specifically interested in the report that  attributes Russia to the DNC.  And then there's another related question asking, are there  differences between the two?  And then there's another related question asking, are there  differences between CrowdStrike's reports and yours?  I don't believe we are talking about the same things,  because when we see something published by the recent  exploits, we are not adding this to our paper since it's  already on the internet.  So our white paper is a technical breakdown of their  toolkit, like X-Agent, external, and I don't think they  talked about this one.  More questions?  Internet?  Audience?  We still got time.  Internet is asking if the targets are any better protected  now?  If they are more protected, well, we are detecting the  samples, so if they are running, it's 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.  Or do incident response, of course, because we are not  doing that.  I don't see questions in here.  Still?  Internet?  Something there?  No, it's getting quiet.  Well then, there is one more question over there.  Hello.  It seemed that a lot of the texts are focused on Windows  machines.  Like I said, they have a second stage back door for iOS,  Android, Linux, and the source code of X-agent is the  Linux version.  And we also have seen set up other samples for OS 10, I  think, if I recall correctly, so they have a big arsenal.  Welcome.  Okay.  We got one question over there.  If there are no further questions, as is my first visit to  CCC, does anyone have a good tip for a good bar in Android?  Guys.  Maybe.  I think social life, we can discuss a little bit later.  So once again, merci beaucoup.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Once again, merci beaucoup.  Thank you.  Thank you.
33c3-8094-visiting_the_bear_den_0_839.png 33c3-8094-visiting_the_bear_den_840_2315.png 33c3-8094-visiting_the_bear_den_2316_2963.png 33c3-8094-visiting_the_bear_den_2964_7751.png 33c3-8094-visiting_the_bear_den_7752_7967.png 33c3-8094-visiting_the_bear_den_7968_8411.png 33c3-8094-visiting_the_bear_den_8412_13943.png 33c3-8094-visiting_the_bear_den_13944_14075.png 33c3-8094-visiting_the_bear_den_14076_14855.png 33c3-8094-visiting_the_bear_den_14856_20027.png 33c3-8094-visiting_the_bear_den_20028_21527.png 33c3-8094-visiting_the_bear_den_21528_25787.png 33c3-8094-visiting_the_bear_den_25788_25991.png 33c3-8094-visiting_the_bear_den_25992_26075.png 33c3-8094-visiting_the_bear_den_26076_27287.png 33c3-8094-visiting_the_bear_den_27288_28739.png 33c3-8094-visiting_the_bear_den_28740_31175.png 33c3-8094-visiting_the_bear_den_31176_32735.png 33c3-8094-visiting_the_bear_den_32736_35795.png 33c3-8094-visiting_the_bear_den_35796_36179.png 33c3-8094-visiting_the_bear_den_36180_38147.png 33c3-8094-visiting_the_bear_den_38148_38231.png 33c3-8094-visiting_the_bear_den_38232_39203.png 33c3-8094-visiting_the_bear_den_39204_47267.png 33c3-8094-visiting_the_bear_den_47268_51803.png 33c3-8094-visiting_the_bear_den_51804_52163.png 33c3-8094-visiting_the_bear_den_52164_52439.png 33c3-8094-visiting_the_bear_den_52440_52523.png 33c3-8094-visiting_the_bear_den_52524_53027.png 33c3-8094-visiting_the_bear_den_53028_53363.png 33c3-8094-visiting_the_bear_den_53364_54491.png 33c3-8094-visiting_the_bear_den_54492_55883.png 33c3-8094-visiting_the_bear_den_55884_56339.png 33c3-8094-visiting_the_bear_den_56340_57443.png 33c3-8094-visiting_the_bear_den_57444_57731.png 33c3-8094-visiting_the_bear_den_57732_61175.png 33c3-8094-visiting_the_bear_den_61176_62783.png 33c3-8094-visiting_the_bear_den_62784_67475.png 33c3-8094-visiting_the_bear_den_67476_67991.png 33c3-8094-visiting_the_bear_den_67992_69239.png 33c3-8094-visiting_the_bear_den_69240_69371.png 33c3-8094-visiting_the_bear_den_69372_69731.png 33c3-8094-visiting_the_bear_den_69732_69851.png 33c3-8094-visiting_the_bear_den_69852_70055.png 33c3-8094-visiting_the_bear_den_70056_70187.png 33c3-8094-visiting_the_bear_den_70188_70295.png 33c3-8094-visiting_the_bear_den_70296_70655.png 33c3-8094-visiting_the_bear_den_70656_71267.png 33c3-8094-visiting_the_bear_den_71268_71339.png 33c3-8094-visiting_the_bear_den_71340_71555.png 33c3-8094-visiting_the_bear_den_71556_71795.png 33c3-8094-visiting_the_bear_den_71796_73523.png 33c3-8094-visiting_the_bear_den_73524_73619.png 33c3-8094-visiting_the_bear_den_73620_75779.png 33c3-8094-visiting_the_bear_den_75780_75899.png 33c3-8094-visiting_the_bear_den_75900_77315.png 33c3-8094-visiting_the_bear_den_77316_80795.png 33c3-8094-visiting_the_bear_den_80796_80855.png 33c3-8094-visiting_the_bear_den_80856_82847.png 33c3-8094-visiting_the_bear_den_82848_84635.png 33c3-8094-visiting_the_bear_den_84636_84899.png 33c3-8094-visiting_the_bear_den_84900_85103.png 33c3-8094-visiting_the_bear_den_85104_88151.png 33c3-8094-visiting_the_bear_den_88152_88247.png 33c3-8094-visiting_the_bear_den_88248_88564.png