BSidesNYC 0x05 - Spycraft 2.0: Hunting Dead Drops in Web Applications (Jonathan Fuller)

So, uh, this is 11:00 a.m. talk on the blue track. Uh, so this is a fun story. It's about spies. It's about, uh, hunting dead drops, C2 communications, and also about malware, right? So, it's going to be fun. Uh, let's welcome Jonathan Fuller. It's his first time at Visa New York City. So, LET'S WELCOME HIM. >> [applause]

>> UH, GOOD MORNING. GOOD MORNING. MY NAME'S, LIKE you said, Jonathan Fuller. I'm the CISO at the United States Military Academy. Uh, if you were in the John Hammond keynote, you might have a a sour taste in your mouth about servicemies, but it's not it's not that bad. He had a rough go, maybe. Um, also Moonlight is an assistant professor in the electrical engineer and computer science department. Um, not really moonlighting. I'm just dualheaded. So, but I get to do fun stuff in forensics and malware analysis and uh I'm really excited to to get to share some of that uh with you today. So, this talk is about u modern spycraft and how attackers hide uh their content and

everyday web applications. Um, so this work began years ago when we were looking at uh botnet takedowns and we're trying to figure out ways to make that a bit easier and and what we found inside malware kind of change how we we think about botnet takedowns. So uh without further ado, let's let's start with the problem. So as as many of you know botnet takedowns and disruptions, it's it's pretty tricky, right? It it almost feels like beheading hydra. you cut off one head and two more emerge. You often hear about botnet resurgence or ineffective uh counteracting techniques uh and the cycle just continues to grow and grow. So uh really in practice it's hard for

investigators, it's hard for defenders to have full access to the CNC infrastructure, including you know victims, malware, uh proxies, servers. um it's really difficult to get a hold of the entire CNC infrastructure for a more comprehensive investigation towards botnet disruption and takedowns. Uh as a result, those investigations often take time. Uh even if they don't take time, like like I said, they they're just lacking all the information they need. Um but in that time like uh the the adversaries are able to migrate CNC servers. They're able to cover their tracks. um a lot could happen uh that would reduce the effectiveness of of botnet disruption and takedown. So uh before we we dive further let's

just look at why botnet disruptions and takedowns are kind of an arduous process at least many of the current practices right so there are four male uh main milestones to botnet disruptions and takedowns uh beginning with the discovery of a botnet that's sufficiently large to warrant a response. You're not going to burn all your resources and assets on something small. uh you're going to invest resources in sufficiently large botn nets that uh may affect CN scattera systems or uh enterprises or governmental resources. So we begin with the discovery of a botnet and determining that it's sufficiently large to warrant a response. Next uh we begin to monitor that botnet. will profile it uh to understand um the scope of the

infection uh to collect information used for counteraction uh to understand the types of malware that creates bots uh and get information from there and then based on that profiling we'll start developing techniques and our our response capabilities in order to to pursue botnet counteraction right after we we counteract that botnet or at least pursue some type of disrup corruption. Then we're going to monitor. We just want to validate the efficacy of our approach to understand um the the resulting scope, right? How many devices are still infected? Did we wipe this out completely? Where do we stand? And as an example, uh after discovering Trickbot in 2016, Microsoft uh realized the scope of infection and decided to uh proceed

with counteraction against Trickbot. So Trickbot grew close to close to half a decade and and Microsoft uh decided to get involved. There may have been some uh issues with an election or election appearance around 2020. So this became quite a a hot topic and Trickbot was uh kind of a global spread uh incident. So uh to profile Trickbot, Microsoft collected over 100,000 malware samples. They analyzed them to to find mapping information to understand the communication routines uh to understand their local and they found 128 servers around the world. And so uh after profiling they developed counteraction techniques understood who the the stakeholders were that they could work with. Um using this information they they required a collaborative effort

with international organizations and they pursued counteraction to disable trickbot servers around the world. So they continue to monitor the trick trickbot uh botnet. Uh they identified that they were able to to disrupt or take down 120 of the 128 servers. Uh and then they continue to monitor other avenues for disruption. of note, uh, most of those eight servers were hosted in bulletproof hosting providers. You just don't have jurisdiction. Sometimes you can't get to them. Um, but it's it's a a lengthy process, right? Uh, so we wondered, are there more efficient ways or effective ways to disrupt botn nets? Right? I'm not saying I'm better than Microsoft here or international organizations, but uh, we're just trying

