BSides Iowa 2018: "BITS and pieces: Abusing BITS for persistence and privilege escalation"

Well hello everybody. We're gonna talk about the background intelligence transfer service in Windows. We'll talk about what that is in a minute. But first we're gonna do the obligatory bit about us. My name is Daniel Day and I'm an incident responder, digital forensicator dude. And I have a background in the United States Army in the Signal Corps doing telecommunications type work. and then did a while in federal law enforcement. Kind of my role evolved into being a digital forensic examiner while I was there. Spent some time doing the whole education thing, both teaching and being a student, and then ended up at KPMG in 2015, where I am still employed today. I have a few certifications,

blah, blah, blah, some of the sand stuff and some from the government, from the Department of Homeland Security related to forensic stuff. Hello everybody, my name is Ilya Kobzar. I'm an incident responder. I have a background in computer forensics. I also do malware reverse engineering with KPMG. So talking about my background, I'm originally from Russia, as you can hear from my accent probably. So my educational background is satellites and and all that rocket science. So then I joined KPMG in 2011 and basically I moved to the United States four years ago and now I work here at KPMG. I also have a few certifications from GIAC. Also since my background is computer forensics, I have ENC and AC certifications. So that's me.

We're really rocket scientists. That's pretty cool. Don't worry, BITS is not rocket science, though. So like I said, the Background Intelligence Transfer Service is what we're going to be talking about today, BITS. And essentially all it is, it's a mechanism for downloading and uploading files, data, things of that nature. You can download and upload from a server or HTTP, and you can also do that between peers on a network. And so it works all these different ways. What's cool about BITS is in the background, it's going to survive if you lose the network connection, it's going to resume the job and continue transferring the data even if the network connection goes out. It's going to survive a reboot. So even if the system gets rebooted, it's going to

come back up, be just fine. But the caveat is you've got to have an active session going with the login user that's doing the download. It's not going to download when they're logged off. But you can use service accounts, including local service. We're going to talk about privilege escalation, getting local system, NT system authority or whatever, or NT authority system. And we're going to talk about that. But you have to have an account to do that. This mechanism is awesome because you can download stuff in the foreground and say it's a priority, compete with whatever the user is doing for bandwidth, but you can also download stuff in the background and there's different prioritization levels

I'll talk about in a second. and it'll use the idle bandwidth on the system and download stuff when the user's not actively using their bandwidth. And this is the primary mechanism used for Windows updates. And so underneath the hood, this is what Windows is doing to pull down updates throughout the environment. So how can bits be abused, right? And we're going to try to talk about this both from the red and the blue team perspective. So I'll talk a little bit more of the red team stuff. We'll talk a little more of the blue team stuff. We're both blue team guys, though, to full disclosure, we're both like blue team through and through. But we're going to try to make it appealing to both audiences. The primary way

bits is seen in the wild being abused is as a downloader, just pulling down payloads, pulling down interesting stuff. That's the main thing that's being seen. Here's a bunch of articles. At the end of this, we have a sources thing. We'll make the presentation available. You'll be able to get links to all of these articles and citations and all of that, so just so you know, it's there. But it could also be used for exfiltration because you can upload data. So it's certainly possible to use it. You could use it for C2 command and control, probably not the most likely scenario, but possible. Persistence, certainly, which we'll talk about. And you could also mess with

it to prevent a system from getting patched and updated, which can also, you know, help keep a system vulnerable so that you can mess with something or wait for an exploit to come out or whatever. So, what I'm gonna do is talk about bits release history solely as an excuse to talk about the features and functionality of bits, right? So that's why I'm going through the release history, but to kind of show how it's evolved a little bit, but also to show all the cool stuff you could do with it and just kind of how that has been used by Microsoft. So first we're gonna talk about the 1.x variety. This has actually been around

since Windows XP, the initial release of Windows XP. Initially, all it could do was download, and it had prioritization of those downloads, which I'll show you in a second. It had throttling, and it did this asynchronously for the background downloads. Andrew Freeborn just gave a great talk in the other room on COM. If you had a chance to get that, iBackgroundCopyJob implements the IUnknown interface from COM in the C++ library. If that means nothing to you, don't worry about it. And up until the creator's update of Windows 10, these jobs, these transfer jobs were all stored in these QManager files in the all users profile Microsoft Network Downloader folder. So pretty cool stuff. We're going

to talk about that in more depth as well. So these jobs can be prioritized. This is just the C enumeration up here. Don't worry, I'm not expecting one to have to read C or C++. What I want to show is that you've got this foreground priority, which is the, hey, this is top priority, compete with the user's bandwidth. And then you've got three levels that are all background priorities, and that's high, normal, low. And that's basically just saying, you know, in the background, download this stuff, and you can add some kind of prioritization between them, and that will occur concurrently by prioritization level. 1.2 was introduced in XP Service Pack 1, not really any new features upgrades worth talking about. 1.5 got introduced in Windows Server

