start	end	text
15040	21360	Hello, everyone. Welcome back to DEF CON 28 Safe Mode, Blue Team Village live stream.
21360	25240	Today, we're going to be talking with, I'm not talking, but he'll be talking,
25240	31960	Connor Morley, discussing Outer Haven, the UEFI memory space decision to be misused.
32200	36720	Reminder, if you have any questions for the speaker, you can obviously reach them at their
36720	41840	Twitter handle, DM them within the Discord channel, or reach them on the Flamingo Hotel
42400	49300	Text Talks Track 1. We'll be watching for questions there. And over to you, Connor.
49620	54220	Thank you very much. So, hi, everyone. My name is Connor Morley. I'm a threat hunter with
54220	60940	F-Secure Countercept, which is an MDR DRT service. Today, I'll be talking about the UEFI memory space,
60940	65900	how it can be exploited by a range of attackers, and how it can defend against it.
65900	71800	And I give it the app name of Outer Haven. So, proper agenda. What we're going to run through,
71800	77940	I'm going to do a quick crash course on what exactly UEFI is, why this is of interest to
77940	86100	attackers and defenders, how to exploit the UEFI memory space, regardless of your technical
86100	92320	expertise. So, all the way from APT actors, all the way down to script gettys. You better go over
92320	97720	some of the issues with defending against exploitation of this memory sector, how we
97720	103860	can overcome those difficulties and monitor this memory area, and what this means for us as an
103860	111040	industry. So, let's dive straight in. The crash course of what exactly is UEFI. So, a lot of people
111040	117240	may have heard the term UEFI, but may not know exactly what it is. So, UEFI stands for the
117240	123080	Unified Extensible Firmware Interface. It's the successor to BIOS. Most people will be familiar
123080	129420	with BIOS, the basic input-output system. It interfaces between the mechanical elements of a
129420	135880	system and its operating system. So, effectively, it works as a translation layer between the
135880	142520	operating system and the firmware for the hardware of your device, hence a firmware interface. So,
142520	149600	for example, if the operating system requests a file to be opened, the file command gets run
149600	156520	from the OS through the UEFI to the firmware of your storage device. It then allocates that
156520	162080	memory sector and returns it, and then that's how it's read, as a very, very general basic overview.
162320	168320	It's key for all system functionality. It conducts all boot operations. It can, as I said,
168320	178000	conducts all interfaces between the software and the hardware, and it is essential in all
178000	182220	modern computers. So, it is found everywhere, regardless of the operating system that you're
182220	189660	using. It's also widely considered far more secure than BIOS. So, we introduced the concept
189660	195240	of something called Secure Boot. So, Secure Boot is the idea that when drivers are loaded at boot
195240	202100	time, their OEM signature is checked in order to guarantee and verify that they're the correct
202100	211960	and authorized driver. This idea of Secure Boot actually eliminated a really easy physical access
211960	217340	bypass to older machines, which basically means as soon as you had physical access to a machine,
217340	224020	you could easily bypass any security. One of the key things to mention about UEFI is that it is
224020	230360	stored on an independent chip on your motherboard, an NVRAM chip, which is totally isolated. It's
230360	236480	its own independent component of the machine, and it is attached to the motherboard. So, it's
236480	243480	completely isolated from everything else. It is its own piece of kit. So, just to really
244580	251420	intensify and solidify where this sits in your computer. So, the UEFI, as I said, sits between
251420	258880	the operating system and firmware, and the firmware that talks to the hardware. So, the operating system, if it wants to talk to your hardware, has to go through the UEFI.
260620	265780	It is essentially just a translation layer of operating system commands
265780	271880	down to firmware layer commands to receive whatever the operating system needs the host to do.
273100	278420	So, most people, when you're talking about UEFI and BIOS, they'll think of this sort of screen.
278420	284760	Your boot screen, sometimes with the boot menu or BIOS settings as one of those options at the bottom.
284760	288800	But the majority of the users will see this sort of screen and just, you know,
288800	295960	as it boots up your computer and not the device. Some people will obviously go into those settings,
295960	302520	which looks something like this. So, on the left, you have the older BIOS settings configuration menu,
302520	309820	and on the right, you have the newer UEFI interactive GUI. So, one of the things that
309820	315580	UEFI actually allows to do is the use of graphical user interfaces, which is not available in BIOS.
315580	321260	This allows for, as you can see, this is there. It allows for branding, it allows for, you know, CPU
321260	327960	temperatures and all this sort of stuff. It also allows for point and click, so the use of a mouse, whereas BIOS doesn't.
327960	334900	This is to do primarily with how EFI operates using EFI binary files, which allows for these
334900	341800	layers to be put on top of it. Again, this allows for security settings, it allows for the boot
341800	347960	order to be configured, and such things like that. So, most people will think this is sort of the limit
347960	352920	of what you can, or this will be like the limit of what most people have dealt with, but the UEFI
352920	360600	itself is actually a lot more complicated. It does a lot more in relation to your host, and it runs
360600	366380	the entire time that your computer is operating, and so it's not just the boot service, it's
366380	374280	fundamental to all operations of all modern hosts that you find around the world. So, there's a lot
374280	380260	more to it that a lot of people are not privy to, but the key thing to know is it is always active,
380260	387140	is essential, and it's isolated from the rest of the system.
387720	397840	So, why is UEFI interesting to attackers and defenders alike? So, why are attackers, red team,
397840	404360	is looking at UEFI? So, as I said earlier, the UEFI is isolated from the rest of the system on its own
404360	408700	little island of silicon. So, it's segregated from the rest of the system by design.
410580	415780	Because it's isolated, it's not well known about, and it's considered quite low-level technology,
415780	422000	it's commonly overlooked in a lot of attack situations, and normally isolated to the
422000	429460	sort of APT rootkit sort of attack frameworks and methodologies and TDPs. So, it's
429460	434280	normally overlooked in most operations by defenders, so it gives this sort of idea that
434280	441720	it's lucrative and valuable to pro attackers. The other thing to note is that remediation of
441720	448960	anything on the UEFI is really difficult. With a lot of components on the machine,
448960	452420	obviously you can chop and change them, hard drives, RAM, CPU, all that sort of stuff,
452420	458200	if you really had to. Changing the UEFI, if you had to, much more difficult. A lot of the time,
458200	463520	they're soldered onto the motherboard. So, as you can imagine, changing that is a real pain.
463960	469860	And even removing it, obviously, interactively through an interface can be really tricky if
469860	476860	you don't have experience with UEFI. So, as I said, there's a whole section later on that I'm
476860	481360	going to cover about why remediation is difficult, and I'm going to go over that in a lot more
481360	488420	detail. One of the other things to note about UEFI is that by standard, by the standards of UEFI,
488420	496040	everything written to it is automatically put as a system. So, it's non-volatile and everything
496040	501300	that's written will automatically stay there throughout boot. Which, as you can imagine,
501300	508480	from a sort of persistence attack methodology sort of mentality, is inherently quite valuable.
509460	514640	So, although this is why attackers are looking at it, why are they looking at it now? What
514640	521040	exactly has changed? So, as I said, it's normally put as being rootkits and little
521040	525700	actors, ATPs, because it's a complex sort of area and a lot of people overlook or don't really
525700	531880	understand. But what's happened is that since Windows... actually, since Windows XP,
531880	537180	surprisingly, but more recently since Windows Vista and onwards, Windows has... Microsoft
537180	546100	has gradually introduced more runtime access to the UEFI memory space. So, UEFI runs boot
546100	551560	services and runtime services, and through the iterations of Windows and obviously their
552620	559060	updates and newer versions, they've steadily introduced more and more runtime service access
559060	565880	to the UEFI memory space. So, research done last year at DEF CON, DEF CON 27, Michael Liebowitz
565880	572980	and Tova Timson, they did a whole presentation on this type of attack, about how to avoid
572980	579740	threat hunters and EDR by utilizing the UEFI memory space, because it avoids detection.
579940	583740	I was really recommending their research, really cool stuff, and obviously this is where
583740	590180	this entire piece of research stemmed from. And they went into how they could use native
590180	598000	Windows API functions to read and write into the UEFI memory space. So, originally, when I
598000	602580	first saw their talk, I thought, oh, this is worrying, but surely there must be a way around
602580	610000	this. Again, this is a section that will come later on, but it was a gap that was found, or
610000	615660	that I, when looking into it, I did see was in the security defensive structure.
617160	622140	So, because of their research, there is now very, because, not because of the research,
622140	628220	but because of Microsoft's expansion, which is runtime service access, there is, by their
628220	634840	exposure, Windows API basic functionalities that allow read and write access into this lucrative,
634840	639740	sort of, not well understood memory sector that's isolated from the rest of the system,
639740	649620	which is pretty valuable. So, how is it that the UEFI memory space is exploited? All the way
649620	659180	from the APT actors, all the way down to script kitties or, you know, newer attackers. So, the way
659180	667980	that Leibovitz and Timson exposed was to use C-sharp precompiled payloads using
667980	674120	kernel32.dll exploit functions and get firmware environment variable ex and set firmware
674860	680660	environment variable ex. As you can imagine, these are the read and write functions.
681440	687960	With these two methods, an attacker can install a payload into this memory space and then create
687960	694000	an external persistence mechanism to read from this isolated memory space at a later point or
694000	700520	by a trigger in order to run a more malicious or internal payload or a beacon or agent or anything
700520	707660	like that from the UEFI memory space. This obviously requires the payloads to be pre-built,
707660	711280	so they have to be obviously targeted and have an understanding of where they're going and
711280	715300	what they can leverage out of the environment they're going into.
716620	724440	It also has to specify, at the time of compilation, the variable names and the GUIDs
724440	729060	or the vendor IDs of the variable they're going to be injecting into the memory space.
729580	733980	And because of this, and obviously you have to have an understanding of how C-sharp can be used for
736280	742180	API DLL interactions in order to leverage the kernel32.dll in order to access the UEFI and
742180	746860	write into it. So you have to have a good understanding and preparedness of who you're
746860	750940	going to attack, how you're going to attack them, and obviously an understanding of the
750940	757880	programming language itself in order to utilize it. So as attack methods go, this is quite advanced
757880	762460	compared to obviously just copying and pasting off the internet and running it as you like.
763980	768760	You also have to have an understanding of UEFI variable constructs, their attributes,
768760	773540	and how they're constructed. So there's a lot of layers to this sort of attack, but it is
773540	779540	very powerful and if leveraged correctly, as they demonstrated, was very effective.
780020	785120	I decided to approach this from another angle. So instead of going for something pre-compiled
785120	792140	and thought about what if we could just do like a drive-by sort of attack. So we went back to the
792780	803140	tried-and-true PowerShell, which is able to leverage the same DLL import functionality.
803500	810840	So ignoring high-level codes, we found that the same functionality into the UEFI
810840	814760	memory space read and write could be emulated in PowerShell just as effectively.
816800	820480	You can do this as a PowerShell script, or you can actually do it as a
820480	825400	on-the-fly sort of write to terminal and execute, and both work just as well.
825400	830700	The only caveat for both attacks is that it has to be run at an administrative level.
830700	837190	The reason for this is the session that you're using in order to have firmware edit privileges,
837640	842180	you have to do token escalation that can only occur as an admin.
844760	851700	So emulating what Tinsman and Leibovitz did, I was able to
853180	857140	replicate theirs as a PowerShell, as I said, as a script and as a drive-by,
857860	865060	and they were both extremely effective and fully functional. It was only after I translated
865060	870640	their C Sharp code into PowerShell, I found that a guy called Michael Nehas,
870640	876940	sorry if I'm pronouncing that wrong, he's actually already written a PowerShell module online which
876940	882900	you can download and import, which has the read and write functionality nicely wrapped as two
882900	890380	separate functions, arguments, and all this sort of stuff, making the copy-paste of my
891660	897060	PowerShell scripting even easier and much smaller because you don't have to take into account the
897060	901500	token escalation and importing the APIs and understanding how to do that. It does it all
901500	910440	for you. So we've gone from pre-compiled targeted C Sharp payloads to very small on-the-fly copy-paste
910440	916420	PowerShell scripting, which as you can imagine if you put that online anyone can tweak the payload
916420	926100	and start playing around with it and it's much easier to do much quicker. So I made some POC code,
926100	929240	there's a link at the end to a repository where this is available to everyone.
930620	937920	So the POC code is PowerShell dumps a reverse shell payload, the idea is that it dumps a reverse
937920	944140	shell payload into your file and then immediately runs it. So it's just a write, read, execute.
944140	948340	Obviously in the real world, as I said earlier, you'd obviously write it to the memory space,
948340	953400	you'd create persistence, read it later, extract it and execute. For a PSA this seemed to work
954680	963600	very well. When I tested this, so the antivirus I was using on the host, Windows 10,
963600	969240	it detected obviously the reverse shell when it was running to memory, which is what you'd expect,
969240	976740	but it didn't terminate it and it didn't remove the payload itself from the UFI memory space. So
976740	985180	the payload itself was still on the host even after the AV had flagged it, which I'll demonstrate
985700	995240	later. As an extra point, this will tie into the defensive problems later, as an attacker,
995240	1000180	you might want to do is the first write operation you have into a UFI memory space and the persistence
1000180	1007120	that you create, when you run that first payload, delete the original entry into UEFI and the
1007120	1012160	persistence and recreate it again. The reason is that the payload inside the first UEFI, if they
1012160	1016980	find the way that you've injected into it, they can obviously trace that back and figure out what
1016980	1021960	you put there or what you've labeled it under and things like that. Whereas if you do it a second
1021960	1026980	time from an encoded or encrypted payload inside the UEFI that you then extract and run again,
1026980	1033140	it becomes much, much harder for investigators to track that from a point of infection to where
1033140	1040920	you're going and what you're doing. So now comes the tricky bit. I do have a demo. So the demo
1040920	1048340	has been created, just as a heads up, to... it was OBS of a virtual machine, however it is
1048900	1056700	fairly small. So I do apologize. The videos themselves are available afterwards. They'll be
1056700	1066340	available for people to look over. And it will be a good description of what's going on. So this is the first one.
1066340	1074080	So this screen shows the drive by header that I'm going to be using in Notepad. As you can see, it's
1074080	1083680	in byte arrays. So I copy that. This payload is fully available from the repository that's available
1083680	1091320	at the end. This is pasted into the administrative PowerShell terminal. As you can see the whoami
1091320	1100380	cm underscore test. That's now being executed. So that's being written into the UEFI memory space
1100380	1104720	and then being extracted and executed. So we're going to go to my attack box
1105780	1112800	where I have a reverse TCP handler waiting for the connection from the POC code,
1112800	1118440	which is going to be extracted from UEFI memory. So we give that a few seconds.
1123080	1129760	And there it is. So that's the reverse shell from the UEFI hosted payload. And the whoami shows
1129760	1137360	that it is cm underscore test. So it's the same machine that we just ran the PowerShell POC code on.
1141140	1146980	One thing to note is that the PowerShell instance in that case will be running
1154660	1166520	in the background. So when you execute the outputs of the PID
1166520	1173280	of the PowerShell instance that it's going to be running as a POC code, obviously in real attacks
1173280	1177160	you wouldn't keep it as a PowerShell instance. You might migrate it to something else, but
1178500	1188260	they're irrelevant. So that's basically the advance of moving from generating
1188260	1192680	payloads and then targeted attacks all the way down to copy pasting and getting the same effect.
1192680	1197760	So that's the attack side of it, but what about defending? So there are a number of issues with
1197760	1203960	defending UEFI memory space. And to understand these issues, it's good to understand why
1203960	1211020	Microsoft has slowly included more access controls to this memory space in their iterative versions.
1212100	1219060	One of the main reasons is the simplification for firmware updates and maintenance.
1219060	1227820	So for example, if you're a vendor of any sort of hardware, if you want to update the
1227820	1233840	firmware of your device in the old versions, you would have to run the update and or you'd have to
1233840	1240780	do specialized boot time scans in order to check that it was the correct version. Whereas now using
1240780	1246680	these interfaces, the operating system is able to run software that can check the installed version,
1246680	1252180	make sure it's compatible, the right type, the right vendor, so on and so forth. It's also able to
1252180	1257420	change the boot order from runtime, so you no longer have to go into the UEFI or BIOS menu.
1257420	1263060	You can just do that straight from the operating system, which obviously is much more user-friendly
1263060	1269900	for a lot of users. One of the interesting things is that in development of Windows, they
1269900	1276500	use UEFI variables and memory space for crash dump data. So if you ever run
1276500	1280760	Windows Developer Editions and you have a crash, you'll find that it will output
1281500	1286880	crash data to the UEFI memory space because it's non-volatile by nature.
1286900	1290480	They know that it will be stored and it will be safe so that they output there.
1292600	1298940	Yeah, so it allows for just much easier maintenance and upgrading and
1298940	1307240	patching of the firmware level of a machine. But what restrictions are there
1307240	1315500	on this variable access that Windows has introduced? Well, none, effectively. The only restriction I could
1315500	1323020	find was a variable size. Over a certain size, when you try to extract it, you might have some
1323020	1329020	issues because it assumes that it's going to be a certain size. You can overload the UEFI if you
1329020	1334740	try hard enough, although I haven't actually tried that and I don't recommend it.
1335740	1341060	You must provide, if you want to read data from UEFI, you must provide the variable name and the
1341060	1347820	GUID or the vendor ID to access that particular variable's data.
1348840	1354760	And this is where the trouble arises from. There is no currently
1354760	1360640	available way to enumerate the variables, well, there wasn't, available way to enumerate the variables
1360640	1367280	on the UEFI RAM chip at runtime, with only one exception, which Ligritz and
1369180	1373620	Timzen demonstrated last year. I couldn't find any other except for one exception, which I'll
1373620	1379200	cover in a second. Therefore, users, software systems, operating systems, anything like that, can only
1379200	1384200	access variables that they already know exist and they already have the necessary credentials for.
1384320	1391000	So, from a defense point of view, that creates an issue. If an attacker creates a new variable
1391840	1395960	with a randomized name and a GUID that's non-specific,
1397140	1403540	an attacker, a defender, can't enumerate these variables and therefore can't analyze what's
1403540	1409800	inside the UEFI memory. So these, any nasties they put in there, effectively go undetected
1409800	1414160	because the defender doesn't know where they're called and can't extract them, can't access them.
1414960	1420620	So, the only exception that was found was a tool called Chipsack. It was designed by the
1420620	1429900	guys over at Intel. It's a deep firmware security analysis and repair tool. It's really powerful.
1430360	1436320	I was quite impressed with it. It does output the UEFI variables at runtime. It was the only
1436320	1443240	tool, and I did a lot of searching, and I found it did that. But the tool itself, even in their
1443240	1449340	reputations, they say it's not for production. It's for development only. It's very large. It's
1449340	1455220	quite clunky. It requires the installation of a custom kernel driver, and it also requires the
1456720	1462680	disablement of certain security functions in order for it to operate, which obviously,
1462680	1468860	as a defense software, if you're going to be using this remotely in production, is counterintuitive.
1468860	1476620	Although it does what I was looking for, it wasn't capable of doing it in the way that was required.
1483320	1486900	Although those are the difficulties, how do you monitor the memory space?
1487820	1494520	I tested a lot of methods in order to try and find runtime access and enumeration.
1494900	1499840	This is just a few of them, but I spent a lot of time going through these methods.
1500320	1508740	Examination of runtime enumeration. First of all, I looked at the UEFI specification itself,
1508740	1516020	which is really extensive. There are lots of sections that explain how you can enumerate UEFI
1516020	1523560	variables, but they mainly focus on what's called the EFI shell, which is a specialized
1523560	1529760	shell that can be accessed at boot time in order to interface with the EFI layer of your device.
1529760	1536240	It requires a custom loader to be put normally on removal medium, which you then
1536240	1540900	access and it provides the shell. So the specification provides a lot of information
1541960	1546580	about commands that can be run in this particular terminal, this sort of environment, in order to get
1546580	1553120	these variables, but not enough really to do it from runtime. So it was inconclusive and I
1553120	1556240	couldn't find runtime services from the specification, unfortunately.
1558660	1563240	Attempts to... so the operating system, as I said, Windows introduced the interaction for the
1563240	1569420	operating system to have access and control over certain elements of UEFI. So UEFI should have
1569420	1577280	an understanding of what is in there. So analyzing how the operating system interfaces with the UEFI
1577840	1586620	showed that it works off of a database inside the isolated EFI partition of your hard drive.
1586920	1594620	From that partition, it then interfaces with a file called BCD, which is a registry file,
1594620	1600740	so key value pairs, which effectively match up to the values that it already knows about
1600740	1607360	at installation. So backtracing this all the way down. By the way, the BCD file in the EFI
1607360	1611800	partition is held by system, so you can't access it from while you're running the Windows system,
1611800	1620720	which was always a fun caveat. So the operating system only knows what it knows at installation,
1620720	1626640	it can't enumerate what is in the EFI memory space. So unfortunately, that was a dead end.
1628660	1633680	I turned back to Chipseq as it was the only tool that I could find that did what I was looking for,
1633680	1638400	and the source code is fully available online, which is really, really cool, a really good thing
1638400	1645040	to look at. So I began looking at how it functions, I began following its procedures and how it
1645040	1653200	accesses the memory. On assessment, I found that it imported something called EDK2, which seemed to
1653200	1665140	be very important in EFI enumeration. Effectively, what the EDK2 does is, after a lot of time playing
1665140	1671040	with it, extracting it, running it independently from Chipseq, which was very difficult, I found
1671040	1677640	that instead of accessing it from runtime, what EDK2 does is it creates what's called an EFI
1677640	1685600	payload, which can be run within an EFI shell to output specific results. So it's more like a
1685600	1695100	compiler for EFI payloads or capsules, as you may call them, which was run from
1695100	1702200	Chipseq for, I think, mainly for remediation or repairs to the firmware. Unfortunately, it didn't
1702200	1707900	do what I was looking for, which was obviously runtime enumeration. So the operating system
1707900	1712220	doesn't enumerate, it only has a list of what it already knows. The specification didn't provide
1712220	1718060	the information I was looking for, and the tool under analysis that I knew could do it,
1718060	1722700	I stumbled at the first hurdle and couldn't figure out how it was operating.
1722700	1728060	So I ended up kind of down a rabbit hole for quite a while, trying to dig myself out of it.
1728060	1735420	Eventually, I did basically knuckle down and get back to Chipseq, and I spent a lot of time
1735420	1742280	following it, debugging it, really analyzing how it worked. And eventually, I figured out
1742280	1750920	through its abstract process how it accesses the UEFI memory space from runtime. And to do this,
1750920	1760660	it uses an undocumented function of the NTDLL.DLL file called NTEnumerateSystemEnvironmentVariable
1760660	1768320	values EX. And what this command does is it extracts the variable information within UEFI
1768320	1775620	to a buffer of your creation, which can then be extracted and carved to find each variable within
1775620	1784400	it. So you run this function from the NTDLL. It provides a data blob in a buffer, which you can
1784400	1790580	then loop through and carve and extract all of the variables for analysis. And this proved to be
1790580	1800900	the saving grace. From the Chipseq tool, I extracted the methodology, I put it in a lightweight wrapper,
1801440	1808780	really analyzed it, put it through its paces. The resulting POC code, which is in Python,
1808780	1817740	runs on everything Windows 7 forwards that I tested. It should, in theory, run on Windows XP
1818580	1825020	because the function within NTDLL was introduced in one of the NTDLL versions, which was released
1825020	1830820	alongside a Windows XP Service Pack 2. So technically, it should run on Windows XP,
1830820	1837660	but I didn't try that one. It does check if the system you're on is UEFI-based before it allows
1837660	1846180	it to run, which is obviously something else to note. As it uses the native NTDLL.dll, which is
1846180	1851660	found on every single Windows host, you're not required to install anything custom except for
1851660	1857540	Python, but also run the POC code. So it leverages local files in order to enumerate this memory
1857540	1864140	space. As with the attacks, it must be run as admin because of the token escalation that's
1864140	1871940	required for firmware access. But as you can see from the left, when running this POC Python code,
1871940	1877860	it did successfully dump all of the AFI variables, including the malicious codes that were
1877860	1886600	not defined anywhere else, and allowed them for analysis as byte data and as translated Unicode.
1887020	1893260	So we've gone from a very large, powerful, clunky tool to a very lightweight,
1893260	1900880	wrapped Python script, which can run on any Windows host post-Windows 7.
1902600	1922430	I do have another demo for that. Bear with me. So this just shows some Python code.
1923110	1927250	We're now going to run that Python file, Python 2.
1929770	1935130	As you can see, it's outputting the AFI variables nice and clearly. As you can see, the ones going
1936330	1940050	past, although it may be quite small on your screen, is showing the DefCon demo.
1941010	1948430	P2 entries, that was from the attack that I demonstrated earlier, along with the associated
1948430	1957210	byte data and the Unicode of the reverse TCP payload that I generated using NSFenum.
1960200	1970560	There we are. That on the left there is DefCon demo-p1. That's an example of how that works.
1982240	1989780	So now we have a good understanding of how this attack can be used at all range of attack levels
1989780	1995720	and how it can be monitored and defended against. Very lightweight and integrated into defensive
1995720	2006620	software. What does this mean for computer users and as researchers? Everyone can be targeted.
2006620	2011740	Equally, everyone can patch them now. So despite the obvious ease with which all
2011740	2018500	critical attackers can leverage this memory space using the API function exposed last year,
2019340	2023800	and as I've demonstrated, it can be all the way up from defined calculated attack
2024980	2028550	methodology all the way down to drive-by copy-pasting,
2030810	2037390	defenders equally now have the equal ease in accessing and enumerating this memory space
2037390	2047070	for analysis. So although standard hunting procedures or antivirus or defensive technologies
2047070	2053770	may not look into this currently, the integration of such technologies now is very, very easy.
2054490	2065330	So integration into standard detection rules, processes, techniques, and defensive software
2065330	2071550	is extremely easy using the lightweight capabilities that I've outlined, which effectively
2071550	2078650	neuter this as a malicious haven on all available modern operating systems, modern hosts.
2079610	2087750	It also allows for increased sort of research in this area. So although we now can monitor this,
2087750	2094290	there may be custom payloads that they use that are specific, or there might be malware variations
2094290	2099550	that are specific for leveraging this memory space, which allow us to create custom rules
2099550	2106810	and remediation methods in order to remove this as a threat. So as we can now enumerate
2106810	2114090	these malicious payloads when they're on a unified memory space, it also allows us to
2114090	2119890	remediate it by leveraging the same capabilities of the attackers, the read-write. If a defender
2119890	2124610	knows what the payloads are called and where they're stored, they can overwrite and remove
2124610	2131690	their payloads from the victim's host. So we are in a situation now where attackers have this
2131690	2137570	capability to leverage this isolated memory space, but defenders equally have the same
2138410	2144870	level of ease in order to monitor and neuter any attempts to leverage it.
2146430	2153330	So that's me. That's my email, if anyone has any questions. The GitHub below is the
2154010	2158810	repository with the POC codes, as well as the full research paper, which outlines
2158810	2165770	processes taken and has a lot more technical information than this presentation. So if anyone
2165770	2171650	does have any questions, please feel free to email me. There's also the talk.txt channel,
2171650	2176190	if anyone has any questions there. Or please feel free to direct message me, and I will answer
2176190	2182170	any questions that I'm capable of. And I look forward to hearing from you guys.
2184310	2189110	The last slide I have prepared. So please, if anyone has any questions, do just let me know.
2189110	2194430	Thank you very much. Thanks a lot, Connor. Appreciate it. Good talk. Thank you.