CDS 2018 | Hello, Carbanak!

hello so I'm Mike Bailey and this is my co-presenter Tom Bennett I am wearing lederhosen because I heard there would be an Oktoberfest party but in actuality I can't attend it but I was so excited that I put a reminder in my Outlook calendar when I accepted this invitation to speak to pack my lederhosen so I'm just gonna get the mileage out of these and I hope that you go and enjoy the Oktoberfest party for me thank you very much for that so we're both staff reverse engineers on the Flair team and we've both looked at the carbon act back door through very different lenses in his case in the binary lens and in my case the source-code lens and what we're here to talk about is the unique experiences that came from that and if you're not familiar the carbon act back door is associated with millions of dollars of financial crimes perpetrated in large part by the Russian fin 7 threat group we're gonna try to keep this pretty accessible for people who are both at the malware analyst level and also at the info SEC professional level and we're gonna talk about some of the unique experiences from that source code kind of journey it's not very common that somebody laborious lien tediously analyzes all the binaries and has to sweat through analyzing actually hundreds of binaries and then somebody else gets to analyze the source code and see if they were right so we're gonna go through a little bit background here and talk about fin 7 and carbon AK where we'll talk about some of the work interesting considerations with regard to that source code we will revisit Tom's binary analysis and he'll be under a little bit of pressure at that moment and we'll talk about some blind spots that Tom really couldn't have possibly seen from a from a binary level and things that we were introduced to from the source code and then we'll actually show you a few more binaries that Tom didn't have access to because they just weren't with you know we didn't accompany the backdoor and we'll talk about some video artifacts which would be very interesting in juicy so just introduce myself a little further I'm the guy that analyzed the source code and my name is Michael Bailey and I live and work in Huntsville Alabama remotely for the flare team I play the banjo but I'm from Wisconsin it's not because I'm Alabamian I'm a daddy too I spin drone based music and I also write lots of debuggers for the mean bad malware that we get to look at on the fly team and I am I'm sorry I maintained the fake net ng project which is an Internet simulator that lets malware talk to something that it thinks is its command and control server so we can hear who it wants to talk to and hear what it is saying I'll let the binary guy introduce himself hey everyone my name is James Bennet people call me Tom it's my middle name and there's no real fun story behind that so you might see James with Tom on papers and blogs I've written in the past either way I'm based in SoCal I work from home I'm also a staff reverse engineer on the flare team I'd say roughly the first half of my career was focused on a higher level analysis of malware but at a large scale I used to work for an antivirus company Trend Micro so I cared more about detection than about understanding the code at a really low level and then halfway through my career roughly I switched focus and I got really interested in reverse engineering so instead of analyzing a lot of samples at 100 level I focused on individual samples at a really deep level and that's why I'm on the FLIR team now reverse-engineer malware and writing reports for our customers and for fun I like video games and hiking so the flare team that we're a part of is fireeyes enclave of reverse engineers and we support the talented staff in the advanced practices team we support our incident responders who throw malware over the fence to be analyzed manage defenders who take care of the companies who pay us to patrol their networks we also work with eyesight for intelligence purposes we do a lot of threat intelligence work we do trainings both internally and externally including trainings that have been done here we just taught malware essentials at cyber defense summit just Monday and Tuesday and we also do blogging and like I said teaching and some research for product detection and also some read teamwork so sometimes we write proofs of concept for novel evasions and what-have-you because reverse engineering is the main service that we provide I want to let Tom talk a little bit about it just briefly and because he's the guy that got to analyze the source code or the binary code I want him to talk about that and the background that he had available to him when he did his analysis right so like mention Mike mentioned we wanted to keep this accessible to a larger audience and we're using terms like binary and assembly disassembly in compilation and that might not be as familiar thank you to some of you so I'm gonna keep this really short and do like a nutshell version of this but basically you have programmers writing their code in a high-level language like see that other programmers can understand and then they compile that and during the compilation process lots of important information like function names and function variables get lost and those high-level instructions get broken down into many more low-level instructions known as assembly and that assembly gets translated into the bits and bytes of the binary that the computer can understand so we can run the program and what we end up with is an executable and we call that binary sometimes so as a reverse engineer we typically don't get access to that source code alright we wish we did or make our job a lot easier but also I guess less fun we like to do what we do at the bottom here this disassembly and this reverse engineering process so we use a tool like a disassembler that will take those bits and bytes out of the binary and convert them back to that assembly level language that we can read and we analyze that and we come to our conclusions and write our reports on that and sometimes we have an additional tool called the D compiler that can further abstract those low-level assembly instructions back into a c-level source code representation that's not going to be the same as the actual source code that was used to write the program the names are all gone and it's also usually Messier but you know sometimes it's helpful so we spend a lot of our time with the assembly and the D compilation would you click here thank you alright so we're talking about carving out today it's a sophisticated in versatile backdoor it's originally known as on a knock actually the malware authors called it on a knock you can see in the source code and in the strings of the binary that it was originally named on an ax but a lot of the blogs and papers that came out about this backdoor they claimed that the name carbon app and that's the name that we know it as today right so it's again sophisticated we've seen it going back as early as early 2014 it's used by select criminal groups including the carbonate group and I put my quote fingers in our carbonate group because at fireEye we believe that there is no one single carbon that group but actually the carbon act that door is shared among several groups at least a few different groups that have a sort of trust relationship with each other and are willing to share this back door it is a private that door it's not like poison ivy or something that you can just download off the web and use it for whatever you want and in the summer of 2016 one of our clients asked for a full analysis report and I took that ticket and Tom spent his summer vacation reverse engineering carbonate I probably spent over two months looking at like three or four carbon act binaries and writing a report for it and we also wanted to mention fin 7 so if n 7 is one of those groups that we talked about that had access to the carbon at that door these guys are professionals they're a Russian financial criminal group they typically like to target payment card data but they are opportunists and they're flexible and whatever they can get that's worth something they might just decide to go after you can see we've had our eye on them for some time we've written a lot of blogs and papers about these guys and their tools and their tactics and of important note and August 1st of this year the FBI indicted three members of the fin 7 group and they actually revealed something very interesting that this group was operating a security company again using my quotation fingers Combee security they had a website they had a LinkedIn presence and they were actually recruiting people and you know they hire them on and we believe these guys were unwitting accomplices to these financial crimes that were being perpetrated by fencer man group so it was very interesting discovery yeah so thanks to the magic of our cyber sleuth team the advanced practices team fire I captured the source code for carbon Anik and so one Monday morning I logged in and I decided to look at what the next ticket was for me to analyze normally it's a little backdoor or a proxy or just a little piece of malware in this case it was something that my buddy here thought was absurd it was he said did you take the Whopper ticket then he said you know that could take like months but it was a little bit late because I already took it and the reason why he said it was a little absurd it was 20 megabytes of files as 100,000 lines of code 40 binaries and 15 of those were pieces of malware really 14 technically so what does the Russian source code look ironically it's written in a pretty good English but on the right hand side and up above you can see that it's decorated with a lot of Russian language words and this document is codepage 1250 one and that's Cyrillic script and it has a lot of words that I'd like to know I'm not a Russian speaker now the flare team has a lot of fluent Russian speakers or at least a few and I'm not one of them but I took this ticket so I wanted to get something out of all this like what what does this mean really important to me to figure that out I've got the source code let's make something of it so I went to the freebie bin at the bookstore just kidding just kidding nothing yeah no so what I did is I wrote a python script like any reverse engineer would do and I tore through all the files and I found all the non Latin words and I grouped them by order of their frequency of occurrence and I built a 3400 word vocabulary this for myself and I studied this list the whole list not just kidding I studied 500 words here and I looked them all up that's what I did and I went on to Russian for everyone calm while my daughter was playing and watching TV and napping because I was totally into this and not playing with her that day God daddy but uh I had a great time learning a lot of Russian and so I did that also I could bring this malware analyst Russian lesson to you I want to go down this list for you and tell you how these words are pronounced they'll sound a little familiar to you the unit 1 of your Russian lesson ok viola Vieira Vieira hazard a command Volta plug-in service and process so if I'd known the Russian was gonna be that easy I probably would have tied it earlier yeah obviously there were some other words they're a little more complicated than that but studying this gave me the ability to translate the user interfaces that were present in the source code base so this is a really fun example of one of these or interfaces I translated it's the command and control panel for commanding infected hosts and probably the most amusing part of this has got to be the launch of socks proxy icon with a literal pair of socks on it I really had to hand it to the developers for making my job on that day so having the source code is kind of like God Mode x-ray vision game right or maybe not I'm actually gonna let Tom here set up an example that's running it'll it'll run to the contrary I guess I'll say alright so usually when I'm reversing a back door I know there's gonna be a point in the code where the commands come in from the from the client and then they're going to process that command and come to some code that executes the command for it right and typically your back door your average back door is gonna have like one or two functions that that deal with handling commands Carbonite cut seven right and I put a screenshot of each of these functions here these are control flow graphs from Idaho just kind of showing you the logical flow of how a function would look visually right so a command would come in to carbon a can actually go through this little journey and it's not really a little journey actually it's quite a long journey through the code before it ends up at the actual functionality itself right and not only is it going through these functions but it's also going through these named pipes now named pipes on Windows it's this mechanism it's kind of like a file where you can write into a name pipe and you can read out of a name pipe but it doesn't leave any file on the file system and Carbonite used several of these to talk to itself in different places so one function or a process or thread would write into one of these name pipes and then another function thread or process would would read out of it it's kind of like a telephone so he can talk to itself right so carbon that supports over 40 commands and I had to follow this journey for every one of those 40 commands I had to map out which functions it went through which branches it took and which main pipes it went over and it was so complicated that I actually had to like actually create a map so in my notes I had a map to show like where every command went so I could follow it back later when I needed to refer to that command and thankfully with Ida Pro it did help quite a bit I could keep a tab open for every one of these functions and flip between them pretty easily and with cross references and being able to dive in and out of functions it wasn't as as complicated or as bad as I you know thought it could have been but I think Mike has a different story looking at the source code yeah my journey was a little bit more like Frodo and Sam wise Gamgee getting ready to go do the Fellowship of the Ring trilogy this on the right isn't meant for you to read it's literally just there to show you the depth of all the different functions that were involved and I want to whip through like really breeze through just 20 or 25 functions relating to the secure command will the secure command down its journey to the very very bottom and where it does its job and sets up four systems by installing a malicious notification package so that when you reboot carbon deck will still be there waiting for you so this is the command that handles initially handles the secure command and it calls load plug-in which you think would somehow load a plug-in what it really does is called two different functions depending upon which kind of c2 they're using today to go and get their plugins and those two functions then call potentially two different send functions with different types of messages depending on the c2 protocol they're using and then that causes a write operation which causes another write operation at some other lower level which causes another right file operation which is a Windows function and that's where the trail runs a little bit cold basically they say something into the telephone and then I have to go figure out who's on the other end here's what's on the other end of the name pipe it's another function with a whole bunch of different possible messages they call a function that will run a thread that will call a function that calls a function pointer that calls another function pointer that calls a nother oh yeah okay this is where that gets sent over a pipe and then received and they they say they're gonna load a plug in here but they're really gonna talk over another name pipe so they send a string over a named pipe and then another send operation and another lower-level okay here's where we received that and we handle that asynchronously and we then we're gonna load a plug-in maybe oh are you gonna do this to me again I don't know oh yeah it actually does download the plug-in decrypt it and then finally miles back at the beginning of our journey this is where we were initially handling the secure command it's the first thing I showed you and I'm highlighting two function pointers that they've set up and stashed into a structure that they're gonna pass in and so I'm all that way deep back in all those levels of nested functions and finally I'm like what does this function pointer equal to are you serious right now so I had to trace all the way back and figure that out so here it's a function pointer that calls another function pointer and finally at the dead end of it it finally calls this which is what installs a malicious notification package so the control flow was divergent depending on what kind of c2 they were using because they can opt to use one kind or another and a different server as well for their for downloading plug-ins vs. downloading commands and the control flow diverged based on the fact that they're using C++ with overloaded functions that have the same name and then there were functions that have the same name but we're in different namespaces and I feel like we saw a load plug-in like three or five times it was super confusing to be honest and so if I had to write a book about it I think this would be the book cover carbon ax source code analysis and then I'd scratch my eyes out and never be seen again so surely Mike you must be saying surely Mike there must be cases reading the source code is easier and I would say to you yes definitely there are so here is a case we're having this is an old Fline okay well anyway so in this case the source code is uh is we're looking at D compilation it's not the source code we're looking at an optimized comparison here where carbon AK is assessing for each process name in the operating system it's going to derive a unique number and compare it with a very long list of other unique numbers that it has hard-coded in the binary and they're all doing this also that the male or analyst can't figure out what processes they're looking for they're looking for specific processes to detect something but we don't know what and at the source code level it actually is a lot cleaner it's like a really organized block of Trend Micro process names and then the comments on the left on the right hand side just tell me exactly what they're looking for and then in the middle we have AVG and at the end we're looking for Kaspersky so if it matches any of these it'll drop to here and return this or if it matches these it'll return this or if it matches these it will return this another thing at the source code level that you get to see is things that were completely commented out like this AV evasion for AVG which if I were to uncomment it it'd be a little easier to read the with the syntax highlighting but what they're doing is they're looking for an avg dll that might be stitched into their process address space and if they find it they will locate the entry points which is the first function that normally gets called in any binary they would locate the entry point of a vgs dll and they'd say hey AVG we're unloading now it's time to go home like the process is closing and terminating you need to unload so that everything can happen nicely and AVG is totally compliant we tested this in late 2017 it's a new DLL they have a different DLL name but it totally still works so we disclosed that to them another example is an active AV evasion that we saw for Trend Micro where you used to work fun times so this I won't speak in great detail but you can read the details if you're interested basically uses a difference like an alternate way of injecting process what's called process injection so injecting code into another process and it evades the state machine or heuristics that Trend Micro has implemented and slips right under the radar so in that block of code before where I was saying that they're figuring out what antivirus is in place on the machine that is where they would decide that this is the method that they want to use and so we just closed that as well and actually got a pretty positive response a couple months later Trend Micro implemented a feature called aggressive event detection and if you enable it it will detect that so if you work at mandiant you feel a certain pressure when you do anything to try to figure out who the people behind the keyboard are Manion is where the apt one report came from which was the seminal threat intelligence distillation of like unmasking the hackers behind the keyboard it had pictures of people from their forum postings and like actual pictures of human beings who typed these bad things in the console from the Chinese People's Liberation Army so I thought I should look for some of that stuff so I did I gave it a shot it didn't really turn out that well turns out one of the usernames corresponds to a video game character in a game called Touhou another one is Igor which is like the most common name ever and the list goes on basically nothing conclusive from this I mean if we see these again it might mean something but it didn't really tie to any specific person or a threat actor so that was a dud I felt like it was an open-ended question just like he said like it's pretty open-ended what are you gonna do like spend a couple months on it I did and I kind of did a survey I felt like I was in charge of my own like plan for how to do this I just said have fun I'm gonna look for all the exploits and see what exploits are stitch in here and I did and I had this list so I'm not going to talk about all these exploits in great detail except I will say that they all can be found publicly these are all things you can find on the rapid7 repository or you can find them on exploit DB or you can find them written about in random blogs that have to do with security and all they did is take the source code verbatim and then just mash it into their source code base and it was a really effective productive way to do business I also felt like I had to go find any secret scheme material passwords etc that might be in the source code base and I did I found some c2 passwords on the far top left there in the center I found some private key material that was embedded in a binary and encoded but basically it was in the plain for me to go pick out and there was an encrypted certificate file that I have forced and the password was the single character the number one so it was really disappointing to write that through for sir but it ended up this is kind of another dud it was for tests company so all these almost were for you know testing nothing really particularly interesting there I thought I would be a whiz kid and find some new network based indicators that fire I didn't know about but that also turned out to be a dud we knew about all of these from our tracking so everything's all tagged up in the threat intelligence and these all correspond to operations that we already know about so Intel's already on top of it I have to say so at this point I think we can lean on Tom to see how we did in our blog he did this extravagant blog with barry van Garrett of the advanced practices team and he's gonna talk about that it is barry and then nice to meet you in person so Barry and I from our best practices team like Mike said a little over a year ago we worked on a blog together and this blog kind of added some additional technical details that we didn't see in previous blogs on the carbon deck and we also shared some novel insights into the operations and the users of the carbon act tool and we came to several conclusions based on our research and you know this is an additional month of research after I already spent two months on the analysis just a month on this blog alone and I wanted to share a bit about that research before we talk about those conclusions but the main thing is now that we have the source code can we actually prove any of these conclude to be accurate or not right so we put this forward with a fair level of confidence but you never fully know usually except in this case now we did so let's talk about that so behind the block I seem that over the years where the Flair team had a lot of tickets submitted for carbon atom right so a lot of people wanted us to analyze carbonate samples over the years so if I had to guess at the time that I was doing this research I would have thought there may have been dozens of carbonate samples in our malware repository and these samples are easy to hunt for they're fairly large and have a lot of unique characteristics so inviting a signature to find them and our repo is not a big deal but the problem was that these samples are always packed when I say pad I mean they're either compressed or encrypted or obfuscated in some way so even if we could find them we couldn't really pull anything useful out of them in that state but I also knew that at fireEye we have a few generic automated unpacking services at our disposal so these services are usually pretty good they don't work on every single sample of course but they take a generic approach to getting memory dumps of malware and for carbonate it worked every time which is really cool so I knew we had a big repo of malware I knew we had at least dozens of carbon axles we had the signatures to find it and we have a way to unpack them automatically so I threw together some scripts to do all that and what I found was not dozens of samples but hundreds which was really exciting really cool and I knew we could pull a lot of neat data out of there but some of the data I was pulling out was actually exposing some of our customers so there's some customer sensitive data that I was pulling out so I had to be careful barrie helped out by going through and culling that list so I need any sample that we thought was sensitive we pulled out and even after doing that we still had 220 samples that we could talk about so that's a lot a lot more than I thought so what kind of data was I pulling out I started with the the original compiled time for these samples right so in Windows and Visual Studio when you compile your project the compiler is going to add a timestamp into the headers of your executable that tell you when that sample was compiled right and unfortunately with carbon deck when they when the carbon deck samples were packed that compile time gets lost by another compile time which is the compile time of the pack version of the sample and I didn't care about when the packed sample was compiled I wanted to know when the original carbon act binary inside of it was was compiled and we were able to pull that up because we were in the memory of the original binary itself so we could get the original compile times and one thing I noted in these hundreds of samples again these samples spent a few years of compilation times I noted there were five different versions of their command and control protocol implemented throughout these sample sets right so each version of the command and control protocol kind of built upon the previous version like improving its encryption or its security making it harder to reverse-engineer and so it sort of went through this evolution over the years so I was able to tell you exactly which version of the protocol each sample had implemented in it writes alright now I had a timeline going I had the compile time and I had the protocol version and lastly I pulled out the command and control addresses and their ports along with the campaign code and for those of you who don't know what I mean by campaign code it's basically a unique string that the operator of the malware well we'll configure into it that will identify the the target right so when the carbonate gets down on some system and infects it and it calls back out it needs to report itself it's someone or something so that the operator knows who it's actually dealing with right so that's what the campaign code for usually it's going to be a date like a month or a week or a day or it might be like an industry vertical so it's like oh we're targeting this industry for this campaign so we'll use that string but sometimes it's actually the customer name itself or like an abbreviation of the name of the target itself and that's why we had to call some of the samples from our set of advanced you cool Thanks so we have all this data one of the conclusions I wanted to talk about from our blog today was because we have all this data I believed strongly that there was likely a build tool being used by these guys so they could take a template carbon act binary put it in this build tool and bacon some configuration and produce a new sample to distribute and I believe that that build tool likely allowed them to configure the C to address the C 2 encryption key and the campaign code at the very least but but why did I think that way well I noted that and all these 220 samples I was looking at the strings in the binary were encrypted with a different key every time and I thought to myself I can't imagine some guys sitting at his desk with Visual Studio manually typing out a new key and recompiling a build from all 220 samples right that doesn't make a lot of sense so I knew there was some automation here in some modification of the binary after the fact and I also noted that there are a lot of samples that had the exact same compile time but the c2 addresses would be different inside and the c2 encryption key would be different so they're able to change data in the binary without recompiling right so again this is all tips that there's a build tool being used and if you don't know that when I'm talking about when I say encrypting strings just very simply when you write a program you're gonna have strengths in your program things like which API is you're gonna call URLs IP addresses file names things like that these are all human readable characters right and you can run a tool on these binaries to dump those strings and even if you're not a reverse engineer you can do some pretty leet analysis just by reading the strings and saying oh I think it's probably gonna do something like this I see all these teenage so it's finally gonna do cheat logging or something right Springs analysis really elite stuff so a lot of malware I want to encrypt this string so it's not so easy to do that in carbonate that's one of these now where that did so so one of the source dumps say is there a build tool bingo we got a build tool so this was really neat I was really excited to see this and it definitely proved a lot of the a lot of the conclusion that we put in the blog I wanted thanks to Mike we have a translation here of this GUI and thanks Mike so on the right I just want to point out a few of the things in this bill tool we have this uh let me grab my laser pointer it's easier yeah so we have this button over here create exe and you can see to the left of that we have two fields input file and output file the input file field is going to be where you designate your template binary that's going to be used for the built right so you have some compiled version of carbon app that you want to use and you point to it with the input file the output file is going to be the new carbon app build that's built by the build tool with all your configuration they did right and the new encrypted straight you can see down here we have admin host these are where you put your c2 addresses in your ports up here we have in the prefect's field they call it traffic this is what we call the campaign code but that's where you put your campaign up here and then down here we have admin password well this is the strain that's going to be used to derive the c2 encryption key used by the by the binary right so it looks like we were right about all that except I don't see anything about the encrypted strings here and this GUI right so where would I find that yeah I got it just did it thank you nope can you go back one no that's it oh I'm sorry oh so that's the old go back one all right so I have you got the source code to figure out more about the D encrypted strains I wanted to know if I was right about that it's the build tool actually we encrypting the strings every time that it builds a new sample so over on the left here we have source code from the actual carbonate door and there's a function it's a macro they call CS which means code string and you can wrap your strings that you want to be encrypted with this CS macro and it's going to automatically encrypt them for you but what's actually happening is for every string that you do that it's prepending that string with the string BS and appending yes so it's kind of sandwich in all your strings with these BS and es markers right and I didn't you know I kind of figured BS turd for begin string and es stood for n string and you can see here we're and a strings tool that dumps all the strings out of the template binary and you have all the strings with the BS and yes and I looked in the builder header file and saw in fact the S stands for beginning code string and E F stands for handing code string so what's happening here you run the build tool it's going to search for these BS des markers and all the strings in the binary when it finds them it pulls the string out between them encrypts it with the new key and then puts it back in the binary and that's how they're able to without any effort have newly encrypted strings every single time which is really great for them OPSEC wise because for us is reverse engineers we literally have to find that key in every sample and and rerun our string decryption plugins and Ida Pro to decrypt all the strings again so that we can see what we're looking at right so it does add extra work for us so I got a really cool discovery but what about those template binaries right so another conclusion from the blog I noticed that due to the frequency and the close proximity of the compilations of carbonate that we saw I thought that we were probably dealing with the fact that operators had access to the source code themselves so why did I think that so spanning just over two years of the sample said I was looking at I saw over fifty seven unique compiled times that's a lot of compile times for two years and in my opinion anyways especially when you have a build tool right so you already have a build tool why are you recompiling all the time I also noted that some of these samples were compiled within just four hours of each other so again what's up why are you compiling again when you already have a build tool and again just four hours after you just compiled right and these really close proximity binaries that we were looking at they had the exact same configuration so they didn't even like what are they changing that's what I wanted to know they're not using the build tool that is still changing something in the code and recompiling so what were they doing but that I had to go to the binaries itself so I have a sample a on the left and sample B on the right this is the same function in both samples and this is just the same this is the disassembly from Ida Pro and I pointed out just two differences between this function and in both the samples and sample a at the bottom there's an additional call to this run thread function and it's calling this thread pause log monitor thread that's what I named it right this is my analysis right so possibly monitor thread it simply looks for a log file from a point of sale software and uploads it to their command-and-control server alright so in simple B at the top there's an additional run that I'd call this not in sample a this is running a thread called bliss Co thread so I didn't know what Blizzcon was at the time but it turns out it's like the Russian Pay Pal it's a way for Russians to send money to each other online and it's basically trying to determine is this a user of bliss Co the person on this computer do they use bliss Co or not so what does the source don't say about these little changes I saw in the binary well it turns out they're using something known as preprocessor directives so you see there's this if death and end if statement and whatever's in between that is code that could either optionally be included in the project or excluded from the project when you compile all right so every time you compile you can enable or disable these macros to include or exclude optional code right so if we see this macro at the top plugins trusted host right and if that's enabled then it's gonna run thread the trusted hustling well that trusted host read thank you for my laser that trusted host read is the Bliss code meant that I was talking about right so they all had to do is enable and disable this macro in their project and they can enable this functionality or not include it in the project and then at the bottom we see this other macro plugins monitoring file and that's going to run the monitoring file thread if it's enabled and that is the pozzuoli monitor thread that I that I named so it lookin for that point-of-sales long right so it turns out these operators are using these macros to easily enable and disable functionality to fine tune their carbon app builds for particular targets right so this is in addition to using the build tool and there's one other interesting discovery that I made switch in Dec so one more piece of information that also really helps solidify this this theory that I had in my mind is I saw some samples of carbon act that were using outdated versions of the protocol so just for one example to clarify what I mean I found a Carbonite sample that was compiled in June of 2016 however I was implementing protocol version 4 and protocol version 5 had already been available for two months so how is that possible if there's just one place where the source code fit it's very unlikely that it would be a sample that's compiled after 2 months after the new version of the protocol already exists but it sees in the old version so all this together you know the fine-tuning the macros enabling disabling and and using outdated protocol and all led me to this theory that it's very likely that there's multiple independent copies of this carbonate project in existence right and that there's not one single place but the force is shared with operators that trusted you know they trust each other there's trust here thank you so changing topics a little bit I wanted to play a game of how's my reversing right again it's I'm like a little kid here we don't usually get the source code right so it's kinda like oh I have the answer key finally like how did I do I wanted to see like I named all these functions right and you know I plan on with my name sometimes because it's for me and I know what I'm looking at but how accurate where my function is compared to what they were actually called in the source code so I took a single function and you can see on the left here there's a D compilation from Ida Pro so these are all my function names that I gave these functions and on the right is the actual source code with the function names at the now our author gave now most of the names I was pretty close or are almost like exactly accurate to the actual name of the function and I'm not going to talk about the cases routes right because that's kind of boring and we don't have time for that but let's talk about some of the places where I was wrong or just a little off and I think those are more interesting so at the top of on the right here there's a comment for this function kind of overview of what the function does and roughly translated to English that comment says fulfills commands at once after launching bot and the name of their function they named it first execute commands I name this function do some things and I named it that because this function doesn't really do anything in particular it's actually just calling a bunch of other commands and other functions in the program to perform functionality it's kind of like an init script for this back door right so I I just kind of joked I was like yeah it's just doing stuff I would have called it an it but there's another function I already named an it and there's like yeah just does stuff right so and they call it first execute commands technically I think I was pretty accurate but obviously the name was quite off from what they called it next up on the right here they named this function load key logger config now at the time when I was looking at this function it was really complicated there's not a lot of context here it was doing a lot of things with those name pipes I was talking about it was sending messages around there was no like Windows API is being called I really didn't know what the function was for other than to send messages across these named pipes and the only message I saw was the string klg config now I assumed that kog stood for key log so it's talking about like a key log config but there was nothing to do with key logging at all and that function right again it's just like sending a message over a PI so I didn't know and I didn't want to make any assumptions so when I named this function I just named it literally after exactly what it does so it's a really long function in that has no meaning to anyone here except for me or anyone else who has reverse-engineered carbonate like me so I call the send kog config plug name manager pipe messages but that's what it is I was off there because I didn't have the full contest and lastly I wanted to point out I wanted to point out one thing down here at the bottom it's calling this function command exec and it's calling the command run men which I've already analyzed and I know that run men is going to download some binary from the internet and load it in memory and run it but it's never it's never gonna touch disk that binary is never touching disk right so that's what run man command does and it's calling London on this executable they named WI BSC I don't know what WI DXE is at the time I didn't have that binary there's nothing in the code else that talks about WAV so it wasn't mystery to me this is one of those blind spots that Mike was talking about I had no contest all I knew it was gonna run some binary that it download from the server and they call it WI exe so I'm just calling that out now cuz Mike is gonna talk about that shortly so you'd think we might be all done at this point we've reviewed the binaries by the hundreds and we've looked over the source code and we've seen all of our blind spots but we were not done we were far from done there was like twice as much work to be done because basically we had to go through all the binaries and reverse them and make sure we had fully accurate reports on them it wasn't enough to have a high level and it wasn't enough to leave it with any uncertainty we really needed to figure out for sure and have some facts on these binaries so I'm gonna talk about a few of these just three of them and I'll leave them up on the screen so you can see them all but I'm just gonna talk about 3-carbon ACK a compiled version of Carbon ACK ironically not the star of the show there's no incentive for me to analyze this other than to find deviations of which there were none and so it's kind of a nothing burger that we have a copy of Carbonite cuz I'm looking at the source code now there's a mysterious wxe that turn to be a web injection and what web injection is for is either scraping passwords or other sensitive information from a web session or modifying a web session so that a transaction might take place to a different account you can pretty much manipulate what the web client does on that machine between here and the bottom we have a few commercially and publicly available things we have Metasploit shell code that is a stager for Metasploit we have some cobalt strike stuff at the bottom we have an open source project as well and it's called RDP wrap and its purpose is to let more than one user RDP or remote desktop into that machine so they can all see what's going on on the scene without interrupting each other and the purpose then would be to log in while a user is on the machine and still be using the machine without interrupting that legitimate user and blowing your operation yeah so it turns out that this was compiled into carbon AK and he'd reversed it he was kind of like why do we have this well that was also they were using Mimi Katz to do kind of the same thing and they had preprocessor macros surrounding that and essentially probably foresaw a case where they would maybe send carbon ACK without this pink feature of functionality and then download it separately but that's not all after that we wrote some finished intelligence a finished intelligence product that went on our intelligence portal so the eye sight intelligence portal now has a 75 page report that covers the findings and I wanted to involve this guy and share some of his work because he did some interesting and compelling video work and I won't let him talk about that thanks Mike so a few years ago Kaspersky put out this paper that was really intriguing where it talked about this financial criminal group that was using Carbonite to rob banks so what they would do is they would spend some weeks or some months kind of as a shadow employee of a given Bank shoulder surfing on the employees of that bank using the desktop video recording feature of Carbon app they would watch the employees do that work they would see what tools they use what processes they have in place what their rules are and how they do their work and when they felt comfortable they would come on in insert fraudulent transactions that would not trigger any alerts and then make out with millions of dollars it's pretty pretty incredible pretty intense and he called it job shadowing like there are employees of the bank for a little while they'll love it they get their pay all right so yeah and we had access to some of these videos of this carbon app backdoor video recording feature the problem was these videos apparently were not the right format because even though we had the video player ourselves from the source dump we tried to play them and it just wasn't happening and it turned out that these videos were over an older format it's a proprietary format to these guys they wrote their own video player in their own file format for the videos but we had the code so I knew we could figure this out and it wasn't as nearly as bad as I thought it was gonna be it turns out that the old version of the code was still in the comment so all I had to do was comment in the old loop for playing a video and it works like sweet videos unfortunately the videos were not very interesting except for one video that I wanted Mike to talk about because he has some background that he can relate to this video yeah so this this is basically we're shoulder surfing an attacker an operator of other people's systems and in the screenshot there are a couple things of interest it looks like they've got their kin list of kind of a hot list of commands they're gonna use in an operation and as a former red teamer and the Mannion red team this felt familiar to me it feels like that moment when you're about to operate against your target you're gonna fish them get into their network and your hands are sweaty and you want to test your command you want to make sure that your persistence is working that you didn't misspell anything that you don't have any windows file length limitation conflicts nothing wrong make sure that your operations gonna go perfectly smoothly nothing just nothing untested before you go into that new territory and so the odd thing here is though Carbon arc is nowhere to be seen there's no carbon ACK visible they're not operating carbonate and carbon AK has all these features it has persistence and has screenshotting like they're doing in PowerShell here in the middle it has all these things like why is carbon AK absent why are they doing this other stuff and why are they being videotaped so it lends to the question who's being shoulder serviced do they know that they're being shoulder served and in wild speculation I like to think that maybe it could be an employee of combi security one of those unwitting accomplices may be getting ready to do just a normal pen test for a customer who wasn't really a customer and maybe somebody was supervised supervising and doing a little bit of quality assurance to make sure that they're not filtering the goods I just don't know otherwise what this means yeah so this interesting tidbit takes us to the end we have a few takeaways sometimes the source code really doesn't help hard code is hard it just doesn't matter where you encounter it or what level you look at it if it's complicated sometimes it's just complicated take a lot of time to look at naturally though a source code does come with unique discoveries and we were fortunate to find that we're thankful for the advanced practices team for capturing that source code and also the carbon ACK authors stateful you know they do a lot of custom stuff but they're really not averse to pulling in public things they have no shame about pulling in Mimi Kats Metasploit stuff cobalt strike etc and we confirmed some theories from the blog right so having the source code helped us see that we were actually right and a lot and a lot of those conclusions in the blog and even though we didn't have the answers I mean just do enough research and having a large enough sample set you can come to conclusions that are accurate right so it's kind of cool to have that proven and also vindication by binary analysis for spot-on again we don't usually get the answer keys or like it was kind of nerve-wracking for me to like go meit's gonna find out if I was correct about everything and he should certainly let me know that I was so that was really cool yeah it was a very high quality analysis so kudos to you thank you so we want to leave it at QA we have run out of time I don't know Ian do we have any time for any last questions coming over sorry I was hiding so uh yeah we are out of time for question but I do want to throw one quick one out there for you guys and that's you know as you're going through the source code review did you come across any anti re stuff that Tom had to deal with along the way I would say that hole named pipe thing was inside her yes just normally it's a single switch statement only one of those blocks that he showed of the seven is really strictly necessary to evaluate which commands gonna run it felt like that whole thing was just like I'm gonna make this take forever for you enjoy this great also for all those string comparisons that are doing with a V process names or even the command names the names of the commands that carbon AK would execute they weren't in there they'd had the hashes of the strings instead so they were comparing hashes and I had to brute force and guess at the name a lot of those commands and a lot of those process names I didn't get every single one but I did get a lot so Mike was able to actually show me the ones that source code was pretty much wide open like Here I am fortunately I mean no my office station they're excellent well thank you guys very much for the talk today I hope everybody here enjoyed it we do have another talk related offense 7:00 here coming up in about 10 minutes so get back here for 5:30 where we'll be applying some fin 70 TPS to a couple of different attack frameworks all right thank you thank you very much [Applause]

Channel: FireEye, Inc.

Views: 10,699

Rating: 4.9751554 out of 5

Keywords: cds 2018, cyber defense summit, cyber defense summit 2018

Id: 7LeK0pOiC98

Length: 46min 45sec (2805 seconds)

Published: Mon Dec 10 2018