2003. And this is what added the ability to do the uploads and do uploads and get a reply back from the server And also it enabled you to use explicit credentials with bits. So prior to that, you know, it was all just downloads Then it was uploads the implement a new interface. I background copy job to very creative title, right? but you'll see a little pattern there and And that's what they did now The job will survive for 90 days by default. This is controlled in this particular register key, HKEY_LOCAL_MACHINES_SOFTWARE_POLICIES_MICROSOFT_BITS. You'll see this job inactivity timeout, it's set to 90. So from a blue team perspective or from a red team perspective, changing this or seeing this changed You know, would be potentially an indicator this

has been modified, maybe by an attacker, but there's legitimate reasons to change it as well. But just, you know, by default, 90 days. And a job can have hundreds of files in it that are all set to the same policy, but this is your default time the job will survive, you know, reboots, errors, anything of the sort, and keep trying. The Windows Service DLL that implements the Bits client is called qmanager.dll. And I'm only going to be discussing the version of the DLL itself simply as a little indicator under the hood. to show kind of from Microsoft's perspective what's a big deal as far as changes go and what's not. Because we're going to see

jumps, major version changes from bits one to two. But underneath the hood, the DLL is just going to be doing minor version changes, which kind of shows that from Microsoft's perspective, this wasn't as big of a change or it was. The other thing, full disclosure, have never seen this in the wild, have not read about anybody seeing in the wild. But something could check the version of the DLL something was just to see what features could be implemented or not implemented It's it's plausible probably not the way you'd go about doing that most likely, but it's plausible So just throwing it out there So in 1.0 the DLL version was 6.0 dot whatever the build

number 1.2 jumped up to 6.2 1.5 6.5 so all still minor releases within the 1.x lifecycle of bits Again, you don't have to read C++, but I want to point this out. With iBackgroundCopyJob2, the interface introduced in bits 1.5, a method was introduced called setNotifyCommandLine. And you simply can pass a pointer, a string, to the name of a program and another pointer to a string containing a bunch of command line parameters. And when the bits job is done, it will execute this command for you using create processes user underneath the hood and it will do so with NT system authority. So really interesting stuff and we're going to talk about how you can without that

level of authority inject stuff in, inject bits jobs in and then at the end call whatever you want to execute this. So pretty cool stuff and this is something called bits inject we'll talk about. Somebody's done this. It was a Defcon talk. So jumping to the 2.x variety of bits, this was introduced in Windows XP Service Pack 2 and Server 2003 Service Pack 1. I'm not gonna read through everything on the slides here. I'm gonna kind of skim through some of these and just point out the high level stuff. One thing that's really cool is you could download ranges from a file with this. So you could specify an offset in the file and then the length you wanted to download for. So maybe

you embedded something kind of cool inside something else, maybe doing a little stego or doing something weird, or you just wanna download segments of something, you could do that. And then there's a new interface yet again, iBackgroundCopyJob3. And I'm only tracking this one interface, by the way, there's lots of new interfaces being added, but this is the main one I'm talking about. So 2.5 gets introduced in Server 2008, XP Service Pack 3 and Windows Vista. It adds a little bit more. Big one is IPv6 support, certificate-based client authentication. We do get a new interface that allows us to specify some options with HTTP, including like some headers and things of that nature. And so that's kind of a neat thing you could use. And so, you know, the

website might not respond for you, but you can pass custom headers. We've seen that before, but now you can do it with bits and with your bits jobs as well. Again, here's our QManager DLL file. Still minor version upgrades, even though it's a major version upgrade from like the front face of bits. Oh, it's 2.0 now. Underneath the hood and the DLL, these are still just minor version upgrades, 6.6, 6.7 from the perspective of Microsoft. And you know, we've all seen how you try to download something in Windows and it like tells you, "Ah, it's gonna be 30 more seconds." You know, you come back, you know, 34 hours later and it might be done, you know. Maybe there's stuff going on in the background. It's trying

to calculate stuff. It's trying to prioritize different stuff concurrently. Some stuff in the foreground, stuff in the background. It's kind of interesting to see kind of what's all going on. And maybe that plays into it, but it's kind of a funny thing. So jumping to the 3.x version of bits here. This gets introduced in Server 2008 as well, and Vista, later versions of them. This is where Windows XP support is gone. Bits 3 is not on Windows XP. A lot of cool stuff going on in here. Again, you guys can read. It does improve event logging, but it still just stinks overall. We'll talk about why. in a minute, but the big deal here is

it introduces something called peer caching. And peer caching is, this is the first time now, Bits has the ability to reach out to peers on the same domain and try to fetch files. But there's some limitations to that when it's initially released. The big one being, it's off by default. It's disabled, so you have to turn it on So that's an obstacle. And the peers have to be in the same subnet, same domain, it requires a bunch of different things here. But here it is. You've got to have this peer server that helps, this bit server that's helping out and all that jazz. But it's there. They're starting to move in this direction. But from