to to understand the art of the possible. Are we able to to push the needle a little bit further to create opportunities for organizations to pursue more effective botnet counteraction? And so how did we get from from botnet counteraction to we're heading to spycraft 2.0 in a bit. But but just so we uh understand this a little bit more. Um we we began examining the malware itself and how each bot actually communicates with the CNC server. not unlike most botnet takedown techniques, but we we decided to focus more so on that malware versus servers and proxies and other artifacts that made up the CNC infrastructure. This is a malware analysis project only. And so we we

identified that, you know, bots already know how to authenticate themselves to the CNC server. They they already know how to communicate. They contain all the information we need. We just really need to know how to look and what to look for. And so tracing that logic within malware, their communication routines, um we realize that as defenders, as investigators, we could potentially repurpose uh logic within the malware for our own use. Is there some weakness inherent in that logic that we can exploit? And this insight changed everything, right? This led to our first major discovery. So we'll dive into that a bit. Um, so bots are the trusted end host agents of a command and control server. In fact,

attackers are entirely dependent upon information excfiltrated by victim systems to gain situational awareness into a victim's network. And often times uh bots use standard protocols for file transfer, for data storage, for messagebased communication. Uh, and many of these protocols though are overpermissioned, right? That means that they provide featurerich or unfettered access into a CNC server beyond a subset of features implemented by a given client. Right? So for instance, if I'm using a protocol that does push pull, but my malware just requires it to do push, like I'm doing password stealing, if they're using the entire protocol and I'm able to take advantage of that, then I can do push and pull even though the malware doesn't

implement that full push and pull feature. In fact, here's a list of of common overpermission protocols in use today. Uh this list was uh derived a lot from the MITER attack framework where we dug in, looked at some of their blogs and posts and understood what malware often uses and then we pulled this list together um really source from industry and academic experts. Now we wondered if we could exploit this knowledge to uh to use against the botn nets. All right, so let's look at a quick example um of covert infiltration of CNC servers. Uh so to demonstrate, we're going to use a deplock malware to to kind of give you an understanding a more

practical understanding of how we're able to to exploit these over mission over permission protocols and malware. If you've never heard of that term over permission, it's I'm pretty sure I made it up and it's not a real thing. Um so just humor me here. So we first analyzed the deplock malware uh and discovered its use of the overpermission file transfer protocol. You might wonder why is anyone using file transfer protocol? It's known to be insecure. Um but attackers often pro uh prefer efficiency and ease of use over uh a security of their botnet. Right now the more sophisticated your attackers get the more sophisticated techniques would be used. But essentially you find the lowest uh cost effort um so that you can

maximize your ROI. Uh so we found that FTP and a couple of these other overpermission protocols are quite commonly used even though they're wellknown in securities. So we analyze the deplock malware uh discover the use of the file transfer protocol and then we look for something called infiltration vectors. Right? Infiltration vectors um that's a defender term, right? So the malware has FTP credentials baked in. They're obuscated. So it requires some dynamic analysis so that you could populate memory locations for extracted. But they're offuscated. They're baked in. And if we can recover these credentials, we could use them as infiltration vectors right from the defender standpoint to infiltrate that CNC server. However, if you just infiltrate

a CNC server, right, you could you could act as under the guise of a trusted bot. You're establishing similar communication routines that a mau would, but you don't want to just kick the door open. I picture that Kool-Aid man from the commercial when he breaks through the wall. You don't want to do that to a CNC server. You want to be a little bit more stealthy. So, we we identify CNC monitoring capabilities. Really, those are just um malware capabilities that give you insight into what's on that CNC server. So instead of like you know uh doing a findall and pulling everything you can more uh intelligently search through a CNC server knowing what to look for. So if malware does live

monitoring capabilities and screen capture what do you think you're going to find on that CNC server? Maybe some images some PNG files. Uh that's what we mean by CNC monitoring capabilities. So uh we do some capability analysis, find live monitoring, uh victim profiling, file exfiltration. Then we use that infiltration vector to get into the botnet and then we use the file monitoring capabilities to do some active monitoring, right? We poke around in a more intelligent fashion rather than just flip all the tables over in furniture. and we identified some PNG files confirming uh live monitoring capability and and we found some other malicious files which means that the CNC server was probably used as a dropper at

some point. I want to couch this all in um ethical research, right? There's some things we can do and some things we can't do. Um so we didn't pull any files off the server. Um no torchious interference as it would be called cuz that's that's illegal, right? Uh while this software was flagged as malicious on virus total um it could also be a mom and pop shop hosting a server that was exploited and used for malicious actions. So this technique while valuable um would be used by uh those with legal authority to pursue actual botnet counter action. So this technique gives us the ability to do peer disclosure. We could find other infected systems on the network. Uh we could

