Teaching Old Shellcode New Tricks
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Teil | 6 | |
| Anzahl der Teile | 20 | |
| Autor | ||
| Lizenz | CC-Namensnennung 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/32393 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache | ||
| Produktionsort | Brüssel |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
3
4
7
8
17
18
00:00
HalbleiterspeicherMetropolitan area networkSchlussregelPhysikalische TheorieKernel <Informatik>Wurm <Informatik>Physikalisches SystemTabelleSchreib-Lese-KopfKontrollstrukturFilter <Stochastik>AdressraumHash-AlgorithmusLastHardwareStochastische AbhängigkeitVerschlingungRechenschieberAnalytische FortsetzungSeitentabelleProzess <Informatik>SummengleichungWeb logProxy ServerThreadProgrammbibliothekZeichenketteKontextbezogenes SystemSystemaufrufFunktionalSchnittmengeComputersicherheitEndliche ModelltheorieComputerspielPivot-OperationBrowserWechselsprungBildschirmfensterSoftwareentwicklerGrenzschichtablösungCASE <Informatik>Lesen <Datenverarbeitung>TLSDatenflussNichtlinearer OperatorExploitBimodulNabel <Mathematik>Wurzel <Mathematik>MereologieBitReverse EngineeringSpeicheradresseMultiplikationsoperatorZahlenbereichService PackInelastischer StoßKonfigurationsraumMathematische LogikPatch <Software>E-MailOrtsoperatorRichtungGraphfärbungDichte <Stochastik>Faktor <Algebra>FontRechter WinkelCodeGrundsätze ordnungsmäßiger DatenverarbeitungEin-AusgabeLoopLeistung <Physik>Weg <Topologie>DifferenteOffice-PaketMobiles EndgerätLipschitz-StetigkeitPackprogrammMinimumDesign by ContractInzidenzalgebraWeb SiteRechenwerkStabilitätstheorie <Logik>ErwartungswertInformation RetrievalMaskierung <Informatik>OvalDatenstrukturComputeranimation
09:20
BildschirmfensterAdressraumPhysikalisches SystemProgrammbibliothekBimodulp-BlockProzess <Informatik>IdentifizierbarkeitTabelleSkriptspracheKeller <Informatik>AdditionElektronische PublikationSystemzusammenbruchHalbleiterspeicherEin-AusgabeMusterspracheMereologieSoftware Development KitFigurierte ZahlTwitter <Softwareplattform>EmulatorURLLastInelastischer StoßCodeWeb logBinärcodeVerschlingungZeichenketteNetzbetriebssystemDateiverwaltungHash-AlgorithmusRechenschieberWurm <Informatik>Zeiger <Informatik>KontrollstrukturFunktionalSystem FSyntaktische AnalyseSystemaufrufNebenbedingungPortscannerKonfiguration <Informatik>Funktion <Mathematik>Dichte <Physik>Proxy ServerFahne <Mathematik>CASE <Informatik>Vorzeichen <Mathematik>Reelle ZahlComputerspielInformationEndliche ModelltheorieNabel <Mathematik>Motion CapturingMinkowski-MetrikKernel <Informatik>ARM <Computerarchitektur>DisassemblerBefehl <Informatik>Peer-to-Peer-NetzServerExogene VariableRechter WinkelÜbersetzungsspeicher
15:55
Wurm <Informatik>Hash-AlgorithmusAdressraumProzess <Informatik>BildschirmfensterTabelleLastLesen <Datenverarbeitung>HalbleiterspeicherProgrammbibliothekMatchingSyntaktische AnalyseMultiplikationsoperatorURLMathematische LogikCASE <Informatik>CodeSystemaufrufGarbentheoriePunktp-BlockWechselsprungMotion CapturingFunktion <Mathematik>Radikal <Mathematik>System FDemo <Programm>ViewerSelbstrepräsentationElektronische UnterschriftVirenscannerProgrammschleifeSchwellwertverfahrenProgrammierungSymboltabelleDifferenteEnergiedichteEin-AusgabePunktgitterRechter WinkelZeichenketteHydrostatikBefehl <Informatik>Figurierte ZahlGanze FunktionMereologieComputervirusKernel <Informatik>Stabilitätstheorie <Logik>Elektronischer ProgrammführerTermBildgebendes VerfahrenComputeranimation
22:31
ProgrammbibliothekLastBinärdatenComputerunterstützte ÜbersetzungMicrosoft dot netBimodulProzess <Informatik>BildschirmfensterSystemaufrufHash-AlgorithmusMathematische LogikFahne <Mathematik>Funktion <Mathematik>Faktor <Algebra>TabelleReverse EngineeringZeichenketteWurm <Informatik>AdressraumPhysikalisches SystemWinkelElektronische UnterschriftGraphfärbungKugelkappeComputeranimationVorlesung/Konferenz
25:06
SichtenkonzeptKernel <Informatik>BildschirmfensterProzess <Informatik>BootenSpeicherabzugProgrammbibliothekTabelleHalbleiterspeicherMereologieFunktion <Mathematik>RohdatenProxy ServerDisjunktion <Logik>AdressraumGanze FunktionWurm <Informatik>BinärcodeBinärdatenFahne <Mathematik>MaßerweiterungSyntaktische AnalysePhysikalischer EffektLastZweiDemo <Programm>SoftwaretestImplementierungCodeStabilitätstheorie <Logik>sinc-FunktionRekursive FunktionZahlenbereichMobiles EndgerätPhysikalisches SystemNotepad-ComputerProgrammierungIdeal <Mathematik>BrowserMAPArithmetisches MittelGraphfärbungDifferenteFlussdiagramm
29:57
Rechter WinkelProxy ServerZeiger <Informatik>BinärcodeMathematikProzess <Informatik>Funktion <Mathematik>FlächeninhaltPhysikalisches SystemProgrammbibliothekMinimumBrowserIdeal <Mathematik>SpeicherabzugHalbleiterspeicherARM <Computerarchitektur>Kernel <Informatik>BildschirmfensterKeller <Informatik>SkriptsprachePivot-OperationVideokonferenzSyntaktische AnalysePunktTabelleComputeranimationProgramm/Quellcode
32:00
Wurm <Informatik>BootenProzess <Informatik>Rechter WinkelTermSystemaufrufKernel <Informatik>BrowserMailing-ListeSkriptspracheIdeal <Mathematik>CodeObjekt <Kategorie>TabelleAdressraumGraphfärbungComputeranimation
33:18
Wurm <Informatik>CodeHash-Algorithmust-TestGüte der AnpassungSkriptspracheVersionsverwaltungMAPRechter WinkelPunktGrundsätze ordnungsmäßiger DatenverarbeitungInterpretiererDatenflussBildschirmfensterKontrollstrukturSystemaufrufComputeranimation
34:49
Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:10
Brussels 2017.
00:21
So why this talk? I think writing shellcode is fun. I've been doing it for a number of years now. And I think it's time to update some of the publicly available shellcode ideas that we have out there. And so there's basically two parts to this talk. There's a background, and then we're going to go into some of the actual more fun topics. So today I'm going to be targeting Stephen Feuer's Hash
00:43
API. It's either called the Hash API, Metasploit Payload Hash. Does anybody, who knows what that is out there? Anybody? Hands, a couple hands. Okay, so it uses a four byte hash, basically a 13 bit roar instruction or simply rotate.
01:02
And it has roots that go back to 2003 from Scapes understanding Windows shellcode paper. And it's really compact, really efficient. It's actually really awesome because it parses the export table, and it works like this. Let me just go ahead and explain it to you. So what it does is it does a call over the actual hash API.
01:22
It goes into the actual payload logic. And then there's a very strict API how this works. It will pop the return address into EBP. And so it'll push everything, for x86, it'll push everything onto the stack. And then it will make a call to EBP.
01:40
So it goes into the hash API itself. Then it's going to parse the export address table and jump into the Windows API. And then it'll return back to the payload logic and it will continue until there's no more payload logic. And you have done whatever you wanted to do.
02:00
So how do you, there have been some defeats. Now remember, I don't know if I mentioned it, but the hash API came out in August 2009, okay? So just keep that in mind. You can defeat the hash API with Emmet. I mean, there's many, many mitigations in Emmet, right? And if you can get to the payload,
02:22
you have to bypass a number of things. There's going to be a couple of things to stop you, and we're going to go into that. There's also Pyotr Banani. I butcher names, that's my job. But this frack article is great because it talks about hash collisions. And there was actually a tool that came out
02:42
called halting attacks via obstructing configurations. And it was a DARPA fast track tool that was made by digital operatives. And what it does, it will inject a DLL in the first loaded modules list, and it will contain all pre-computed collisions so that once you started walking the export table,
03:01
you would crash instead of getting successful exploitation. And then there's control flow guard, return flow guard, and we're not really going to talk about that in this talk because it's a different beast. So, specifically, I think AF more than caller were introduced to stop the hash API call.
03:20
If you see here, it was introduced in 2010, you know, like very quickly after. And it basically stops the reading of the export table via hardware breakpoints. And it's pretty cool, it worked pretty well for a couple years. But, and then they added in 2014 the plus,
03:43
and that includes kernel base. So, the caller. That was introduced in 2013, and what that does, it blocks any returns or jumps directly into a Windows API, so it's more of an anti-ROP. But if you remember when I quickly explained how the hash API works,
04:01
it does a jump from the hash API into the payload. So, these two protections actually mitigate against the hash API itself because it does a jump into the Windows API. So, technically, EMET, I pronounce it two different ways,
04:21
however I'm feeling, it is considered end of life. It is going to end July 31st, 2018, but it still works. And you can see, I say, it depends on your threat model because this is the recent Tor browser exploit versus EMET. So, if some of these people that were doing the things
04:41
that they shouldn't have been doing had EMET, they wouldn't even have gotten to the payload because this is a stack pivot mitigation, right? So, they were using stack pivot to get to the payload. And so, if they had a better payload or paid more for the payload, they wouldn't have this issue, right?
05:01
So, EMET does still work. And it's kind of the case where it's like the iPhone in your pocket because it's easy to implement versus control flow guard where developers have to compile it in. I think Edge is the only browser that has it right now. So, how do you, there's been several bypasses
05:21
for EMET EAF Plus. Skyline, on his Skyford blog, I had to actually go to archive.org because the blog's no longer up and I'm sad. It's a great, it was a great blog. And he described a retulibc style bypass using NTDLL
05:41
and I believe it was hard coded addresses. And my slides are gonna be available and the links are in there if you wanna check it out. And then there's Peter, he also had a blog post on erasing the hardware breakpoints and using NC continue. And it would, you know, no more hardware breakpoints,
06:01
no more export address filtering. And then offensive security had a very similar bypass and they would, there was an EMET function that would call ZDU set context thread which would also zero the hardware breakpoints. So, and the caller check is much easier.
06:22
Jared DeMott in 2014, he just, all he had to do, if you get the address to load library A, you just move it into a register and then dereference it back into the register and you can call it directly. So pretty easy. Now, after reading Jared's paper, I decided to put this into BDF itself
06:41
and back to our factory. And so I made some import address table payloads that would use the actual thunks that were in the import table directly. And this bypassed EMET and the EAF and caller checks. And later on, I actually added a patching of the import address table so that I could add whatever APIs I wanted at any time.
07:03
But, you know, this wasn't everything I wanted to do because I wanted to actually do some position independent import address table payloads to see what would happen. So this was, you know, fast forward December, 2014. So I do some research, I'm looking around, you know,
07:21
what's been done prior work. And so Scape, Matt Miller, I think he might be on the EMET team, I'm not sure. I know he works at Microsoft on the mitigation work, but he had in his paper, he talked about parsing the import address table, not import address table, export address table, and loading a DLL, getting load library,
07:42
loading a DLL so that you had everything you needed in that one DLL, like WS-232. And you could just call the APIs directly in that DLL. There were a couple of issues with it if you look at it from an EMET perspective, because you have to parse the export address table. So that was kind of a non-starter.
08:03
And then there was a PTR, I mean, this guy has done a lot of work, it's pretty amazing, same FRAC article. He talks about import address table parser, and that was enough to get me started. And here's the actual code, and I don't know what operating system it was for, I think it might have been XP service pack one or two,
08:24
but it got my head going where I could understand what I wanted to do. So I wrote my own stub, and basically what it does, it finds PB, P header, import table RVA, and then loops through and finds kernel 32, but it used ANSI string matching, right?
08:44
And then you go on to the next slide. Next I'll go through and find load library and get process address. But what I added at the top is a set balance check, because if you're looping through the import table, sometimes the memory address where you're going to read is out of balance.
09:00
And so I added a FF0000 check to make sure that I did not go out of balance. So this actually worked pretty good. It was very stable. And so I bolted on a reverse TCP shell and I bypassed caller EAF checks and the POCs that I was running. And so then I was like, oh, this is cool. I'll email the EMET team.
09:21
And this was their response, pretty much. So apparently they knew about import table parsers. I mean, they get millions of crash dumps a month, I'm sure, so they had to know, right? And so my POC was limited just to load library A and get process address in the import table of the main module.
09:41
So it didn't do anything really exciting. So this was December, 2014, and I just put it like on a file system and just let it sit there. Just kind of went back to real life and work. And I'll just look at a Twitter. And Casey Smith, Casey Smith does a lot of,
10:01
he executes code in places that you're not expecting it. And they're like signed binaries, like MSBuild and stuff like that. So he bypasses white listing solutions. I see him talking about EAF mitigations getting flagged in Excel, and I knew exactly what his problem was. So I send him my import address table stub, and we started to collaborate.
10:22
And the slides are gonna be out today, and there's a link there. You can go see when I release the code to him. And so he went crazy with this. He was using it everywhere, like everywhere. However, we tried using PowerShell, which I thought personally was strange because if you're running PowerShell, you have full access to the Windows API anyway.
10:42
But sometimes his POCs have small constraints. So it didn't have load library A in the import table. So we started talking about it, and we were gonna use a loaded module, another DLL in memory. And so he wrote an addition that used the same four byte hash to find DLL
11:02
in the loaded modules. So you would need to know your target. He borrowed code from the Stephen Fuhrer hash API stub. And so the havoc protection, to defeat this, because we did dll.name, that's what we were using, not just the short name, because that wouldn't work.
11:21
You would actually have to throw up, or not throw up, but insert many, many DLLs to cause a collision. And what you're gonna see is there are many DLLs at work. So we were both happy with this. So we had two stubs. And we started talking about it. We're like, we knew by this point
11:41
that if you had get process address anywhere in your module space, any DLL, you could get load library A by getting the kernel32 handle, and then calling get process address with a string load library A, and then you have full access to the Windows API. So then, to bypass caller,
12:01
what we did is we, you know, load library A is in the EAX, then we would move it, we'd push it on the stack, and then move the pointer TVX, and then we'd call it through an indirect pointer. So now we had four stubs that we could use. So that was pretty good. We were excited about that. But I wanted to know where I could use them.
12:23
So I wrote some scripts that would go through and find anywhere load library A and get process address was on a Windows system. And these were clean systems, nothing really installed. There is gonna be some overlap because you have SysWOW, you know, system 32. But this is a lot.
12:41
And you can see that Microsoft has made a concern, or somewhat of an effort, to decrease load library A and get process address in the import table. Which is, you know, pretty cool. And so we had a lot of information, we thought this was cool, so we're going to submit to a conference. And this was about May.
13:01
We were like, all right, I think we're ready to submit. And then in June, my world fell apart. There was the Angular exploit kit that used get process address from the user 32 import address table, and FireEye published it, and I almost retired. I was pretty depressed. But we decided to go ahead with a blog post
13:23
because we wanted to release the POC, and one of the things that we had in the POC is we had a dependency walker style. What we would do as part of the script, you give it a binary that your target is, and it would use the output from my scans of load library across all these systems,
13:42
and you give it an operating system. And it would go through and recursively look at what is loaded in every DLL. And it would give you an option of what, or not an option, but it would tell you what DLLs to use. And so it ended aesthetically, right? So that was actually kind of cool. But when we released it, we left kind of a bug.
14:02
We didn't put an exit function. So it was a reverse TCP shell, no exit function, so it crashed right away. And that was definitely by design. And so we talked about it. We're like, we want more payloads. We want to be able to basically reuse what Metasploit has,
14:21
but it's gonna take a lot of work. And I said, you know what? I'm gonna do this. I got some ideas. And that brings us to the fun part. I had two ideas. First, I was gonna remove the steamfury hash API stub, replace it with something that I didn't know what, okay? Or I could build something
14:41
that would rewrite all the payloads for me. And unfortunately or unfortunately, I decided to rewrite all the things with automation. And so Metasploit payloads follow a specific pattern. It basically works
15:00
where you push everything onto the stack. This is for the x86 side. The x64 side is very similar, but just different calling, right? So the last thing you push is the actual hash. And then you can call EBP, pretty straight forward. And so I devised this workflow. My script would take input either via stand-in or from file.
15:22
I would disassemble and I use Capstone because I use Capstone to BDF and it's really easy to use, right? And then I would capture the blocks of instructions. And so every instruction I would tag with a unique identifier saying, all right, so this is part of this block. So I had everything. I would capture the APIs.
15:41
I would capture control flow. I would actually go through and when I see a control flow statement, I'll give it a unique identifier. And then I would go back through and find the location where that was and I'd slap a unique identifier on there so I could kind of figure out what was going on without having to do emulation. And I had to protect load library A and get process address from being clobbered
16:01
throughout the entire payload. And I had to figure out how to do that with automation. And I went at it for five days straight, 12 to 15 hour days. And when I solved the problem, more popped up because there were some payloads that had, they weren't very straightforward. They had conditional statements. They would have conditional loops.
16:21
And I was crossing the threshold where if I would have just sat down and wrote these payloads out, I probably, in that amount of time, I probably could have knocked out 15 to 20 at least because I could have some efficiencies, gain understanding, repeat processes. So I decided just to burn it down. I'm like, I'm done.
16:40
I'm gonna go to the original idea that I had, the first idea. And that was to replace Steam Viewer's hash API with something else. So what I came up with was this is the original, right? We have the hash API plus actual payload logic.
17:00
And I decided to use the import address table stub and then an offset table. And because you have to translate the four byte hash to something, if you're not using the export table, you have to figure out what it is. So what I did is I took all the APIs and then I unique them, put them in a string.
17:20
So, but I had some requirements. I had to keep it, it had to be useful in read execute memory, not just read write execute in case I put it into an executable where the section was only read execute, right? So no encoding within the payload itself
17:42
without moving it to stack or some other location. I tried to keep it as small as possible. Now import table parsing is much more expensive than export table parsing. And I had to support any Metasploit shellcode that used the former hash API.
18:01
So the first four steps are the same, right? Take input, disassemble, capture blocks, capture APIs. So I reused some code, so that was good. But then I had to build a lookup table and then I had to find the appropriate import address table for the executable. And then I have to have appropriate output
18:21
for whatever you need it for. So the offset table approach works as follows. You can see here, you have four byte sections followed by two byte, one byte, two blocks. And the first bytes is the DLL, that's the location from that point
18:41
to the ASCII or the ANSI representation of what should be called. And the API, same thing. So this is an example of a string. And so all these are null terminated. It makes it very easy once you push it onto the stack. And you can see, you get some code reuse out of this
19:01
because I unique the string, so there's no repeats, right? So you see here, this is calling kernel32, then the next API is when exec. Then I'm calling kernel32 again. And the next API is exit thread, so on, so forth. So there is some reuse
19:20
and I thought that was going pretty well. So this is the code, pretty straightforward. I think everybody understands it by now. But how it worked was you jump over the lookup table, I checked the first hash in the lookup table and then I continue until there's a match. And it found, I move the DLL offset to AL,
19:43
I normalize and use load library A to get the actual, to load the DLL memory. And then I will save the DLL handle, I'll put the API offset in AL, I'll normalize, then use get process address to get the Windows API handle and then I have to repair to call the Windows API.
20:01
So I cleared the stack, I save EAX down the stack, so then when I do a pop ID, it ends up back in EAX. I save the return address to EBP, because it's not covered. And then I call the Windows API by calling EAX. On the return, when I come back, I fix up the EBP to point back to the beginning of the import table stub
20:21
and then I return back to the payload logic. So if you're gonna look at it from like a, just an image, you can see here, I'm gonna do a call over, just like Steven Feuer's hash API or the Metasploit payloads. I do a call over and then I pop EBP. Well, at this point, it is the Metasploit actual logic
20:42
running the show. So then I return back into the import address table stub and I tried to not go back to the beginning of the stub every time. I tried to stay within, just go to the lookup table and with all the different payloads, even I got it down to one register
21:01
where I could push the two values, the library and the process address onto the stack and call from one value, just do an offset plus one or a plus four. But the problem was is that it would just get clobbered when I went to a more complicated payload. So I have to go back to the beginning
21:21
of the import address table finding stub. So then you will call, I would actually do a call instead of a jump to the Windows API, return back into the lookup table and then do a return to the payload logic and then continue until there's no more payload logic. Right, so the initial POC only took 12 hours.
21:43
To make the offset table, to design it, everything, took about 12 hours. Adding the workflow, yeah, it took about another 12. Finalizing the tool, don't even talk to me about it. It took a lot of time. But I'm happy where it's going. And what's really fun about this is
22:03
now the API hashes are, besides getting them the first time, now the API hashes are completely meaningless. After I figure out what APIs there are, I can do whatever I want with them. And come to find out that antiviruses depend on them for signatures.
22:21
Yeah. And you know, think about what happens if we mangle them. So I added the ability to mangle the hashes. So let me show a demo of that.
22:58
So the first thing I'm going to do is just run MSFvenom,
23:02
do a reverse TCP shell, and I'm gonna put it into a straight binary file. Just normal binary output. Right, now I'm going to use Fido, I call the tool Fido. I'm gonna cat the, I'll put the binary format
23:25
into Fido. And I'm going to call load library A, get process address, and that's for the main module. And because I'm targeting a certain binary, I know that load library A, get process address is in the import table of the executable
23:40
that I'm targeting. So you can see here that I stripped off Stephen Feuer's hash API call, I disassembled the payload, and I print out what APIs are being used. And then I show the string table, just kind of a check. And then I go through and do all the rest. Now I'm going to use backdoor factory to append a section and throw it on the VM.
24:10
And of course, AV flags it right away. This is Windows Defender. I'm going to do the same thing, except I'm going to use dash M for mangle.
24:27
You can see I go through and show that I'm mangling each hash. And then what I do is I go into the actual payload logic and I update the hashes to match.
24:47
It did not catch it right away. So I set up a net cat listener and there you have it.
25:21
All right, so as you already know, this is called Fido, just cause I couldn't think of anything creative. So it accepts stand in and it will process the payload based on target executable. And that'll be in the next demo. Or you can provide, if you know about the target executable,
25:41
you can provide what you want to use. So if you want to, you know, it has a get process address. You just say GPA. And then you can actually, with slash B, you can provide the target binary. It'll go through and do a dependency walker style recursive look at all the DLLs. You can give it a target OS because it does matter.
26:00
And I have XP, Vista, seven, eight, and 10 with all those depend, like with all the low library stuff. I do need to update it based on stuff I found within the last couple of days, which is pretty exciting. And then you can either take stand in or you can give it a code. And I'll show you what D and L stand for in a second.
26:21
But yeah, we'll go over that. And then you have different, you can, you can mangle, like I just showed, you can have different outputs such as C Python and C sharp output. And the normal output is standout binary format, raw binary format. And you can pick your partial stubs. And so you have GPA, LL, GPA, low library,
26:42
get process address, and you have extern. So if you're gonna use an extern, you need to know what DLL you're targeting that's in memory and what import table or what part of the import table. And there's only two options. And so with testing, I had a lot of issues with some core DLLs, like on Windows seven.
27:03
And I was building a blacklist just to avoid them. And it kept growing. And I was starting to worry what was going on. And it was only, like I said, Windows seven through 10. And if you look, you see kernel 32 there. And I thought it was weird that kernel 32
27:20
had get process address in its import table. So I just ignored it. I thought it was just a bug. Come to find out, it was the API MS win core DLLs. And these are the exposed implementation of the Windows API. And they've existed since Windows seven.
27:41
And get process address is implemented as well as load library. And I'll go into that in a second. But get process address is implemented in the library loader. There's like some letters and some numbers behind a DLL. And they're normally used in system DLLs because it's for portability reasons.
28:01
And it's in every process. Like these are in every process and it's predictable. They are, and you can use them if they're in the import table of a DLL. Yeah, I tested that and it's actually pretty cool. And it's everywhere. I don't know if I can state this enough. It's in every process because it's in kernel 32.
28:23
So there's a view of kernel 32. You can see the API MS win loader or win core library loader DLL. And you see get process and it's in the import table. So let me just explain kind of what we're talking about here. All we need is get process address in any DLL import
28:42
table to access the entire Windows API through import table parsing. Since Windows 7, there's been get process address in kernel 32 import table. So we've had a very stable EMET, EAF, and caller bypass opportunity since Windows 7. I haven't heard anyone using this.
29:03
So I think this is pretty cool. And by the way, get process address is not the only one because within the library loader DLL, there's also load library EX or extended. I think that means extended EXA.
29:22
And the difference, they're basically the same. Low library A is low library EXA with a 0 as a third flag. So when you call low library A, that's what's being handled. And this is completely reliable on Windows 7. I found I don't have a Windows 8 VM on me right now.
29:43
I can't test it. But it's not reliable on Windows 10, not yet. And yeah, but you can actually use this. It's pretty great. So I have a demo with the Tor browser, the recent one.
30:01
All right, so what I'm going to show you here is I went ahead and disabled the stack pivot check.
30:20
I'm going to run the original exploit, show you that EAF gets flagged. OK, you can see at the bottom there. Now, if you were to bypass EAF, the caller would get flagged, unless you were to completely
30:42
bypass or change it. So let me just point this out real quick. So what I did is I took the Firefox executable. That's what Tor browser is using. I did a slash B. And what it did, what my script is doing right now is checking for Windows 7 compatibility.
31:00
And I'm going through and actually doing the recursive parsing to figure out what would be loaded in memory. Now, it's not going to look at the custom DLLs that come with Firefox. It's just looking at what is in the system.
31:22
So the output, as you can see, it'll show what low library and get process binaries are available. So these DLLs have these two APIs in their import table. And then you'll see GPA binaries available. And you can see that I've outlined the API MSWin core
31:45
DLLs. And so you can use these. And I think that's what I'm going to do next in the video. So I'm going to use kernel 32. And I am using kernel 32.
32:05
And it's using extern GPA. So I'm using the get process address in kernel 32 in the API MSWin loader DLL that's in the import table. And what I'm pushing that through, I call it the Tor browser encoder. It's because it needs to be a JavaScript object.
32:23
And so it happens to be a Python list. And so I just print the Python list. And what I did here next is I just put the list there in a JavaScript script.
32:41
And then I've already copied it over. So I'm going to uncomment it and then execute the payload to demonstrate that EAF was bypassed. EAF and color.
33:06
There you go.
33:23
All right, so there are some issues, not necessarily with my script. So if you're using Metasploit and you have Emmet, right? So my API is compatible with Meturpreter, with the staged payloads that have the hash API call.
33:45
The problem is Emmet, right? So whenever you get a staged payload coming back over the second stage, if you do a multistage, it's going to have Stephen Feuer's hash API call. So it will fail. So Metasploit needs to make this fully compatible.
34:02
You need to run your own version of Metasploit or we update Metasploit. And it will take a lot of work. I also have to do, for parity, I have to do Windows x64 side of the house. So yeah, that's pretty much all I have. As far as control flow guard, return flow guard,
34:22
implications, I cannot make an intelligent assessment on that at this point. I don't know enough what the impact could be. So the code is going to be there. I'm going to really sit here in the next couple of minutes. Any questions?
34:46
Well, thanks.