Microsoft's perspective, this is a major version upgrade. So this jumps us from 6.7 to 7.0 in our DLL because that's a big feature, doing this peer stuff. But it kind of paves the way for what's coming in the next release of Windows, the next release of bits, I mean. So bits 4.0. They introduced this Server 2008 R2, the second release, and Windows 7 is when BITS 4 comes out. We get a few things here. We get a little bit simpler way of dealing with the resource access. They introduced this thing called the BITS Compact Server, so you can just run this on like Server 2008 and create like your own little BITS server and it

makes it easier to use. But peer caching goes goodbye and branch caching is now in. So what is branch caching? Branch caching is if you imagine like the branches of a bank, I always think of that because they use the term branch. But you have different branch offices of an organization and they're pulling down Windows updates or they're pulling down some file and you don't want them all hitting the central branch to pull that all down because that's just eating up a lot of resources. So instead, you could push it out and that branch can download it locally within their branch and each branch does it themselves and it helps reduce the... the overall load

on the central environment. This can operate one of two ways. The hosted cache where you effectively have a server that says, "I'm the bit server. Everybody in this branch comes and gets files from me." Or you can do the distributed cache in Windows 7 that says, "Hey, John's got the file. I'm going to go get it from John. Ilya's got the file. I'm going to go get it from Ilya." And then it just goes between the individual workstations. There is a key, disable branch cache, but the cool part about branch cache is it's on by default. So Microsoft introduced peer caching, right, but it was off, but now with branch cache, it's on by default. So really cool stuff. You opt in automatically just by having Windows. So

There it is. Windows 10 did add, if you go into the advanced installation now, it asks you questions about, hey, do you want to download stuff from your peers? So it's in the privacy settings now in Windows 10, but it's on by default if you don't go in there and change it. Again, QManager file, this is still a minor version release, a substantial one, 7.5, but still a minor version release from the perspective of Microsoft. Presumably they're reusing a lot of that peer caching code in branch cache. The 5.x, this gets released... in Windows Server 2012, Windows 8, and the early releases of Windows 10. This introduces a lot of stuff, but the big thing I want to talk about very briefly If

you're not familiar with C or C++, they have a data structure called a union. These languages are what's called statically typed. So if you ever use like Python, you can just be like x equals hello world, and then you can turn around and be like x equals 4, the number 4. right? And it lets you do that. But underneath the hood, those are actually two different data types, right? One is an integer or a number, right? And the other one is a string. Well, in C and C++, they're statically typed languages, and without doing trickery with void pointers and things of this nature, for the most part, they enforce... type safety you have to declare

the type up front well they now have all these properties and you saw how those interfaces for i background copy job they kept having to add new interfaces every time they wanted to add new features so you got i background copy job two three four right and now five they kind of like hey this is kind of ridiculous they have to keep doing this let's like create all these really cool flags and we'll create this id that can have one of many different data types and And the ID will tell us what type this value is because it's a union and then we'll know what type it is and then we'll be able to go

over to this thing and have a variety of different identifiers in these properties and that way we can add new functionality through flags rather than having to keep adding more interfaces. So kind of a neat idea how they're doing it. If that made no sense whatsoever, that's okay. The bottom line here is that they introduced a new way of being able to add new features, hopefully without adding a lot more complexity for developers. What's also cool is they add these PowerShell cmdlets. And they enable us to use bits very easily and we're going to show examples of that and whatnot in a second. And we can also have persistent remote connections with PowerShell. So very

nice. And they do some improvements to the security model so we don't have to be admin using this as well. We don't need as high privileges so we can use better security models. But one of the other cool things that gets introduced is metered networks, the idea of a metered connection. And that's what our proof of concept, that's our little contribution that we've not seen anywhere else yet, comes in, is with metered connections. Because this is a new thing. A lot of people are using devices where you have to pay for your bandwidth. Well, Microsoft has enabled a whole host of options to help us to help us kind of say, oh, when might you want to download Windows updates or not download Windows updates, right? If you've

got this huge two gig update you need to pull down, but I'm like over my cap and I'm now paying overage charges, maybe now is not the time to pull that down. And so Microsoft's added a whole bunch of flags. These aren't even all of them. I will show them a little bit later, all of them. But one of them is this bits cost state unrestricted, which basically says only pull it down if there's no restrictions on this network whatsoever, right? But you can get more granular than that, right? If it's below capacity, near capacity, if overcapacity charges are applied, if overcapacity is applied but I'm being throttled, you can actually granularly detect these things,

unmuted connections. So pretty cool stuff that it's all there now. From the DLL perspective, it's interesting that these are still minor releases. So 7.7 for Server 2012 and Windows 8, and for Windows 10, it's 7.8, right? Another minor release for Windows 10. So jump into 10, Bits 10, and they're kind of syncing up their version histories with Windows 10 here. This came out with the Creators Update. So if anybody remembers this annoying screen constantly bugging you, hey, you should get Creators Update. Fun things there. So they added a few things here. Again, I'm not going to go through everything, but they allowed more granular control. They offered this thing called on-demand mode where you can randomly access files. But despite this jump from 5 to 10 in their public

