00:00:00.000-->00:00:05.973 >>Alright, thanks for coming. I know it's uh, lunch time. And no one likes to miss lunch time. 00:00:05.973-->00:00:10.978 So, uh my name's Josh Pitts. I got out of the Marines right before 9/11. I wrote, uh Back 00:00:13.914-->00:00:19.052 Door Factory and uh Back Door Factory Proxy. And this is a, this is a file on infection 00:00:19.052-->00:00:25.859 framework that will inject code into PE, ELF and Maco binaries, the x86 and sixty-four bit side. 00:00:25.859-->00:00:32.633 And also do ARMv7 for ELF. I uh, because of that, I found OnionDuke, which was a, uh 00:00:32.633-->00:00:37.237 Russian malware infecting downloads over Tore, why would you do that over Tore? I have no 00:00:37.237-->00:00:43.310 idea. Uh, but I co-authored a uh, environmental key framework, uh that made environmental key 00:00:43.310-->00:00:48.315 malware called Ebowla and yes that's spelled correctly. I work at Okta where I do red teaming. 00:00:50.550-->00:00:56.390 I, we uh do design reviews, everything you can think of. Pen Testing, reverse engineering of 00:00:56.390-->00:01:01.361 anything we put on our network and there's my twitter handle and there's my GitHub where a 00:01:01.361-->00:01:07.601 lot of this code is. So um, why this talk? Well you know, I- I- think, writing shellcode is fun 00:01:07.601-->00:01:14.141 believe it or not. Uh my wife thinks I need new hobbies and that's fair. Um, so and I want 00:01:14.141-->00:01:18.045 to talk about the current state about public Windows shellcode, how it works and uh talk about 00:01:18.045-->00:01:23.283 updating it. So we've got three parts. There's history, there's further development and there's 00:01:23.283-->00:01:29.156 uh, mitigations and bypasses. So the first part. So MetaSploit's shellcode right now uses Stephen 00:01:29.156-->00:01:36.029 Fewer's Hash API or MetaSploit Payload Hash. Uh, the, the basic concept is it, of it, uh it uses 00:01:36.029-->00:01:41.935 a four byte hash with a thirteen bit war instruction. Uh, define Windows APIs into use the export 00:01:41.935-->00:01:47.975 table, or define Windows APIs in the export table of a DLL, any system DLL. And I was introduced 00:01:47.975-->00:01:54.348 in August 2009 and some of this has roots back to uh Matt Miller or Scapes, one thirty two 00:01:54.348-->00:01:58.552 shellcode paper. And these slides are online and then I have a link to the paper. And uh 00:01:58.552-->00:02:03.924 Scape now works for Microsoft in the mitigation department. So just keep that in mind. So this 00:02:03.924-->00:02:10.697 is um how it works. You do a call over the payload, you push everything onto the stack and 00:02:10.697-->00:02:17.237 then the, the, the uh, the shell code or the, the hash API will parse export address table and 00:02:17.237-->00:02:22.376 then jump into Windows API and then return back to payload logic and it will continue until 00:02:22.376-->00:02:27.514 there is no more payload logic and your payloads been executed. Now this allows, what was kind 00:02:27.514-->00:02:31.084 of cool though about this is that this allowed payloads to be portable across all Windows pla- 00:02:31.084-->00:02:36.089 uh platforms. And of course some mitigations uh decided to uh be or to come out. You have EMET or 00:02:39.326-->00:02:44.331 E MET uh this was a SFHA, Microsoft. And then you have uh Piotr Bania. He has a Phrack 00:02:47.000-->00:02:51.705 article on, oh beating uh, some of these uh payloads. And then there's also the HAVOC um, 00:02:51.705-->00:02:56.710 mitigation. Which was released, uh uh the concept was released in POC GTFO twelve seven. Amen. 00:02:59.980-->00:03:04.951 Um, and, and, HAVOC stands for Halting Attacks Via Constructing Configurations. And this was 00:03:04.951-->00:03:10.390 funded by Darpa uh fast track. It's by Digital Operatives and what it did, it threw um, it 00:03:10.390-->00:03:17.297 threw a DLL up into the loaded module list of uh the DLLs and it what it, what it did, it, it, 00:03:17.297-->00:03:22.302 basically it pre-computed collisions uh for this four byte war, um, four byte hash war 00:03:25.605-->00:03:30.610 assembly. Uh, anyway, so what it did, it made these collisions and actually it uh worked pretty 00:03:33.113-->00:03:38.718 well. So there's also the EMET Caller in EAF uh protections. Remember the shellcodes was 00:03:38.718-->00:03:45.158 introduced in August 2009. And the EMET EAR protections was introduced in 2010. And what 00:03:45.158-->00:03:51.364 this does is it protects uh KERNEL32 NTDLL and KERNELBASE uh from ya know read that. And then 00:03:51.364-->00:03:55.836 also you have the caller protection which is really more uh, restricts ROC like calls but 00:03:55.836-->00:04:00.941 still computers hash tag PI would trigger on this also. They say you cannot go into a Windows 00:04:00.941-->00:04:05.946 API cia a ret or a jump it had to be basically a uh indirect call. And as you may have heard, 00:04:08.281-->00:04:13.286 EMET end of life. It's supported through July thirty-first, next year. It still works and, but 00:04:16.323-->00:04:22.262 it's being reintroduced into Windows 10 uh this fall and we're going to talk about that. 00:04:22.262-->00:04:27.667 And it, it does still work. I mean, so this is the this is the pro, this is the Tor exploit 00:04:27.667-->00:04:33.640 that uh was targeting some people that was doing some illegal things on Tor. Nobody 00:04:33.640-->00:04:39.980 does that, um, it, it basically it flagged on a stack pivot mitigation. So, so EMET still 00:04:39.980-->00:04:44.985 has um, some relevance in the field, right? So Bypassing EMET, there have been a couple, uh, uh 00:04:49.222-->00:04:54.227 public bypasses and uh Skypher had a, a um or Skyline, used a, a method um to make EMET think 00:05:04.538-->00:05:06.540 that the the code was valid reading the ex... [audio skipping], Piotr uh Bania, and 00:05:06.540-->00:05:10.210 he wouldn't use hard wired breakpoints, he would erase them essentially. And often since 00:05:10.210-->00:05:16.983 security, they had a bypass by reusing code within EMET itself. Now the caller uh bypass, like I 00:05:16.983-->00:05:22.489 said earlier if you have the handle two Windows API all you do is move it into a uh, there's 00:05:22.489-->00:05:27.127 a couple ways to do it, but all you do is move it into a, uh register, you reference the 00:05:27.127-->00:05:32.032 register and then you call it directly. Or you can do a indirect call. I think it's 00:05:32.032-->00:05:37.571 shorter to do an indirect call. Directly, I think it's only two bytes. So knowing this, a bit, 00:05:37.571-->00:05:42.475 back in May 2014, I've put import address based payloads into BDF and they worked just 00:05:42.475-->00:05:46.713 like compiled code because I realized the closer you, you are to working like compiles code, 00:05:46.713-->00:05:51.718 the harder it is to stop you with uh, any mitigations and it also makes you harder to see for 00:05:54.487-->00:06:00.594 anti-viruses. Uh, so I added these in, in May and then December I wanted to see if I 00:06:00.594-->00:06:05.699 could use a concept and exploitation um, and I wanted to use the import address table. So 00:06:05.699-->00:06:11.438 I looked for some prior work. Skape's uh paper, again I used that, I looked at that. It 00:06:11.438-->00:06:16.910 wasn't, I, import address table payload, uh that he had, but there was some issues with it 00:06:16.910-->00:06:22.949 because he used the export table to get to uh,uh uh API load library A and then he would use 00:06:22.949-->00:06:28.655 that to get to a DL, DLL and then use an import table off of that. Um and it was, I think it 00:06:28.655-->00:06:33.660 was hard coded to a certain version of, of the system DLL. And then uh, uh Piotr Bania, he 00:06:36.029-->00:06:40.433 had a import address table parser. I decided to use that but just for reference. The 00:06:40.433-->00:06:45.438 first known, I guess use of import address table, uh for something malicious was a virus 00:06:48.008-->00:06:52.846 from 1997. Ok, uh it was not really an exploit, it just used the import table directly. So 00:06:52.846-->00:06:57.851 uh, it was a file infector and it would just use the import table. So this is Piotr Bania's, 00:07:00.654-->00:07:06.559 uh point of concept. I could not get this to work on a modern Windows OS. Uh, I think I was 00:07:06.559-->00:07:11.498 testing this on a Windows XP service pack three. And alsa Windows 7. And so I decided to 00:07:11.498-->00:07:16.736 update it for some tolerances and I'll explain that. So the way it would work, is you would 00:07:16.736-->00:07:22.342 find image base, in the P being, you could get the P header and then you'll get the import table 00:07:22.342-->00:07:26.780 relative virtual address and then you would loop through and find KERNEL32 via a ASKI match. 00:07:26.780-->00:07:31.785 And so, um next, oh, it find low library A and get a procedure address but I added a check in 00:07:37.357-->00:07:43.196 set to, set bounds of readable memory to make sure that um, it's readable memory. Because if 00:07:43.196-->00:07:47.467 you can't read the memory you will have a crash. And then after the stub is done, low 00:07:47.467-->00:07:52.472 library A would be an EBX and get, uh get procedure address, GetProcAddress, would be in ECX. 00:07:54.507-->00:08:00.714 I bolted on a reverse GCB shell and it's this bypass column, EF checks, really easy. And then I 00:08:00.714-->00:08:06.853 emailed the EMET team. And uh, this was the response essentially. So uh, so they knew 00:08:06.853-->00:08:12.625 about it obviously uh Matt Miller, I don't know if he was consulted but they knew about 00:08:12.625-->00:08:19.432 it. I mean they get tons of crashes and they analyze crashes. Uh so, in my POC just 00:08:19.432-->00:08:25.238 use the load library A and get a proc address from the import table. It was pretty limited, so 00:08:25.238-->00:08:30.944 if the, if the uh binary did not have it in the import table then it was useless at the time. So 00:08:30.944-->00:08:35.949 this code sat from December 2014 until February 2016 when SubT, if you don't know SubT you 00:08:38.351-->00:08:44.891 should get to know him. Uh he's the person that executes code and things, he ru- executes 00:08:44.891-->00:08:48.862 codes and things that shouldn't be executing code. Not through exploitation but through hidden 00:08:48.862-->00:08:54.167 features and other uh things that just, ya know these are signed by Microsoft and you can 00:08:54.167-->00:08:58.571 run code and it's great. Like ya know, like it's pretty awesome. So uh, he, he tweeted that he 00:08:58.571-->00:09:02.909 was having problems at EMET because of EAF. And I knew exactly what his problem was so 00:09:02.909-->00:09:08.114 we started to collaborate. And I sent him the only stub I had at the time and he went crazy with 00:09:08.114-->00:09:13.319 it. He was using it pretty much everywhere. Uh the only problem was, in powershell, uh 00:09:13.319-->00:09:18.958 powershell did not have load library A in the import table. So we talked about uh moving, 00:09:18.958-->00:09:24.364 looking elsewhere for loadlibrary And GetProcAddress from a loaded module. And, so he 00:09:24.364-->00:09:30.770 wrote an addition to do this and he borrowed code from uh Stephen Peer's API stuff. And changed it 00:09:30.770-->00:09:35.775 around a little bit. He decided to use a four byte hash. Uh, the ROR algorithm to, to find just 00:09:38.077-->00:09:43.750 the DLL name. Versus DLL and API. And so that means you, you would find, you would use that 00:09:43.750-->00:09:49.155 hash to find um anything in the loaded module that will match that and so if you're going to 00:09:49.155-->00:09:54.294 do something like Havoc where you're going to cause a collision you would need to know 00:09:54.294-->00:09:59.032 all the possible combinations of anything that might be deployed with any applications as far as 00:09:59.032-->00:10:04.037 DLLs. And so um, so yea, uh, uh, he wrote that stub and we were excited about it. So now we had 00:10:06.506-->00:10:12.812 two stubs. Okay that's cool, alright. Uh, so then we knew you could use, get, GetProcAddress 00:10:12.812-->00:10:17.984 anywhere in memory space and if you do that, you can get load library A as long as you 00:10:17.984-->00:10:21.955 enumerate the location of KERNEL32. So you use the four byte hash algorithm like I 00:10:21.955-->00:10:28.328 mentioned uh and then you would get, um this is how we would uh get uh load library A. Pretty 00:10:28.328-->00:10:32.065 simple right? And then we would push the handle into the stack and then move ES, uh, we would 00:10:32.065-->00:10:38.104 push the handle of load library A onto the stack and move ESP to EBX and then we would do an 00:10:38.104-->00:10:44.511 indirect call to EBX. So now we have four stubs that we could use. But we didn't know where we 00:10:44.511-->00:10:50.750 could use them. So what we did is I went through and enumerated system binaries across all five, 00:10:50.750-->00:10:56.856 five operating systems for load library A, get procedure address or just get procedure address in 00:10:56.856-->00:11:02.428 the import table. And this is the output of that. I saved the output in a Json format. So when 00:11:02.428-->00:11:07.066 you're, you're looking for an import to use, you would walk everything that is loaded 00:11:07.066-->00:11:12.839 recursively in a, in a dependency walker style fashion. Uh to find anything that might 00:11:12.839-->00:11:18.945 be in memory. So we had a lot of op, opportunity to use this. And um, if, if you look you see, 00:11:18.945-->00:11:25.518 they made an effort to decrease the use of load library A and get, GetProcAddress. And you see 00:11:25.518-->00:11:32.025 Windows 10 has less, right? Then XP. Obviously. But then you see there's more, GetProcAddress. So 00:11:32.025-->00:11:38.231 either way, it was, it was a pretty good find. So we're going to submit to a, to a CFP, or 00:11:38.231-->00:11:44.237 we're going to submit to a conference. Uh, this is about June and then this came out. Uh, 00:11:44.237-->00:11:48.841 a flash exploit that used GetProcAddress from user thirty-two import table to get a 00:11:48.841-->00:11:54.380 payload, was discovered by FireEye. And this was pretty depressing, cause then what we 00:11:54.380-->00:11:59.319 waid, we, we, it wasn't' good anymore. I mean, not good, but it just wasn't as exciting. So 00:11:59.319-->00:12:04.157 we wrote a blog post about it and we released the POC that would pick for you which stub 00:12:04.157-->00:12:09.696 you would use. Uh and we released a reversed CCP shell with this with no exit function 00:12:09.696-->00:12:15.134 so it would automatically crash all the time. Uh that was kind of trolling a little bit. But 00:12:15.134-->00:12:20.406 um, we want to do more stuff. So we wanted more payload, we wanted to get this into 00:12:20.406-->00:12:26.980 MetaSploit somehow. And we knew it'd be a lot of work and we had a couple ideas. So that brings 00:12:26.980-->00:12:31.818 us to part two. So two ideas. Remove Stephen Fewer's Hash API and replace it with something 00:12:31.818-->00:12:36.055 else completely. But we, or build something to rewrite payload logic for use with an 00:12:36.055-->00:12:41.561 import address table, uh parsing stub. So I decided to rewrite all the things. So, and do it 00:12:41.561-->00:12:47.000 automatically and magically. And this is how MetaSploit payloads work. You push everything on, 00:12:47.000-->00:12:53.539 well for, for x86, so you push everything onto the stack and call the hash API with a call 00:12:53.539-->00:12:58.544 EVP. Um, so I had a workflow, I used Capstone for disassembly, keystone for reassembly. The 00:13:00.847-->00:13:06.085 only thing that I had issues with was protecting the save load library A and 00:13:06.085-->00:13:11.891 GetProcAddress from being clobbered because of conditional instructions that would pick a 00:13:11.891-->00:13:18.164 path and then I'll lost context. Um, and I worked on this for five days straight for about 00:13:18.164-->00:13:23.803 twelve to fiteen hour days over Christmas. Not on Christmas but over Christmas holidays. And 00:13:23.803-->00:13:28.808 when I solved one problem, more appeared. And there was a point that I crossed it and where I 00:13:31.911-->00:13:36.482 could probably just rewritten everything or at least getting a good, or at least have a good 00:13:36.482-->00:13:42.822 POC of things uh to show for my work. But really I had nothing, so I decided to burn it down. Uh 00:13:42.822-->00:13:47.827 so the next idea was to take the hash API and the actual payload logic, remove, remove the uh old 00:13:50.296-->00:13:55.301 hash API, use my, one of my import address table stubs, then offset table. So, I had some 00:13:58.271-->00:14:03.976 requirements. I needed support, uh read/execute memory. Just incase somebody would use this 00:14:03.976-->00:14:10.249 other places that weren't read, write, execute memory. Let me keep it small, as possible. I 00:14:10.249-->00:14:15.154 want to support any Metasploit payload that uses Stephan Fewer's hash API. So at the same 00:14:15.154-->00:14:21.327 four steps I would take, I would take uh imports in, dissasemble it, capture the instructions, 00:14:21.327-->00:14:27.366 uh, or capture the blocks of instructions, capture all the API's be able to look up offset 00:14:27.366-->00:14:31.604 table and then I'd find the appropriate import address tables for the executable and 00:14:31.604-->00:14:36.442 then there will be an output table I mean an output to different types. So even if the 00:14:36.442-->00:14:41.514 user does not provide a DLL they're looking for, this would do it automatically because of 00:14:41.514-->00:14:46.519 all the Json, uh, output that I've saved. So this is what I came up with. Uh, so you would 00:14:49.222-->00:14:54.227 take the four block, four byte block hash, uh used in the API parsed export table but now it's 00:14:57.530-->00:15:02.568 going to point to the APIs and the DLLs that were going to be called and those, those are 00:15:02.568-->00:15:07.607 going to be in a string and they're going to be null terminated. So for example you, 00:15:07.607-->00:15:14.147 you have the first hash right? It's four bytes. And then, the DLL offset, if it matches, it, 00:15:14.147-->00:15:19.152 it's going to point to KERNEL32. And then the next API is gonna, the APIs gonna point to WinExec. 00:15:21.220-->00:15:26.692 So you have the next hash, points to KERNEL32 again. And then it points to the next API 00:15:26.692-->00:15:32.765 exit thread, so on, so forth. So you do, because I unique the string, you do have some overlap 00:15:32.765-->00:15:39.172 and you can save some space. So, this, this logic for the parsing, for parsing the lookup 00:15:39.172-->00:15:43.442 table. Basically I jump over the table, I move the first hash into the lookup table and I 00:15:43.442-->00:15:50.016 continue until I find a match. If found I move the DLL offset into AL. I normalize for memory 00:15:50.016-->00:15:55.021 and I use load library A to load the DLL. And then I save the DLL handle. I put the API offset in 00:15:59.091-->00:16:04.764 AL, normalize and use GetProcAddress to get the Win API handle. I prepare the call 00:16:04.764-->00:16:09.402 to the WIndows API by clearing the stack. I save EAX down the stack for recovery on pop AD. 00:16:09.402-->00:16:15.308 then I save the return address to EBP then I call the Windows API. While the API returns I fix 00:16:15.308-->00:16:19.579 the EB- EBP to point back to the beginning of the import address table stub. And then I return 00:16:19.579-->00:16:25.151 back to the payload logic. So this is how it works, I jump over uh everything, into uh the 00:16:25.151-->00:16:30.156 payload logic that comes with Metasploit. Uh and then I return, or I- I- do a call into 00:16:32.291-->00:16:37.063 the import address table stub. And then lookup table goes into a Windows API, returns back the 00:16:37.063-->00:16:41.400 lookup table and then I go back into the payload logic and I just continue until done. So the 00:16:41.400-->00:16:46.539 initial POC to write the table took about twelve hours. ANd then add in all the workflow and 00:16:46.539-->00:16:51.344 then the stubs took about another twelve hours and uh it, it took awhile to get the tool 00:16:51.344-->00:16:56.349 to where it's at, but I'm really happy about it. So now that these um, API hashes are been, 00:16:59.518-->00:17:04.290 they no longer hold reference. Um, they're now meaningless, okay? After, after it goes 00:17:04.290-->00:17:09.729 though and we figure out what they are, they're meaningless. And I found out AVs depend on 00:17:09.729-->00:17:16.736 them for signatures. So, what, what, what happens if we, um, just randomize them? It's pretty 00:17:16.736-->00:17:21.741 fun actually. So I've got to demo that, yeah. Do this properly. Everybody see that? 00:17:25.611-->00:17:30.616 Okay. Okay, so all I'm doing here is just doing a um, I'm just outputting to file a 00:17:42.428-->00:17:47.433 reverse TCP um shell, MSFvenom. And then I'm going to cat that out into uh Fid0. That's the 00:17:53.439-->00:17:59.545 name of this tool, Fid0. And I'm going to do a loadlibraryA GetProcAddress, um, we're going 00:17:59.545-->00:18:05.484 to use those out of the import table of the main module. And I'm, I'm, uh outputting that to 00:18:05.484-->00:18:10.489 file. And uh, the, the outputs uh fairly, fairly useful to tell you what's going on. Pretty 00:18:12.959-->00:18:17.964 straightforward. And now I'm going to use Backdoor Factory and effect tcpview and I'm going 00:18:20.533-->00:18:25.538 to put that on Window 10. And there's Windows Defender. Of course it was detected. I'm 00:18:35.948-->00:18:40.953 going to do the same thing but I'm going to use M for Mangle. Going to use Backdoor Factory 00:18:45.424-->00:18:50.429 again to infect tcpview. I drop that onto disk. And then I set up a netcat handler. And then no 00:19:06.545-->00:19:11.550 detection. [applause] Alright so here's an example of using FID0 as you've seen in the video. So 00:19:26.065-->00:19:31.070 I was having some issues with a couple DLLs. And when I say couple, all the system ones. Uh 00:19:33.639-->00:19:39.145 I was running into a problem where, where I had to build a blacklist to avoid using those 00:19:39.145-->00:19:45.518 as, saying they had the GetProcaddress or load library A in their import table. And I 00:19:45.518-->00:19:49.688 decided to look at this because it was going to a point where I was just blacklisting 00:19:49.688-->00:19:54.894 everything. ANd I figured out that it was just Windows 7 through 10. So I decided to 00:19:54.894-->00:20:00.933 look, look into it some more. And this is when I discovered the effect of MINWIN. Uh these, 00:20:00.933-->00:20:06.305 these, typically these are used in system DLLs. It's, it's for portability and they've been 00:20:06.305-->00:20:12.912 used in Windows 7, they've been in use since Windows 7. And if the DLL, if it is in the DLL's 00:20:12.912-->00:20:18.150 import table in your process space, you can use an exposed API, such as, GetProcAddress. 00:20:18.150-->00:20:23.155 And in, and GetProcAddress case, it's everywhere. It's in every single process. Um, because it's 00:20:28.594-->00:20:33.599 in KERNEL32. Uh, so this is the view of KERNEL32's import table. So KERNEL32's import, importing 00:20:36.469-->00:20:41.140 GetProcAddress via its import table through one of these MINWIN DLLs. And then it exports 00:20:41.140-->00:20:46.378 it back out uh so it can be used ya know through the normal API. But if you're parsing the import 00:20:46.378-->00:20:52.418 table then you can use it. So let me explain what this means. We just need GetProcAddress in 00:20:52.418-->00:20:57.423 any DLL, any import table in any DLL to access the entire Windows API. We just need it, just need 00:21:00.860-->00:21:07.266 GetProcAddress period. So uh, since Windows 7, get roc address has been in KERNEL32 import 00:21:07.266-->00:21:12.271 table. So that means, we've had a, a stable EMET EAF and Caller bypass since Windows 7. And it 00:21:14.406-->00:21:19.378 still works on Windows 10. So I'm going to demonstrate that with uh, the Tor exploit that I 00:21:19.378-->00:21:24.383 talked about earlier. Alright so what I'm showing here is I turned off the stack pivot um 00:21:36.428-->00:21:41.433 mitigation just to show that EAF will flag the, as far as the mitigation. So now I'm going to 00:21:48.574-->00:21:53.579 drop the exploit and payload into um Tor browser. You see the mitigation pops up and tells you 00:21:57.082-->00:22:02.021 what was flagged. It's very nice. So now, I'm going to uh just run FID0 with using Firefox 00:22:05.958-->00:22:11.564 as the uh target binary. And what you're seeing here uh where it says number of lookups to do, 00:22:11.564-->00:22:15.901 it tells you everything. That's recursively, it's parsing through and trying to figure out 00:22:15.901-->00:22:21.907 which, what DLLs are loaded through the system. And then it will continue through and tell 00:22:21.907-->00:22:26.912 you where you can, you can, where you can use what import table. And so um, it 00:22:29.915-->00:22:33.319 automatically used GetProcAddress you can see it at the bottom where it says GPA. 00:22:33.319-->00:22:38.324 But I'm going to use the MINWIN DLL. Cause you can see it's in KERNEL32 and then it's the API 00:22:42.895-->00:22:47.900 MS Win Core Libraryloader DLL. And what I, what I did here is I had an encoder to uh put the 00:22:50.069-->00:22:55.074 output, uh standout so I can reformat it into uh a proper Javascript format. Just showing 00:23:00.279-->00:23:05.284 that. I already have it in the uh, exploit example. I just need to uncomment it. This is a calc 00:23:14.226-->00:23:19.231 payload. Restarting the Tor browser. And there you go. [applause] Alright and um, so 00:23:46.225-->00:23:51.230 these payloads were introduced at RECON Brussels back in January 2017. For Def Con 00:23:51.230-->00:23:56.335 twenty-five I'm releasing sixty-four bit payloads and that brings us to mitigation and 00:23:56.335-->00:24:01.740 bypsses. So I opened up a, uh Github issue to incorporate these import address table 00:24:01.740-->00:24:06.512 payloads into MetaSploit, Uh part of what I was offering to do was to release these 00:24:06.512-->00:24:11.517 sixty-four bit stubs uh to whelp with that process. And, and, if, if my top would have ended here, 00:24:14.920-->00:24:19.758 right here. However, three months later, after my Github issue submission and five weeks 00:24:19.758-->00:24:24.163 before this talk the EMET protections are being added back into Windows 10. Implemented via 00:24:24.163-->00:24:29.234 the Kernel. Additionally uh, Matt Graeber, pointed out to me that there's now a import 00:24:29.234-->00:24:34.239 address table mitigation. Which is, this was my reaction. Just flipping tables for days. Uh, 00:24:38.110-->00:24:43.115 yeah. So how does, how does the import address table filter work? Well, so I, you had to 00:24:46.018-->00:24:49.054 downl- I had to download the preview edition This is coming out in the fall by the way, 00:24:49.054-->00:24:53.425 officially. But you can get it preview edition. So first off they're not enabled by default. 00:24:53.425-->00:24:57.696 You have to go through and click through and enable everything. But what it does is they take, 00:24:57.696-->00:25:03.602 there's a pointer to the import uh name and they zero that pointer. So at, at this point 00:25:03.602-->00:25:07.673 the, the thunks are there so that compile code can work. But at this point you're driving 00:25:07.673-->00:25:13.879 blind and uh, if you're driving blind you're, you're probably going to crash at some point. 00:25:13.879-->00:25:20.486 And uh, yeah it's pretty awesome. So but ya know the funny thing is I knew that 00:25:20.486-->00:25:27.092 something like this might happen so I had a, an ace in my pocket. Um so this is KERNEL32 entry for 00:25:27.092-->00:25:31.997 GetProcAddress. And on the next line is GetProcAddress for caller. Um, this was introduced 00:25:31.997-->00:25:38.470 on Windows 8 It's exported by kernel base and then imported by KERNEL32. That means it's in 00:25:38.470-->00:25:43.142 every process. It works very similar to GetProcAddress. It's not filtered by the import 00:25:43.142-->00:25:48.147 address table filter yet. And this is how it works. You just add a zero on the end and that's 00:25:52.584-->00:25:57.589 [laughter] technically, yeah way to go guys. Uh so yea, so it, [inaudible noise] so I've added, 00:26:00.192-->00:26:05.197 I've added this into uh FID0 and you use it basically um, you use it through ExternGPAFC so I've 00:26:08.333-->00:26:13.338 got a demo for that real quick. Um, sorry. Alright so, what I, what I did. Let me just, I don't 00:26:26.485-->00:26:31.490 remember. Alright so what we're doing here is, so I'm just taking a sixty-four bit uh, 00:26:39.465-->00:26:44.703 reverse shell from MetaSploit and I'm just using GetProcAddress and then I'm 00:26:44.703-->00:26:49.308 passing it to Backdoor Factory patching who is sixty-four and then I'm going to throw that 00:26:49.308-->00:26:55.080 onto the operating system. Now I do not have the protection enabled yet, just to show you 00:26:55.080-->00:27:00.018 that the protection does work. There you go. Uh, now I'm going to enable the protection. And 00:27:30.482-->00:27:35.487 then uh, it's going to take a second to crash but it will crash. There you go. And then 00:27:42.494-->00:27:47.499 I'll run it again and it should be faster the next time. Alright, now I'm going to use 00:27:57.109-->00:28:02.047 uh, GetProcAddress for caller. Put that on disk. And there you go. [applause] So I did let 00:28:27.573-->00:28:32.945 Microsoft know about this. So they're gonna, they're gonna have a patch for it whenever it 00:28:32.945-->00:28:38.417 comes out officially. Because since they were making an effort to make it an honest try to fix 00:28:38.417-->00:28:43.922 it then I decided to let the know. So now what? Now we can't parse the export table or the 00:28:43.922-->00:28:49.494 import table. Uh is is possible that you could find more APIs that are not filtered and that 00:28:49.494-->00:28:55.200 can give you use- useful information to get to GetProcAddress? Yeah, probably. 00:28:55.200-->00:29:01.873 Or, what if we didn't use import table or the export table? So let's think about this real 00:29:01.873-->00:29:08.246 quick. Um, in modern users space Windows exploitation you have to bypass ASLR dep and other 00:29:08.246-->00:29:12.451 protections. And on top of that your exploitation is most likely to be tailored to a specific 00:29:12.451-->00:29:18.056 version or versions of software and operating systems. So why shouldn't your payload be 00:29:18.056-->00:29:23.929 targeted also? Why does the payload have to work on every operating system from XP to uh 00:29:23.929-->00:29:28.934 Windows 10? Right? Why not make it targeted to that specific um version of application. So the 00:29:32.237-->00:29:37.743 way that you would do that is you would go to GetProcAddress directly. And the way it would 00:29:37.743-->00:29:42.748 work is you would take PEB imagebase and that's easy enough to find and then GetProc, the 00:29:42.748-->00:29:47.753 offset for GetProcAddress and that's going to be version dependent. And the offset can be 00:29:50.055-->00:29:55.060 found during exploit or during exploit or payload development. And um, this is going to be in 00:29:57.629-->00:30:02.634 the main module of the main program. Or it can be any, in any application uh specific DLL. 00:30:04.836-->00:30:10.776 So I would not target system DLLs because those change very often. So if, so if there's a 00:30:10.776-->00:30:16.515 DLL that has the same offset for a number of versions, for lets say, they depend on openSSL for 00:30:16.515-->00:30:21.987 something and they just, they just uh, hope they don't update the openSSL binary, binary even 00:30:21.987-->00:30:28.593 though you're not exploiting the openSSL, you can use the uh GetProcAddress um, offset in 00:30:28.593-->00:30:33.598 that DLL across multiple versions. So and, and it does say codes. So this is, this is 00:30:35.667-->00:30:41.873 the import uh parse table code to find and GetProcAddress. Just to GetProcAddress. It's a fair 00:30:41.873-->00:30:46.845 bit of code, um but if you know what, if you know what GetProcAddress offset is going 00:30:46.845-->00:30:53.351 in, that's how much code it takes, obviously, right? So uh, and, and so what if, what if you 00:30:53.351-->00:30:58.356 had um more, what if you had, you couldn't find a single GetProcAddress in one DLL Well 00:31:01.093-->00:31:06.098 what you would do is you would find a uh, DLL that was consistent acr- across all 00:31:08.734-->00:31:14.973 versions that had GetProcAddress and then you would engineer, you would diff the um binaries 00:31:14.973-->00:31:19.644 across different versions, diff the DLL's across different versions and then you would make 00:31:19.644-->00:31:25.217 a similar lookup table, uh so that you could use the diff sections to figure out what 00:31:25.217-->00:31:30.255 version you're in and that would be associated with the appropriate offset table. So I 00:31:30.255-->00:31:35.260 have an example of not of the actual diffing process but I have the example of using an 00:31:37.262-->00:31:43.335 offset for GetProcAddress. Either within the uh main module program or the external offset, 00:31:43.335-->00:31:50.275 uh DLL, right. So um, if anyone wants to help me develop that or engineer that system, please 00:31:50.275-->00:31:56.248 find me. I'm easy to contact. I'm on Twitter and I have an email address. Um, that sums up 00:31:56.248-->00:32:01.186 my talk. Any questions? [applause]