dismantle the botnet that way. We could shut down the CNC server, blacklist it. Um and all this is cool. Um but uh it's kind of old news. This is not the main aim of the talk. Uh the point is just to to show our our foray into using malware to counteract botets, right? That was our initial goal to try to answer that first question that I proposed to you guys. Uh this was presented at Schmooon, uh Georgia Tech and Avenger Con. You could look up C3PO is actually the name of the framework. Um, what's it stand for? Covert command and control something of over permission protocol infiltration. I don't remember the name of it. That's what C3PO stands for, but

if you're interested, you're welcome to look it up. There's lots of details about C3PO and how we did this at scale. Um, and we're able to to find some pretty cool things. So, why do we care about malware logic or use in the first place? Well, we talked about that a little bit, right? To to create more opportunities for defenders to efficiently, effectively dis disrupt botnetss. Um, so we know malware already knows how to communicate, how to authenticate, um, how to hide, um, and instead of just analyzing the malware and its behavior, we can reuse what that malware is already doing. So we took the F FTP logic, we uh found it within the deplock

malware, we found the exact connections, you know, the infiltration vectors, the CNC monitoring capabilities, uh and we used it to access a CNC server. So we flipped the script, right? Uh the ve very logic the adversary built to control victims uh became our tool against that adversary. And that's that's the whole art of the heart of this work, right? We want to turn the malware's capabilities uh against themselves. Um which I I meant to mention once in a while people have to get up to leave and I had this thought that whoever gets up in this talk is probably a malicious actor and is really offended. Um so just so you know we're we're all watching. Um but yeah, what

does this have to do with spycraft? So during our analysis, there was a there was an unexpected finding, right? We're looking at over permission protocols. Um, but not every malware uses an overpermission protocol, right? You guys know they're ransomware, they're crypto miners, uh, XYZ, they're across the board. And we discovered something interesting. A malware that wasn't first connecting to its CNC server, but a malware that was connecting to Twitter. And this obviously caught our attention. We know that some malware will establish a uh will test internet connection. if I have internet, you know, uh continue the attack else sleep for 360 seconds or something, right? So, it's not it's not uncommon for malware to contact benign sources.

Um and often times it'll just throw you off your your track, right? If you're just doing pecap analysis, per se, and you're looking at overlapping communication routines and network flows, it can confuse a defender. Um, obviously if you throw more advanced defenders there, they might be able to piece it out, but uh, low lowhanging fruit. Use FTP, do a bunch of benign connections, throw a defender off, um, make him annoyed. And so we kind of piqu our interest though. Why why Twitter? Um, and was this a one-off or was this the the start of a new new kind of malware tradecraftraft, right? Was it Spycraft 2.0 like the new version? um where malware [clears throat] it's

hiding its communication in in plain sight. So as you'll notice at the top right MITER has uh um uh I think what do you call it a threat ID or capability ID um with respect to dead drop resolver. So around the time of our study MITER posted this on their uh their website and there's a bunch of other reports of dead drop resolvers out there. So this is emerging technology really when you think about why why would a malware author want to do this right? Um well, if you've heard of fast flux networks or domain generation algorithms, there are all these dynamic command and control resolution techniques that attackers are using in order to more covertly access

their CNC server. Well, we know with fast networks, you can do block listing really easily. Domain generation algorithms, if you have control of the malware, you could extract the DGA algorithm. you could reverse engineer it and then you could forecast all future possible CNC domain names and block list them ahead of time so you're effectively dismantling the entire CNC infrastructure. So that's why DDR or this approach dead drop resolvers come into play. Malware authors are always looking for the next best thing to evade detection to seem more benign than they actually are. And so if if they are relying on Twitter on benign web applications and websites for access to their command and control servers, can

we leverage this to counteract those botn nets? Right? They are effectively taking some control and they're handing it over to web app. Granted, it's very uh hard to find. It could be offuscated, but uh when MAU authors hand over any bit of control, that's that's our opportunity to kind of pounce on that and and try to use that MAU logic uh reuse that MAU logic for counter action. So, a dead drop, if you're not familiar with a dead drop, any of you guys familiar with this park? Does anyone know you? Yeah. Yeah. Wow. Okay, that's suspicious that you know what this is. There's only there should be none. No. Uh, so there was a FBI agent, Richard