version, the reality is underneath the hood, it's only a build change. It's still 7.8, in case you remembered it. It's not a mistake. It was 7.8 before. It's 7.8 still. So just as a refresher, your first number is your major version. Second number is your minor version. The third number is your build, right? only the build changes here so underneath the hood it's not a big shift but there is some big changes the most notable one being that before they were storing everything in these dot dat files called q manager files and now they're storing it in an ese database and i'll talk about some of the challenges of that in a minute so it's

everything in the release history um Hopefully that gives some idea of the capabilities, things like that, but let's move over to, okay, that's great, that's all very theoretical. What can I do about it? How do I use it? Whether you're a red teamer or a blue teamer, let's talk about that. So first let's talk about some tools and techniques with little to no assembly required. Easy button stuff, right? So BITS admin's been around for a while. It was available with the install CD for XP Service Pack 2. And it's a command line utility that lets you very easily create jobs. You can do a one-liner like this very first line up here and just say,

"Hey, I'm gonna create a job here. I'm gonna call it WinUpdate." That name is arbitrary. You can call it whatever you want, Bob's Download, whatever. WinUpdate. It's gonna be a download. That's type of job. It's going to have a priority of normal, so it's a background job, normal priority. And we're going to pull it down from this particular URL. Full heads up, we've got a little Easter egg on that URL, and we control it. So if you want to play with it, go ahead. And then it's going to get saved to cdrive.winupdate.exe. So that's the one-liner. The alternate way you can do it is by all the remaining lines. So I can create the job,

winupdate. I can add a file to a job. And this is what you would have to do if you wanted multiple files in the job. So I'm going to add file, add file, add file. And then you got to call resume. Kind of weird. Actually took me a while to figure this out in the C++ and using com, and I'll talk about that in a second. But anytime you change a job in bits in any way, by adding a file to it, by changing the priority, whatever you do, it automatically suspends the job. So you have to then turn around and resume the job for it to do anything. So it took a while to

figure that out. But so you call resume after you do anything using this method. And then you can call this info just to get some idea of what's happening, a status update on it. So you would think bits admin It's been around since 2001. It's actually deprecated since Windows 7, so you'd think everybody's using PowerShell now, that's the new way of doing it. Actually, this was seen in malware as recently as 2016. It's actually still out there quite a bit, just the articles from 2016. A lot of malware is packaging this with their malware, this bits admin tool, and using it to download stuff. So, kind of an interesting thing. One notable example is this

Trojan ZLAP queue, and again, I have links to all these articles and stuff at the end of the sources. But PowerShell is now the way to do this. But as the Windows API goes, right, you've got all these older interfaces, all the way through iBackgroundCopyJob4. So bits.admin works with all of those just fine and, you know, just keeps working. Or it might be 3, I'm sorry. But it works with all the old stuff, and it'll just continue working to pull down files. So it still works. You just get a warning saying, hey, it's deprecated. You should use PowerShell. PowerShell makes this much easier. You literally just go start bits transfer, source, destination, pulls down the

file. That easy. You don't even have to give the source and destination parameters, they're optional. It just assumes if you give a URL and then a file path, it'll take it in that order and do it for you anyway. So this is the simplest, easiest way to do it. So this is the way, probably gonna see it the most, you know, it'll probably be an obfuscated PowerShell, whatever, but this is the way to do it. So if you see this start bits transfer go, oh, wait a minute. You can also do this remotely. Remember I said you had to have an active session? So here's how you can pull this off. You can create a

new PowerShell session, point the computer name at the host name of the victim system, I'm calling it victim system here, create a name for the job, I'm calling it Windows Updates for you, and pass the compromised credentials. Now this assumes you have these credentials and whatnot, but if you're already on PowerShell, you probably do. Enter the session and give it the name of the transfer job, Start the job the same way we did before, and you can pass an asynchronous flag too to help us along. And exit the session. And then this is the key thing. If you stop there and then you log out, your job just got suspended. Too bad. But if you

disconnect from the PS session, it lives on with a life of its own and continues doing its thing. So that's the key little step at the end there. So bits inject. This was done at DEF CON 25, I believe. And there's QManager files I talked about. He saw these and he went, "Hey, wait a minute, let's play with this and see how we could maybe inject jobs into this." And what he found was there was no kernel level file protections, not even trusted installer protections on these particular files. The only thing protecting these files was the bit service itself. So he's like, "Well, I can stop a service. That's easy enough." So if you just stop the bit service, modify the file, restart the bit service, it just does

whatever's in the file, just carries it out. You can actually take one file, copy it to another computer, and it'll do whatever's in that file as well. There's nothing per system about it, nothing like that at all. So very easy thing, particularly since you have that set notify command line, you can set all those parameters as well. And that's what this tool does, it's a Python tool. One click solution is what he says, pretty easy to use. And it goes ahead and you can inject jobs into the system. Now this assumes you have local admin, but now when you run this, you've got anti-system authority, or anti-authority system, sorry, I always say it backwards. Pretty

hard to detect, but if you're a blue teamer, you're gonna be looking for the bit service being stopped, you're gonna be looking for modifications to those queue manager files, right? So it's one of the indicator that we'd be looking for as blue teamers. So, like I said, there are event logs as well. They basically just say, bits job started, bits job, finished, bitch job suspended. They don't give any information beyond that. They don't tell us what it was doing, what files were downloaded, how many files were in it. They don't tell us anything. So they're almost useless, but they're there at least as another indicator. Something was going on with bits. I don't know what's

happening. I should probably look and see what's going on in the QManager file, QManager files. And so up to bits four, these tools will work. And I'll talk about why I think they break in five. There's a 010 hex editor template, if you use that text editor, I love it. And that was also created by, I think his name's Dorazuri, I think is his name, created, don't quote me, it's in the sources. And he creates this template. The French National Agency for Information Systems Security created a bits parser, Python 3 based. Then Andrea Sancho, wait, I have to punk you out. Andrea Sancho, right over there, wrote bits jobs parser, We had a need to

refactor it as a Python 2 script and a simple script for our purposes. She did that. And in the process of refactoring it, also added some additional error handling and also actually is now carving more data out of it. So this is not just parsing the active jobs. She's actually also carving data out of it as well. And so really cool stuff. And you could find jobs that are now complete and longer in there. Pretty cool stuff. Like I said, it switches over to using this ESE database. Using ESE database view, which is a bit limited, at least in this application, I saw the files, jobs, and then the other tables that you see there. I would have assumed you'd see stuff in files and jobs, but

it didn't, even while the jobs were active. So very weird, opened up these files in a hex editor. The database file itself didn't see much, but there's a .chk file and a .log file in the same directory, and I actually saw the data in the hex of the jobs that I was doing in there, but I couldn't open those as valid ESC databases. I didn't have time to play with this too much more. ESE Database is a whole... There's a lot of people trying to solve this problem. It's not my domain, so this is an open area of research if anyone wants to play with it. But if you recall how... Bits changed the whole

structure, the property ID and the value. What I found was when we started using some of those custom flags, it broke the ability of the parsers to work when you set those. If you do it the old school way and you just download something without those flags, everything parses fine. But when I started using the new flags, all the parsers broke. And so it's really interesting. It makes me think that a little bit more of what's going on under the hood with that, and it also changed how the DAT files work. Whether it's worthwhile to write something to parse it, knowing the data structure changes to an ESC database, I don't know. It's up to

you. But pretty cool stuff. Just throwing it out there. I don't have all the answers, right? But I'm just throwing out what I've found so far and what's there. So tools and techniques with some assembly required. Not literal assembly language, but in this case C++. You can also do it in C Sharp. So this is what we did. We wrote a proof of concept using the COM API or APIs. And this proof of concept assumes a few things. Number one, we are targeting a specific user, a specific subset of users, and we know something about the network that they connect to. The thing we want to do is we know that when they're at their

work network, that network is monitored. We know they've got a SOC. We know they've got security solutions in place. We're afraid if we download our payload on the work network, we're going to get caught. We're going to make the assumption you can... It's easy to change this, but we're going to make the assumption we know he plugs in. It's an ethernet connection when this person's at work. All right, we're just going to make that assumption. Relatively easy to do with wireless as well, but we're gonna make the assumption he's got an Ethernet connection and We're gonna make the assumption that we've got a local admin account on our targets machine Okay, so there's a lot

of assumptions here, but use lots of ways to get to that point, but here we are We've got all those things we want to download a payload, but we're afraid of getting caught. We've made it this far We don't want to mess up. We'd rather live off the land then put malware on here and do a bunch of crazy stuff We've gotten this far. We don't want to get caught and So what we want to do is set this Ethernet connection or any Ethernet connection as metered and then we're going to create a transfer job that says don't download over a metered connection. And that's going to be a way of getting around maybe not

seeing a download on the network we want to avoid that on. So you can do this by just changing the setting. I mean if you have local admin you could do it this way. But you could also do it in PowerShell or even just directly in the registry. So what's cool is in HKEY_LOCAL_MACHINE, software, Microsoft, Windows NT, current version network list, default media cost, you can go directly to the Ethernet key in there, change the value to hex 2, and it's now a metered connection. So underneath the hood, that's what's happening. So if you want to do this programmatically, there's a guy by the name of Michael Pietroforte who did this for us, and he

wrote this PowerShell script. There is a link to that. So from there, we set the connection, We've set the connection now as a metered connection. We want to download our payloads. Now we're not so worried because it's not going to download over the work connection. It's going to download later when he goes to Starbucks or goes home. And so they won't see the download hopefully, right? So phase two, this requires bits five, right, for the new flags and whatnot property values. So this is Windows 8, server 2012 or greater, works on Windows 10. And we implement iBackgroundCopyJob5. We're going to set this bits job property value as a D word, and we're going to set