Hansen, um, back in 2001. He was caught, uh, I think they paid $7 million to a Russian double agent to find the mole in the FBI and based on fingerprints and other sorts of tracking, they identified Richard Richard Hansen, who for almost a decade has has been handing top secret information over to the Russians. Um, one piece of information, right? The Russians had an embassy in DC, uh, and the US was kind of, you know, wanted to keep an eye on. So, they bought a house across the street and started to dig a big tunnel under. Am I getting this right? >> I could be making it up. You never know. Only one guy would know. Anyway,

>> Robert, >> Robert Hansen, not Richard. Thank you very much. Yeah. Sorry to whoever is Richard Hansen. I apologize. Robert Hansen, right? Dug a tunnel. The US are trying to surveil Russia and he gave up a bunch of information. Well, he would go to this park, use a chalk to mark on the sign, walk into the park, he would have some files wrapped in a black trash bag, and he would tape it underneath of a bridge. This was his dead drop and the marking where his Russian uh handler would come in, grab the files, and leave. So, this is what this is spycraft 1.0. All right, this is this is what dead drops are in effect. And now, dead

drop resolvers um they're the digital equivalent of hiding that that those files under the bridge. And they're public web applications like Twitter, like Pastpin, GitHub. Um they're used by by malicious actors to hide command and control server information in plain sight right? And so once a system's infected, um it connects to one of these dead drops to retrieve the command and control server. It's oftent times encoded. Uh and then the malware goes ahead and retrieves that information. It decodes that message layer by layer to reveal the true IP or URL for the CNC server before establishing that final connection. Right? Uh this technique has all the hallmarks of of a classic spy craft, right? Classic spy spy incident. An

endless supply of public channels or public parks. Uh granting the attacker both anonymity and elasticity, right? So much to choose from. Uh and you could create an account without really verifying yourself. Uh DDRs also enable unlimited un uh unpredictable endpoints. Each one disposable, each one easily replaced. Uh the traffic itself looks harmless. Uh ordinary HTTPS traffic uh request a legitimate sites making this this technique kind of hard to observe. It's often indistinguishable from user normal user activity. Right? Enterprises can't do blanket restrictions on Twitter and GitHub. You just can't block all that traffic. you could maybe be more concerned about the subsequent outbound connection to a CNC server, but really triaging this to the full extent. It's

kind of tricky without uh understanding what this malicious software is doing. And then the messages themselves are multi-layered, right? You can't just brute force these most of the time um to understand what's behind that encoded uh encoded content on the web app, right? Uh and lastly, this is a purview future down the road, right? this specific malware sample does exist. This Twitter handle is still up. Sorry, it's gone. Um I guess I could show you if you want to check it out. Uh you could go to Twitter and I think still find it because we submitted a request to Twitter with some evidence saying, "Hey, you found this malware. It's talking to this account. Can you please take it down?" And their

response was like, "If you find this offensive, please block the account." which doesn't necessarily get there, but um it is hard to counteract uh DDR malware for instances like this, right? >> Did you have a question? >> As if I'm running a platform like that that can possibly be a sign. Uh what do you think is a good strategy for platforms to actually identify? >> We'll get there. Good question. I didn't plant that question, by the way. Good question. So, like I said, these traits make DDR malware nearly invisible. And what we're trying to do now, what I'm trying to to to convey is our ability to turn that visibility back on, right? To understand

what's happening um in in this digital world of spyraph. So, how do we stop DDR malware? Right? This question led to to three key insights. And the first is DDR samples must decode that CNC address for use. Thus the malware has that that decoding logic baked within right. um and investig if investigators if we understand how uh the malware is de manipulation logic that's their decoding or decryption logic if we can understand how that works then maybe we can extract that logic do some platform scanning um to your question and identify similarly encoded content uh revealing CNC IPs or URLs and using something like virus toler URL host to understand the scale of maliciousness maybe we can do something like that so

this this first insight was was a breakthrough. Um we were like, "Oh man, this will be cool if we could figure this out." Um but when we tried to operationalize this idea, it was it was quite tricky, right? Uh malware samples don't always make their DDR routines obvious. Malware authors may prefer efficiency of ease and use, but they're not they're not dumb, right? They want to to um to add some complexity to their malware to prevent uh immediate triage and response by investigators. So many malware connect to multiple domains producing really a tangle of network connections and then even after even if we're able to confirm uh which routine in the malware performed the decoding um

they're often in mathematical representations in in code. Um this is compile code not source code right. Uh and if those are interle with network flows within your communication routines it it makes it pretty tricky to just extract this routine. It's not a plugandplay. It's not a control c control V approach. So these this in challenge spawned from our first key insight led us to to two additional key insights. So imagine investigators observing network connections uh to web apps followed by another connection. Um if you want to identify the DDR logic uh we realized that we could uh localize DDR routines based on content fetching and content use. Right? So profiling the specific place that the malware connects