this bits cost state unrestricted flag, which is literally just PAX 1. And we're going to say we're only going to download this file on an unrestricted network because we've set the work network as a metered network. And I'm basically using, I'll show you the code, but basically using this Microsoft example code. I will apologize before I show the code because it's not how I would write it. I would use smart pointers and things of this nature, but I'm just using the raw C pointers and whatnot that Microsoft made because hey, they practically wrote it for me. So here's the full enumeration and we're using the bits cost state unrestricted flag. What's cool about this is

they actually, some of these flags further down are actually just bitwise ors of other flags. And so as an example, the cost state transfer not roaming is actually just an or of all those other flags. It's just doing a bitwise or of all those others. So they kind of made like these alias flags, if you will. We're just setting the first one, bits cost state unrestricted flag on this particular job. We didn't implement phase three because it's just proof of concept, but we could very easily call set notify command line. We could do a lot of other things once we have this file on the system. So just showing kind of how we could do

this. All right, so let's continue. The next part is going to be the actual proof of concept sample analysis. So Dan wrote the code, he compiled the binary, and we started analysis. So first of all, let's talk about the general approach which you would use when you encounter a malicious sample. So first of all, you would try to get quick IOCs by performing automated analysis, and that can be done by either running sandboxes There are a lot of tools which could be commercial or free open source. So there are a lot of options. So you would do that first to get IUCs, to get some pointers to continue your analysis which will help you to basically understand

what the sample does. So what you do next, you would start doing static properties analysis and that includes header and structural analysis, getting strings, obtaining hashes, hashes for the binary, hashes for the sections, so all that kind of stuff. So reviewing imports, which is also important. If you have packed binary, you'll need to determine what packer was used, how to unpack it, and that kind of stuff. So, next what you would do, you would try to run a malware or malicious sample in isolated and controlled environment. And what you do, you enable as much monitoring tools as you want that could include processes execution monitoring network network monitoring tools file system monitoring so there are a

lot of tools I have few dozens of those which I use often every time I need to do something with doing the behavior analysis also important part of behavior analysis is Basically, since the environment is isolated, so you don't want to be detected by adversaries or malicious actors, so you should create a local isolated network to monitor all the traffic and you need to provide a sample, whatever it needs to continue its execution. So it can be done either by providing specific network incoming packets or doing patching of the sample or doing all that kind of stuff. So that's what you would do generally. So the next and the last step, and this is the most time-consuming step of your analysis, is basically manual

dynamic and static code reverse engineering. And for that you use disassemblers, debuggers. There are various tools out there for either Windows binaries or Unix. So you do that. So, yeah, that's the general approach for analyzing malicious binaries. And we're going to take our sample and go through each of these steps and see what we can get. So, first of all, automated analysis. So, I uploaded the binary to a sandbox and we basically have no results, no specific threat. And it makes sense because our binary doesn't do anything malicious by itself. It just uses the Windows bits operation to download the payload. So let's do static properties analysis. We can start with strings. So you can

see the strings picture here. And so here we have the basically we can assume that that's the output pass of where the payload will be written to. And also something which looks like a URL and we have the same exe file. So that's basically where it's being retrieved from. So our sample, we did not include any obfuscation, we did not include any packing, so most likely when you start doing like real malware analysis, you would not be able to see this information so easily, so you'll need to unpack, de-obfuscate, and do that stuff. But here Here is a good pointer for us and so we can start building theories what the sample does. So we have URL, we have output, pass

and the file name. Yeah, so you can see it's suspicious. It makes sense. That's all I explain. So next we review the imports table and if you use some automated tools for static properties analysis these COM APIs would be red flagged. So that's not normal that you have these APIs in the imports table and basically we will be using this pointer for our further static and dynamic code reverse engineering because This is a good clue where we can start from. So yeah, that's the static properties analysis. Let's continue. Now we have the behavior analysis. So first of all, let's take a look at the file system activity. So we have four queue manager files modified after the

sample was executed. So that also gives us some clue that most likely we're having deal with the sample which utilizes bits for its operation. So also after the execution we have the CTAMP and that bit 93B6.tmp file created. So this is also suspicious, like if I see this kind of activity I go directly to that file. If it's being deleted after execution you just enable monitoring tools which would catch any deleted files so you can retrieve that and analyze. So this is great. Let's continue. And also during the Behavior analysis with I found that the all all activity being initiated by SVC host at the XE and not by our sample and probably that's why the

Sandbox was not able to catch this because it's basically SVC host at the XE is legitimate Microsoft binary so And that's what we have from the processes execution. So we have CMD.exe thread which creates process bits POC.exe and then it creates another threads and terminates itself. So that's basically all you would see from the process from the running process on the on the compromised system. So next we monitor network activity. And as I said, so we have isolated environment, so we monitor network traffic. So what we see is the GET request for that exactly URL we previously observed in the strings. And we see a response from that URL with basically a payload. So yeah, that's for network activity.

Now I'm going to show you a quick demo for the textual analysis performed. And so we are going to quickly step over the static and dynamic code analysis for this sample. We're also going to look at the queue manager files, how they're being modified, what we saw before and after. So let's begin. First of all, we go, we find the queue manager, that file which we observed before while doing the behavior analysis, so we know that this file has been modified. So I just copy it down. rename it to so we can determine which one was before and after. So for the parsing, I use 0.0.1.0 hex editor template for bits, queue manager job files, and as Dan already mentioned, so we have the reference

to this template. We'll show that at the end of the presentation. So what we have here... It's really easy to see. So we have the destination paths of the bits queue manager file which we currently have on the system. And so what we can see here that there is some Microsoft phone cache configuration file. And we also have the remote URL which is set to Microsoft.com. So pretty standard normal observation. So we have that stored. Now let's continue. Let's start with static code analysis. I like starting my analysis doing first looking at the code in general in disassembler and then make some assumptions, make some assumptions conclusions and then try to prove them doing dynamic code reverse

engineering. So what do we do first? First of all, we previously observed those APIs which are responsible for COM interface, operation with COM interfaces. So we have the co-initialize, co-create instance and co-initialize security and co-initialize ex so basically we are going to jump right into into the subroutine which uses that those apis all right So what we have here, when you start doing analysis and that's how I was teached to do that and I feel like it's pretty helpful. So first of all you need to look for any calls the subroutine does and any conditional jumps. So this can give you an idea what's happening in the binary. So we can see here, so we have

calls to co-initialize ex, co-initialize security, and create instance. Like right after those, we have test operations and conditional jumps. So what test is, is basically implied and bitwise operation and why it's called implied, why we call it implied because it basically does not modify any registries as a result of its execution. It basically what it does, it sets a specific flags. That's all it does. And most, so most commonly test being used to determine whether the registry is zero or whether a registry is, value is negative. So how you can determine that is based on the either zero flag or signed flag. Signed flag means that the most significant bit is set, which means that the value is

negative. So, and this specific sample uses the conditional jumps for errors, error check. So basically we call for initialize x, then we test results because the output of this call is written to EAX registry. We test the output and if there are any errors, we jump to... we jump to error reporting and termination of the process. If there is no errors, we continue execution. So we see that the flow continues here. This is basically what all these calls do. They initialize COM interface for our sample. What else we see? So we see some strings which is also helpful. It kind of gives you an idea sometimes to... It helps you not to be lost in the code and probably you can

sometimes you can find really helpful stuff in the strings. So what else we have here? So we have, as you probably noticed, some of the call functions are disassembler helped us to understand what those are, which are Windows Comma APIs, but some calls were not explained to us. So for example, this SAP 401 1.0 or this call for a pointer in the registry. So, what else we have here? We have, again, we see our URL and the output exe file here in strings. So, that's kind of interesting. And then we just see uninitialized call for uninitialized com API, which is basically unloads all DLLs and returns to the main program flow. So... Yeah, that's what we have from

static analysis. Let's continue and load our sample to debugger to see what it does. And we already have some assumptions and we'll try to verify those. So when you load the sample to debugger, similar to what we were doing with disassembler, first we go to imports table and you will be able to see same COM API's in here. So let's go, let's jump right into that code section which is responsible for operation with COM API. So yeah. As I previously told, we have basically first call is the initialization of the COM, then we set the security impersonation and this is basically what you would do when you start initializing COM interface. So what we also have here, so

this call right here is the Co-create instance and what it does basically it it creates an instance of I background manager interface so background copy manager interface, so Next we have the call for Call for creating the beats job and we see that it's indirect addressing here, so that's kind of tells you that and this unicode it says the it pushes the name of our job on stack and then this call creates the bits job. So what do we have next? Here at this point we basically setting transfer policy flag and I can tell you that this is the part of the code where we basically set our flag as Dan previously mentioned, the transfer

policy property flag, which is hex one. So what this instruction makes it it pushes the hex 1 to the value which is stored in stack pointer. So ESP is the stack pointer registry. So you can see it here. And what it is, you can kind of see it's the same address. It's basically where our stack is currently pointing to. So that value will be pushed on stack. Then we will call for query interface. ABI here and then at here we will actually perform the transfer policy flag setting. So yeah, and you see again those checks for errors. So if signed we're jumping to the error reporting. So yeah, let's continue. What we are doing next, so once we have the policy flag set, we

verify that the actual job was created and the policy flag was set correctly. And what we do next, we basically provide these two arguments to be added to the job bits queue job manager file. which are being added here with this call. And yeah, so the next what we do, this call is basically call for resume the bits interface and that will let us to basically execute the internet connection to the URL and download the payload. So yeah. Also, what I suggest, like when you do the code analysis, pay attention to the functions which are being used most often. And in this case, we see this function being called constantly. And we saw that here too. Yeah, I'll show you a little