to that um to that web app and then tracking that information flow information flow throughout the malware. But even if we isolate that logic, how do we know what specific algorithms are being used? So the little red dots in there, right? That's representation of the logic. If we can isolate that, that doesn't really tell us much unless we know what specific algorithms were used and in what order. Which led to our third key insight um which is the de manipulation routines if you're using symbolic execution which maybe I'm getting ahead of myself here but they they reduce to symbolic expressions which they're just uh arithmetic and logic operations um in an expression. And if you know anything about symbolic

expression or symbolic execution, you're just mutating branch predicates as you explore a malware and you're just doing the converse of what maybe that concrete value to do branch traversal would be. Um so it creates an expression saying you know a is greater than two go left. If a is less than two go right as as it traverse branches it continues to add logical operations. So now a is less than two um b is greater than three and it starts building this expression for you to traverse one path versus another. So if it reduces the symbolic expressions uh can we take these symbolic expressions and match them to known algorithms uh to find demolition demanipulation recipes. So we take a

known algorithm like B 64. We create a symbolic expression. Then we take the symbolic expression from the malware and then we compare them and we say do they reduce to the same thing? If so, they're the same algorithm. And let's look at this with uh the mud drop malware example. We're going to look at a macro level and I think we have time to deep dive into the micro level as well to understand how this framework uh analyzes DDR malware and extracts these recipes. Remember the goal is we could identify the DDR malware. That's a great step. We identify it. We email Twitter and we say, "Hey, take this down." um they say no, we email paste spin and they're

like, "Yep, we'll do it for you." You know, different web apps respond differently, but in either case, it's a win. We got a post taken down. Um how can we take this a step further, right? Um and that's why we want to extract these demanipulation recipes so that we can use them pro for proactive dead drop discovery. We want to multiply our efforts. So our framework takes the mud drop malware, which is a known DDR malware. I'm using it kind of our running example to illustrate the the uh effic efficacy of this approach. So our our framework takes the mud drop and it does DDR logic localization. Remember that wants to take um uh some path

within the binary and understand where is that DDR connection and capability happening. Normally this happens right at the beginning of malware execution. Uh David in the last talk he mentioned how do you um decode PowerShell script and someone on a Reddit posted you run it right well in malware analysis uh they're often packed and offiscated what is a great way to unpack or deoffiscate malware you run it and set a breakpoint and a normal breakpoint is the first network connection that's a great breakpoint so if you dynamically run malware set a breakpoint at like a internet open a or when http open or or sock open. That's a great break point where you know the malware is likely

offis deoffiscated itself unpacked itself and it's ready to execute the rest of the payload. So DDR logic localization normally happens right after the unpack right at the beginning of malware execution. Um and so we will look for the logic localization in order to extract those routines and then match them right. Um in this case in this running example uh the DDR logic showed that the malware connected to a WordPress and it retrieved this dead drop content just a random string of characters. Then we have to do the de manipulation boundary isolation. It's just a fancy way to say it connects to Twitter and it does the decoding or de manipulation and then it connects to the CNC server. We

have to locate localize that logic. we find a boundary um and then uh we'll we'll go to the micro level first. So micro level how does it do this? It uses concolic analysis. So concolic analysis is the port man 2 for concolic execution and symbolic analysis. Really you're running the malware concretely to to um populate environment variables or different concrete variables. Um but as we know if you run malware concretely it'll take one path. If you don't have the proper environment variable set, it might go straight to exit, right? Um or it might not take the path you want and you won't get full malware exploration. So we use symbolic execution in order to trick the malware to go down paths we

want. Uh for this we use a framework called S2E. Uh you could use anger plus symbion if you want to do it uh a little differently. There are many frameworks that you can do concolic analysis with but uh in this case we use S2E. So we execute the malware. Uh we identify the DDR candidate where it first connects and then we note that okay this connects to a a web app. You could use Traco which is a uh research um product that provides you a hardened list of known good websites. So we use Traco. We compare uh our first connection with a known good list of web apps. If it's one of those we continue execution. All

right. train train code tr uh it's based on some research they just have a heart so you can go on and download new list um all the time but yeah it's a great resource so it'll connect to WordPress and then it will read from WordPress right so up to this point there's some concolic concrete execution happening uh but you'll see a little bit about where the um symbolic execution's occurring so when it reads data from WordPress We want to inject symbolic data there. We want to tell the malware that here's the real data from WordPress, but really we're smuggling in data that we can track the information flow throughout. Uh so that's called you could call it