bit later. So let's figure out what that is. What we do, we just go to our disassembler and try to open that function. And so what we have here, we have set of upper ends and everything. And here we have reference for VF print file. So most likely that's the W print file function. And we will verify that in a second. All right, so yeah, what is helpful in either you just rename the functions and you can easily see the ones you renamed and you can easily highlight those and so that helps you with analysis. Now let's start executing our sample. Let's take a look at this specific function and let's make sure that we made our assumptions correct. So right here, we have

push for this Unicode string. We see that the Unicode string creating job was pushed on stack. Then we have the call for this function and Yeah, right here we see that that exact string was pushed and displayed on the terminal. So yeah, that's how we do combination of static and dynamic code analysis and just making these assumptions or theories and trying to prove them. Yeah, now let's go over all this, all the execution of our binary. So I have you a few breakpoints here. So we have the job created. Now we are going to add the executable name and the URL to the new job right here. So... now we continue execution and right here, right before the call for uninitialize com

interface. So there was a call for resume of the bits operation and that's what it makes to basically execute the transfer job and reach out to our URL to retrieve the executable payload. So now we are going to take a look at the bits queue manager file after it was modified by our sample and compare it to what we had before. So you can easily see that the URL and the payload file name were added to the queue manager file. So yeah, so we're naming it after. run template, parse the QManager file and open the pass and the URL information right here. So yeah, we can see that CTEM Windows update was added as well as the remote URL. So we compare

that to what we had before, some Windows fonts cache configuration and the Microsoft.com URL, which means that our program was executed as it was expected. So yeah, let's return back to the presentation. Yeah, I think I can. - Couldn't find my-- - Yeah, I can do that. - Here you go. - So, all right. So now quick, Now, quick question for you guys. You probably saw when I was doing behavioral analysis, you saw this beginning of the payload, which is MZ, and then we have some string right here and the URL. So do you guys have any ideas what this can be? So basically, what do you think this string is? Like this here. God, what is that? Yeah. Like that, what is

it? Like what would you basically, uh, when you, when you run a sample, you, you, you got that temporary file created, you open it in hex editor and you see this MZ and whatever string that is. So, um, my first assumption would be that, uh, uh, that's definitely basic C4 encoded string. And, uh, since, yeah, I like analyzing shellcode and if I see this kind of stuff in shellcode, I definitely know what that is. So yeah, basically we just decoded some phrase in there and that's all it is. Just a bogus text file with basic support. So if you download the file, you don't have to worry about anything. You can put the valid binary header and Z in there, so it'll actually verify as an EXE. So like

Chrome might not let you download it perhaps, but... - With a space 64. - Yeah, yeah. So yeah, that's all for analysis. - Yeah, so does anybody have any questions for us? All right, that's pretty easy. So here's how to contact us if you do come up with one later. Awesome. Just high level takeaway though. Let me show you the sources too. They're going to be in here. I know you can't read them from here right now, but we do have all these sources, including all the tools that have been mentioned and everything. There's sources for all of that stuff, and we'll make this all available online. Key thing, just at a high level, recapping a little bit, right? Background Intelligent

Transfer Service used by Windows can upload files, download files, we're using it as a download. The cool new feature, the thing we did that's a little bit different from others in the past, is set something as a metered connection. I just threw the binary at Ilya and I said, "Hey, this is gonna like maybe download some stuff, figure out what it does." I just compiled it in C++, didn't really give him much more context. But I did put a lot of strings in the binary itself to help them out. If you want to see the code, if you read C++, great. If not, you can just totally zone out. Our talk's pretty much over. But

this is the code. I'm using basically the Microsoft example, but tweaking it so it actually does something, because their example doesn't actually download. It just creates the job. It doesn't do anything. So... Effectively, you can see some of the stuff that Ilya was talking about. It's initializing some stuff, sets up the threading model, and then it's just doing these checks. This is the test, AX registered or enhanced AX register. EAX test, this is testing for these errors. It's the H result that gets returned if you know COM. So it's setting up that. There's the impersonation. It checks if it's exceeded or not. Gets the UID right and you could go to the software classes registry

key as well if this was registered on the system because it's calm. Just one other place to look. And I put a lot of strings in here. They're very helpful. The point wasn't to obfuscate this and make him waste a week on it. The point was to just kind of show what it would look like. and then you know the job gets created it called it payload updates because you know why not make it blatant and Jobs created and then this is the magic right here. We're creating this bits cost state Unrestricted and then down here. I'm setting that property bits job property ID cost likely get passed over to it here Right here and

then gets the property the file gets added right and this is the The UROA control, that's going to be the output name, and then the job gets resumed at the end, it wraps up. I'm apologizing right now because this is not how I would write this in good idiomatic C++. There's no way I'd be using gotos and I'd definitely be using smart pointers but work smarter not harder. It's a proof of concept. Microsoft already wrote a lot of this for me so I was like, "Hey, I'll just re-implement this." If you're gonna do something more robust, you probably wanna use ATL or something like that and use C-COM pointer. You can use the modern C++

smart pointers but it's a little trickier. You have to add your own, add ref and all that jazz. But anyway, This is who we are. Here's our contact information. Thank you very much.