constraint or uh canolic uh taint propagation. You could just call it symbolic tagging. There's many different terms for it, but we we hide some data into the the memory buffer that's supposed to contain the information received from WordPress. So whether WordPress is alive or not doesn't really matter. We're faking it till we make it, right? We're injecting data to induce exploration. And so that expiration induces m lambda is just uh our representation for that symbolic expression. We tagged it with sim tag one and that data is flowing through the malware. Uh and eventually there's going to be a subsequent outbound connection. So we'll track another internet connect A. And if the the target within internet connect a has

our SIM tag then we know oh okay that's the information that it read from WordPress and it uses that to establish a subsequent outbound connection. That's how we identify DDR capabilities, right? Initially connect to a web app, use that data to establish a subsequent outbound connection equals DDR malware. And then somewhere within that, that's where we find the de manipulation boundaries. Decoding has to occur somewhere in there. To go from a random string of data to a 188 93 whatever, whatever IP address, some de manipulation logic has to be within there. So we're going to uh use that de manipulation boundary to kind of pull out those algorithms for for further study. So next we do the de manipulation recipe

identification. We have the boundary. Now we identify the recipes. In this case the recipes base 16 and character rotation and that gives us that CNC IP address. Right? So this is kind of what it looks like. You have the dead drop content and then you apply base 16 decoding and then character rotation and then you get the final CNC server address. So we've confirmed it's a DDR malware, right? But how do we actually pull out those de manipulation recipes? So we we have two pseudo implementations of decoding in malware. The source code isn't uh fully accurate. It's shortened for brevity. As you'll notice, my rotate character for function, I made that up and there's no code attached to it, so

uh don't Google it. Um but as as you'll notice here on the left side, lines three through five um uh are kind of a a character rotate and then uh the other line shown here 6 through 8 uh table lookup for B 16. Um and then on the right side, that's just what a different version of B 16 looks like. So how would we show that both versions of base 16 are the same algorithm? Imagine the one on the left is from a malware sample and the one of our on the right is from our known version of B 16. We don't know how the malware author implements B 16. We don't we know how you can implement it.

The input uh reduces in the same output for B 16, right? Um so we have two different implementations uh that we want to uh understand equivalency and so essentially we have uh the the evaluation of what data means. So on the left side data initially contains that dead drop content right it's red uh I could barely see on my screen too so I hope you can see that. Um but yeah, internet connect a goes out to WordPress. Internet read file reads the dead drop into the data field. And so data at line two contains that decoded content. At line five is it's being decoded. And then at line nine when it's fully decoded. Same thing on the right. Line two is the

dec or the encoded content. and line six because it's just doing base 16. It decodes it to the uh the the CNC server. Right now, if we inject symbolic data, you remember we're going to do some symbolic expression matching. We're going to extract symbolic expressions from the malware and then known symbolic expressions and try to do some matching. Let's see if this works, right? Um so, uh we have lambda 1 and lambda 2. This is what a symbolic expression looks like. Remember, it's arithmetic and logical operations. It's just a series of mathematical operations expressing expressing how the execution got to that point in time. How could you replicate that same execution path? You would solve the symbolic constraint and it

would give you values to plug into if statements. If this go right and it would just help you traverse down that that binary. So if we compare these together, are they equal? Well, char rotation, character rotation happens initially and base 16 decoding on the other side. Uh, so on the left side, it's a combination of both. So they're they're definitely not equal. You're comparing one symbolic expression that contains multiple decoders to a symbolic expression that is purely B 16. They will not reduce to the same values. So that that won't work. So we need to localize the B16 decoding in order to properly compare it. Um and while their characters are different, right, one's using a table lookup versus uh straight

mathematical inline computations, they reduce to the same value if they're indeed equal. Uh and so let's let's go through a a little example. As as we're executing through this malware, um we will halt execution. When the malware accesses any value containing lambda or that symbolic data, this is built into our framework. It'll just halt execution and it will extract that information, concretize that information and go to work with it. So in this case, uh it's executing it halts at line two because lambda data was marked with lambda and data is red. So it halts and it says what's in that or what's in the the data field concretize it. And it does that. It changes it to a

concrete value. It solves that symbolic equation and it says it's 1 2 3. Good. Now I want you to take 1 2 3 and use it as input for a set of known decoding algorithms that we have. We have I'll show you I think it's like 15 of them or 14 of them. It'll submit them as input and it'll attract the output. So in this case 1 2 3 as you'll you see on the top right corner outputs to 5 6 7 8 ab and abcf depending on the decoder um under evaluation. We'll continue executing the malware and it will halt again at line five when data is again accessed and it will ask what is the value of data data is 5678.

Well, if you'll notice, 5 6 7 8 was the output of the character rotate algorithm. So, this then tells us that between lines 2 and line five is where character rotate occurred. It'll continue this process and it'll repeat it and then it will localize the character rotate and it will localize the B16 algorithm based on their input to output domain mapping. This is how that boundary is isolated. And now instead of comparing the entire symbolic expression from one from the malware to our known algorithms, it will allow us to more correctly we're now comparing apples to apples, not apples to oranges. So compare those expressions and you will find equality amongst them and that's how we do it. So we take every

expression we localize them and then we start comparing them with our known symbolic expressions and that results in our extraction of our recipe using concolic analysis providing us a scalable approach to analyze DDR malware and extract recipes based on those recipes. uh we can perform recipe scanning, right? Uh we scan web app platforms and uh network traffic web app platforms um for information. Uh obviously we're limited by being throttled. You can only crawl so much. Um but as a proof of concept, we show effectiveness of this approach. And then after we're able to identify recipes, scan web apps, uh we can pro proactively identify dead drops for remediation. Uh in this case from this one uh dead drop on the left of the

screen the bottom left we're able to identify three previously unknown dead drops. So the dead drops found on the right I didn't have malware samples for those. We scan the WordPress platform using our recipe and we identify other similarly encoded content and then we submitted the resulting CNC addresses. We didn't know that at the time. who submitted those to virus total URL hos to understand their maliciousness um and then those are the results reported there and we deployed this on 100,000 malware samples captured uh over a decade like I mentioned this concolic analysis provided us a scalable approach to do this if you know anything about concolic analysis it would blow up your computer if if if it runs too long so we set

about a 15-minute timer. Um, some we just couldn't analyze for unresolved symbolic constraints. The symbolic um, expressions were just too hard to resolve. We just couldn't do it. Uh, and here are some large scale findings. Right? So, 100,000 malware samples, we found maybe 9% of DDR malware in our data set. Uh, seven unique web apps. And we found Pacein to be the most prominent use web app. So, we know that Paceman has been long been used for malicious purposes, right? You could host droppers on there. You could host scripts. It's it's always always been a go-to for uh malicious use, but uh this is probably one of the first works to expose it pervasiveness to to

host dead drops. Uh next, we we identify several blockchain explorers. So, this is pretty cool, right? Blockchains are immutable. You can't take something down, right? So, this is a really robust way to host CNC addresses. You could you could uh request uh help from blockchain hosting providers, right? They host you could go to their website and I'll show an example of that, but they host transactions. You could request that they remove their hosting of the transactions, but blockchains are immutable. So once they're once they're up, they're up. Um and we found about 25% of uh of our DDR malware in our data set use these blockchain explorers. They they often share wallet IDs. So there

are multiple connections. They might try one connection to a transaction ID or wallet ID. And if that doesn't work, they just try a different website that hosts the same transactions. Here's an example of what one looks like. And this this is still live um because you can't take it down, right? So uh it uses the two recent transactions which are normally a couple cents, 43 cents, 53 cents, and then it converts those to IP addresses. And that's what the malware uses to connect to its CNC server. Now, what's cool about this though, if you have access, which all of us do, I could go and I could post two new transactions to this wallet and then I could sinkhole the CNC

server, take it out. There was a a study done for pony coordinated malware where they did this exact same thing. They were able to post new transactions and temporarily sinkhole that CNC server. So, all new malware will connect to your CNC server versus the actual CNC server. But then the attackers can just post new transactions and it goes back and forth. So, this would probably get annoying for attackers over time, but if you have time, you should do it. Um, we also found three dynamically generated uh Twitter accounts, which is kind of weird, right? We talked about DJ algorithms and how they're kind of the old thing. We move on to DDRs because DJ algorithms are susceptible to reverse

engineering, allowing you to predict all future candidate domains for disruption. But we found some samples of DDR malware that achieved a hybrid approach. So they they had a DGA algorithm inside to randomly generate Twitter accounts, register them and use them for um CNC server uh dynamic resolution, but as we know DGA techniques still apply for counteraction. We can reverse and we can pre- request blocking of these based on evidence that we have. This was a interesting finding. Um and then a bunch of known really well-known web apps. We wondered if malware authors don't use these because it just uh they've been studied quite a bit. There's a paper Marcia that really deep dives into uh more holistic use of

web apps for command and control infrastructures. Um so we wonder if uh things like that make malware authors less likely to use really popular web apps or well-known web apps. Um, and for time sake, I'll I'll move through some of this faster. But what we also did instead of just scanning web apps, we also used uh a net reset pcap data set that they provided us. And we scan this entire data set just to look at traffic to see if we could identify any indications of DDR malware leveraging our recipes to scan content presented within those pcap files. And we identified 72 new dead drops hosted across uh 11 web apps. And not surprisingly, B 64 is kind of a

go-to. Even saw it in David's talk when we're talking about PowerShell obuscation. B 64 is always used. It's even used in normal benign network traffic because it helps ensure data maintains integrity as it's being uh transmitted. Um but B 64 is a go-to. And and so you might wonder why can't we just brute force everything? Just brute force everything with B 64. Well, it's because um 60% of those you you'll see uh that are not B 64 actually the remaining 60% use multi-layered approaches. So brute forcing really is not a tractable approach. Uh from another perspective we already found also found 67 hen CNC servers. uh which means that based on the numbers attackers have just been reusing the

same CNC servers and just re-encoding them across web app platforms and what does this tell us really that web app providers struggle to identify dead drops on their platforms right and it also illustrates a bit of importance and and shows the impact of our approach um we can see that 60% of dead drops that are used to protect CNC servers uh still remain available during this time of study Let me wrap up here here shortly. Um and so from the net reset data set, we were able to request remediation uh and successfully remediated 80% of those dead drops which affects all the malware that rely on them. So real world impact uh we move beyond reaction right um we

try to remediate DN or dead drop resolvers and CNC servers before they ever go live. uh our large scale study and the findings right those provide helpful and and help us to understand the scope of this issue. Um we improved detection by 57% and we're able to work with web app providers some of whom positively responded to take down post um from their web apps in order to remove uh hosted CNC servers. And then the best part uh it's a scalable defense. We enabled web app providers to detect and remediate threats early. So malware logic reuse is a thing, right? You can reuse logic within malware or attempt to to to provide opportunities for counteraction or disruption of botn

nets. Uh attackers evolve, right? Uh they try to blend in better. Um and we need to to study this malware not to just gain an understanding of what they're doing uh to post a blog about it, but to just gain some intelligence for counteraction. So studying malware uh is not um just about understanding the threat but learning how to to turn what the the attackers use against themselves. And then spycraft 2.0 shows that the best defense may be inside the adversaries own code. And if you're interested in learning more about spycraft 2.0 um there's a paper uh published this month a few days ago um that takes you into full details. There's some code available. There's a ton of artifacts

how we I test our robustness of symbolic expression comparison. Uh please feel free to to go out take a read. Um and if you're interested in learning more, happy to connect and uh shoot me a message. I'm happy to respond. We got maybe two minutes for questions. [applause]

>> [applause] >> So the recipes have pre-baked ciphers and encoding methods. Did you see any indications of custom or slightly tweaked ciphers or encoding methods? >> Yeah, those are tricky, right? So I I may not have shown a list. I might have skipped over, but we have a list of like known decoders and we just comb through MIDER other research papers and we're like what are attackers normally going to use? We even have some ways to identify encryption in the paper. Uh we use something called constraints uh like constraint solving where we just track constraints through encryption APIs to extract the key and use it. We didn't find many of those. But yeah, that's definitely a limitation rolling your own

uh encryption or or decoding. It would be tricky because you can't match them to any known. Yeah, great question.

No, I didn't. We didn't see I'm sure it ex just like when I talked about uh the over permission protocol. We not all of them are over permission. We identified some DDR. Not all of them are DDR. There's probably some good techniques. I was talking to um the volunteer running this classroom and he was mentioning identifying some some malicious uh steganography attacks and his threat intel work. So yeah, they're they're definitely out there. So you mentioned like you know the example

as platforms what are the things that they can do identify >> yeah that's that's a tough question right they have to weigh freedom of expression um with trying to remove malicious actions right and there's only so much you can do so we wanted to provide this resource as a mechanism for web app providers to understand that they are armed to do this if they if they choose to do it. So you could scan platforms, you they already do that, right? In the paper, we have an entire sections about how web app providers are already scanning for child uh sexual abuse content and other like uh malicious content on their platforms. The scanning is already happening. You

can just extend it to identify malicious artifacts and IoC's from uh botn nets. All right, thank you guys for your time. Um, I think we're done, but I'm happy to talk offline if if you guys have any questions. So, yeah, thank you again for your time. [applause]