# MediaChunks

chunk_id: 157_chunk_16
chunk_text:
somehow like this but probably a lot faster if you're on a real car. 928.18s - 931.18s | So for a Tesla for example it might be on one bus 931.18s - 934.18s | it's I think like 3,000 messages a second. 934.18s - 937.18s | So it can be quite a lot. 937.18s - 942.18s | One step back even if you connect to this. 942.18s - 947.18s | So for Linux the CAN interface is like any other network interface 947.18s - 951.18s | if your adapter is compatible with SocketCAN. 952.18s - 956.18s | The only difference is that you don't have network manager 956.18s - 960.18s | to directly get your interface up and running. 960.18s - 963.18s | And you also need a bitrate. 963.18s - 969.18s | So you have to tell the computer how fast the bus operates. 969.18s - 974.18s | And you can measure that by using an oscilloscope of course. 974.18s - 978.18s | Luckily for automotive it's usually 500 kilobits per second. 978.18s - 980.18s | So you can also try that. 980.18s - 989.18s | And just as a disclaimer there are also more modern standards 989.18s - 991.18s | like improvements on the CAN standards. 991.18s - 993.18s | For example CAN FD. 993.18s - 997.18s | And there you will also need to have the data rate for example. 997.18s - 1001.18s | But let's assume standard CAN for now. 1001.18s - 1004.18s | And then we've already seen the CANup command. 1004.18s - 1008.18s | I just want to walk very quickly through what you can see here. 1009.18s - 1011.18s | That's one single message picked out. 1011.18s - 1015.18s | You see the interface in the front. 1015.18s - 1019.18s | If you have multiple CAN interfaces connected that's important. 1019.18s - 1024.18s | Then the CANID and the data length and the data. 1024.18s - 1029.18s | And the thing is this CANID if you are used to IP 1029.18s - 1034.18s | you're usually used to having a source and a destination address. 1034.18s - 1037.18s | The CANID is actually neither. 1037.18s - 1040.18s | Think of it more like a publisher subscribed topic. 1040.18s - 1049.18s | So it will tell you how to define or how to interpret the bits in the data part. 1049.18s - 1051.18s |


chunk_id: 157_chunk_17
chunk_text:
991.18s | like improvements on the CAN standards. 991.18s - 993.18s | For example CAN FD. 993.18s - 997.18s | And there you will also need to have the data rate for example. 997.18s - 1001.18s | But let's assume standard CAN for now. 1001.18s - 1004.18s | And then we've already seen the CANup command. 1004.18s - 1008.18s | I just want to walk very quickly through what you can see here. 1009.18s - 1011.18s | That's one single message picked out. 1011.18s - 1015.18s | You see the interface in the front. 1015.18s - 1019.18s | If you have multiple CAN interfaces connected that's important. 1019.18s - 1024.18s | Then the CANID and the data length and the data. 1024.18s - 1029.18s | And the thing is this CANID if you are used to IP 1029.18s - 1034.18s | you're usually used to having a source and a destination address. 1034.18s - 1037.18s | The CANID is actually neither. 1037.18s - 1040.18s | Think of it more like a publisher subscribed topic. 1040.18s - 1049.18s | So it will tell you how to define or how to interpret the bits in the data part. 1049.18s - 1051.18s | Also it's the priority of the message. 1051.18s - 1056.18s | So the lower the ID the higher the priority. 1056.18s - 1061.18s | And this data can be really arbitrarily defined. 1061.18s - 1064.18s | The information in there is called signals. 1064.18s - 1070.18s | It can be 1 bit, it can be 5 bit, it can be all 8 bytes. 1070.18s - 1073.18s | So that's up to the manufacturer to define that. 1073.18s - 1081.18s | And that's why we usually need some reverse engineering to make sense of this information. 1081.18s - 1086.18s | So you might want to get started. 1086.18s - 1090.18s | But maybe you do not want to remove all the plating of your car. 1090.18s - 1096.18s | It sounds like a lot of work to figure out all the wiring and stuff. 1096.18s - 1100.18s | So that's actually how we started. 1100.18s - 1104.18s | But if you don't want to do that there's also the way the garages do that. 1104.18s - 1107.18s | So Janis already spoilered it. 1107.18s - 1113.18s | You have this OBD2 connector for vehicle diagnostics. 1114.18s - 1120.18s | And this


chunk_id: 157_chunk_18
chunk_text:
Also it's the priority of the message. 1051.18s - 1056.18s | So the lower the ID the higher the priority. 1056.18s - 1061.18s | And this data can be really arbitrarily defined. 1061.18s - 1064.18s | The information in there is called signals. 1064.18s - 1070.18s | It can be 1 bit, it can be 5 bit, it can be all 8 bytes. 1070.18s - 1073.18s | So that's up to the manufacturer to define that. 1073.18s - 1081.18s | And that's why we usually need some reverse engineering to make sense of this information. 1081.18s - 1086.18s | So you might want to get started. 1086.18s - 1090.18s | But maybe you do not want to remove all the plating of your car. 1090.18s - 1096.18s | It sounds like a lot of work to figure out all the wiring and stuff. 1096.18s - 1100.18s | So that's actually how we started. 1100.18s - 1104.18s | But if you don't want to do that there's also the way the garages do that. 1104.18s - 1107.18s | So Janis already spoilered it. 1107.18s - 1113.18s | You have this OBD2 connector for vehicle diagnostics. 1114.18s - 1120.18s | And this connector is usually very conveniently located somewhere in the driver area of your vehicle in front. 1120.18s - 1125.18s | And you can just plug in a diagnostic connector there. 1125.18s - 1130.18s | It's usually an OBD2 dongle which connects via Bluetooth to a diagnostic device. 1130.18s - 1134.18s | And will read out data like that. 1134.18s - 1138.18s | And the protocol to do this is called UDS, Unified Diagnostic Services. 1138.18s - 1142.18s | And it's basically a request response protocol. 1142.18s - 1147.18s | The diagnostic tester will, for example, in our case we want the steering wheel angle. 1147.18s - 1150.18s | So it will ask, is you responsible for that? 1150.18s - 1152.18s | Can you give me the steering wheel angle? 1152.18s - 1154.18s | And it will respond with the correct value. 1154.18s - 1158.18s | So that's on top of the CAM protocol. 1158.18s - 1163.18s | It can also be IP but usually CAM or both. 1163.18s - 1168.18s | And in between there's actually another protocol which is called ISOTP. 1168.18s - 1171.18s | And which allows to basically combine multiple CAM edges. 1171.18s - 1176.18s | They


chunk_id: 157_chunk_19
chunk_text:
connector is usually very conveniently located somewhere in the driver area of your vehicle in front. 1120.18s - 1125.18s | And you can just plug in a diagnostic connector there. 1125.18s - 1130.18s | It's usually an OBD2 dongle which connects via Bluetooth to a diagnostic device. 1130.18s - 1134.18s | And will read out data like that. 1134.18s - 1138.18s | And the protocol to do this is called UDS, Unified Diagnostic Services. 1138.18s - 1142.18s | And it's basically a request response protocol. 1142.18s - 1147.18s | The diagnostic tester will, for example, in our case we want the steering wheel angle. 1147.18s - 1150.18s | So it will ask, is you responsible for that? 1150.18s - 1152.18s | Can you give me the steering wheel angle? 1152.18s - 1154.18s | And it will respond with the correct value. 1154.18s - 1158.18s | So that's on top of the CAM protocol. 1158.18s - 1163.18s | It can also be IP but usually CAM or both. 1163.18s - 1168.18s | And in between there's actually another protocol which is called ISOTP. 1168.18s - 1171.18s | And which allows to basically combine multiple CAM edges. 1171.18s - 1176.18s | They are limited to 8-byte to one message in UDS. 1176.18s - 1181.18s | So you can send longer data. 1181.18s - 1186.18s | But that comes with the difference that now we also... 1186.18s - 1191.18s | I told you before that this is not like source and destination address to Kennedy. 1191.18s - 1195.18s | But for UDS it's actually the destination address now. 1195.18s - 1199.18s | So there's also, if you want to read data, there's also a data identifier. 1199.18s - 1201.18s | Which identifies which data it is. 1201.18s - 1207.18s | So you can have now multiple different interpretations for data with the same kind of ID. 1207.18s - 1210.18s | And data can be split over multiple CAM frames. 1210.18s - 1212.18s | Just watch out for that. 1212.18s - 1216.18s | Alright, and with that I think we should have everything ready to go. 1216.18s - 1217.18s | Yeah, I think so. 1217.18s - 1219.18s | We have considered the physical layer. 1219.18s - 1222.18s | We have considered the transfer to the software. 1222.18s - 1225.18s | We have considered how we can interpret those CAM messages. 1225.18s - 1228.18s |


chunk_id: 157_chunk_20
chunk_text:
are limited to 8-byte to one message in UDS. 1176.18s - 1181.18s | So you can send longer data. 1181.18s - 1186.18s | But that comes with the difference that now we also... 1186.18s - 1191.18s | I told you before that this is not like source and destination address to Kennedy. 1191.18s - 1195.18s | But for UDS it's actually the destination address now. 1195.18s - 1199.18s | So there's also, if you want to read data, there's also a data identifier. 1199.18s - 1201.18s | Which identifies which data it is. 1201.18s - 1207.18s | So you can have now multiple different interpretations for data with the same kind of ID. 1207.18s - 1210.18s | And data can be split over multiple CAM frames. 1210.18s - 1212.18s | Just watch out for that. 1212.18s - 1216.18s | Alright, and with that I think we should have everything ready to go. 1216.18s - 1217.18s | Yeah, I think so. 1217.18s - 1219.18s | We have considered the physical layer. 1219.18s - 1222.18s | We have considered the transfer to the software. 1222.18s - 1225.18s | We have considered how we can interpret those CAM messages. 1225.18s - 1228.18s | So we have all together to create our game. 1228.18s - 1234.18s | And as a small in-between motivation, that's the actual result. 1234.18s - 1237.18s | You can see Tim sitting in our Volkswagen ID.3. 1237.18s - 1243.18s | In front we have placed a big monitor playing Need for Speed Most Wanted from 2008. 1243.18s - 1246.18s | With the actual car. 1246.18s - 1250.85s | Thank you. 1250.85s - 1258.08s | You can see a little bit more of our V2G experience. 1258.08s - 1260.08s | On the left side you can see our setup. 1260.08s - 1263.08s | A laptop where the game is actually running. 1263.08s - 1269.08s | In front of the car we have placed a huge monitor for a very immersive experience for the driver. 1269.08s - 1272.08s | But also for all other people inside the car. 1272.08s - 1276.08s | On the right side you can see me playing again Need for Speed Most Wanted. 1276.08s - 1279.08s | And you can see I'm very focused on this game. 1279.08s - 1286.08s | So, as I said, it's very immersive and it's a very cool experience sitting in such an


chunk_id: 157_chunk_21
chunk_text:
So we have all together to create our game. 1228.18s - 1234.18s | And as a small in-between motivation, that's the actual result. 1234.18s - 1237.18s | You can see Tim sitting in our Volkswagen ID.3. 1237.18s - 1243.18s | In front we have placed a big monitor playing Need for Speed Most Wanted from 2008. 1243.18s - 1246.18s | With the actual car. 1246.18s - 1250.85s | Thank you. 1250.85s - 1258.08s | You can see a little bit more of our V2G experience. 1258.08s - 1260.08s | On the left side you can see our setup. 1260.08s - 1263.08s | A laptop where the game is actually running. 1263.08s - 1269.08s | In front of the car we have placed a huge monitor for a very immersive experience for the driver. 1269.08s - 1272.08s | But also for all other people inside the car. 1272.08s - 1276.08s | On the right side you can see me playing again Need for Speed Most Wanted. 1276.08s - 1279.08s | And you can see I'm very focused on this game. 1279.08s - 1286.08s | So, as I said, it's very immersive and it's a very cool experience sitting in such an equipped car. 1288.55s - 1294.55s | But how can we now connect the laptop, the game, with the car? 1294.55s - 1297.55s | You can see on the right the topology again. 1297.55s - 1302.55s | Therefore we have several possibilities to connect the car. 1302.55s - 1304.55s | First, we can use wires. 1304.55s - 1309.55s | We can use the USB-based P-CAN Pro, for example. 1309.55s - 1314.55s | Connecting, as one possibility, to the internal CAN bus. 1314.55s - 1319.55s | Therefore we have to figure out which CAN bus relevant messages are located on. 1319.55s - 1323.55s | We have to find the relevant messages. 1323.55s - 1329.55s | Figuring out the relevant signals of the CAN messages, as Tim already explained. 1329.55s - 1334.55s | And there's an overwhelming number of CAN messages on this internal bus. 1334.55s - 1337.55s | As Tim said, several thousands per second. 1337.55s - 1341.55s | So it's quite difficult to figure this stuff out. 1342.55s - 1348.55s | Also, the whole breakout box stuff we've shown to you is required to get access to those internal buses. 1348.55s - 1354.55s | So the more convenient solution is connecting


chunk_id: 157_chunk_22
chunk_text:
equipped car. 1288.55s - 1294.55s | But how can we now connect the laptop, the game, with the car? 1294.55s - 1297.55s | You can see on the right the topology again. 1297.55s - 1302.55s | Therefore we have several possibilities to connect the car. 1302.55s - 1304.55s | First, we can use wires. 1304.55s - 1309.55s | We can use the USB-based P-CAN Pro, for example. 1309.55s - 1314.55s | Connecting, as one possibility, to the internal CAN bus. 1314.55s - 1319.55s | Therefore we have to figure out which CAN bus relevant messages are located on. 1319.55s - 1323.55s | We have to find the relevant messages. 1323.55s - 1329.55s | Figuring out the relevant signals of the CAN messages, as Tim already explained. 1329.55s - 1334.55s | And there's an overwhelming number of CAN messages on this internal bus. 1334.55s - 1337.55s | As Tim said, several thousands per second. 1337.55s - 1341.55s | So it's quite difficult to figure this stuff out. 1342.55s - 1348.55s | Also, the whole breakout box stuff we've shown to you is required to get access to those internal buses. 1348.55s - 1354.55s | So the more convenient solution is connecting directly to the OBD2 port. 1354.55s - 1359.55s | And use the diagnostic services for pulling those informations. 1359.55s - 1363.55s | And getting conveniently just the requested information. 1363.55s - 1368.55s | But since we live in 2024, wires are a little bit outdated. 1368.55s - 1371.55s | We have created a Raspberry Pi head. 1371.55s - 1379.55s | Which allows us to emulate an Xbox 360 controller with a Raspberry Pi Zero. 1379.55s - 1382.55s | Connecting directly to the OBD2 port of the car. 1382.55s - 1388.55s | And this Raspberry Pi connects via Bluetooth to the laptop, emulates this controller. 1388.55s - 1393.55s | And the laptop can stand outside the car and runs the game. 1393.55s - 1396.55s | For this setup we use UDS. 1396.55s - 1403.38s | Now a little bit into detail of the actual hardware we use for it. 1403.38s - 1410.38s | The lower layer of this, you can see it's a classical Raspberry Pi Zero with no modifications. 1410.38s - 1415.38s | Above that we have located the Raspberry Pi CAN head. 1415.38s - 1422.38s | Which is responsible for converting those physical CAN signals to a software readable


chunk_id: 157_chunk_23
chunk_text:
directly to the OBD2 port. 1354.55s - 1359.55s | And use the diagnostic services for pulling those informations. 1359.55s - 1363.55s | And getting conveniently just the requested information. 1363.55s - 1368.55s | But since we live in 2024, wires are a little bit outdated. 1368.55s - 1371.55s | We have created a Raspberry Pi head. 1371.55s - 1379.55s | Which allows us to emulate an Xbox 360 controller with a Raspberry Pi Zero. 1379.55s - 1382.55s | Connecting directly to the OBD2 port of the car. 1382.55s - 1388.55s | And this Raspberry Pi connects via Bluetooth to the laptop, emulates this controller. 1388.55s - 1393.55s | And the laptop can stand outside the car and runs the game. 1393.55s - 1396.55s | For this setup we use UDS. 1396.55s - 1403.38s | Now a little bit into detail of the actual hardware we use for it. 1403.38s - 1410.38s | The lower layer of this, you can see it's a classical Raspberry Pi Zero with no modifications. 1410.38s - 1415.38s | Above that we have located the Raspberry Pi CAN head. 1415.38s - 1422.38s | Which is responsible for converting those physical CAN signals to a software readable CAN message. 1423.38s - 1429.38s | And the top layer, we have created a self-designed PCB. 1429.38s - 1437.38s | For connecting to this OBD2 port of the car. 1437.38s - 1442.38s | From this OBD2 port we only use four connections. 1442.38s - 1447.38s | The 12V, the ground, the CAN high and CAN low connection. 1447.38s - 1455.38s | The CAN high and CAN low connection is directly transferred via this PCB to the lower CAN head. 1455.38s - 1458.38s | Which converts this message. 1458.38s - 1464.38s | But the more interesting part of this PCB is the 12V, 5V DC-DC conversion. 1464.38s - 1469.38s | So we can very conveniently connect this dongle to our car. 1469.38s - 1474.38s | Without the requirement for a power bank and power supply of the Raspberry Pi. 1474.38s - 1477.38s | As a short disclaimer, we are no electrical engineers. 1477.38s - 1482.38s | So if you have any recommendation about this, feel free to contact us. 1482.38s - 1485.38s | We are quite happy about recommendations. 1485.38s - 1494.38s | This circuit for 12V, 5V DC-DC conversion is just taken out of the datasheet of the used IC.


chunk_id: 157_chunk_24
chunk_text:
CAN message. 1423.38s - 1429.38s | And the top layer, we have created a self-designed PCB. 1429.38s - 1437.38s | For connecting to this OBD2 port of the car. 1437.38s - 1442.38s | From this OBD2 port we only use four connections. 1442.38s - 1447.38s | The 12V, the ground, the CAN high and CAN low connection. 1447.38s - 1455.38s | The CAN high and CAN low connection is directly transferred via this PCB to the lower CAN head. 1455.38s - 1458.38s | Which converts this message. 1458.38s - 1464.38s | But the more interesting part of this PCB is the 12V, 5V DC-DC conversion. 1464.38s - 1469.38s | So we can very conveniently connect this dongle to our car. 1469.38s - 1474.38s | Without the requirement for a power bank and power supply of the Raspberry Pi. 1474.38s - 1477.38s | As a short disclaimer, we are no electrical engineers. 1477.38s - 1482.38s | So if you have any recommendation about this, feel free to contact us. 1482.38s - 1485.38s | We are quite happy about recommendations. 1485.38s - 1494.38s | This circuit for 12V, 5V DC-DC conversion is just taken out of the datasheet of the used IC. 1494.38s - 1502.29s | Feel free to come off stage to us and discuss it with me. 1502.29s - 1508.29s | We have also added the possibility to add status LEDs, but that's to be done. 1508.29s - 1513.29s | They are connected to the GPIO pins of the Raspberry Pi. 1513.29s - 1518.29s | So if you want to extend the project, you can use them for your own purpose. 1518.29s - 1522.29s | So we have the hardware, now the software. 1522.29s - 1527.29s | I'm just going very briefly over the software architecture of our tool. 1528.29s - 1534.29s | If you want to use it in the Bluetooth mode, there's an install script for that. 1534.29s - 1542.29s | You just run it on your pre-imaged Raspberry Pi and it will set up everything which is required. 1542.29s - 1546.29s | If you don't want to do it, then just run it on your own laptop. 1546.29s - 1548.29s | There's a run script for Linux. 1548.29s - 1553.29s | For Windows, you just directly run the Python protocol. 1553.29s - 1558.29s | The run script actually will also set up some interfaces and stuff. 1558.29s


chunk_id: 157_chunk_25
chunk_text:
1494.38s - 1502.29s | Feel free to come off stage to us and discuss it with me. 1502.29s - 1508.29s | We have also added the possibility to add status LEDs, but that's to be done. 1508.29s - 1513.29s | They are connected to the GPIO pins of the Raspberry Pi. 1513.29s - 1518.29s | So if you want to extend the project, you can use them for your own purpose. 1518.29s - 1522.29s | So we have the hardware, now the software. 1522.29s - 1527.29s | I'm just going very briefly over the software architecture of our tool. 1528.29s - 1534.29s | If you want to use it in the Bluetooth mode, there's an install script for that. 1534.29s - 1542.29s | You just run it on your pre-imaged Raspberry Pi and it will set up everything which is required. 1542.29s - 1546.29s | If you don't want to do it, then just run it on your own laptop. 1546.29s - 1548.29s | There's a run script for Linux. 1548.29s - 1553.29s | For Windows, you just directly run the Python protocol. 1553.29s - 1558.29s | The run script actually will also set up some interfaces and stuff. 1558.29s - 1563.29s | But you can do this beforehand if you do not want to execute it with pseudo-privileges, 1563.29s - 1567.29s | because that's required for interface management. 1567.29s - 1575.29s | Then for emulating the game controller, for the Bluetooth version, we used the HitPi project 1575.29s - 1577.29s | to emulate a Bluetooth device. 1577.29s - 1581.29s | If you run it on your own laptop, we used the VGamePad library, 1581.29s - 1585.29s | which is also cross-platform, so it also runs on Windows. 1587.29s - 1589.29s | You can also use that. 1589.29s - 1593.29s | For the Bluetooth one, it kind of doesn't really work on Windows so far. 1593.29s - 1597.29s | So if you have any recommendations on that and are an expert on Hit devices, 1597.29s - 1601.29s | also pull requests are welcome. 1602.29s - 1609.29s | So now to our actual domain components. 1609.29s - 1610.29s | We have a car detector. 1610.29s - 1614.29s | If you have multiple vehicles, as we have the ID3 and the Tesla, 1614.29s - 1618.29s | you can give it basically a list of 10 IDs and it will figure out which


chunk_id: 157_chunk_26
chunk_text:
- 1563.29s | But you can do this beforehand if you do not want to execute it with pseudo-privileges, 1563.29s - 1567.29s | because that's required for interface management. 1567.29s - 1575.29s | Then for emulating the game controller, for the Bluetooth version, we used the HitPi project 1575.29s - 1577.29s | to emulate a Bluetooth device. 1577.29s - 1581.29s | If you run it on your own laptop, we used the VGamePad library, 1581.29s - 1585.29s | which is also cross-platform, so it also runs on Windows. 1587.29s - 1589.29s | You can also use that. 1589.29s - 1593.29s | For the Bluetooth one, it kind of doesn't really work on Windows so far. 1593.29s - 1597.29s | So if you have any recommendations on that and are an expert on Hit devices, 1597.29s - 1601.29s | also pull requests are welcome. 1602.29s - 1609.29s | So now to our actual domain components. 1609.29s - 1610.29s | We have a car detector. 1610.29s - 1614.29s | If you have multiple vehicles, as we have the ID3 and the Tesla, 1614.29s - 1618.29s | you can give it basically a list of 10 IDs and it will figure out which car it is 1618.29s - 1622.29s | and then use the according configuration. 1622.29s - 1625.29s | The heart of our project is the car connector, 1625.29s - 1634.29s | which will convert all the car signals in the messages to triggers for the Xbox emulation. 1634.29s - 1641.29s | Then there is the vehicle configuration, which has all the vehicle-specific stuff in there. 1641.29s - 1645.29s | I'll just have a more detailed look on that. 1648.29s - 1652.29s | You can configure a name for your vehicle to reference it. 1652.29s - 1654.29s | Then you have to specify which operation mode, 1654.29s - 1657.29s | if you want to use the internal mode or the UDS mode. 1657.29s - 1662.29s | Sometimes if you have an older car where there is no gateway in between the internal buses 1662.29s - 1667.29s | and the OBD2 connector, you can also use the internal mode for that. 1668.29s - 1674.29s | Or if you install the OBD2 adapter for the Tesla. 1676.29s - 1681.29s | Otherwise, for the UDS mode, you will also have what you can see on the right side. 1681.29s - 1685.29s | You will have


chunk_id: 157_chunk_27
chunk_text:
car it is 1618.29s - 1622.29s | and then use the according configuration. 1622.29s - 1625.29s | The heart of our project is the car connector, 1625.29s - 1634.29s | which will convert all the car signals in the messages to triggers for the Xbox emulation. 1634.29s - 1641.29s | Then there is the vehicle configuration, which has all the vehicle-specific stuff in there. 1641.29s - 1645.29s | I'll just have a more detailed look on that. 1648.29s - 1652.29s | You can configure a name for your vehicle to reference it. 1652.29s - 1654.29s | Then you have to specify which operation mode, 1654.29s - 1657.29s | if you want to use the internal mode or the UDS mode. 1657.29s - 1662.29s | Sometimes if you have an older car where there is no gateway in between the internal buses 1662.29s - 1667.29s | and the OBD2 connector, you can also use the internal mode for that. 1668.29s - 1674.29s | Or if you install the OBD2 adapter for the Tesla. 1676.29s - 1681.29s | Otherwise, for the UDS mode, you will also have what you can see on the right side. 1681.29s - 1685.29s | You will have to send those polling messages I talked about earlier. 1685.29s - 1691.29s | Basically, you can just paste them in here and it will periodically send them to get the data. 1691.29s - 1694.29s | There is also an update interval. 1694.29s - 1699.29s | Usually, we have a higher interval for the steering angle and brakes, 1699.29s - 1702.29s | and for the buttons we use a lower update interval, 1702.29s - 1706.29s | because there is a limit how fast the ECUs will respond. 1706.29s - 1710.29s | Also, we have some, you can see the auto-detect IDs I mentioned before, 1710.29s - 1714.29s | and also some high-level configuration stuff. 1714.29s - 1717.29s | For example, we limit the steering, 1717.29s - 1723.29s | because if you play a racing game and you have to turn the wheel two times for the maximum steering, 1723.29s - 1725.29s | it's just too slow. 1726.29s - 1729.29s | Also, there is the steering dead zone, 1729.29s - 1737.29s | which basically you have a bit more space to set your steering wheel to zero, 1737.29s - 1742.29s | because otherwise, if it's like 0.01 degrees and it will always


chunk_id: 157_chunk_28
chunk_text:
to send those polling messages I talked about earlier. 1685.29s - 1691.29s | Basically, you can just paste them in here and it will periodically send them to get the data. 1691.29s - 1694.29s | There is also an update interval. 1694.29s - 1699.29s | Usually, we have a higher interval for the steering angle and brakes, 1699.29s - 1702.29s | and for the buttons we use a lower update interval, 1702.29s - 1706.29s | because there is a limit how fast the ECUs will respond. 1706.29s - 1710.29s | Also, we have some, you can see the auto-detect IDs I mentioned before, 1710.29s - 1714.29s | and also some high-level configuration stuff. 1714.29s - 1717.29s | For example, we limit the steering, 1717.29s - 1723.29s | because if you play a racing game and you have to turn the wheel two times for the maximum steering, 1723.29s - 1725.29s | it's just too slow. 1726.29s - 1729.29s | Also, there is the steering dead zone, 1729.29s - 1737.29s | which basically you have a bit more space to set your steering wheel to zero, 1737.29s - 1742.29s | because otherwise, if it's like 0.01 degrees and it will always go left in the menus, 1742.29s - 1745.29s | or you just cannot drive straight, 1745.29s - 1750.29s | it's actually pretty hard to get your steering wheel to exactly zero degrees. 1750.29s - 1752.29s | So, that's pretty handy. 1753.29s - 1757.29s | I'll go a bit into detail on the signal configuration later, 1758.29s - 1762.29s | but for now, let's look at how it works out. 1762.29s - 1764.29s | Yeah, we are ready to play. 1764.29s - 1767.29s | Unfortunately, we are not allowed to bring our car with us, 1767.29s - 1770.29s | so we have brought some videos of the gaming experience. 1770.29s - 1775.29s | You can see me here driving with first-person view, playing SuperTux Kart. 1780.51s - 1785.51s | You can see I control the racing car with the steering wheel, left and right, 1785.51s - 1790.51s | and now I've paused, because you can see I put my foot on the brake, 1790.51s - 1792.51s | and see what happens next. 1792.51s - 1800.75s | As expected, the racing car slows down, and I was overtaken. 1802.75s - 1809.75s | Now, you can see I've started the indicator. 1809.75s -


chunk_id: 157_chunk_29
chunk_text:
go left in the menus, 1742.29s - 1745.29s | or you just cannot drive straight, 1745.29s - 1750.29s | it's actually pretty hard to get your steering wheel to exactly zero degrees. 1750.29s - 1752.29s | So, that's pretty handy. 1753.29s - 1757.29s | I'll go a bit into detail on the signal configuration later, 1758.29s - 1762.29s | but for now, let's look at how it works out. 1762.29s - 1764.29s | Yeah, we are ready to play. 1764.29s - 1767.29s | Unfortunately, we are not allowed to bring our car with us, 1767.29s - 1770.29s | so we have brought some videos of the gaming experience. 1770.29s - 1775.29s | You can see me here driving with first-person view, playing SuperTux Kart. 1780.51s - 1785.51s | You can see I control the racing car with the steering wheel, left and right, 1785.51s - 1790.51s | and now I've paused, because you can see I put my foot on the brake, 1790.51s - 1792.51s | and see what happens next. 1792.51s - 1800.75s | As expected, the racing car slows down, and I was overtaken. 1802.75s - 1809.75s | Now, you can see I've started the indicator. 1809.75s - 1815.75s | We have mapped the indicator function for left to throwing items in this game. 1815.75s - 1819.75s | You can do this for your own purpose, for your own game, but we have mapped it like this. 1820.75s - 1828.75s | So, you can see here, I'm throwing this exploding muffin to the racing car in front of me, 1828.75s - 1830.75s | so it will explode. 1830.75s - 1836.75s | Unfortunately, because PowerPoint is a little bit annoying, 1836.75s - 1844.75s | usually you should see that I have turned on the full beam 2, 1844.75s - 1852.75s | so we have mapped the full beam trigger to the nitro activation in the game. 1853.75s - 1858.75s | So, it's very cool driving in the night, igniting, and the car speeds up. 1859.75s - 1860.75s | See what happens? 1860.75s - 1863.75s | Yeah, you can see the nitrogen. 1863.75s - 1871.75s | Now, you can see it's a little bit difficult to drive, especially with just one hand, 1871.75s - 1878.75s | but it is possible to race, it is possible to overtake enemies in this game, 1878.75s - 1882.75s | and it is also possible


chunk_id: 157_chunk_30
chunk_text:
1815.75s | We have mapped the indicator function for left to throwing items in this game. 1815.75s - 1819.75s | You can do this for your own purpose, for your own game, but we have mapped it like this. 1820.75s - 1828.75s | So, you can see here, I'm throwing this exploding muffin to the racing car in front of me, 1828.75s - 1830.75s | so it will explode. 1830.75s - 1836.75s | Unfortunately, because PowerPoint is a little bit annoying, 1836.75s - 1844.75s | usually you should see that I have turned on the full beam 2, 1844.75s - 1852.75s | so we have mapped the full beam trigger to the nitro activation in the game. 1853.75s - 1858.75s | So, it's very cool driving in the night, igniting, and the car speeds up. 1859.75s - 1860.75s | See what happens? 1860.75s - 1863.75s | Yeah, you can see the nitrogen. 1863.75s - 1871.75s | Now, you can see it's a little bit difficult to drive, especially with just one hand, 1871.75s - 1878.75s | but it is possible to race, it is possible to overtake enemies in this game, 1878.75s - 1882.75s | and it is also possible for you to get the right items, 1882.75s - 1887.75s | in this example the acceleration one, to win racing games. 1893.49s - 1895.49s | And it's actually a lot of fun. 1896.49s - 1898.49s | You see, we're very excited about this. 1899.49s - 1903.49s | So, maybe, over to Tim. 1903.49s - 1907.49s | So, the question all of you probably have in your mind, 1907.49s - 1911.49s | how do you support your own car to use this? 1911.49s - 1919.49s | Well, before you get started on that, just make sure you keep in mind the safety, 1919.49s - 1923.49s | so make sure you cannot accidentally drive into a wall. 1924.49s - 1928.49s | Because if you're in your garage, and you're really into your game, 1928.49s - 1934.49s | and by accident you switch to drive mode, you don't want to do that, 1934.49s - 1938.49s | even if you're probably out on the gas, right? 1938.49s - 1940.49s | So, make sure you cannot do that. 1940.49s - 1944.49s | Of course, that's a problem on combustion engine vehicles, 1944.49s - 1948.49s | where you do not have to turn on the engine,


chunk_id: 157_chunk_31
chunk_text:
for you to get the right items, 1882.75s - 1887.75s | in this example the acceleration one, to win racing games. 1893.49s - 1895.49s | And it's actually a lot of fun. 1896.49s - 1898.49s | You see, we're very excited about this. 1899.49s - 1903.49s | So, maybe, over to Tim. 1903.49s - 1907.49s | So, the question all of you probably have in your mind, 1907.49s - 1911.49s | how do you support your own car to use this? 1911.49s - 1919.49s | Well, before you get started on that, just make sure you keep in mind the safety, 1919.49s - 1923.49s | so make sure you cannot accidentally drive into a wall. 1924.49s - 1928.49s | Because if you're in your garage, and you're really into your game, 1928.49s - 1934.49s | and by accident you switch to drive mode, you don't want to do that, 1934.49s - 1938.49s | even if you're probably out on the gas, right? 1938.49s - 1940.49s | So, make sure you cannot do that. 1940.49s - 1944.49s | Of course, that's a problem on combustion engine vehicles, 1944.49s - 1948.49s | where you do not have to turn on the engine, 1948.49s - 1952.49s | but then make sure not to drain your 12-volt battery, 1952.49s - 1954.49s | like playing all night. 1954.49s - 1960.49s | Yeah, that's probably not good, if you do not have a charger connected. 1961.49s - 1963.49s | So, what do you need? 1963.49s - 1965.49s | I think we talked about everything of that. 1965.49s - 1967.49s | The Raspberry Pi, a con-head. 1967.49s - 1971.49s | You can also use just an OBD-II augmented cable, 1971.49s - 1976.49s | if you do not want to solder your own OBD-II head. 1976.49s - 1980.49s | So, that all should be less than 50 bucks, I think, to get started. 1980.49s - 1983.49s | If you use the diagnostic mode, 1983.49s - 1987.49s | and you have to get a diagnostic tester to reverse-engineer that, 1987.49s - 1989.49s | that really depends on the car, probably. 1989.49s - 1991.49s | There are sometimes some very cheap ones, 1991.49s - 1996.49s | and if you have to get a garage-level one, it's pretty expensive. 1996.49s - 2000.49s | So, yeah, probably too much. 2000.49s - 2003.49s | Okay, and then you can start reverse-engineering. 2003.49s -


chunk_id: 157_chunk_32
chunk_text:
1948.49s - 1952.49s | but then make sure not to drain your 12-volt battery, 1952.49s - 1954.49s | like playing all night. 1954.49s - 1960.49s | Yeah, that's probably not good, if you do not have a charger connected. 1961.49s - 1963.49s | So, what do you need? 1963.49s - 1965.49s | I think we talked about everything of that. 1965.49s - 1967.49s | The Raspberry Pi, a con-head. 1967.49s - 1971.49s | You can also use just an OBD-II augmented cable, 1971.49s - 1976.49s | if you do not want to solder your own OBD-II head. 1976.49s - 1980.49s | So, that all should be less than 50 bucks, I think, to get started. 1980.49s - 1983.49s | If you use the diagnostic mode, 1983.49s - 1987.49s | and you have to get a diagnostic tester to reverse-engineer that, 1987.49s - 1989.49s | that really depends on the car, probably. 1989.49s - 1991.49s | There are sometimes some very cheap ones, 1991.49s - 1996.49s | and if you have to get a garage-level one, it's pretty expensive. 1996.49s - 2000.49s | So, yeah, probably too much. 2000.49s - 2003.49s | Okay, and then you can start reverse-engineering. 2003.49s - 2007.49s | So, here you can see the UDS tester set-up, basically. 2007.49s - 2011.49s | The actuator, we are looking at the steering wheel angle, as before. 2011.49s - 2016.49s | Here we have a tablet with the diagnostic tool, 2016.49s - 2018.49s | which reads out the steering angle. 2018.49s - 2022.49s | And here we have my laptop, which runs CAN Sniffer, 2022.49s - 2024.49s | which is a very convenient tool 2024.49s - 2027.49s | to show you the differences in CAN messages. 2027.49s - 2032.49s | And what we'll do next is turn the steering wheel 2032.49s - 2035.49s | to see where the information is. 2035.49s - 2040.49s | And, actually, I turn it one time completely to the left 2040.49s - 2043.49s | and one time to the right to get the min and maximum value, 2043.49s - 2045.49s | which is possible for the signal, 2045.49s - 2048.49s | but you have seen where it is located. 2048.49s - 2051.49s | And, yeah, sometimes you're lucky, 2051.49s - 2056.49s | and you will find already complete CAN database files, 2056.49s - 2059.49s | called DBC files, online for your car. 2059.49s -


chunk_id: 157_chunk_33
chunk_text:
2007.49s | So, here you can see the UDS tester set-up, basically. 2007.49s - 2011.49s | The actuator, we are looking at the steering wheel angle, as before. 2011.49s - 2016.49s | Here we have a tablet with the diagnostic tool, 2016.49s - 2018.49s | which reads out the steering angle. 2018.49s - 2022.49s | And here we have my laptop, which runs CAN Sniffer, 2022.49s - 2024.49s | which is a very convenient tool 2024.49s - 2027.49s | to show you the differences in CAN messages. 2027.49s - 2032.49s | And what we'll do next is turn the steering wheel 2032.49s - 2035.49s | to see where the information is. 2035.49s - 2040.49s | And, actually, I turn it one time completely to the left 2040.49s - 2043.49s | and one time to the right to get the min and maximum value, 2043.49s - 2045.49s | which is possible for the signal, 2045.49s - 2048.49s | but you have seen where it is located. 2048.49s - 2051.49s | And, yeah, sometimes you're lucky, 2051.49s - 2056.49s | and you will find already complete CAN database files, 2056.49s - 2059.49s | called DBC files, online for your car. 2059.49s - 2062.49s | Then you can also try to get this information out of there 2062.49s - 2064.49s | and use that. 2064.49s - 2067.49s | But, otherwise, reverse-engineering of this data is quite good 2067.49s - 2071.49s | because it's like you can easily turn the steering wheel 2071.49s - 2073.49s | to see where the data is, right? 2073.49s - 2075.49s | It's just if there are 3,000 messages, 2075.49s - 2079.49s | it might take you some time to find the right one. 2079.49s - 2082.49s | Then, for configuring it, 2082.49s - 2084.49s | you basically add all this information, 2084.49s - 2086.49s | the CAN ID, the position in the signal, 2086.49s - 2088.49s | and the length of the data. 2088.49s - 2091.49s | And then that's why we use Python for the configuration. 2091.49s - 2097.49s | You can just use a function to specify the signal mapping. 2097.49s - 2103.49s | In this case, we have the first byte turning to the left, 2103.49s - 2104.49s | the second to the right, 2104.49s - 2106.49s | and then we specify the min and max value 2106.49s - 2110.49s | and map this to


chunk_id: 157_chunk_34
chunk_text:
2062.49s | Then you can also try to get this information out of there 2062.49s - 2064.49s | and use that. 2064.49s - 2067.49s | But, otherwise, reverse-engineering of this data is quite good 2067.49s - 2071.49s | because it's like you can easily turn the steering wheel 2071.49s - 2073.49s | to see where the data is, right? 2073.49s - 2075.49s | It's just if there are 3,000 messages, 2075.49s - 2079.49s | it might take you some time to find the right one. 2079.49s - 2082.49s | Then, for configuring it, 2082.49s - 2084.49s | you basically add all this information, 2084.49s - 2086.49s | the CAN ID, the position in the signal, 2086.49s - 2088.49s | and the length of the data. 2088.49s - 2091.49s | And then that's why we use Python for the configuration. 2091.49s - 2097.49s | You can just use a function to specify the signal mapping. 2097.49s - 2103.49s | In this case, we have the first byte turning to the left, 2103.49s - 2104.49s | the second to the right, 2104.49s - 2106.49s | and then we specify the min and max value 2106.49s - 2110.49s | and map this to a range of minus 1.0 to 1.0. 2113.18s - 2114.18s | All right. 2114.18s - 2119.18s | That's what you need to configure it for your own car. 2119.18s - 2121.18s | So, in conclusion of this talk, 2121.18s - 2126.18s | if anybody asks you, especially our professor, 2126.18s - 2132.18s | now you definitely know that V2G stands for Vehicle-to-Game. 2132.18s - 2134.18s | Car hacking can be really fun, 2134.18s - 2137.18s | and I think our project is a great entry point 2137.18s - 2138.18s | if you want to get into that 2138.18s - 2143.18s | or just want to be able to say 2143.18s - 2148.18s | that you have a very expensive game controller at home. 2148.18s - 2150.18s | Always be careful if you do that stuff. 2150.18s - 2153.18s | Do not drive into walls. 2153.18s - 2156.18s | We actually use it, as Janis said before, 2156.18s - 2158.18s | as a demonstrator to motivate students, 2158.18s - 2159.18s | to show it to visitors. 2159.18s - 2163.18s | It's always a good icebreaker to get started 2163.18s - 2166.18s | about talking about automotive security. 2166.18s - 2169.18s |


chunk_id: 157_chunk_35
chunk_text:
a range of minus 1.0 to 1.0. 2113.18s - 2114.18s | All right. 2114.18s - 2119.18s | That's what you need to configure it for your own car. 2119.18s - 2121.18s | So, in conclusion of this talk, 2121.18s - 2126.18s | if anybody asks you, especially our professor, 2126.18s - 2132.18s | now you definitely know that V2G stands for Vehicle-to-Game. 2132.18s - 2134.18s | Car hacking can be really fun, 2134.18s - 2137.18s | and I think our project is a great entry point 2137.18s - 2138.18s | if you want to get into that 2138.18s - 2143.18s | or just want to be able to say 2143.18s - 2148.18s | that you have a very expensive game controller at home. 2148.18s - 2150.18s | Always be careful if you do that stuff. 2150.18s - 2153.18s | Do not drive into walls. 2153.18s - 2156.18s | We actually use it, as Janis said before, 2156.18s - 2158.18s | as a demonstrator to motivate students, 2158.18s - 2159.18s | to show it to visitors. 2159.18s - 2163.18s | It's always a good icebreaker to get started 2163.18s - 2166.18s | about talking about automotive security. 2166.18s - 2169.18s | And so the only question that remains is 2169.18s - 2171.18s | what you're going to use it for. 2171.18s - 2179.74s | Yeah. Feel free to contact us. 2179.74s - 2182.74s | Do any contributions to our project. 2182.74s - 2183.74s | Write us an email. 2183.74s - 2185.74s | Here you can see the QR code. 2185.74s - 2186.74s | The Git repository is public, 2186.74s - 2192.74s | so you can make an issue or do a pull request. 2192.74s - 2193.74s | Feel free. 2193.74s - 2196.74s | We're happy if we can keep in contact with you. 2196.74s - 2201.22s | And I think we have eight minutes left for questions, 2201.22s - 2202.22s | if there are any. 2202.22s - 2206.22s | Otherwise, we can also take further questions offstage. 2206.22s - 2214.06s | Have you thought about playing with heads-up display? 2214.06s - 2216.06s | You know, you can get these things now. 2216.06s - 2217.06s | You just put it on the dash, 2217.06s - 2223.06s | and it'll actually just reflect your iPad 2223.06s - 2225.06s | or anything up onto the windscreen, 2225.06s - 2229.06s | and it looks like


chunk_id: 157_chunk_36
chunk_text:
And so the only question that remains is 2169.18s - 2171.18s | what you're going to use it for. 2171.18s - 2179.74s | Yeah. Feel free to contact us. 2179.74s - 2182.74s | Do any contributions to our project. 2182.74s - 2183.74s | Write us an email. 2183.74s - 2185.74s | Here you can see the QR code. 2185.74s - 2186.74s | The Git repository is public, 2186.74s - 2192.74s | so you can make an issue or do a pull request. 2192.74s - 2193.74s | Feel free. 2193.74s - 2196.74s | We're happy if we can keep in contact with you. 2196.74s - 2201.22s | And I think we have eight minutes left for questions, 2201.22s - 2202.22s | if there are any. 2202.22s - 2206.22s | Otherwise, we can also take further questions offstage. 2206.22s - 2214.06s | Have you thought about playing with heads-up display? 2214.06s - 2216.06s | You know, you can get these things now. 2216.06s - 2217.06s | You just put it on the dash, 2217.06s - 2223.06s | and it'll actually just reflect your iPad 2223.06s - 2225.06s | or anything up onto the windscreen, 2225.06s - 2229.06s | and it looks like a heads-up display kind of a thing. 2229.06s - 2230.06s | Have you thought about that, 2230.06s - 2235.06s | just for a way to project onto the screen? 2236.06s - 2239.06s | Um, so... 2239.06s - 2240.06s | Oh, yeah, so the question was 2240.06s - 2244.06s | if we have thought about, like, projecting the game, 2244.06s - 2247.06s | basically, onto the screen of the car. 2247.06s - 2249.06s | So we've thought about that. 2249.06s - 2250.06s | We haven't done it. 2250.06s - 2252.06s | We also thought about because the ID3 2252.06s - 2256.06s | actually has a heads-up display. 2256.06s - 2260.06s | Yeah, so I think there are adapters 2260.06s - 2262.06s | to the protocol they use there, 2262.06s - 2265.06s | and then you can use it as an HDMI interface, 2265.06s - 2267.06s | basically, if you plug in there. 2267.06s - 2270.06s | So we have some plans maybe for the future, 2270.06s - 2273.06s | but we actually haven't done that or tested it. 2273.06s - 2277.06s | But, yeah, also just putting a projector 2277.06s - 2278.06s | in the back of the car, 2278.06s -


chunk_id: 157_chunk_37
chunk_text:
a heads-up display kind of a thing. 2229.06s - 2230.06s | Have you thought about that, 2230.06s - 2235.06s | just for a way to project onto the screen? 2236.06s - 2239.06s | Um, so... 2239.06s - 2240.06s | Oh, yeah, so the question was 2240.06s - 2244.06s | if we have thought about, like, projecting the game, 2244.06s - 2247.06s | basically, onto the screen of the car. 2247.06s - 2249.06s | So we've thought about that. 2249.06s - 2250.06s | We haven't done it. 2250.06s - 2252.06s | We also thought about because the ID3 2252.06s - 2256.06s | actually has a heads-up display. 2256.06s - 2260.06s | Yeah, so I think there are adapters 2260.06s - 2262.06s | to the protocol they use there, 2262.06s - 2265.06s | and then you can use it as an HDMI interface, 2265.06s - 2267.06s | basically, if you plug in there. 2267.06s - 2270.06s | So we have some plans maybe for the future, 2270.06s - 2273.06s | but we actually haven't done that or tested it. 2273.06s - 2277.06s | But, yeah, also just putting a projector 2277.06s - 2278.06s | in the back of the car, 2278.06s - 2280.06s | it's probably quite good, yeah. 2280.06s - 2282.06s | It's not a security-related problem. 2282.06s - 2286.06s | It's just throwing money on it by such a converter, 2286.06s - 2288.06s | and then you can easily connect your laptop 2288.06s - 2290.06s | with those internal screens of the car. 2290.06s - 2295.06s | That's expensive but easily doable. 2295.06s - 2299.06s | Um, yeah, but come up with your own setup. 2299.06s - 2303.06s | I think there's a lot of possibility, right? 2303.06s - 2304.06s | Yeah. 2304.06s - 2309.42s | The question was how if we build up 2309.42s - 2311.42s | a flight simulator out of this. 2311.42s - 2316.42s | If you have a real airplane, maybe you can transfer this. 2316.42s - 2317.42s | I don't know. 2317.42s - 2319.42s | Maybe you can use also your car for this. 2319.42s - 2320.42s | It should be possible. 2320.42s - 2323.42s | It's just an Xbox controller. 2323.42s - 2327.42s | You can map it to anything you want. 2327.42s - 2329.42s | Okay, any further questions? 2329.42s - 2330.42s | No? 2330.42s - 2331.42s | No. 2331.42s - 2332.42s |


chunk_id: 157_chunk_38
chunk_text:
2280.06s | it's probably quite good, yeah. 2280.06s - 2282.06s | It's not a security-related problem. 2282.06s - 2286.06s | It's just throwing money on it by such a converter, 2286.06s - 2288.06s | and then you can easily connect your laptop 2288.06s - 2290.06s | with those internal screens of the car. 2290.06s - 2295.06s | That's expensive but easily doable. 2295.06s - 2299.06s | Um, yeah, but come up with your own setup. 2299.06s - 2303.06s | I think there's a lot of possibility, right? 2303.06s - 2304.06s | Yeah. 2304.06s - 2309.42s | The question was how if we build up 2309.42s - 2311.42s | a flight simulator out of this. 2311.42s - 2316.42s | If you have a real airplane, maybe you can transfer this. 2316.42s - 2317.42s | I don't know. 2317.42s - 2319.42s | Maybe you can use also your car for this. 2319.42s - 2320.42s | It should be possible. 2320.42s - 2323.42s | It's just an Xbox controller. 2323.42s - 2327.42s | You can map it to anything you want. 2327.42s - 2329.42s | Okay, any further questions? 2329.42s - 2330.42s | No? 2330.42s - 2331.42s | No. 2331.42s - 2332.42s | All right. 2332.42s - 2333.42s | Okay, thank you. 2333.42s - 2335.42s | Thank you for listening, and have a nice day. 2335.42s - 2337.42s | Enjoy the last day of DEF CON.


chunk_id: 157_chunk_39
chunk_text:
All right. 2332.42s - 2333.42s | Okay, thank you. 2333.42s - 2335.42s | Thank you for listening, and have a nice day. 2335.42s - 2337.42s | Enjoy the last day of DEF CON.


chunk_id: 158_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=Fd6v9NXmszM", "title": "DEF CON 32 - Spies and Bytes: Victory in the Digital Age - General Paul M Nakasone", "description": "Join General Paul M. Nakasone, U.S. Army (Retired), for a deep dive into the realities of modern cyber warfare at DefCon. With critical stories from his extensive career, General Nakasone will expose the details of national security in the digital era.\n\nThe longest-serving leader of both the National Security Agency and U.S. Cyber Command, General Nakasone has been on the frontlines of America's cyber defense. He will share firsthand accounts of defending against nation-state hackers, securing critical infrastructure during global crises, and the strategies that kept adversaries at bay.\n\nThis talk will examine the evolving nature of conflict, where the battlefield extends into cyberspace and unique partnerships must be built to offer agility and resilience. General Nakasone will discuss the persistent threats posed by sophisticated hackers and the innovative defenses employed to counteract them. He\u2019ll delve into the importance of intelligence sharing, international alliances, and transparency in operations.\n\nLooking ahead, General Nakasone will present a forward-thinking vision for the future of warfare. He\u2019ll highlight the necessity for adaptive cyber strategies, resilient defenses, and the cultivation of new leadership to address emerging threats.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2650, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 1.42s - 6.42s | This text was transcribed using whisper model: large-v2 Nothing like starting your day with a shot of Kentucky bourbon. Hi, I'm Paul. Former handle, 11.60s - 16.60s | Dernza. I want to thank uh Dark Tangent for inviting me to DEF CON 32. More importantly I 20.04s - 25.58s | want to thank Dark Tangent for building a community of hackers. Hackers that have been 25.58s - 30.98s | invited not only in the private sector but also for our hackers that work in 30.98s - 35.48s | government. And it's so good to see so many of you today. Thanks a lot for coming and 35.48s - 40.48s | joining us for what will undoubtedly be the best DEF CON ever. Hey, let me begin. You 43.12s - 48.56s | know it's been 180 days, 6 months since I left Cyber Command and the National Security 48.56s - 53.56s | Agency. I retired from the Army and had a number of different experiences. It's just been 53.86s - 61.23s | incredible. I thought I'd share something a couple months ago. I decided to


chunk_id: 158_chunk_1
chunk_text:
threats.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2650, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 1.42s - 6.42s | This text was transcribed using whisper model: large-v2 Nothing like starting your day with a shot of Kentucky bourbon. Hi, I'm Paul. Former handle, 11.60s - 16.60s | Dernza. I want to thank uh Dark Tangent for inviting me to DEF CON 32. More importantly I 20.04s - 25.58s | want to thank Dark Tangent for building a community of hackers. Hackers that have been 25.58s - 30.98s | invited not only in the private sector but also for our hackers that work in 30.98s - 35.48s | government. And it's so good to see so many of you today. Thanks a lot for coming and 35.48s - 40.48s | joining us for what will undoubtedly be the best DEF CON ever. Hey, let me begin. You 43.12s - 48.56s | know it's been 180 days, 6 months since I left Cyber Command and the National Security 48.56s - 53.56s | Agency. I retired from the Army and had a number of different experiences. It's just been 53.86s - 61.23s | incredible. I thought I'd share something a couple months ago. I decided to look for a job. 66.11s - 73.09s | And the job that I was looking for they said hey we have to do a background check on you. I 73.09s - 78.09s | said fantastic. Imagine my surprise when the background check comes back and it says 79.97s - 87.96s | unable to confirm U.S. citizenship. Wow, what a story that would be. I wonder if the 87.98s - 92.98s | Washington Post knows. So after a informed and impassioned conversation with the Social 95.62s - 100.62s | Security Administration, they invited me to visit their local office, which I did. Now when 102.70s - 108.46s | you come into the local Social Security Administration office, there's like a ticket 108.46s - 113.04s | booth. You know like you would have at a deli, right? And I saw like tickets but it wasn't 113.06s - 118.06s | like 1 through 10. It was like 1 through 10 and then also letters there. And I was thinking 120.32s - 126.50s | letters and numbers. Wow, I better take many tickets because I want to get seen fast. Who 126.50s - 131.50s | knew that that's both monitored and frowned upon by


chunk_id: 158_chunk_2
chunk_text:
look for a job. 66.11s - 73.09s | And the job that I was looking for they said hey we have to do a background check on you. I 73.09s - 78.09s | said fantastic. Imagine my surprise when the background check comes back and it says 79.97s - 87.96s | unable to confirm U.S. citizenship. Wow, what a story that would be. I wonder if the 87.98s - 92.98s | Washington Post knows. So after a informed and impassioned conversation with the Social 95.62s - 100.62s | Security Administration, they invited me to visit their local office, which I did. Now when 102.70s - 108.46s | you come into the local Social Security Administration office, there's like a ticket 108.46s - 113.04s | booth. You know like you would have at a deli, right? And I saw like tickets but it wasn't 113.06s - 118.06s | like 1 through 10. It was like 1 through 10 and then also letters there. And I was thinking 120.32s - 126.50s | letters and numbers. Wow, I better take many tickets because I want to get seen fast. Who 126.50s - 131.50s | knew that that's both monitored and frowned upon by the Social Security Administration. The 135.86s - 140.86s | Department of Motor Vehicles. The DMV. Amazing place to be. Can we have the next slide 141.54s - 146.54s | please? Now a number of my friends and family indicated to me that I should be very careful in 152.42s - 157.42s | terms of what I do when I go to the DMV. Why is that? Because if you're not precise in the 160.12s - 165.16s | information that you bring, they're going to send you back. Are you able to see the slide 165.16s - 175.72s | yet? Oh, that's unfortunate. Okay, that's me at the DMV. That's before they send me home 178.96s - 185.96s | two times to get the right information for my license. I'll spare you the second shot. But 185.96s - 190.74s | here's what I would tell you. They didn't require me to take a road and a written test so I 190.74s - 197.12s | thought it was at least above the curve there. Last thing I would say. Imagine after three 197.12s - 202.12s | decades of serving and not being able to bring your cell phone to work. Right? That's


chunk_id: 158_chunk_3
chunk_text:
the Social Security Administration. The 135.86s - 140.86s | Department of Motor Vehicles. The DMV. Amazing place to be. Can we have the next slide 141.54s - 146.54s | please? Now a number of my friends and family indicated to me that I should be very careful in 152.42s - 157.42s | terms of what I do when I go to the DMV. Why is that? Because if you're not precise in the 160.12s - 165.16s | information that you bring, they're going to send you back. Are you able to see the slide 165.16s - 175.72s | yet? Oh, that's unfortunate. Okay, that's me at the DMV. That's before they send me home 178.96s - 185.96s | two times to get the right information for my license. I'll spare you the second shot. But 185.96s - 190.74s | here's what I would tell you. They didn't require me to take a road and a written test so I 190.74s - 197.12s | thought it was at least above the curve there. Last thing I would say. Imagine after three 197.12s - 202.12s | decades of serving and not being able to bring your cell phone to work. Right? That's a 202.12s - 207.76s | big deal, man. We don't allow cell phones in where we work at the NSA and Cyber Command. And 207.76s - 212.76s | then I got this email saying, hey Paul, leave your cell phone, your iPad, your Apple watch at 215.06s - 220.08s | home. You're going to DEF CON. Wow. Good to see some things haven't changed in my life. Hey, 221.08s - 226.08s | today I want to talk about the journey of NSA and Cyber Command and cyberspace. What I want to 229.38s - 234.46s | talk about is our beginnings, want to talk about where we were, what we've done, some of the 234.46s - 239.40s | impacts that we've had. I also want to talk about the opportunities and challenges and then 239.40s - 244.40s | conclude with, hey, this is really what we need to do collectively going forward. The picture 244.82s - 250.72s | that's shown there is the National Security Operations Center. It is among the most 250.72s - 255.74s | sensitive places in the National Security Agency. We don't take visitors. It's not a stop on the 257.74s - 263.30s | hop on, hop off


chunk_id: 158_chunk_4
chunk_text:
a 202.12s - 207.76s | big deal, man. We don't allow cell phones in where we work at the NSA and Cyber Command. And 207.76s - 212.76s | then I got this email saying, hey Paul, leave your cell phone, your iPad, your Apple watch at 215.06s - 220.08s | home. You're going to DEF CON. Wow. Good to see some things haven't changed in my life. Hey, 221.08s - 226.08s | today I want to talk about the journey of NSA and Cyber Command and cyberspace. What I want to 229.38s - 234.46s | talk about is our beginnings, want to talk about where we were, what we've done, some of the 234.46s - 239.40s | impacts that we've had. I also want to talk about the opportunities and challenges and then 239.40s - 244.40s | conclude with, hey, this is really what we need to do collectively going forward. The picture 244.82s - 250.72s | that's shown there is the National Security Operations Center. It is among the most 250.72s - 255.74s | sensitive places in the National Security Agency. We don't take visitors. It's not a stop on the 257.74s - 263.30s | hop on, hop off tour for D.C. And it's one of the places where we're able to provide 263.30s - 268.18s | indication warnings to the President, the Secretary of Defense, senior military 268.18s - 274.18s | commanders about what's happening in the world. What's going on? And if you think about it, 274.96s - 280.14s | this allows our leaders to have knowledge. They see first, they know first, and hopefully they 280.14s - 286.98s | can act first. When I took over NSA in the spring of 2018, I established a series of wake 286.98s - 292.64s | up conditions. What are wake up conditions, you ask? Wake up conditions are this idea that, 292.64s - 299.52s | hey, I want the officer on duty to call me when something happens, right? There might be 299.52s - 303.40s | Americans in danger, there might be a hostage crisis, there might be something that's going on 303.40s - 307.62s | in the world that is going to get alerted to the President and the Secretary of Defense. I 307.62s - 314.12s | always like to have that information first before my boss knows. Now, here is how the world 314.12s - 322.12s |


chunk_id: 158_chunk_5
chunk_text:
tour for D.C. And it's one of the places where we're able to provide 263.30s - 268.18s | indication warnings to the President, the Secretary of Defense, senior military 268.18s - 274.18s | commanders about what's happening in the world. What's going on? And if you think about it, 274.96s - 280.14s | this allows our leaders to have knowledge. They see first, they know first, and hopefully they 280.14s - 286.98s | can act first. When I took over NSA in the spring of 2018, I established a series of wake 286.98s - 292.64s | up conditions. What are wake up conditions, you ask? Wake up conditions are this idea that, 292.64s - 299.52s | hey, I want the officer on duty to call me when something happens, right? There might be 299.52s - 303.40s | Americans in danger, there might be a hostage crisis, there might be something that's going on 303.40s - 307.62s | in the world that is going to get alerted to the President and the Secretary of Defense. I 307.62s - 314.12s | always like to have that information first before my boss knows. Now, here is how the world 314.12s - 322.12s | has changed in the past even five years. The first year, three times I was called. Three times 323.26s - 329.26s | an entire year. My last month in the job, over ten times I was called. And it was a very 329.76s - 336.88s | interesting relationship that developed between the senior operations officer and my wife, who 336.88s - 344.87s | normally took the calls at our home. It went something like this. It's for you, it's them, 348.75s - 355.52s | good luck. So that's the world in which we live in today. The scope, scale, sophistication and 355.52s - 361.66s | speed of what we're facing is tremendously different. But if we want to understand where we 361.66s - 366.44s | are today and where we need to go, it's my belief that we have to take a look at where we've 366.44s - 372.44s | been, what shaped us, what we've experienced and what has actually occurred. Next slide, it's 374.38s - 380.38s | 2008. We find out the Russians have conducted an intrusion into our classified systems using 383.68s - 390.82s | simple USB keys. Air jumping capability with malware that allows them to


chunk_id: 158_chunk_6
chunk_text:
has changed in the past even five years. The first year, three times I was called. Three times 323.26s - 329.26s | an entire year. My last month in the job, over ten times I was called. And it was a very 329.76s - 336.88s | interesting relationship that developed between the senior operations officer and my wife, who 336.88s - 344.87s | normally took the calls at our home. It went something like this. It's for you, it's them, 348.75s - 355.52s | good luck. So that's the world in which we live in today. The scope, scale, sophistication and 355.52s - 361.66s | speed of what we're facing is tremendously different. But if we want to understand where we 361.66s - 366.44s | are today and where we need to go, it's my belief that we have to take a look at where we've 366.44s - 372.44s | been, what shaped us, what we've experienced and what has actually occurred. Next slide, it's 374.38s - 380.38s | 2008. We find out the Russians have conducted an intrusion into our classified systems using 383.68s - 390.82s | simple USB keys. Air jumping capability with malware that allows them to establish a beach 390.82s - 396.82s | head in our secret and top secret systems. From this intrusion really three things happen. First 398.66s - 406.00s | of all, really this sense that combat operations come to a stop in the theaters of war in Iraq 408.88s - 414.88s | and Afghanistan. Secondly, monopolizes the intention of the incomplete Department of Defense 414.98s - 422.33s | and the Pentagon. And thirdly, the idea is shattered within our Department of Defense that our 426.97s - 433.97s | classified systems are truly secure. Now the Pentagon's response to this is called Operation 433.97s - 441.80s | Buckshot Yankee. A farcical, maybe comical attempt, maybe what you would say is a shit show, in 441.82s - 447.82s | terms of what goes on with regards to the deployment by a foreign adversary into our classified 450.00s - 455.98s | networks. We don't understand the, we don't understand the threat, we don't understand the 455.98s - 460.50s | malware, we don't understand the technology. We have a number of different commands to come, 460.50s - 465.38s | come together, action officers that are trying to figure out what's going on, counting computers, 465.38s -


chunk_id: 158_chunk_7
chunk_text:
establish a beach 390.82s - 396.82s | head in our secret and top secret systems. From this intrusion really three things happen. First 398.66s - 406.00s | of all, really this sense that combat operations come to a stop in the theaters of war in Iraq 408.88s - 414.88s | and Afghanistan. Secondly, monopolizes the intention of the incomplete Department of Defense 414.98s - 422.33s | and the Pentagon. And thirdly, the idea is shattered within our Department of Defense that our 426.97s - 433.97s | classified systems are truly secure. Now the Pentagon's response to this is called Operation 433.97s - 441.80s | Buckshot Yankee. A farcical, maybe comical attempt, maybe what you would say is a shit show, in 441.82s - 447.82s | terms of what goes on with regards to the deployment by a foreign adversary into our classified 450.00s - 455.98s | networks. We don't understand the, we don't understand the threat, we don't understand the 455.98s - 460.50s | malware, we don't understand the technology. We have a number of different commands to come, 460.50s - 465.38s | come together, action officers that are trying to figure out what's going on, counting computers, 465.38s - 472.33s | more computers one day, less computers the next day. The idea that the infection is spreading, it 472.35s - 478.35s | is truly a mess. It's finally cleared up in the fall of 2008 when the National Security Agency is 480.23s - 486.23s | able to identify the threat, identify the vector, and then identify the way that we've got to return 487.57s - 494.51s | assurance to our classified systems. Okay, that's one intrusion. But what I would tell you from the 494.51s - 500.51s | past and why this is so important is that intrusion sets off a series of actions in our Department of 502.49s - 508.49s | Defense. Then Secretary of Defense Gates says that, hey maybe we need to think about a new command 509.35s - 515.35s | that operates in cyberspace. We'll call it U.S. Cyber Command. And we want this command to take a 516.63s - 522.63s | look at securing the nation in cyberspace, defending our networks and our data, and providing 523.91s - 531.22s | support to other military commanders. Four officers were given the job of designing and selling 533.76s - 539.76s | this concept and educating a


chunk_id: 158_chunk_8
chunk_text:
472.33s | more computers one day, less computers the next day. The idea that the infection is spreading, it 472.35s - 478.35s | is truly a mess. It's finally cleared up in the fall of 2008 when the National Security Agency is 480.23s - 486.23s | able to identify the threat, identify the vector, and then identify the way that we've got to return 487.57s - 494.51s | assurance to our classified systems. Okay, that's one intrusion. But what I would tell you from the 494.51s - 500.51s | past and why this is so important is that intrusion sets off a series of actions in our Department of 502.49s - 508.49s | Defense. Then Secretary of Defense Gates says that, hey maybe we need to think about a new command 509.35s - 515.35s | that operates in cyberspace. We'll call it U.S. Cyber Command. And we want this command to take a 516.63s - 522.63s | look at securing the nation in cyberspace, defending our networks and our data, and providing 523.91s - 531.22s | support to other military commanders. Four officers were given the job of designing and selling 533.76s - 539.76s | this concept and educating a whole slew of leaders within the Pentagon. Jen Easterly, who you'll 541.12s - 547.12s | hear about or you'll hear from later today, S.L. Davis, T.J. White, and myself. Now this is 550.68s - 556.68s | 2009. We were talking about things like, how does an email transition the internet? How do you 556.70s - 562.70s | work TCP IP? How do you take a look at hunting and penetration testing? How do you take a look at 565.60s - 571.60s | building a secure architecture? We were having this conversation, I realized, with people and 575.58s - 581.58s | senior leaders that had never turned on their computers. In fact, their assistants were printing 582.42s - 588.42s | their emails, providing them to the leaders, and the leaders would write out the response. And 589.36s - 595.36s | the assistant would send it back to the person that asked the question. So we had to think 595.36s - 601.36s | differently. Because I would share with you, sometimes new ideas in the Pentagon are not warmly 603.40s - 609.40s | greeted. Particularly when those ideas have a request for money and people. So what do we do? 612.48s -


chunk_id: 158_chunk_9
chunk_text:
whole slew of leaders within the Pentagon. Jen Easterly, who you'll 541.12s - 547.12s | hear about or you'll hear from later today, S.L. Davis, T.J. White, and myself. Now this is 550.68s - 556.68s | 2009. We were talking about things like, how does an email transition the internet? How do you 556.70s - 562.70s | work TCP IP? How do you take a look at hunting and penetration testing? How do you take a look at 565.60s - 571.60s | building a secure architecture? We were having this conversation, I realized, with people and 575.58s - 581.58s | senior leaders that had never turned on their computers. In fact, their assistants were printing 582.42s - 588.42s | their emails, providing them to the leaders, and the leaders would write out the response. And 589.36s - 595.36s | the assistant would send it back to the person that asked the question. So we had to think 595.36s - 601.36s | differently. Because I would share with you, sometimes new ideas in the Pentagon are not warmly 603.40s - 609.40s | greeted. Particularly when those ideas have a request for money and people. So what do we do? 612.48s - 619.12s | We developed a story. We talked about networks that were like neighborhoods. We talked about 619.12s - 625.12s | security in terms of the way that you put on locks and alarm systems on your house. The idea of a 627.66s - 633.66s | neighborhood watch. The idea that we had to think differently about a domain, a cyberspace, than 634.06s - 640.06s | we'd ever thought about before. And these four officers took this briefing with these type of 643.50s - 649.50s | slides to a number of different senior leaders within the Pentagon. Being able to tell that story. 651.44s - 657.44s | Being able to actually answer the questions that came up so readily. The commands approved in 658.30s - 664.30s | 2010. A new four star headquarters is established. And then over a series of years, we build a 667.48s - 674.02s | force. We build a force of hackers, we build a force of defenders, we build a force of analysts, 674.02s - 680.02s | we build a force across all our services. And our first adversary is ISIS. ISIS in the terms of 681.02s - 688.27s | being able to understand in


chunk_id: 158_chunk_10
chunk_text:
619.12s | We developed a story. We talked about networks that were like neighborhoods. We talked about 619.12s - 625.12s | security in terms of the way that you put on locks and alarm systems on your house. The idea of a 627.66s - 633.66s | neighborhood watch. The idea that we had to think differently about a domain, a cyberspace, than 634.06s - 640.06s | we'd ever thought about before. And these four officers took this briefing with these type of 643.50s - 649.50s | slides to a number of different senior leaders within the Pentagon. Being able to tell that story. 651.44s - 657.44s | Being able to actually answer the questions that came up so readily. The commands approved in 658.30s - 664.30s | 2010. A new four star headquarters is established. And then over a series of years, we build a 667.48s - 674.02s | force. We build a force of hackers, we build a force of defenders, we build a force of analysts, 674.02s - 680.02s | we build a force across all our services. And our first adversary is ISIS. ISIS in the terms of 681.02s - 688.27s | being able to understand in 2015, the fact that this terrorist organization was starting to have 691.97s - 698.85s | tremendous success in Iraq and Afghanistan, I'm sorry, in Syria and Iraq. And as they had 698.85s - 704.85s | tremendous gains across the battle space, they were also having tremendous gains in an information 705.27s - 711.27s | operational campaign that they were conducting to raise money, to recruit forces, and to 715.49s - 721.49s | proselytize. Guess what? We had tremendous challenges at cybercom. We had really no 724.59s - 730.59s | infrastructure. We had limited capabilities and we had really no authorities. And this first 730.71s - 736.71s | foray into being able to battle an adversary was not quite successful for U.S. Cyber Command. And 741.21s - 747.21s | then things changed in 2016. 2016 as the slide shows here, brought together our best warriors on the 749.89s - 756.33s | internet with our best warriors on the ground. Special operations forces were our number one 756.35s - 762.85s | calling and our number one advocate to what we were doing. Folks like Tony Thomas and Joe 762.85s - 769.65s | Votel, leaders within the special operations community said, we need


chunk_id: 158_chunk_11
chunk_text:
2015, the fact that this terrorist organization was starting to have 691.97s - 698.85s | tremendous success in Iraq and Afghanistan, I'm sorry, in Syria and Iraq. And as they had 698.85s - 704.85s | tremendous gains across the battle space, they were also having tremendous gains in an information 705.27s - 711.27s | operational campaign that they were conducting to raise money, to recruit forces, and to 715.49s - 721.49s | proselytize. Guess what? We had tremendous challenges at cybercom. We had really no 724.59s - 730.59s | infrastructure. We had limited capabilities and we had really no authorities. And this first 730.71s - 736.71s | foray into being able to battle an adversary was not quite successful for U.S. Cyber Command. And 741.21s - 747.21s | then things changed in 2016. 2016 as the slide shows here, brought together our best warriors on the 749.89s - 756.33s | internet with our best warriors on the ground. Special operations forces were our number one 756.35s - 762.85s | calling and our number one advocate to what we were doing. Folks like Tony Thomas and Joe 762.85s - 769.65s | Votel, leaders within the special operations community said, we need to have a virtual presence to 769.65s - 775.93s | battle ISIS. And that virtual presence appeared. We had an infrastructure. We started to get 775.93s - 781.93s | capabilities. We had limited authorities. And suddenly, the ability to take on ISIS became our 782.21s - 787.71s | number one goal and our number one success story. The ability for ISIS to produce high 787.71s - 793.71s | definition visuals, the ability for ISIS to set up multi-language websites, the ability for ISIS to 797.25s - 803.25s | communicate broadly was taken on and was taken down. And in fact, we matched the fires on the 804.49s - 810.49s | ground with fires on net. Now you would think after that experience, you would think, you know, 811.93s - 817.93s | in 2015 and 2016, that we would be prepared for what information operations from a determined 819.97s - 832.46s | adversary might bring to our country. The 2016 presidential election is well covered. I'm sorry, 832.46s - 841.73s | if we can go back one slide, please. Go back one slide. A number of different reports that were 841.73s - 847.87s | released in terms of what the Russians


chunk_id: 158_chunk_12
chunk_text:
to have a virtual presence to 769.65s - 775.93s | battle ISIS. And that virtual presence appeared. We had an infrastructure. We started to get 775.93s - 781.93s | capabilities. We had limited authorities. And suddenly, the ability to take on ISIS became our 782.21s - 787.71s | number one goal and our number one success story. The ability for ISIS to produce high 787.71s - 793.71s | definition visuals, the ability for ISIS to set up multi-language websites, the ability for ISIS to 797.25s - 803.25s | communicate broadly was taken on and was taken down. And in fact, we matched the fires on the 804.49s - 810.49s | ground with fires on net. Now you would think after that experience, you would think, you know, 811.93s - 817.93s | in 2015 and 2016, that we would be prepared for what information operations from a determined 819.97s - 832.46s | adversary might bring to our country. The 2016 presidential election is well covered. I'm sorry, 832.46s - 841.73s | if we can go back one slide, please. Go back one slide. A number of different reports that were 841.73s - 847.87s | released in terms of what the Russians were doing in the, in this run up to the 2016 847.87s - 854.11s | presidential election. Their equation was pretty set. It went something like this. We'll take 854.11s - 860.11s | their best intel services, the SVR, the FSB, the GRU. We'll combine them with a series of proxies, 863.11s - 869.99s | like the Internet Research Agency out of St. Petersburg, Russia. We'll be able to take a very, 869.99s - 876.99s | very honed message, feeding both sides of divisive issues and then leverage the technologies of 877.05s - 883.05s | bots and U.S. social media organizations to feed a message broadly within the United States. 885.93s - 891.93s | Here's the thing the Russians didn't plan for. The fact that we did nothing. We failed in 2016 896.57s - 902.41s | to protect our democratic processes. And so as I came to the command and the agency in 2018, 902.41s - 906.71s | there was certainly a sense, whether it was from Congress, whether it was from the White House, 906.73s - 912.21s | whether it was from the Secretary of Defense, that this election in 2018, the midterms was going to 912.21s - 918.21s


chunk_id: 158_chunk_13
chunk_text:
were doing in the, in this run up to the 2016 847.87s - 854.11s | presidential election. Their equation was pretty set. It went something like this. We'll take 854.11s - 860.11s | their best intel services, the SVR, the FSB, the GRU. We'll combine them with a series of proxies, 863.11s - 869.99s | like the Internet Research Agency out of St. Petersburg, Russia. We'll be able to take a very, 869.99s - 876.99s | very honed message, feeding both sides of divisive issues and then leverage the technologies of 877.05s - 883.05s | bots and U.S. social media organizations to feed a message broadly within the United States. 885.93s - 891.93s | Here's the thing the Russians didn't plan for. The fact that we did nothing. We failed in 2016 896.57s - 902.41s | to protect our democratic processes. And so as I came to the command and the agency in 2018, 902.41s - 906.71s | there was certainly a sense, whether it was from Congress, whether it was from the White House, 906.73s - 912.21s | whether it was from the Secretary of Defense, that this election in 2018, the midterms was going to 912.21s - 918.21s | be completely different. Here was our equation in 2018. A new organization. It's called the Russia 921.55s - 927.55s | Small Group. It was the idea of bringing the best of NSA and U.S. Cyber Command together. It was 930.62s - 936.62s | adding really capable leaders. Two leaders whose names you probably recognize. Ann Neuberger led 937.62s - 943.48s | the NSA contingent of the Russia Small Group. She's going to talk later today here at DEF CON. 943.48s - 950.22s | Tim Hawk, he led the element from U.S. Cyber Command. He's now a commander of U.S. Cyber 950.22s - 956.32s | Command. And we took it and combined these new leaders, this new organization with a new 956.32s - 962.90s | strategy. A strategy of defending forward. The idea that we're no longer going to take some type 962.96s - 970.96s | of adversary trying to interfere or influence our electoral process. And so we took the idea of hunt 970.96s - 976.56s | forward operations. Let me talk about hunt forward operations for a second. Hunt forward 976.56s - 982.56s | operations. The idea that was brought to me by a young Air Force captain


chunk_id: 158_chunk_14
chunk_text:
| be completely different. Here was our equation in 2018. A new organization. It's called the Russia 921.55s - 927.55s | Small Group. It was the idea of bringing the best of NSA and U.S. Cyber Command together. It was 930.62s - 936.62s | adding really capable leaders. Two leaders whose names you probably recognize. Ann Neuberger led 937.62s - 943.48s | the NSA contingent of the Russia Small Group. She's going to talk later today here at DEF CON. 943.48s - 950.22s | Tim Hawk, he led the element from U.S. Cyber Command. He's now a commander of U.S. Cyber 950.22s - 956.32s | Command. And we took it and combined these new leaders, this new organization with a new 956.32s - 962.90s | strategy. A strategy of defending forward. The idea that we're no longer going to take some type 962.96s - 970.96s | of adversary trying to interfere or influence our electoral process. And so we took the idea of hunt 970.96s - 976.56s | forward operations. Let me talk about hunt forward operations for a second. Hunt forward 976.56s - 982.56s | operations. The idea that was brought to me by a young Air Force captain and a young NSA analyst that 982.92s - 988.92s | said, hey general, maybe if we take a defensive team and we go to a country that invites us and we hunt 995.80s - 1001.60s | on their networks with that country, we can discover what the Russian tradecraft, their 1001.60s - 1007.60s | technology and their malware was all about. Sounds good to me. But here's the even better part of 1008.22s - 1014.22s | what they thought about. The idea of taking the malware and the tradecraft that they had seen in a 1017.66s - 1023.66s | place like Ukraine and sharing that not back with Fort Meade and the silos that exist within the 1026.94s - 1032.94s | National Security Agency and U.S. Cyber Command, but how about with VirusTotal? A cybersecurity 1033.26s - 1039.26s | consortium that suddenly is able to attribute, signature and develop many times an antidote to the 1043.30s - 1048.94s | malware that we saw and then broadcast it to the world. That's the difference, ladies and gentlemen, 1048.94s - 1054.94s | in terms of being able to defend our democracy, work with a series of partners and think 1054.94s - 1060.28s


chunk_id: 158_chunk_15
chunk_text:
and a young NSA analyst that 982.92s - 988.92s | said, hey general, maybe if we take a defensive team and we go to a country that invites us and we hunt 995.80s - 1001.60s | on their networks with that country, we can discover what the Russian tradecraft, their 1001.60s - 1007.60s | technology and their malware was all about. Sounds good to me. But here's the even better part of 1008.22s - 1014.22s | what they thought about. The idea of taking the malware and the tradecraft that they had seen in a 1017.66s - 1023.66s | place like Ukraine and sharing that not back with Fort Meade and the silos that exist within the 1026.94s - 1032.94s | National Security Agency and U.S. Cyber Command, but how about with VirusTotal? A cybersecurity 1033.26s - 1039.26s | consortium that suddenly is able to attribute, signature and develop many times an antidote to the 1043.30s - 1048.94s | malware that we saw and then broadcast it to the world. That's the difference, ladies and gentlemen, 1048.94s - 1054.94s | in terms of being able to defend our democracy, work with a series of partners and think 1054.94s - 1060.28s | differently. The 2018 elections, incredibly successful in terms of being able to deliver a safe and 1060.32s - 1066.32s | secure election. The 2020, the 2022 elections all followed a similar path. Here's why this is so 1068.10s - 1073.64s | important to the agency in command and to, I would say, what we do in terms of election security. 1073.64s - 1078.78s | First of all, it brought to the idea of where we work in government about the power of 1078.78s - 1084.78s | partnerships. It begins within our organizations internally, NSA and Cyber Command, organizations 1085.26s - 1090.76s | that need to work together. It broadly works within terms of the interagency. How do we bring in 1093.22s - 1099.24s | CISA? How do we bring in the FBI? How do we bring in other elements of our government to ensure a 1099.24s - 1104.64s | safe and secure election? And then the final piece, how do we bring the private sector? How do we 1104.64s - 1110.72s | ensure the private sector that knows so much about what's going on is able to contribute to the 1110.76s - 1116.76s | security of our democratic processes?


chunk_id: 158_chunk_16
chunk_text:
| differently. The 2018 elections, incredibly successful in terms of being able to deliver a safe and 1060.32s - 1066.32s | secure election. The 2020, the 2022 elections all followed a similar path. Here's why this is so 1068.10s - 1073.64s | important to the agency in command and to, I would say, what we do in terms of election security. 1073.64s - 1078.78s | First of all, it brought to the idea of where we work in government about the power of 1078.78s - 1084.78s | partnerships. It begins within our organizations internally, NSA and Cyber Command, organizations 1085.26s - 1090.76s | that need to work together. It broadly works within terms of the interagency. How do we bring in 1093.22s - 1099.24s | CISA? How do we bring in the FBI? How do we bring in other elements of our government to ensure a 1099.24s - 1104.64s | safe and secure election? And then the final piece, how do we bring the private sector? How do we 1104.64s - 1110.72s | ensure the private sector that knows so much about what's going on is able to contribute to the 1110.76s - 1116.76s | security of our democratic processes? Secondly, it sends a warning to Russia and China, Iran and 1121.70s - 1127.70s | North Korea that we are capable actors, the best actors, the best hackers, offensively, and the 1130.58s - 1136.58s | best defenders. No doubt, a message was sent by our action. You know, in the old days, we had a 1136.94s - 1142.94s | term for the way that we approached the defense of a lot of our networks. We called that clean-up 1147.48s - 1153.26s | on aisle nine. We'd seen our adversaries steal our intellectual property, steal our personal 1153.26s - 1161.26s | identifiable information, try to influence our elections, and the role that was left to us was 1161.62s - 1169.62s | to clean that all up. After 2018, that stops. And the idea of being able to defend forward, 1169.62s - 1175.66s | persistently engage with your adversaries, bring a series of partners, comes to the fruition. 1175.66s - 1181.74s | Okay. 2018 midterm elections is incredibly important in terms of our development as a force. 1181.74s - 1187.74s | Let me share with you a story that perhaps is not as well known. Who will forget COVID-19? So it's 1191.28s


chunk_id: 158_chunk_17
chunk_text:
Secondly, it sends a warning to Russia and China, Iran and 1121.70s - 1127.70s | North Korea that we are capable actors, the best actors, the best hackers, offensively, and the 1130.58s - 1136.58s | best defenders. No doubt, a message was sent by our action. You know, in the old days, we had a 1136.94s - 1142.94s | term for the way that we approached the defense of a lot of our networks. We called that clean-up 1147.48s - 1153.26s | on aisle nine. We'd seen our adversaries steal our intellectual property, steal our personal 1153.26s - 1161.26s | identifiable information, try to influence our elections, and the role that was left to us was 1161.62s - 1169.62s | to clean that all up. After 2018, that stops. And the idea of being able to defend forward, 1169.62s - 1175.66s | persistently engage with your adversaries, bring a series of partners, comes to the fruition. 1175.66s - 1181.74s | Okay. 2018 midterm elections is incredibly important in terms of our development as a force. 1181.74s - 1187.74s | Let me share with you a story that perhaps is not as well known. Who will forget COVID-19? So it's 1191.28s - 1197.28s | the spring of 2020, and all of us are starting to grasp this idea of a global pandemic. I think many 1200.62s - 1206.36s | of you remember, you know, the challenges of finding hand sanitizer or looking for personal 1206.36s - 1212.94s | protective equipment or understanding really where this pandemic was going as so many of our 1212.94s - 1220.94s | countrymen were becoming sick and many losing their lives. In the spring of 2020, the Secretary of 1220.96s - 1225.26s | Health and Human Services and the Secretary of the Department of Defense came together and said, 1225.26s - 1231.26s | we need to develop a vaccine. A vaccine that can be designed, tested, and deployed not in years, 1234.14s - 1240.14s | but in months. And this idea became known as Operation Warp Speed. Now the part of the story 1243.24s - 1248.88s | that involves the National Security Agency and U.S. Cyber Command is the fact that the Secretary 1248.92s - 1254.92s | of Defense came to me and said, Paul, I want to make sure as this vaccine is developed by Health and 1256.80s - 1262.80s | Human Services and a


chunk_id: 158_chunk_18
chunk_text:
- 1197.28s | the spring of 2020, and all of us are starting to grasp this idea of a global pandemic. I think many 1200.62s - 1206.36s | of you remember, you know, the challenges of finding hand sanitizer or looking for personal 1206.36s - 1212.94s | protective equipment or understanding really where this pandemic was going as so many of our 1212.94s - 1220.94s | countrymen were becoming sick and many losing their lives. In the spring of 2020, the Secretary of 1220.96s - 1225.26s | Health and Human Services and the Secretary of the Department of Defense came together and said, 1225.26s - 1231.26s | we need to develop a vaccine. A vaccine that can be designed, tested, and deployed not in years, 1234.14s - 1240.14s | but in months. And this idea became known as Operation Warp Speed. Now the part of the story 1243.24s - 1248.88s | that involves the National Security Agency and U.S. Cyber Command is the fact that the Secretary 1248.92s - 1254.92s | of Defense came to me and said, Paul, I want to make sure as this vaccine is developed by Health and 1256.80s - 1262.80s | Human Services and a series of private sector companies that we protect the design phase, the test 1265.04s - 1273.04s | phase, and the detection phase. Let me be honest with all of you. When I took over as the Director of 1273.04s - 1278.28s | the National Security Agency and Commander of U.S. Cyber Command, I don't remember the part of the 1278.28s - 1286.28s | instruction about global pandemic. And I don't remember the part of the instruction about working 1286.28s - 1292.26s | with a series of partners that were broader than perhaps the Secretary of Defense's remit and the 1292.26s - 1300.26s | Defense Industrial Base. But this is where the power of what we do comes together. Because here's 1301.50s - 1308.00s | what we did. First of all, take what is our platform at the National Security Agency and garner 1308.72s - 1312.36s | as much foreign intelligence as possible. What are the Chinese and what are the Russians doing? How are 1312.36s - 1317.80s | they planning for what they want to do? What is their tradecraft as they look at the development of a 1317.80s - 1325.80s | vaccine within the United States? Secondly, let's have


chunk_id: 158_chunk_19
chunk_text:
series of private sector companies that we protect the design phase, the test 1265.04s - 1273.04s | phase, and the detection phase. Let me be honest with all of you. When I took over as the Director of 1273.04s - 1278.28s | the National Security Agency and Commander of U.S. Cyber Command, I don't remember the part of the 1278.28s - 1286.28s | instruction about global pandemic. And I don't remember the part of the instruction about working 1286.28s - 1292.26s | with a series of partners that were broader than perhaps the Secretary of Defense's remit and the 1292.26s - 1300.26s | Defense Industrial Base. But this is where the power of what we do comes together. Because here's 1301.50s - 1308.00s | what we did. First of all, take what is our platform at the National Security Agency and garner 1308.72s - 1312.36s | as much foreign intelligence as possible. What are the Chinese and what are the Russians doing? How are 1312.36s - 1317.80s | they planning for what they want to do? What is their tradecraft as they look at the development of a 1317.80s - 1325.80s | vaccine within the United States? Secondly, let's have a hostage exchange. A hostage exchange taking our 1326.98s - 1332.98s | best people and putting them in places like Health and Human Services or pharmaceutical companies to 1333.00s - 1338.84s | understand how do you actually develop a vaccine? What's your network look like? How do you test it? 1338.84s - 1347.22s | What's the assurance that you have as this vaccine is developed? And the final piece is how do you 1347.22s - 1355.24s | coordinate all of this seamlessly to make sure that what is being done is being done based upon what 1355.24s - 1362.74s | we're seeing our threat do? And this was the work of Ann Neuberger, who is the Director of Cyber 1362.76s - 1368.46s | Security for the National Security Agency. Persistent in her approach, being able to bring together 1368.46s - 1372.84s | partners, being able to understand that there are truly vulnerabilities in a number of our government 1372.84s - 1380.04s | networks that had to be patched. It wasn't perfect, but I will tell you that we were persistent about it. 1381.14s - 1386.72s | And we reached out to a series of partners that we had never dealt


chunk_id: 158_chunk_20
chunk_text:
a hostage exchange. A hostage exchange taking our 1326.98s - 1332.98s | best people and putting them in places like Health and Human Services or pharmaceutical companies to 1333.00s - 1338.84s | understand how do you actually develop a vaccine? What's your network look like? How do you test it? 1338.84s - 1347.22s | What's the assurance that you have as this vaccine is developed? And the final piece is how do you 1347.22s - 1355.24s | coordinate all of this seamlessly to make sure that what is being done is being done based upon what 1355.24s - 1362.74s | we're seeing our threat do? And this was the work of Ann Neuberger, who is the Director of Cyber 1362.76s - 1368.46s | Security for the National Security Agency. Persistent in her approach, being able to bring together 1368.46s - 1372.84s | partners, being able to understand that there are truly vulnerabilities in a number of our government 1372.84s - 1380.04s | networks that had to be patched. It wasn't perfect, but I will tell you that we were persistent about it. 1381.14s - 1386.72s | And we reached out to a series of partners that we had never dealt with before. And what was the 1386.72s - 1394.14s | result? A vaccine that was delivered in record time, two weeks before the date in December of 2020. 1396.27s - 1405.99s | Secondly, the safe development, testing and distribution of 300 million doses of a vaccine that 1405.99s - 1412.85s | addressed COVID-19. And finally, and most importantly, to the work of those pharmaceutical 1412.85s - 1420.61s | companies, to Health and Human Services, and to our agency in command, the realization that that 1420.61s - 1428.93s | vaccine saved thousands and thousands of lives. That's the work of bringing together what our 1428.93s - 1437.65s | government does best, and what the private sector does well as well. So this was really kind of the 1437.65s - 1443.33s | end of 2020. And it was a busy year. And we were thinking that everything was really good as we had a 1443.33s - 1448.13s | safe and secure election, as we were dealing with a number of adversaries in cyberspace, as we were 1448.13s - 1457.69s | able to develop a vaccine, until an unannounced visitor comes to the National Security Agency the 1457.69s - 1467.05s | Tuesday before


chunk_id: 158_chunk_21
chunk_text:
with before. And what was the 1386.72s - 1394.14s | result? A vaccine that was delivered in record time, two weeks before the date in December of 2020. 1396.27s - 1405.99s | Secondly, the safe development, testing and distribution of 300 million doses of a vaccine that 1405.99s - 1412.85s | addressed COVID-19. And finally, and most importantly, to the work of those pharmaceutical 1412.85s - 1420.61s | companies, to Health and Human Services, and to our agency in command, the realization that that 1420.61s - 1428.93s | vaccine saved thousands and thousands of lives. That's the work of bringing together what our 1428.93s - 1437.65s | government does best, and what the private sector does well as well. So this was really kind of the 1437.65s - 1443.33s | end of 2020. And it was a busy year. And we were thinking that everything was really good as we had a 1443.33s - 1448.13s | safe and secure election, as we were dealing with a number of adversaries in cyberspace, as we were 1448.13s - 1457.69s | able to develop a vaccine, until an unannounced visitor comes to the National Security Agency the 1457.69s - 1467.05s | Tuesday before Thanksgiving 2020. Any time that Kevin Mandia comes to the National Security 1467.05s - 1474.33s | Agency unannounced, I get nervous. I would tell you, though, that Kevin came to talk about something he 1474.33s - 1480.73s | was incredibly nervous about, the Russians within his network. He had started to see a series of 1480.73s - 1486.81s | patterns within Mandia that concerned him. As he came to NSA and talked about it, we were able to 1486.81s - 1491.45s | confirm some of the things that we were seeing as well. This became known as SolarWinds. Many of you 1491.45s - 1497.25s | recall this. The supply chain attack by the SVR within Russia against a number of different 1497.25s - 1504.05s | companies within the United States. Hey, what was unique about this? What was unique about this is 1504.05s - 1512.57s | the fact that we have an adversary that understands our authorities and laws almost as well as we do. 1513.57s - 1520.73s | As they bought a series of VPSs within the United States, brought them up, conducted their operations 1520.73s - 1528.69s | and took them down before we could ever get a


chunk_id: 158_chunk_22
chunk_text:
Thanksgiving 2020. Any time that Kevin Mandia comes to the National Security 1467.05s - 1474.33s | Agency unannounced, I get nervous. I would tell you, though, that Kevin came to talk about something he 1474.33s - 1480.73s | was incredibly nervous about, the Russians within his network. He had started to see a series of 1480.73s - 1486.81s | patterns within Mandia that concerned him. As he came to NSA and talked about it, we were able to 1486.81s - 1491.45s | confirm some of the things that we were seeing as well. This became known as SolarWinds. Many of you 1491.45s - 1497.25s | recall this. The supply chain attack by the SVR within Russia against a number of different 1497.25s - 1504.05s | companies within the United States. Hey, what was unique about this? What was unique about this is 1504.05s - 1512.57s | the fact that we have an adversary that understands our authorities and laws almost as well as we do. 1513.57s - 1520.73s | As they bought a series of VPSs within the United States, brought them up, conducted their operations 1520.73s - 1528.69s | and took them down before we could ever get a warrant. The idea of not only being able to impact tens 1528.69s - 1536.05s | or hundreds, but 18,000 different victims with a supply chain attack. That means the Defense 1536.05s - 1541.05s | Industrial Base. That means Microsoft. That means Deloitte. That means Cisco. That means the Health 1541.05s - 1550.89s | and Human Services Treasury Department of State. An incredibly powerful intrusion that was 1550.89s - 1556.09s | discovered, first of all, by Mandia, confirmed by our agency, and then dealt with by the private 1556.09s - 1563.73s | sector. But if that was just one intrusion in 2020-21, I would have been happy. But that was 1563.73s - 1571.53s | quickly followed by Microsoft Hafnium in March. And then who'll forget Colonial Pipeline? 43% of 1571.53s - 1579.34s | the petroleum products that flow through the East Coast flow through Colonial Pipeline. And then, of 1579.34s - 1583.78s | course, as we think about the summer, a series of different ransomware attacks that were conducted by 1584.42s - 1592.98s | adversaries and criminals against JBS, among the largest food purveyors in the United States. So 1592.98s - 1599.50s | think about this. In six months, from the


chunk_id: 158_chunk_23
chunk_text:
warrant. The idea of not only being able to impact tens 1528.69s - 1536.05s | or hundreds, but 18,000 different victims with a supply chain attack. That means the Defense 1536.05s - 1541.05s | Industrial Base. That means Microsoft. That means Deloitte. That means Cisco. That means the Health 1541.05s - 1550.89s | and Human Services Treasury Department of State. An incredibly powerful intrusion that was 1550.89s - 1556.09s | discovered, first of all, by Mandia, confirmed by our agency, and then dealt with by the private 1556.09s - 1563.73s | sector. But if that was just one intrusion in 2020-21, I would have been happy. But that was 1563.73s - 1571.53s | quickly followed by Microsoft Hafnium in March. And then who'll forget Colonial Pipeline? 43% of 1571.53s - 1579.34s | the petroleum products that flow through the East Coast flow through Colonial Pipeline. And then, of 1579.34s - 1583.78s | course, as we think about the summer, a series of different ransomware attacks that were conducted by 1584.42s - 1592.98s | adversaries and criminals against JBS, among the largest food purveyors in the United States. So 1592.98s - 1599.50s | think about this. In six months, from the time Kevin Mandia comes on our doorstep at NSA to really the 1599.50s - 1607.86s | end of it, we've seen supply chain. We've seen zero day. We've seen ransomware. So what's our 1607.86s - 1613.38s | playbook at the agency in command? Here's our playbook. Our playbook begins with intelligence. 1613.58s - 1618.54s | It's being able to take what we do so well in terms of our foreign intelligence and be able to apply it to what 1618.54s - 1625.14s | is going on. Secondly, it has always been my posture that when you're in a difficult time and not 1625.14s - 1631.70s | understanding what your adversaries are doing, unleash your hackers. We unleash the hackers of NSA 1631.70s - 1640.54s | and Cyber Command to understand exactly what Russia or China or a series of criminals are trying to do in 1640.54s - 1649.18s | terms of zero days, ransomware, or supply chain. The third part is bring a series of new partners 1649.18s - 1657.62s | together. So bring the partners within the interagency. Bring FBI and DHS to the party. Bring also this idea of 1657.62s - 1663.74s | your international partners. So whether


chunk_id: 158_chunk_24
chunk_text:
time Kevin Mandia comes on our doorstep at NSA to really the 1599.50s - 1607.86s | end of it, we've seen supply chain. We've seen zero day. We've seen ransomware. So what's our 1607.86s - 1613.38s | playbook at the agency in command? Here's our playbook. Our playbook begins with intelligence. 1613.58s - 1618.54s | It's being able to take what we do so well in terms of our foreign intelligence and be able to apply it to what 1618.54s - 1625.14s | is going on. Secondly, it has always been my posture that when you're in a difficult time and not 1625.14s - 1631.70s | understanding what your adversaries are doing, unleash your hackers. We unleash the hackers of NSA 1631.70s - 1640.54s | and Cyber Command to understand exactly what Russia or China or a series of criminals are trying to do in 1640.54s - 1649.18s | terms of zero days, ransomware, or supply chain. The third part is bring a series of new partners 1649.18s - 1657.62s | together. So bring the partners within the interagency. Bring FBI and DHS to the party. Bring also this idea of 1657.62s - 1663.74s | your international partners. So whether or not it's the Five Eyes, the English-speaking countries of the world, 1663.74s - 1672.10s | that's the U.S., U.K., Canada, New Zealand, and Australia, or a series of broader partners. Whether or not it's 1672.10s - 1678.22s | countries within the Indo-Pacific region that understands China well, or whether or not it's countries within Europe 1678.22s - 1685.14s | that understands Russia well, the more the merrier. And then finally, bring the private sector and have this 1685.14s - 1693.02s | discussion. The way that we were able to get after SolarWinds was the fact that we had a very, very brave and 1693.02s - 1699.90s | forward-thinking CEO in Kevin Mandia coming to us to be able to understand what was going on and then being able to 1699.90s - 1710.13s | talk about it publicly. So what's my assessment? Where are we at with all of this with regards to ransomware and 1710.13s - 1717.97s | criminal attacks? Our attribution is much better. Our partnership is growing. Our intelligence is really good. But I 1717.97s - 1727.05s | would tell you bottom line is, we're not keeping up. We are not keeping up. We need a new


chunk_id: 158_chunk_25
chunk_text:
or not it's the Five Eyes, the English-speaking countries of the world, 1663.74s - 1672.10s | that's the U.S., U.K., Canada, New Zealand, and Australia, or a series of broader partners. Whether or not it's 1672.10s - 1678.22s | countries within the Indo-Pacific region that understands China well, or whether or not it's countries within Europe 1678.22s - 1685.14s | that understands Russia well, the more the merrier. And then finally, bring the private sector and have this 1685.14s - 1693.02s | discussion. The way that we were able to get after SolarWinds was the fact that we had a very, very brave and 1693.02s - 1699.90s | forward-thinking CEO in Kevin Mandia coming to us to be able to understand what was going on and then being able to 1699.90s - 1710.13s | talk about it publicly. So what's my assessment? Where are we at with all of this with regards to ransomware and 1710.13s - 1717.97s | criminal attacks? Our attribution is much better. Our partnership is growing. Our intelligence is really good. But I 1717.97s - 1727.05s | would tell you bottom line is, we're not keeping up. We are not keeping up. We need a new strategy. We need increased 1727.05s - 1735.69s | pressures on countries like Russia that allow hackers to conduct criminal attacks into different countries within the 1735.69s - 1745.37s | world. And we need some new and innovative ideas to be able to address the profit motive and the profitability of what 1745.37s - 1752.25s | these criminals are doing. So if that was all it was with regards to what's going on in cyberspace, that would be one 1752.25s - 1760.17s | thing. But this has been followed over the past year by even greater concerns that I have with regards to the state of our 1760.17s - 1769.29s | cybersecurity. Many have heard that in March and May of 2020, 2023, the National Security Agency, FBI, DHS, and CISA 1769.45s - 1779.19s | released a report about pre-positioning in our critical infrastructure and key resources. Pre-positioning by an actor that's 1779.19s - 1789.95s | named Volt Typhoon that's tied to the Chinese government. The idea that this actor is living off the land. Living off the land. 1789.95s - 1797.63s | The idea of being able to not have any signatures, not have any known indicators, but be able


chunk_id: 158_chunk_26
chunk_text:
strategy. We need increased 1727.05s - 1735.69s | pressures on countries like Russia that allow hackers to conduct criminal attacks into different countries within the 1735.69s - 1745.37s | world. And we need some new and innovative ideas to be able to address the profit motive and the profitability of what 1745.37s - 1752.25s | these criminals are doing. So if that was all it was with regards to what's going on in cyberspace, that would be one 1752.25s - 1760.17s | thing. But this has been followed over the past year by even greater concerns that I have with regards to the state of our 1760.17s - 1769.29s | cybersecurity. Many have heard that in March and May of 2020, 2023, the National Security Agency, FBI, DHS, and CISA 1769.45s - 1779.19s | released a report about pre-positioning in our critical infrastructure and key resources. Pre-positioning by an actor that's 1779.19s - 1789.95s | named Volt Typhoon that's tied to the Chinese government. The idea that this actor is living off the land. Living off the land. 1789.95s - 1797.63s | The idea of being able to not have any signatures, not have any known indicators, but be able to take the resources that are 1797.63s - 1806.71s | available at their disposal at the place and time of their choosing to create havoc within our critical infrastructure. And 1806.71s - 1813.47s | whether or not that critical infrastructure is in the Pacific, whether or not the critical infrastructure is in the United States, the 1813.47s - 1824.19s | intent here is an intent not to gather intelligence. It's an intent to cause havoc within our country in a time and place of our 1824.19s - 1837.03s | adversaries choosing. The bad news is we have Volt Typhoon within our critical infrastructure. The good news is we found them. And so now 1837.03s - 1847.27s | that we found them, what do we have to do? The first thing is we need to make sure that we talk about this publicly all the time. China 1847.27s - 1861.76s | needs to own this type of behavior. We need to point it out. We need to make sure that a spotlight is shined on this at all times. Secondly, we need 1861.76s - 1871.36s | to discuss with a series of nations this idea of a diplomatic approach to saying


chunk_id: 158_chunk_27
chunk_text:
to take the resources that are 1797.63s - 1806.71s | available at their disposal at the place and time of their choosing to create havoc within our critical infrastructure. And 1806.71s - 1813.47s | whether or not that critical infrastructure is in the Pacific, whether or not the critical infrastructure is in the United States, the 1813.47s - 1824.19s | intent here is an intent not to gather intelligence. It's an intent to cause havoc within our country in a time and place of our 1824.19s - 1837.03s | adversaries choosing. The bad news is we have Volt Typhoon within our critical infrastructure. The good news is we found them. And so now 1837.03s - 1847.27s | that we found them, what do we have to do? The first thing is we need to make sure that we talk about this publicly all the time. China 1847.27s - 1861.76s | needs to own this type of behavior. We need to point it out. We need to make sure that a spotlight is shined on this at all times. Secondly, we need 1861.76s - 1871.36s | to discuss with a series of nations this idea of a diplomatic approach to saying that our critical infrastructure is off limits. No 1871.36s - 1882.64s | prepositioning and targets that are aimed at our civilian populations. Thirdly, after decades, after decades of spending tremendous amounts of 1882.64s - 1895.16s | money, tremendous amounts of time, exhortations with regards to the state of cybersecurity, we're still not there. Our patching is still lacking. Our 1895.16s - 1907.04s | cybersecurity levels are incredibly low. And so today at DEF CON 32, I encourage all of you, take a look at the AI cyber challenge that DARPA has 1907.04s - 1920.02s | presented. Take a look at Northgate and the idea of being able to bring a series of ideas to bring scope and scale to the problem of cybersecurity. And 1920.02s - 1929.50s | finally, we need a larger force. We need a larger force that's able to address a series of nation state actors or a series of criminals that are conducting this. 1929.50s - 1938.06s | And whether or not that's being able to bring a larger force with greater partners, a larger force with technology, or a larger force with a broader private 1938.06s - 1950.45s | sector, we need it. So change


chunk_id: 158_chunk_28
chunk_text:
that our critical infrastructure is off limits. No 1871.36s - 1882.64s | prepositioning and targets that are aimed at our civilian populations. Thirdly, after decades, after decades of spending tremendous amounts of 1882.64s - 1895.16s | money, tremendous amounts of time, exhortations with regards to the state of cybersecurity, we're still not there. Our patching is still lacking. Our 1895.16s - 1907.04s | cybersecurity levels are incredibly low. And so today at DEF CON 32, I encourage all of you, take a look at the AI cyber challenge that DARPA has 1907.04s - 1920.02s | presented. Take a look at Northgate and the idea of being able to bring a series of ideas to bring scope and scale to the problem of cybersecurity. And 1920.02s - 1929.50s | finally, we need a larger force. We need a larger force that's able to address a series of nation state actors or a series of criminals that are conducting this. 1929.50s - 1938.06s | And whether or not that's being able to bring a larger force with greater partners, a larger force with technology, or a larger force with a broader private 1938.06s - 1950.45s | sector, we need it. So change is also imprinting not only what's going on in cybersecurity, but I will also tell you the character of warfare and our 1950.45s - 1959.93s | national security. What do I mean by the character of warfare? This character of warfare is the idea of how nations be able to organize or equip or conduct 1959.93s - 1973.93s | operations during wartime. And today, it's being done largely within the digital domain. I show here, the Magura V5, a fascinating approach that the 1973.93s - 1988.97s | Ukrainians have taken towards battling the Russian Black Sea Fleet. You know, when the Russians invaded Ukraine in February of 2022, the Ukrainian Navy had no 1988.97s - 2002.45s | ships. Yet, in a little over two years, the Ukrainian Navy, utilizing a series of approaches that bring their hackers together, that bring their industrial 2002.53s - 2014.81s | private sector partners together, that brings technology together, have developed platforms like these that have sunk over a third of the Russian Black Sea Fleet. That's $500 million 2014.81s - 2032.71s | in damages. What does one of those platforms cost? $250,000. That's it. And guess what? An operator utilizes a simple laptop with


chunk_id: 158_chunk_29
chunk_text:
is also imprinting not only what's going on in cybersecurity, but I will also tell you the character of warfare and our 1950.45s - 1959.93s | national security. What do I mean by the character of warfare? This character of warfare is the idea of how nations be able to organize or equip or conduct 1959.93s - 1973.93s | operations during wartime. And today, it's being done largely within the digital domain. I show here, the Magura V5, a fascinating approach that the 1973.93s - 1988.97s | Ukrainians have taken towards battling the Russian Black Sea Fleet. You know, when the Russians invaded Ukraine in February of 2022, the Ukrainian Navy had no 1988.97s - 2002.45s | ships. Yet, in a little over two years, the Ukrainian Navy, utilizing a series of approaches that bring their hackers together, that bring their industrial 2002.53s - 2014.81s | private sector partners together, that brings technology together, have developed platforms like these that have sunk over a third of the Russian Black Sea Fleet. That's $500 million 2014.81s - 2032.71s | in damages. What does one of those platforms cost? $250,000. That's it. And guess what? An operator utilizes a simple laptop with a Starlink connection that 2032.71s - 2047.39s | allows that platform to approach 40 miles an hour, travel about 400 kilometers, and deliver a lethal impact of 700 to 800 pounds of explosive. Ladies and 2047.39s - 2058.11s | gentlemen, that's the future of warfare. That's the changing character of warfare that's playing together and playing before our eyes right now. I would tell you much as the 2058.11s - 2070.99s | book in the 1990s said, it's not the big that eat the small, it's the fast that eat the slow. And this is the fast eating the slow. Hey, but there's been a bigger 2070.99s - 2080.63s | picture. It's not only just the changing character of warfare, it's the changing nature of our national security. Think about the national security, how it's 2080.63s - 2095.33s | changed over the past five years. We've dealt with a global pandemic. We've dealt with cybersecurity, we've dealt with terrorism, we've dealt with fentanyl. And guess 2095.33s - 2112.81s | what? The idea of two broad oceans and two friendly neighbors protecting our country doesn't hold up to this type of broader change in character of what's coming at us. So


chunk_id: 158_chunk_30
chunk_text:
a Starlink connection that 2032.71s - 2047.39s | allows that platform to approach 40 miles an hour, travel about 400 kilometers, and deliver a lethal impact of 700 to 800 pounds of explosive. Ladies and 2047.39s - 2058.11s | gentlemen, that's the future of warfare. That's the changing character of warfare that's playing together and playing before our eyes right now. I would tell you much as the 2058.11s - 2070.99s | book in the 1990s said, it's not the big that eat the small, it's the fast that eat the slow. And this is the fast eating the slow. Hey, but there's been a bigger 2070.99s - 2080.63s | picture. It's not only just the changing character of warfare, it's the changing nature of our national security. Think about the national security, how it's 2080.63s - 2095.33s | changed over the past five years. We've dealt with a global pandemic. We've dealt with cybersecurity, we've dealt with terrorism, we've dealt with fentanyl. And guess 2095.33s - 2112.81s | what? The idea of two broad oceans and two friendly neighbors protecting our country doesn't hold up to this type of broader change in character of what's coming at us. So this idea of 2112.81s - 2120.65s | national security has changed. The idea of being one power in the world is being replaced by many powers in the world. The rising importance of China, both 2120.65s - 2131.93s | diplomatically, informationally, militarily, and economically is playing out. You know, I entered the service when there was really a binary approach to what we did. A binary approach of either 2131.93s - 2152.57s | you're at peace, or you're at war. Today, we're in a real stat of aggressive competition, competition within our information sphere, our economic sphere, crisis, or conflict. It's our job to ensure that we 2152.57s - 2184.59s | maintain this idea of aggressive competition, that we ensure that we were able to mitigate the crises that appear and deter the conflicts that are in the future. So what do we need to do? What goes on in terms of being able to approach this? First of all, I would tell you that there are three things that we should be thinking about. First of all, new strategies and new ideas. In the fall of 2021, the United States government released a number of 2184.59s - 2214.43s |


chunk_id: 158_chunk_31
chunk_text:
this idea of 2112.81s - 2120.65s | national security has changed. The idea of being one power in the world is being replaced by many powers in the world. The rising importance of China, both 2120.65s - 2131.93s | diplomatically, informationally, militarily, and economically is playing out. You know, I entered the service when there was really a binary approach to what we did. A binary approach of either 2131.93s - 2152.57s | you're at peace, or you're at war. Today, we're in a real stat of aggressive competition, competition within our information sphere, our economic sphere, crisis, or conflict. It's our job to ensure that we 2152.57s - 2184.59s | maintain this idea of aggressive competition, that we ensure that we were able to mitigate the crises that appear and deter the conflicts that are in the future. So what do we need to do? What goes on in terms of being able to approach this? First of all, I would tell you that there are three things that we should be thinking about. First of all, new strategies and new ideas. In the fall of 2021, the United States government released a number of 2184.59s - 2214.43s | sensitive reports about Russia, what it was going to do in Ukraine. Guess where a lot of those reports came from? Can you imagine being Dernza and having those discussions with a series of Russian analysts that have spent decades of their life collecting this information, and you say something like this? Hey, you know that information that we've been collecting for decades about Russia, some of the most sensitive information that we have? We're 2214.43s - 2244.15s | going to go ahead and release that to the world. Yeah, it was kind of like this, a complete silence. But if you think about it, if we're able to do that, if we take our competitive advantage, which is our intelligence, and if we can protect our sources and methods, if we do it in a manner that builds a coalition, disrupts an adversary like Russia, and enables a partner like the Ukrainians, that sounds like 2244.15s - 2275.76s | it's in our national interest. Why wouldn't we do that? And this is the broader approach, I would tell you. And one of the things I'm most proud of about the National Security Agency is taking a look at how


chunk_id: 158_chunk_32
chunk_text:
sensitive reports about Russia, what it was going to do in Ukraine. Guess where a lot of those reports came from? Can you imagine being Dernza and having those discussions with a series of Russian analysts that have spent decades of their life collecting this information, and you say something like this? Hey, you know that information that we've been collecting for decades about Russia, some of the most sensitive information that we have? We're 2214.43s - 2244.15s | going to go ahead and release that to the world. Yeah, it was kind of like this, a complete silence. But if you think about it, if we're able to do that, if we take our competitive advantage, which is our intelligence, and if we can protect our sources and methods, if we do it in a manner that builds a coalition, disrupts an adversary like Russia, and enables a partner like the Ukrainians, that sounds like 2244.15s - 2275.76s | it's in our national interest. Why wouldn't we do that? And this is the broader approach, I would tell you. And one of the things I'm most proud of about the National Security Agency is taking a look at how do we do things more transparently? Many of you have seen the tool Ghidra that we released in 2019. Can you imagine the conversation we had about releasing Ghidra in 2019? Yeah, it was fascinating. But it's also been followed up by initiatives like the Cybersecurity Collaboration Center, this 2275.76s - 2305.72s | idea that, hey, within the NSA, we should not only get but give from the private sector. How do we work with over 2000 partners in the defense industrial base and provide them information, and also gather information from them about what's going on? I call that this idea of almost a canary in the coal mine. This is the spirit of new ideas and new approaches that we need given the changing environment of national security. Here's a second 2305.76s - 2339.96s | thing that we need. We need unique partnerships. Unique partnerships, partnerships that consider ransomware, partnerships that consider Chinese prepositioning within our critical infrastructure, partnerships that are able to get after the increasingly challenged difficulty of dealing with ransomware. You know, this idea of unique partnerships, this idea of unique partnerships, it's not only that we have to keep up with the threat, we've


chunk_id: 158_chunk_33
chunk_text:
do we do things more transparently? Many of you have seen the tool Ghidra that we released in 2019. Can you imagine the conversation we had about releasing Ghidra in 2019? Yeah, it was fascinating. But it's also been followed up by initiatives like the Cybersecurity Collaboration Center, this 2275.76s - 2305.72s | idea that, hey, within the NSA, we should not only get but give from the private sector. How do we work with over 2000 partners in the defense industrial base and provide them information, and also gather information from them about what's going on? I call that this idea of almost a canary in the coal mine. This is the spirit of new ideas and new approaches that we need given the changing environment of national security. Here's a second 2305.76s - 2339.96s | thing that we need. We need unique partnerships. Unique partnerships, partnerships that consider ransomware, partnerships that consider Chinese prepositioning within our critical infrastructure, partnerships that are able to get after the increasingly challenged difficulty of dealing with ransomware. You know, this idea of unique partnerships, this idea of unique partnerships, it's not only that we have to keep up with the threat, we've got to be ahead 2339.96s - 2371.61s | of the threat. And we need greater partnerships between what we do in the government and what many of you do as you do your own operations. You are the experts that operate in gray space. You are the ones that first see things that are unique. For someone who is at the Pentagon on 9-11, the thing that I take most from that experience is the fact that if you see something, say something. So we need all of you working 2371.61s - 2401.57s | with organizations like the Cyber National Mission Force, a unit I once commanded, under advisement, their program to be able to understand what's going on in the private sector. Or it's working with CISA, an ability to share this information. We need this. We need your assistance. We need your expertise. We need to understand what's going on as well. And then finally, we need to maintain the trust and confidence. One of the 2401.57s - 2432.39s | key lessons that I took as the Director of the National Security Agency was maintaining the trust and confidence of what we do with the American people. Incredible


chunk_id: 158_chunk_34
chunk_text:
got to be ahead 2339.96s - 2371.61s | of the threat. And we need greater partnerships between what we do in the government and what many of you do as you do your own operations. You are the experts that operate in gray space. You are the ones that first see things that are unique. For someone who is at the Pentagon on 9-11, the thing that I take most from that experience is the fact that if you see something, say something. So we need all of you working 2371.61s - 2401.57s | with organizations like the Cyber National Mission Force, a unit I once commanded, under advisement, their program to be able to understand what's going on in the private sector. Or it's working with CISA, an ability to share this information. We need this. We need your assistance. We need your expertise. We need to understand what's going on as well. And then finally, we need to maintain the trust and confidence. One of the 2401.57s - 2432.39s | key lessons that I took as the Director of the National Security Agency was maintaining the trust and confidence of what we do with the American people. Incredible authorities, incredible surveillance capabilities that are provided to the National Security Agency. I'm a private citizen who believes strongly, just as I did when I was the Director of the National Security Agency, that oversight is a must. That scrutiny is good. That we should always understand what our intelligence community is doing. 2434.39s - 2455.25s | But I would also tell you that we will not be transparent all that we can do. We just cannot do that. The adversaries that we have faced today, whether or not it's Russia, China, Iran, or North Korea, require us an ability to understand what they're doing and protect that information. 2455.25s - 2485.09s | You know, one of the things that I would tell you that after six months being retired, I do think a lot about the things that perhaps I should have done, both being Commander and Director. One of the things that I am certain I should have done is come and address DEF CON as the Acting Commander. Much in the same way DT talked today about building a community, this is a community that we need to build. 2485.73s - 2496.93s | And so it's my


chunk_id: 158_chunk_35
chunk_text:
authorities, incredible surveillance capabilities that are provided to the National Security Agency. I'm a private citizen who believes strongly, just as I did when I was the Director of the National Security Agency, that oversight is a must. That scrutiny is good. That we should always understand what our intelligence community is doing. 2434.39s - 2455.25s | But I would also tell you that we will not be transparent all that we can do. We just cannot do that. The adversaries that we have faced today, whether or not it's Russia, China, Iran, or North Korea, require us an ability to understand what they're doing and protect that information. 2455.25s - 2485.09s | You know, one of the things that I would tell you that after six months being retired, I do think a lot about the things that perhaps I should have done, both being Commander and Director. One of the things that I am certain I should have done is come and address DEF CON as the Acting Commander. Much in the same way DT talked today about building a community, this is a community that we need to build. 2485.73s - 2496.93s | And so it's my hope that future Dernses and Commanders will make sure that their speaking tour is stopping here at Vegas, at DEF CON 33, and beyond. 2499.51s - 2511.40s | So as I got ready to retire, I had a lot of options. And I would tell you the number one option that I wanted to do was to be able to give back. 2511.88s - 2527.44s | And so I'm now the Founding Director of the Institution of National Security at Vanderbilt University. In 40 days, we're going to launch this new institute. This is a university, Vanderbilt, that is world class. 2528.64s - 2536.72s | This is a university that's able to take a look at a series of problems and approach them with expert faculty, with unique partnerships, 2537.44s - 2543.60s | and with an interagency approach to looking at how we get things done across a number of different silos within academia. 2545.44s - 2572.36s | It's also an institute, are we there? Okay, sorry about that. It's also an institute that's going to take artificial intelligence, cyber security, and intelligence for decision making, and apply that to the program that we're developing. 2574.55s - 2590.79s | You


chunk_id: 158_chunk_36
chunk_text:
hope that future Dernses and Commanders will make sure that their speaking tour is stopping here at Vegas, at DEF CON 33, and beyond. 2499.51s - 2511.40s | So as I got ready to retire, I had a lot of options. And I would tell you the number one option that I wanted to do was to be able to give back. 2511.88s - 2527.44s | And so I'm now the Founding Director of the Institution of National Security at Vanderbilt University. In 40 days, we're going to launch this new institute. This is a university, Vanderbilt, that is world class. 2528.64s - 2536.72s | This is a university that's able to take a look at a series of problems and approach them with expert faculty, with unique partnerships, 2537.44s - 2543.60s | and with an interagency approach to looking at how we get things done across a number of different silos within academia. 2545.44s - 2572.36s | It's also an institute, are we there? Okay, sorry about that. It's also an institute that's going to take artificial intelligence, cyber security, and intelligence for decision making, and apply that to the program that we're developing. 2574.55s - 2590.79s | You know, one of the interesting things that I found in my travels across the United States when I was the Director and Commander was, I would show up on the West Coast, or Austin, or Boston, Massachusetts, and I was normally twice the age of the people I was talking to. 2591.35s - 2613.64s | And then I'd come back to D.C., and I was one of the younger ones in the room. 15 times more people are over the age of 50 than under the age of 30 working national security issues today. We need to change that, and this institute at Vanderbilt University is our approach to be able to start that momentum. 2614.60s - 2624.20s | So I invite all of you, those that have done so much of the work that has been able to build our economy and understand what our nation does in cyberspace, to join us. 2625.00s - 2634.92s | Later on today, please see Brett Goldstein, who will be here to talk about what you might be able to do to join our journey as we take a look at a new institute for national security. 2635.96s - 2643.56s | Ladies and


chunk_id: 158_chunk_37
chunk_text:
know, one of the interesting things that I found in my travels across the United States when I was the Director and Commander was, I would show up on the West Coast, or Austin, or Boston, Massachusetts, and I was normally twice the age of the people I was talking to. 2591.35s - 2613.64s | And then I'd come back to D.C., and I was one of the younger ones in the room. 15 times more people are over the age of 50 than under the age of 30 working national security issues today. We need to change that, and this institute at Vanderbilt University is our approach to be able to start that momentum. 2614.60s - 2624.20s | So I invite all of you, those that have done so much of the work that has been able to build our economy and understand what our nation does in cyberspace, to join us. 2625.00s - 2634.92s | Later on today, please see Brett Goldstein, who will be here to talk about what you might be able to do to join our journey as we take a look at a new institute for national security. 2635.96s - 2643.56s | Ladies and gentlemen, thank you so much for your patience and your attention. Best wishes for DEF CON 32. Thanks a lot.


chunk_id: 158_chunk_38
chunk_text:
gentlemen, thank you so much for your patience and your attention. Best wishes for DEF CON 32. Thanks a lot.


chunk_id: 159_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=-iNezAL_EF0", "title": "DEF CON 32 - Sudos and Sudon\u2019ts: Peering inside Sudo for Windows - Michael Torres", "description": "In February 2024, Microsoft announced the release of Sudo for Windows for Windows 11 Insider Preview[1]. Like the Unix sudo utility, it provides a method for users to run commands with elevated permissions. This talk will share the results of an analysis of Sudo for Windows, starting with a summary of the information provided by Microsoft. From there, we will explore the architecture used to coordinate the elevation of the specified process, the ALPC service used to communicate between elevated and non-elevated processes, how Rust interoperates with Windows APIs, and the path resolution process for files and relative paths. As part of that journey, we will discuss a few discovered security issues.\n\nThis presentation will be valuable to anyone with an interest in Windows reverse engineering or Rust memory safety. A conceptual understanding of Windows Inter-Process Communication (IPC) and heap allocation may make parts of the talk more approachable, but the main ideas will be accessible to anyone with a high-level understanding of process memory layout (stack vs heap).", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 1640, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.91s - 8.22s | This text was transcribed using whisper model: large-v2 Hey everybody, how's it going? My name is Michael Torres. I'm going to be talking about uh, 8.22s - 14.22s | pseudo for Windows. Title of the talk is Pseudos and Pseudonts. Here's a quick overview of 14.22s - 17.70s | what I'm going to talk about. You can read so I'm not going to bore you too much, but first 17.70s - 21.64s | we're going to go over what pseudo for Windows is cause it sounds weird. Then we're going to 21.64s - 27.58s | hit uh, some research, initial research on it, how it all works. Talk about some non-security 27.58s - 31.54s | issues according to MSRC, I'm supposed to use those words. Uh, then we're going to talk 31.56s - 35.60s | about some security issues that we found. One of them is unfortunately still under embargo. 35.60s - 41.60s | Talk more about how I found that one later. Uh, but let's hit it. So who am I? Uh, I do operational 43.84s - 48.68s | technology security at Google. I also sort of do cyber depending on who you ask for the


chunk_id: 159_chunk_1
chunk_text:
- 8.22s | This text was transcribed using whisper model: large-v2 Hey everybody, how's it going? My name is Michael Torres. I'm going to be talking about uh, 8.22s - 14.22s | pseudo for Windows. Title of the talk is Pseudos and Pseudonts. Here's a quick overview of 14.22s - 17.70s | what I'm going to talk about. You can read so I'm not going to bore you too much, but first 17.70s - 21.64s | we're going to go over what pseudo for Windows is cause it sounds weird. Then we're going to 21.64s - 27.58s | hit uh, some research, initial research on it, how it all works. Talk about some non-security 27.58s - 31.54s | issues according to MSRC, I'm supposed to use those words. Uh, then we're going to talk 31.56s - 35.60s | about some security issues that we found. One of them is unfortunately still under embargo. 35.60s - 41.60s | Talk more about how I found that one later. Uh, but let's hit it. So who am I? Uh, I do operational 43.84s - 48.68s | technology security at Google. I also sort of do cyber depending on who you ask for the 48.68s - 52.62s | United States Marine Corps Reserve. I also volunteer my time with VETSEC which is a 52.62s - 56.68s | profit focused on helping uh, veterans of the armed services for the US and allied 56.70s - 61.80s | countries get careers in cyber security. I also just do random research projects like this 61.80s - 69.16s | that are not related to any of that when I get bored. So here I am. So what is pseudo for 69.16s - 73.72s | Windows? They uh, Microsoft announced that they're going to introduce this utility in Windows 73.72s - 78.96s | 11 in the H2 update which usually drops around September so in a month or so. It's currently 78.96s - 83.44s | an insider preview which is how I got access to test all this good stuff. The way it works at a 83.48s - 89.32s | very high level is it uses UAC, that standard process elevation thing, to support the type of 89.32s - 93.06s | command line features you're probably used to if you use pseudo on Linux. So taking your 93.06s - 97.66s | input, your output, all that, putting it back


chunk_id: 159_chunk_2
chunk_text:
48.68s - 52.62s | United States Marine Corps Reserve. I also volunteer my time with VETSEC which is a 52.62s - 56.68s | profit focused on helping uh, veterans of the armed services for the US and allied 56.70s - 61.80s | countries get careers in cyber security. I also just do random research projects like this 61.80s - 69.16s | that are not related to any of that when I get bored. So here I am. So what is pseudo for 69.16s - 73.72s | Windows? They uh, Microsoft announced that they're going to introduce this utility in Windows 73.72s - 78.96s | 11 in the H2 update which usually drops around September so in a month or so. It's currently 78.96s - 83.44s | an insider preview which is how I got access to test all this good stuff. The way it works at a 83.48s - 89.32s | very high level is it uses UAC, that standard process elevation thing, to support the type of 89.32s - 93.06s | command line features you're probably used to if you use pseudo on Linux. So taking your 93.06s - 97.66s | input, your output, all that, putting it back into the prompt that you originally ran it in. 97.66s - 101.26s | Uh, that's both console input and output which are different on Windows than standard in, 101.26s - 105.44s | standard out, and standard error. It does this via fancy pipes and redirection and all that 105.44s - 110.74s | good stuff. It's written in Rust. It is now fully open source. At the time they just, at the 110.74s - 114.54s | time I did this research, they said it was open source but it wasn't published yet. Uh, 114.54s - 118.62s | which meant that I did a lot more work than I actually had to do but that's alright. That's 118.62s - 124.28s | what, that's what's fun I guess. Uh, I found two issues with again, according to MSRC, no 124.28s - 128.26s | security impact. I have to use those words over and over again. One is a memory corruption 128.26s - 132.02s | issue which is fun cause like I said it's written in Rust. Uh, and the other one was a 132.02s - 137.10s | search order confusion issue. I found two issues with security impact. One allowed uh, 137.10s -


chunk_id: 159_chunk_3
chunk_text:
into the prompt that you originally ran it in. 97.66s - 101.26s | Uh, that's both console input and output which are different on Windows than standard in, 101.26s - 105.44s | standard out, and standard error. It does this via fancy pipes and redirection and all that 105.44s - 110.74s | good stuff. It's written in Rust. It is now fully open source. At the time they just, at the 110.74s - 114.54s | time I did this research, they said it was open source but it wasn't published yet. Uh, 114.54s - 118.62s | which meant that I did a lot more work than I actually had to do but that's alright. That's 118.62s - 124.28s | what, that's what's fun I guess. Uh, I found two issues with again, according to MSRC, no 124.28s - 128.26s | security impact. I have to use those words over and over again. One is a memory corruption 128.26s - 132.02s | issue which is fun cause like I said it's written in Rust. Uh, and the other one was a 132.02s - 137.10s | search order confusion issue. I found two issues with security impact. One allowed uh, 137.10s - 141.74s | cross user code execution which, kind of sad. You don't really want other users to run code 141.74s - 146.94s | as you if you like your secrets being yours. And the other one allows you to data tamper 146.94s - 151.84s | the input and output data for sudo. And again I can't go into too much detail on that one 151.84s - 158.15s | but we'll talk more about it later. Most of my research was conducted against sudo version 158.15s - 162.99s | 1. Uh, you'll note that both of these bullet points say sudo version 1 but have different 162.99s - 167.39s | signature dates. I can't help you. They didn't increment the version number so I just had to 167.41s - 173.53s | use the signature date on the binary to distinguish the two. Uh, one is from February, one's 173.53s - 177.09s | from March. I don't know if they've released a more recent update cause I haven't checked in 177.09s - 182.09s | the last three weeks. So they might have but three weeks ago it was still the version from 182.09s - 189.89s | March. So precursor things to know.


chunk_id: 159_chunk_4
chunk_text:
141.74s | cross user code execution which, kind of sad. You don't really want other users to run code 141.74s - 146.94s | as you if you like your secrets being yours. And the other one allows you to data tamper 146.94s - 151.84s | the input and output data for sudo. And again I can't go into too much detail on that one 151.84s - 158.15s | but we'll talk more about it later. Most of my research was conducted against sudo version 158.15s - 162.99s | 1. Uh, you'll note that both of these bullet points say sudo version 1 but have different 162.99s - 167.39s | signature dates. I can't help you. They didn't increment the version number so I just had to 167.41s - 173.53s | use the signature date on the binary to distinguish the two. Uh, one is from February, one's 173.53s - 177.09s | from March. I don't know if they've released a more recent update cause I haven't checked in 177.09s - 182.09s | the last three weeks. So they might have but three weeks ago it was still the version from 182.09s - 189.89s | March. So precursor things to know. User account control. If you use Windows, which I 189.89s - 194.59s | assume most of you do cause you came to a talk about sudo for Windows, you've seen a user 194.59s - 197.35s | account control prompt, right? You always just hit yes cause you don't care what you're 197.35s - 202.77s | doing you just want it to work. Uh, the way it works is normal processes without elevation run 202.77s - 208.31s | in what's called medium integrity. That's pretty much everything except for processes or 208.31s - 213.45s | systems that are designed to use low integrity. Which quick shorthand is basically just web 213.45s - 217.49s | browsers and your PDF reader because they want that to have the absolute least privilege they 217.49s - 222.19s | can. Elevated processes, so the thing that runs once you hit that yes button cause you don't 222.19s - 227.97s | care you just want it to work. Uh, we're run as high integrity. Only processes running in 227.97s - 234.11s | high integrity are allowed to modify system resources which implicitly means that they can 234.11s - 239.11s | get system level permissions which is roughly


chunk_id: 159_chunk_5
chunk_text:
User account control. If you use Windows, which I 189.89s - 194.59s | assume most of you do cause you came to a talk about sudo for Windows, you've seen a user 194.59s - 197.35s | account control prompt, right? You always just hit yes cause you don't care what you're 197.35s - 202.77s | doing you just want it to work. Uh, the way it works is normal processes without elevation run 202.77s - 208.31s | in what's called medium integrity. That's pretty much everything except for processes or 208.31s - 213.45s | systems that are designed to use low integrity. Which quick shorthand is basically just web 213.45s - 217.49s | browsers and your PDF reader because they want that to have the absolute least privilege they 217.49s - 222.19s | can. Elevated processes, so the thing that runs once you hit that yes button cause you don't 222.19s - 227.97s | care you just want it to work. Uh, we're run as high integrity. Only processes running in 227.97s - 234.11s | high integrity are allowed to modify system resources which implicitly means that they can 234.11s - 239.11s | get system level permissions which is roughly equivalent to root on Windows, right? It's 239.11s - 242.55s | considered a defense in depth measure by Microsoft. They do not consider it a primary 242.55s - 247.73s | control. They do not consider UAC bypasses a security issue. They won't service them, they 247.73s - 252.13s | don't consider them part of bug bounty. Importantly for why sudo for Windows needs to 252.13s - 258.63s | exist, you can't spawn a process with UAC and inherit the standard in standard out standard 258.63s - 263.17s | error or console input and console output into the privilege process. Meaning that if you're 263.17s - 269.25s | in a command prompt and you try to run, you know, reg query as a privilege process, you can't 269.25s - 273.85s | then pipe that into another command or redirect it into a text file or something like that. 273.85s - 281.24s | It'll spawn it as a new process that can't put it back into your same window. Other things to 281.24s - 286.74s | know about, uh, the ALPC interface. It's an inter-process communications framework. It is 286.74s - 291.92s | officially undocumented and only used by Microsoft internal systems.


chunk_id: 159_chunk_6
chunk_text:
equivalent to root on Windows, right? It's 239.11s - 242.55s | considered a defense in depth measure by Microsoft. They do not consider it a primary 242.55s - 247.73s | control. They do not consider UAC bypasses a security issue. They won't service them, they 247.73s - 252.13s | don't consider them part of bug bounty. Importantly for why sudo for Windows needs to 252.13s - 258.63s | exist, you can't spawn a process with UAC and inherit the standard in standard out standard 258.63s - 263.17s | error or console input and console output into the privilege process. Meaning that if you're 263.17s - 269.25s | in a command prompt and you try to run, you know, reg query as a privilege process, you can't 269.25s - 273.85s | then pipe that into another command or redirect it into a text file or something like that. 273.85s - 281.24s | It'll spawn it as a new process that can't put it back into your same window. Other things to 281.24s - 286.74s | know about, uh, the ALPC interface. It's an inter-process communications framework. It is 286.74s - 291.92s | officially undocumented and only used by Microsoft internal systems. The way it works is the 291.92s - 296.88s | server listens on a port which is just an object cause everything in Windows is an object. 296.88s - 302.02s | That port is just a string name. Sometimes it's a string as is the case with sudo. You can 302.02s - 308.16s | see the example there. Uh, sometimes it's a GUID if it's a com object or things like that. 308.16s - 313.60s | The way that security is supposed to be implemented on ALPC is that the server can query 313.60s - 319.26s | attributes of the client, like the process ID, the, uh, SID, the principal name, and all of 319.26s - 325.88s | that of the color. And the client is able to say I only want to connect to an ALPC server if 325.88s - 330.08s | it's also this SID or some other properties that I don't remember frankly and they're not in 330.08s - 334.52s | the slide so I'm not gonna remember them right now. Um, the other thing to know is that in 334.52s - 340.18s | Rust if you want to use Windows native APIs like create process or


chunk_id: 159_chunk_7
chunk_text:
The way it works is the 291.92s - 296.88s | server listens on a port which is just an object cause everything in Windows is an object. 296.88s - 302.02s | That port is just a string name. Sometimes it's a string as is the case with sudo. You can 302.02s - 308.16s | see the example there. Uh, sometimes it's a GUID if it's a com object or things like that. 308.16s - 313.60s | The way that security is supposed to be implemented on ALPC is that the server can query 313.60s - 319.26s | attributes of the client, like the process ID, the, uh, SID, the principal name, and all of 319.26s - 325.88s | that of the color. And the client is able to say I only want to connect to an ALPC server if 325.88s - 330.08s | it's also this SID or some other properties that I don't remember frankly and they're not in 330.08s - 334.52s | the slide so I'm not gonna remember them right now. Um, the other thing to know is that in 334.52s - 340.18s | Rust if you want to use Windows native APIs like create process or shell execute X which are 340.18s - 344.48s | important if you're trying to run a process as an elevated user. Um, you have to use one or 344.48s - 349.16s | you don't have to but Microsoft released two crates for it. Windows and Windows Sys. So 349.16s - 354.36s | those are first party owned by Microsoft. They both require you to run in unsafe Rust. 354.36s - 358.60s | Meaning that now we can get memory issues and buffer overreads and buffer overruns and all 358.60s - 363.34s | that good stuff. Um, the only difference between Windows and Windows Sys is the Windows 363.36s - 369.76s | crate does type coercion for you. So if you have a Rust string and you want to call a Windows 369.76s - 373.94s | API if you use the Windows crate you just give it the Rust string and magic happens. I don't 373.94s - 377.78s | really know Rust that well so sorry it just magically happens to me. Uh, whereas with 377.78s - 382.52s | Windows Sys you have to explicitly cast things into the right data type to get it to work in 382.52s - 390.56s


chunk_id: 159_chunk_8
chunk_text:
shell execute X which are 340.18s - 344.48s | important if you're trying to run a process as an elevated user. Um, you have to use one or 344.48s - 349.16s | you don't have to but Microsoft released two crates for it. Windows and Windows Sys. So 349.16s - 354.36s | those are first party owned by Microsoft. They both require you to run in unsafe Rust. 354.36s - 358.60s | Meaning that now we can get memory issues and buffer overreads and buffer overruns and all 358.60s - 363.34s | that good stuff. Um, the only difference between Windows and Windows Sys is the Windows 363.36s - 369.76s | crate does type coercion for you. So if you have a Rust string and you want to call a Windows 369.76s - 373.94s | API if you use the Windows crate you just give it the Rust string and magic happens. I don't 373.94s - 377.78s | really know Rust that well so sorry it just magically happens to me. Uh, whereas with 377.78s - 382.52s | Windows Sys you have to explicitly cast things into the right data type to get it to work in 382.52s - 390.56s | Rust. So Microsoft's blog post did actually include a fair bit of detail, uh, which was cool 390.56s - 394.86s | to see, uh, both from a security research perspective and just a curiosity perspective. It's 394.88s - 399.74s | cool to see them publish information about their tools like this. Uh, there are three modes 399.74s - 404.26s | that Sudo for Windows supports. Those are new window, input closed, and inline. The new 404.26s - 409.06s | window one is basically just the same as if you ran run as and then the command. So there's 409.06s - 413.66s | not really much novelty there. Uh, the input closed and inline modes do this weird client 413.66s - 418.26s | server thing which you can see at the bottom, uh, right there. That sort of high level thing 418.26s - 422.78s | we'll go into that more in a second. The difference between inline and input closed is in 423.76s - 428.06s | input closed the elevated process can't see the un-elevated console's standard end. So if you 428.06s - 433.14s | were to pipe the result of a command into a Sudo execution and your system


chunk_id: 159_chunk_9
chunk_text:
| Rust. So Microsoft's blog post did actually include a fair bit of detail, uh, which was cool 390.56s - 394.86s | to see, uh, both from a security research perspective and just a curiosity perspective. It's 394.88s - 399.74s | cool to see them publish information about their tools like this. Uh, there are three modes 399.74s - 404.26s | that Sudo for Windows supports. Those are new window, input closed, and inline. The new 404.26s - 409.06s | window one is basically just the same as if you ran run as and then the command. So there's 409.06s - 413.66s | not really much novelty there. Uh, the input closed and inline modes do this weird client 413.66s - 418.26s | server thing which you can see at the bottom, uh, right there. That sort of high level thing 418.26s - 422.78s | we'll go into that more in a second. The difference between inline and input closed is in 423.76s - 428.06s | input closed the elevated process can't see the un-elevated console's standard end. So if you 428.06s - 433.14s | were to pipe the result of a command into a Sudo execution and your system is configured to 433.14s - 439.04s | run it in input closed mode, your elevated process won't be able to see it. They say that 439.04s - 444.82s | those are in order by most secure to least secure so new window being the most secure and 444.82s - 448.78s | inline being the least secure. Um, they don't really go into a lot of details about that 448.78s - 453.80s | other than that it's, it keeps things open for longer. Um, again I mentioned earlier it, in 456.10s - 460.26s | the blog post they say it's open source. They link to a GitHub repo. That GitHub repo was 460.26s - 464.50s | empty when I was doing this research so I just got to look at Rust code in Ghidra which if 464.50s - 469.48s | you haven't done it I don't recommend it. Um, but now it's open source. You can go on GitHub 469.48s - 473.14s | and look at all their stuff. Um, they included that diagram as I mentioned to explain the 473.14s - 476.74s | request flow. We'll go into that more in a second but you can see that there's a


chunk_id: 159_chunk_10
chunk_text:
is configured to 433.14s - 439.04s | run it in input closed mode, your elevated process won't be able to see it. They say that 439.04s - 444.82s | those are in order by most secure to least secure so new window being the most secure and 444.82s - 448.78s | inline being the least secure. Um, they don't really go into a lot of details about that 448.78s - 453.80s | other than that it's, it keeps things open for longer. Um, again I mentioned earlier it, in 456.10s - 460.26s | the blog post they say it's open source. They link to a GitHub repo. That GitHub repo was 460.26s - 464.50s | empty when I was doing this research so I just got to look at Rust code in Ghidra which if 464.50s - 469.48s | you haven't done it I don't recommend it. Um, but now it's open source. You can go on GitHub 469.48s - 473.14s | and look at all their stuff. Um, they included that diagram as I mentioned to explain the 473.14s - 476.74s | request flow. We'll go into that more in a second but you can see that there's a client 476.74s - 485.17s | server thing in there. So off the rip like this was actually found after the rest of this 485.17s - 489.31s | research cause I was finally able to look at the source code. The new window mode still 489.31s - 495.11s | creates that RPC server so you're still able to do fun things with the RPC server. Um, it 495.11s - 500.45s | doesn't always do what's on the tin. Sometimes it does actually pull in your standard in, 500.45s - 503.85s | standard out, standard error in your console input and console out and pipe it into the new 503.85s - 510.13s | process. Um, again it's supposed to be the most secure uh but it does always get the standard 510.13s - 516.53s | in handle unlike the input disabled one. I don't know of any ways that that's necessarily a 516.53s - 520.53s | security issue but it's kind of an odd novelty because they describe it as being the most 520.53s - 527.63s | isolated from the unprivileged process perspective. So I started looking into this because 527.63s - 533.11s | I saw on Hacker News that veritable Y


chunk_id: 159_chunk_11
chunk_text:
client 476.74s - 485.17s | server thing in there. So off the rip like this was actually found after the rest of this 485.17s - 489.31s | research cause I was finally able to look at the source code. The new window mode still 489.31s - 495.11s | creates that RPC server so you're still able to do fun things with the RPC server. Um, it 495.11s - 500.45s | doesn't always do what's on the tin. Sometimes it does actually pull in your standard in, 500.45s - 503.85s | standard out, standard error in your console input and console out and pipe it into the new 503.85s - 510.13s | process. Um, again it's supposed to be the most secure uh but it does always get the standard 510.13s - 516.53s | in handle unlike the input disabled one. I don't know of any ways that that's necessarily a 516.53s - 520.53s | security issue but it's kind of an odd novelty because they describe it as being the most 520.53s - 527.63s | isolated from the unprivileged process perspective. So I started looking into this because 527.63s - 533.11s | I saw on Hacker News that veritable Y Combinator uh news aggregator that one of my co-workers 533.11s - 536.45s | at Google actually which I didn't know at the time made a blog post about Sudo for Windows 536.45s - 541.71s | and published some research. Um, he pulled apart the RPC server some and found that at the 541.71s - 547.09s | time that RPC client server thing had zero authentication which is obviously very bad. That 547.09s - 550.95s | means you can just tell the server you would like to run a privileged command and it'll 550.95s - 555.93s | happily do it. Um, that was fixed by the time I was testing it. Note that that's in quotes. 555.93s - 561.23s | Talk more about that in a second. Um, and it talked to again it pulled apart that RPC like 561.23s - 566.39s | client server API if you will and highlighted the methods of interest to call. Specifically 566.39s - 572.03s | that server do elevation API. That's what actually is called by the client into the server 572.03s - 577.01s | to coordinate execution, passes handles that the process binds to and then you can get all 577.01s - 581.11s


chunk_id: 159_chunk_12
chunk_text:
Combinator uh news aggregator that one of my co-workers 533.11s - 536.45s | at Google actually which I didn't know at the time made a blog post about Sudo for Windows 536.45s - 541.71s | and published some research. Um, he pulled apart the RPC server some and found that at the 541.71s - 547.09s | time that RPC client server thing had zero authentication which is obviously very bad. That 547.09s - 550.95s | means you can just tell the server you would like to run a privileged command and it'll 550.95s - 555.93s | happily do it. Um, that was fixed by the time I was testing it. Note that that's in quotes. 555.93s - 561.23s | Talk more about that in a second. Um, and it talked to again it pulled apart that RPC like 561.23s - 566.39s | client server API if you will and highlighted the methods of interest to call. Specifically 566.39s - 572.03s | that server do elevation API. That's what actually is called by the client into the server 572.03s - 577.01s | to coordinate execution, passes handles that the process binds to and then you can get all 577.01s - 581.11s | your input and output and all that good stuff. It also passes a bunch of parameters relevant 581.11s - 585.65s | to the command being ran like the command to run, arguments to the command, the current 585.65s - 594.60s | working directory and optionally the environment depending on the flags you pass to Sudo. 594.62s - 598.96s | Here is a more detailed look at run mode 3 inline mode. This is the one I did most of my 598.96s - 603.74s | research with because it is listed as the most insecure so it's probably the easiest target 603.74s - 608.84s | right? I'm lazy. Um, you can see on the far side there you have the actual unprivileged 608.84s - 613.64s | console where the person runs Sudo who am I and they're trying to run it as that elevated 613.64s - 619.08s | user. The way that works is it first spawns an elevated process to host that RPC service 619.08s - 623.12s | using normal run as. The user gets a prompt again they click yes like everyone does 623.14s - 628.32s | because they just want the thing to work. Um, the client


chunk_id: 159_chunk_13
chunk_text:
| your input and output and all that good stuff. It also passes a bunch of parameters relevant 581.11s - 585.65s | to the command being ran like the command to run, arguments to the command, the current 585.65s - 594.60s | working directory and optionally the environment depending on the flags you pass to Sudo. 594.62s - 598.96s | Here is a more detailed look at run mode 3 inline mode. This is the one I did most of my 598.96s - 603.74s | research with because it is listed as the most insecure so it's probably the easiest target 603.74s - 608.84s | right? I'm lazy. Um, you can see on the far side there you have the actual unprivileged 608.84s - 613.64s | console where the person runs Sudo who am I and they're trying to run it as that elevated 613.64s - 619.08s | user. The way that works is it first spawns an elevated process to host that RPC service 619.08s - 623.12s | using normal run as. The user gets a prompt again they click yes like everyone does 623.14s - 628.32s | because they just want the thing to work. Um, the client then sends an RPC into that 628.32s - 633.22s | privileged process telling it what command it wants to run. The privileged process binds to 633.22s - 637.42s | the handles that gets passed in there so that all your input output and standard error stuff 637.42s - 643.00s | just flows naturally. Privileged process that the user specified gets spawned and then 643.00s - 649.91s | magic happens you can do all your normal command line pipes and stuff. So summarizing 649.91s - 653.35s | everything we just talked about sort of high level notes. Uh, it's written in Rust, it's 653.37s - 658.45s | open source. Uh, Rust requires you to enter into unsafe mode so again memory safety issues 658.45s - 664.01s | can happen. Uh, to call Windows native APIs which things like this kind of have to do. Um, 664.01s - 672.34s | an ALPC is what's used to coordinate the actual execution of the user specified process. So 672.34s - 676.84s | our first issue, the memory safety issue in Rust. Um, sort of odd right but as I just 676.84s - 682.42s | mentioned you have to use unsafe APIs. Uh, they removed


chunk_id: 159_chunk_14
chunk_text:
then sends an RPC into that 628.32s - 633.22s | privileged process telling it what command it wants to run. The privileged process binds to 633.22s - 637.42s | the handles that gets passed in there so that all your input output and standard error stuff 637.42s - 643.00s | just flows naturally. Privileged process that the user specified gets spawned and then 643.00s - 649.91s | magic happens you can do all your normal command line pipes and stuff. So summarizing 649.91s - 653.35s | everything we just talked about sort of high level notes. Uh, it's written in Rust, it's 653.37s - 658.45s | open source. Uh, Rust requires you to enter into unsafe mode so again memory safety issues 658.45s - 664.01s | can happen. Uh, to call Windows native APIs which things like this kind of have to do. Um, 664.01s - 672.34s | an ALPC is what's used to coordinate the actual execution of the user specified process. So 672.34s - 676.84s | our first issue, the memory safety issue in Rust. Um, sort of odd right but as I just 676.84s - 682.42s | mentioned you have to use unsafe APIs. Uh, they removed this functionality before they 682.44s - 688.18s | published it to GitHub so I can't tell you exactly how it happened. But at a hi- at a from 688.18s - 694.28s | my analysis what happened was if you gave a path that rewrote from the beginning meaning 694.28s - 700.82s | that you had a leading like backslash or C colon backslash right. It would write your path 700.82s - 705.96s | to the start and then when it passed it to an API function it didn't truncate at the end of 705.96s - 711.04s | where your path was. It just read until the end of the buffer to the first null byte. I think 711.06s - 717.30s | that that happened because they assumed that a path as string would point to a null 717.30s - 721.50s | terminated buffer as you would kind of expect it to if you're used to C. When in fact it just 721.50s - 726.50s | points to a vector of U8s that may or may not include a null byte at the end. Um, here's 728.64s - 733.04s | sort of my mock up of the code. Uh, you can


chunk_id: 159_chunk_15
chunk_text:
this functionality before they 682.44s - 688.18s | published it to GitHub so I can't tell you exactly how it happened. But at a hi- at a from 688.18s - 694.28s | my analysis what happened was if you gave a path that rewrote from the beginning meaning 694.28s - 700.82s | that you had a leading like backslash or C colon backslash right. It would write your path 700.82s - 705.96s | to the start and then when it passed it to an API function it didn't truncate at the end of 705.96s - 711.04s | where your path was. It just read until the end of the buffer to the first null byte. I think 711.06s - 717.30s | that that happened because they assumed that a path as string would point to a null 717.30s - 721.50s | terminated buffer as you would kind of expect it to if you're used to C. When in fact it just 721.50s - 726.50s | points to a vector of U8s that may or may not include a null byte at the end. Um, here's 728.64s - 733.04s | sort of my mock up of the code. Uh, you can pull these slides off the Defcon media server if 733.04s - 736.28s | you want to take a better look at it but this is just sort of demonstrating what I just 736.28s - 741.96s | talked about where if you assume that you can take the path as a string and then just get a 741.96s - 747.24s | pointer to it and pass it to the Windows API function you'll end up very sad because it'll 747.24s - 752.50s | just read until the first null byte not necessarily until the end of your target string. 752.50s - 758.44s | Meaning you have buffer overread in heap, uh, for arbitrary numbers of bytes that you can't 758.44s - 764.02s | necessarily control but because you can control the path you can control approximately how 764.06s - 769.76s | far into that heap buffer you read. Uh, so like I just said you can read everything up to the 769.76s - 776.10s | first non, non-null byte. You don't control which heap allocation you're reading and it 776.10s - 781.04s | doesn't let you write memory into arbitrary things that are outside of your heap boundary 781.04s - 785.44s


chunk_id: 159_chunk_16
chunk_text:
pull these slides off the Defcon media server if 733.04s - 736.28s | you want to take a better look at it but this is just sort of demonstrating what I just 736.28s - 741.96s | talked about where if you assume that you can take the path as a string and then just get a 741.96s - 747.24s | pointer to it and pass it to the Windows API function you'll end up very sad because it'll 747.24s - 752.50s | just read until the first null byte not necessarily until the end of your target string. 752.50s - 758.44s | Meaning you have buffer overread in heap, uh, for arbitrary numbers of bytes that you can't 758.44s - 764.02s | necessarily control but because you can control the path you can control approximately how 764.06s - 769.76s | far into that heap buffer you read. Uh, so like I just said you can read everything up to the 769.76s - 776.10s | first non, non-null byte. You don't control which heap allocation you're reading and it 776.10s - 781.04s | doesn't let you write memory into arbitrary things that are outside of your heap boundary 781.04s - 785.44s | because it is rust. It's a vector. Uh, so it'll reallocate if you reach the capacity of the 785.44s - 791.12s | current heap allocation. Um, but still you get to read things from previous heap 791.12s - 796.56s | allocations which in my testing tended to just be paths but it could be something like a 796.56s - 802.66s | token or something like that. Um, it says at the bottom there why I, it's not really a 802.66s - 808.50s | security issue. Uh, the main problem being this is only noticeable if you run sudo with an 808.50s - 814.98s | unprov- or a untrusted input which you shouldn't do anyway so it's not really security 814.98s - 820.38s | impacting if you run sudo with arbitrary things someone you don't trust supplied and then 820.40s - 824.68s | you can read other memory because you shouldn't be doing that in the first place because 824.68s - 830.01s | you're going to execute someone else's code. This screenshot shows what I was talking 830.01s - 834.29s | about so you can see on the left there I run sudo with a leading slash and then a


chunk_id: 159_chunk_17
chunk_text:
| because it is rust. It's a vector. Uh, so it'll reallocate if you reach the capacity of the 785.44s - 791.12s | current heap allocation. Um, but still you get to read things from previous heap 791.12s - 796.56s | allocations which in my testing tended to just be paths but it could be something like a 796.56s - 802.66s | token or something like that. Um, it says at the bottom there why I, it's not really a 802.66s - 808.50s | security issue. Uh, the main problem being this is only noticeable if you run sudo with an 808.50s - 814.98s | unprov- or a untrusted input which you shouldn't do anyway so it's not really security 814.98s - 820.38s | impacting if you run sudo with arbitrary things someone you don't trust supplied and then 820.40s - 824.68s | you can read other memory because you shouldn't be doing that in the first place because 824.68s - 830.01s | you're going to execute someone else's code. This screenshot shows what I was talking 830.01s - 834.29s | about so you can see on the left there I run sudo with a leading slash and then a path and 834.29s - 839.43s | then you can see in process monitor that at the end of the day a create file operation or 839.43s - 845.27s | trying to read the file, um, ends up re- trying to read a file that's the thing that I was 845.27s - 849.63s | trying to read and then a bunch of things from presumably a previous heap allocation 849.65s - 853.39s | because that's the path, that's the current working directory and then some garbage at the 853.39s - 861.44s | end until it reaches the first null byte. So the second issue, uh, search order inconsistency 861.44s - 865.48s | so in Windows just like, actually I shouldn't say that I don't know if it's true in Linux but 865.48s - 871.96s | in Windows if you run a command without a path it is supposed to execute that command in 871.96s - 876.56s | the current working directory if it's present and then search your path. Uh, so if you run 876.56s - 881.76s | sudo program.exe you expect it to run the program.exe in the current working directory 881.78s - 888.28s | not some other random program.exe.


chunk_id: 159_chunk_18
chunk_text:
path and 834.29s - 839.43s | then you can see in process monitor that at the end of the day a create file operation or 839.43s - 845.27s | trying to read the file, um, ends up re- trying to read a file that's the thing that I was 845.27s - 849.63s | trying to read and then a bunch of things from presumably a previous heap allocation 849.65s - 853.39s | because that's the path, that's the current working directory and then some garbage at the 853.39s - 861.44s | end until it reaches the first null byte. So the second issue, uh, search order inconsistency 861.44s - 865.48s | so in Windows just like, actually I shouldn't say that I don't know if it's true in Linux but 865.48s - 871.96s | in Windows if you run a command without a path it is supposed to execute that command in 871.96s - 876.56s | the current working directory if it's present and then search your path. Uh, so if you run 876.56s - 881.76s | sudo program.exe you expect it to run the program.exe in the current working directory 881.78s - 888.28s | not some other random program.exe. Uh, path resolution didn't work that way. The way it 888.28s - 892.66s | worked is again because of that client server thing it would try to resolve the path in 892.66s - 896.52s | the context of the privilege process which had a different current working directory 896.52s - 901.40s | meaning that you could end up running a command you didn't expect to run. Uh, says up there 901.40s - 904.96s | it's a somewhat contrived example but if you had compiled your own binary and named it 904.96s - 911.14s | cmd.exe and then you tried to run sudo cmd.exe it wouldn't run your command.exe it would 911.18s - 917.12s | run the system32 cmd.exe. According to Microsoft it's not a vulnerability. I have their exact 917.12s - 922.12s | response quoted there at the bottom. But they fixed it anyway. Um, so they more or less 925.76s - 930.84s | looked up the in the unprivileged process they looked up the command you gave them and 930.84s - 936.88s | resolved it and then passed the fully resolved path into the privileged process. Um, they 936.88s - 942.06s | fixed it. I'm not gonna complain too


chunk_id: 159_chunk_19
chunk_text:
Uh, path resolution didn't work that way. The way it 888.28s - 892.66s | worked is again because of that client server thing it would try to resolve the path in 892.66s - 896.52s | the context of the privilege process which had a different current working directory 896.52s - 901.40s | meaning that you could end up running a command you didn't expect to run. Uh, says up there 901.40s - 904.96s | it's a somewhat contrived example but if you had compiled your own binary and named it 904.96s - 911.14s | cmd.exe and then you tried to run sudo cmd.exe it wouldn't run your command.exe it would 911.18s - 917.12s | run the system32 cmd.exe. According to Microsoft it's not a vulnerability. I have their exact 917.12s - 922.12s | response quoted there at the bottom. But they fixed it anyway. Um, so they more or less 925.76s - 930.84s | looked up the in the unprivileged process they looked up the command you gave them and 930.84s - 936.88s | resolved it and then passed the fully resolved path into the privileged process. Um, they 936.88s - 942.06s | fixed it. I'm not gonna complain too much but it's kind of odd that you accept input from 942.06s - 945.16s | people on what issues are, fix them and then tell them yeah but we don't think it's a real 945.16s - 954.15s | issue. And this is a very well drawn I'm an artist if you didn't know uh example of how that 954.15s - 960.07s | would work from an attacker's perspective. So you try to run cmd.exe you expect it to run 960.07s - 965.67s | yours it ends up running some other command in the privileged process path which isn't the 965.67s - 974.21s | one you wanted. So let's talk more about that RPC server. Again, it's ALPC. Um, source code 974.21s - 979.39s | wasn't available so I had to look in Giger to figure out what all these parameters meant. Uh, I 979.39s - 984.13s | got pretty good results out of it. I didn't know what those handles were or how to deal with 984.13s - 989.09s | them necessarily but luckily I didn't have to. You can just bind to input and output without 989.09s - 994.77s | dealing or without worrying about the handles too much.


chunk_id: 159_chunk_20
chunk_text:
much but it's kind of odd that you accept input from 942.06s - 945.16s | people on what issues are, fix them and then tell them yeah but we don't think it's a real 945.16s - 954.15s | issue. And this is a very well drawn I'm an artist if you didn't know uh example of how that 954.15s - 960.07s | would work from an attacker's perspective. So you try to run cmd.exe you expect it to run 960.07s - 965.67s | yours it ends up running some other command in the privileged process path which isn't the 965.67s - 974.21s | one you wanted. So let's talk more about that RPC server. Again, it's ALPC. Um, source code 974.21s - 979.39s | wasn't available so I had to look in Giger to figure out what all these parameters meant. Uh, I 979.39s - 984.13s | got pretty good results out of it. I didn't know what those handles were or how to deal with 984.13s - 989.09s | them necessarily but luckily I didn't have to. You can just bind to input and output without 989.09s - 994.77s | dealing or without worrying about the handles too much. Um, importantly the unprivileged 994.77s - 999.05s | process ID so the one that you run before you hit that yes prompt as quick as humanly 999.05s - 1005.15s | possible is what is used to create the socket name. So it's predictable as long as you know 1005.15s - 1010.19s | the process ID that's uh trying to run sudo. And again I mentioned earlier after James 1010.19s - 1014.69s | Foreshaw's blog post they added an authentication check which was checking that the 1014.69s - 1020.93s | client's process path so that unprivileged process was the same as the server's process path 1020.93s - 1029.04s | meaning both are running sudo.exe. See Windows system 32 sudo.exe, right? Um, overview of 1029.04s - 1033.28s | that, that auth check on the right, right? Just is the image name of my calling process the 1033.28s - 1040.90s | same as my image name? If it is, good to go. We'll run your command. Which brings us to our 1040.90s - 1046.74s | first security issue. Um, it turns out that that's not really a good authentication check. Um, 1046.74s - 1053.42s | any user can issue elevation requests to that


chunk_id: 159_chunk_21
chunk_text:
Um, importantly the unprivileged 994.77s - 999.05s | process ID so the one that you run before you hit that yes prompt as quick as humanly 999.05s - 1005.15s | possible is what is used to create the socket name. So it's predictable as long as you know 1005.15s - 1010.19s | the process ID that's uh trying to run sudo. And again I mentioned earlier after James 1010.19s - 1014.69s | Foreshaw's blog post they added an authentication check which was checking that the 1014.69s - 1020.93s | client's process path so that unprivileged process was the same as the server's process path 1020.93s - 1029.04s | meaning both are running sudo.exe. See Windows system 32 sudo.exe, right? Um, overview of 1029.04s - 1033.28s | that, that auth check on the right, right? Just is the image name of my calling process the 1033.28s - 1040.90s | same as my image name? If it is, good to go. We'll run your command. Which brings us to our 1040.90s - 1046.74s | first security issue. Um, it turns out that that's not really a good authentication check. Um, 1046.74s - 1053.42s | any user can issue elevation requests to that RPC server meaning that any user of a multi-user 1053.42s - 1057.76s | Windows system to include, you know, unprivileged users because anyone can call an 1057.76s - 1063.52s | ALPC socket like your web browser, um, can go ahead and run commands in the context of a 1063.52s - 1068.86s | user, uh, when they run sudo. So it's not latent and a privileged user would have to try to 1068.86s - 1075.22s | run sudo and then you'd be able to exploit this to run it in the context of that user. 1075.22s - 1080.26s | Exploitation requires two things. So, like I mentioned, insufficient authentication. Um, the 1080.26s - 1086.66s | way I did that is I just injected a DLL into a sudo.exe, sudo process that I controlled so 1086.66s - 1091.70s | that I could do whatever I want in the context of a process whose image name is the legitimate 1091.70s - 1096.24s | sudo.exe. Um, and the other part of this was that predictable, uh, port name. That 1096.24s - 1101.68s | predictable RPC control port name. Because users can view the process IDs of other users in 1101.68s - 1106.28s | Windows,


chunk_id: 159_chunk_22
chunk_text:
RPC server meaning that any user of a multi-user 1053.42s - 1057.76s | Windows system to include, you know, unprivileged users because anyone can call an 1057.76s - 1063.52s | ALPC socket like your web browser, um, can go ahead and run commands in the context of a 1063.52s - 1068.86s | user, uh, when they run sudo. So it's not latent and a privileged user would have to try to 1068.86s - 1075.22s | run sudo and then you'd be able to exploit this to run it in the context of that user. 1075.22s - 1080.26s | Exploitation requires two things. So, like I mentioned, insufficient authentication. Um, the 1080.26s - 1086.66s | way I did that is I just injected a DLL into a sudo.exe, sudo process that I controlled so 1086.66s - 1091.70s | that I could do whatever I want in the context of a process whose image name is the legitimate 1091.70s - 1096.24s | sudo.exe. Um, and the other part of this was that predictable, uh, port name. That 1096.24s - 1101.68s | predictable RPC control port name. Because users can view the process IDs of other users in 1101.68s - 1106.28s | Windows, uh, pretty much no matter what there are some types of tokens that can't do that. Uh, 1106.30s - 1111.92s | you can get that information very easily and then you can just call the target sudo, 1111.92s - 1117.22s | privileged sudo process and have it run whatever you command you want and gain execution in 1117.22s - 1123.16s | that user's context. This was patched in the version, in the second version 1 of sudo. The 1123.16s - 1129.10s | one that was, uh, code signed on the 4th of March. So again, high level attack diagram you 1129.10s - 1132.40s | see at the top there we have our victim who's just trying to run sudo and get on with their 1132.46s - 1139.20s | day. We have our attacker with again, I'm an artist, very well drawn horns, thank you. Um, the 1139.20s - 1145.70s | attacker starts their code that's just waiting and trying to find a victim sudo that is 1145.70s - 1152.04s | running and then as soon as it notices one, it spawns its own sudo with a hooked method to 1152.04s - 1158.62s | connect to the target RPC server instead


chunk_id: 159_chunk_23
chunk_text:
uh, pretty much no matter what there are some types of tokens that can't do that. Uh, 1106.30s - 1111.92s | you can get that information very easily and then you can just call the target sudo, 1111.92s - 1117.22s | privileged sudo process and have it run whatever you command you want and gain execution in 1117.22s - 1123.16s | that user's context. This was patched in the version, in the second version 1 of sudo. The 1123.16s - 1129.10s | one that was, uh, code signed on the 4th of March. So again, high level attack diagram you 1129.10s - 1132.40s | see at the top there we have our victim who's just trying to run sudo and get on with their 1132.46s - 1139.20s | day. We have our attacker with again, I'm an artist, very well drawn horns, thank you. Um, the 1139.20s - 1145.70s | attacker starts their code that's just waiting and trying to find a victim sudo that is 1145.70s - 1152.04s | running and then as soon as it notices one, it spawns its own sudo with a hooked method to 1152.04s - 1158.62s | connect to the target RPC server instead of one that it spawned, uh, to run whatever 1158.64s - 1162.72s | command the attacker wants. From the victim's perspective, what this looks like is they ran 1162.72s - 1167.22s | sudo, they as fast as humanly possible because again, they're just trying to get the job done, 1167.22s - 1171.88s | hit the yes button on the UAC prompt and then nothing happens from their perspective. But in 1171.88s - 1180.64s | reality, the attacker was able to run whatever command they wanted. Uh, demo, I think. Do I 1180.64s - 1191.64s | have that wrong? Hopefully it plays. All right. Well, that was surprising. So here I'm just 1191.64s - 1196.84s | showing there's nothing up my sleeve. Um, uh, the left prompt is going to be our victim user. So 1196.84s - 1204.22s | who am I? I'm MTU. Um, it can run sudo just fine. The right prompt is now my unprivileged user or 1204.22s - 1210.30s | my non-administrative user, not MTU. Right now I'm going to show that, uh, sudo works and then 1210.30s - 1218.15s | that the base prompt is not running elevated. And then on the right, on the right,


chunk_id: 159_chunk_24
chunk_text:
of one that it spawned, uh, to run whatever 1158.64s - 1162.72s | command the attacker wants. From the victim's perspective, what this looks like is they ran 1162.72s - 1167.22s | sudo, they as fast as humanly possible because again, they're just trying to get the job done, 1167.22s - 1171.88s | hit the yes button on the UAC prompt and then nothing happens from their perspective. But in 1171.88s - 1180.64s | reality, the attacker was able to run whatever command they wanted. Uh, demo, I think. Do I 1180.64s - 1191.64s | have that wrong? Hopefully it plays. All right. Well, that was surprising. So here I'm just 1191.64s - 1196.84s | showing there's nothing up my sleeve. Um, uh, the left prompt is going to be our victim user. So 1196.84s - 1204.22s | who am I? I'm MTU. Um, it can run sudo just fine. The right prompt is now my unprivileged user or 1204.22s - 1210.30s | my non-administrative user, not MTU. Right now I'm going to show that, uh, sudo works and then 1210.30s - 1218.15s | that the base prompt is not running elevated. And then on the right, on the right, we're 1218.15s - 1222.89s | running that implant code that's just going to spawn some stuff, uh, to try to target that 1222.89s - 1228.89s | victim sudo process. We are racing because if we don't beat the legitimate process, um, the 1228.89s - 1234.09s | RPC socket closes and we can't run our command. So we go slowly insane trying to win the race. I 1234.09s - 1239.27s | did test this in a debugger first, so I was pretty confident it was supposed to work. But man, 1239.27s - 1244.97s | recording this video and just sitting there doing this for two minutes was not fun. Um, at the 1244.99s - 1250.13s | end there, you can see that it worked. On the right side, our unprivileged process again, we were 1250.13s - 1256.17s | able to inject into that victim server process and run command.exe as this, as the privileged 1256.17s - 1260.77s | user. We run who am I? And we see that we're now running as that other user who is just trying to 1260.77s - 1268.50s | run something with sudo. Well, I already played the video, but we could play it again if


chunk_id: 159_chunk_25
chunk_text:
we're 1218.15s - 1222.89s | running that implant code that's just going to spawn some stuff, uh, to try to target that 1222.89s - 1228.89s | victim sudo process. We are racing because if we don't beat the legitimate process, um, the 1228.89s - 1234.09s | RPC socket closes and we can't run our command. So we go slowly insane trying to win the race. I 1234.09s - 1239.27s | did test this in a debugger first, so I was pretty confident it was supposed to work. But man, 1239.27s - 1244.97s | recording this video and just sitting there doing this for two minutes was not fun. Um, at the 1244.99s - 1250.13s | end there, you can see that it worked. On the right side, our unprivileged process again, we were 1250.13s - 1256.17s | able to inject into that victim server process and run command.exe as this, as the privileged 1256.17s - 1260.77s | user. We run who am I? And we see that we're now running as that other user who is just trying to 1260.77s - 1268.50s | run something with sudo. Well, I already played the video, but we could play it again if you 1268.50s - 1279.34s | want. Oh, nothing showing up there. Neat. Let's try it this way. Can you see this? This video 1279.36s - 1300.82s | now? So again, uh, again, left prompt is the uh, privileged user who's just trying to run 1300.82s - 1305.32s | sudo. Uh, the right prompt that's about to spawn is the unprivileged user, not MTU, some evil 1305.32s - 1312.38s | attacker man. Um, user runs command, everything works. Let's see if I can skip this bit a bit. Um, 1316.38s - 1320.08s | user keeps running command, they keep working because you'll notice on the other side, the 1320.08s - 1324.18s | attacker process is failing, it's not winning that race. Uh, like I mentioned, I confirmed 1324.20s - 1329.20s | this in a debugger, but still very frustrating watching it fail over and over and over again. Um, 1329.20s - 1333.54s | but eventually it does work. And we can see on that right side now, we just got a command 1333.54s - 1338.18s | prompt back from the attacker's perspective. We run who am I? And we see that we are running as 1338.18s - 1351.82s | a user


chunk_id: 159_chunk_26
chunk_text:
you 1268.50s - 1279.34s | want. Oh, nothing showing up there. Neat. Let's try it this way. Can you see this? This video 1279.36s - 1300.82s | now? So again, uh, again, left prompt is the uh, privileged user who's just trying to run 1300.82s - 1305.32s | sudo. Uh, the right prompt that's about to spawn is the unprivileged user, not MTU, some evil 1305.32s - 1312.38s | attacker man. Um, user runs command, everything works. Let's see if I can skip this bit a bit. Um, 1316.38s - 1320.08s | user keeps running command, they keep working because you'll notice on the other side, the 1320.08s - 1324.18s | attacker process is failing, it's not winning that race. Uh, like I mentioned, I confirmed 1324.20s - 1329.20s | this in a debugger, but still very frustrating watching it fail over and over and over again. Um, 1329.20s - 1333.54s | but eventually it does work. And we can see on that right side now, we just got a command 1333.54s - 1338.18s | prompt back from the attacker's perspective. We run who am I? And we see that we are running as 1338.18s - 1351.82s | a user other than ourselves, which is not good, I think is what it's called in the business. 1351.82s - 1365.91s | All right. Work with me here. Nope. Hands. Perfect. Um, so I did find out after I tested 1365.93s - 1370.03s | this again, after they made the source code available, that they made that race window really 1370.03s - 1374.97s | short. So I assumed that the way it worked was the victim process ran its command 1374.97s - 1381.01s | successfully and then went ahead and uh, then went ahead and closed the socket after it was 1381.01s - 1385.97s | done. In fact, as soon as you called that elevation request API, it locked all future calls 1385.97s - 1391.19s | of it, which would explain why I had to run the command over and over again, going slowly 1391.23s - 1396.31s | and saying until it worked, but I don't know, not, not really a security control, but good for 1396.31s - 1401.91s | them for locking out other users and thinking about it. So the second vulnerability I 1401.91s - 1406.65s | mentioned, it's still under embargo, unfortunately. Um, I reported it 13th of June


chunk_id: 159_chunk_27
chunk_text:
other than ourselves, which is not good, I think is what it's called in the business. 1351.82s - 1365.91s | All right. Work with me here. Nope. Hands. Perfect. Um, so I did find out after I tested 1365.93s - 1370.03s | this again, after they made the source code available, that they made that race window really 1370.03s - 1374.97s | short. So I assumed that the way it worked was the victim process ran its command 1374.97s - 1381.01s | successfully and then went ahead and uh, then went ahead and closed the socket after it was 1381.01s - 1385.97s | done. In fact, as soon as you called that elevation request API, it locked all future calls 1385.97s - 1391.19s | of it, which would explain why I had to run the command over and over again, going slowly 1391.23s - 1396.31s | and saying until it worked, but I don't know, not, not really a security control, but good for 1396.31s - 1401.91s | them for locking out other users and thinking about it. So the second vulnerability I 1401.91s - 1406.65s | mentioned, it's still under embargo, unfortunately. Um, I reported it 13th of June while the 1406.65s - 1412.75s | rest of this research was done, April, May timeframe. Um, sort of interesting story for you 1412.75s - 1417.59s | since I can't talk too much about the details of this one. The reason I thought of this was I 1417.59s - 1423.69s | was on a run trying to avoid working on the slides and I realized that there was some other 1423.69s - 1429.63s | issues with how they do that client server thing. So I was able to prove it out and get data 1429.63s - 1433.93s | tampering and information disclosure from again, the process or the perspective of a non 1433.93s - 1441.96s | privileged user on the privileged users stuff. So public issues again, it is a GitHub repo. 1441.96s - 1446.12s | There are public issues that I think are sort of notable to talk about when we talk about 1446.12s - 1450.38s | sudo for Windows. The first one, um, the elevation prompt is confusing. So there's a 1450.38s - 1455.12s | screenshot of it on the right. You saw it earlier in the video. You don't know what hitting yes 1455.12s - 1459.06s | will


chunk_id: 159_chunk_28
chunk_text:
while the 1406.65s - 1412.75s | rest of this research was done, April, May timeframe. Um, sort of interesting story for you 1412.75s - 1417.59s | since I can't talk too much about the details of this one. The reason I thought of this was I 1417.59s - 1423.69s | was on a run trying to avoid working on the slides and I realized that there was some other 1423.69s - 1429.63s | issues with how they do that client server thing. So I was able to prove it out and get data 1429.63s - 1433.93s | tampering and information disclosure from again, the process or the perspective of a non 1433.93s - 1441.96s | privileged user on the privileged users stuff. So public issues again, it is a GitHub repo. 1441.96s - 1446.12s | There are public issues that I think are sort of notable to talk about when we talk about 1446.12s - 1450.38s | sudo for Windows. The first one, um, the elevation prompt is confusing. So there's a 1450.38s - 1455.12s | screenshot of it on the right. You saw it earlier in the video. You don't know what hitting yes 1455.12s - 1459.06s | will do because it's just telling you it's a sudo invocation, right? It doesn't tell you, oh, 1459.06s - 1462.62s | sudo is actually going to spawn this other process over here. Maybe you don't want to do that. 1462.62s - 1469.20s | It just says, hi, I'm Microsoft. I'm a legitimate binary. Would you like me to run? Um, not 1469.20s - 1473.18s | great from a security perspective, right? Admittedly, again, most of us probably just click 1473.20s - 1477.40s | yes as fast as humanly possible anyway, or type in our credentials if we have that version 1477.40s - 1484.14s | of UAC enabled. But, um, I believe that they committed to trying to figure out how to make 1484.14s - 1487.88s | it so it was more obvious what the actual command that's going to run is instead of just 1487.88s - 1491.66s | saying, yeah, it's, it says it's legitimate. I'm just going to hit yes and hope everything's 1491.66s - 1496.32s | okay. And the second issue, uh, which is critical to me because I like my computers to 1496.32s - 1503.06s | insult me is, um, sudo for Linux or Unix if you will,


chunk_id: 159_chunk_29
chunk_text:
do because it's just telling you it's a sudo invocation, right? It doesn't tell you, oh, 1459.06s - 1462.62s | sudo is actually going to spawn this other process over here. Maybe you don't want to do that. 1462.62s - 1469.20s | It just says, hi, I'm Microsoft. I'm a legitimate binary. Would you like me to run? Um, not 1469.20s - 1473.18s | great from a security perspective, right? Admittedly, again, most of us probably just click 1473.20s - 1477.40s | yes as fast as humanly possible anyway, or type in our credentials if we have that version 1477.40s - 1484.14s | of UAC enabled. But, um, I believe that they committed to trying to figure out how to make 1484.14s - 1487.88s | it so it was more obvious what the actual command that's going to run is instead of just 1487.88s - 1491.66s | saying, yeah, it's, it says it's legitimate. I'm just going to hit yes and hope everything's 1491.66s - 1496.32s | okay. And the second issue, uh, which is critical to me because I like my computers to 1496.32s - 1503.06s | insult me is, um, sudo for Linux or Unix if you will, has a mode to have it insult you. 1503.08s - 1507.78s | If you don't have legitimate access to run a command, uh, I want that in windows cause I 1507.78s - 1515.65s | like my computers to be mean to me when I'm silly. So summary of everything we just 1515.65s - 1519.85s | talked about, sudo for windows is coming soon. Again, it is scheduled to be in mainline 1519.85s - 1525.79s | windows 11 and I think windows server, don't quote me on that one. Uh, end of September 1525.79s - 1530.83s | ish in the, in the H2 update, uh, it's open source. Again, we, we love to see that. It 1530.83s - 1534.53s | makes it so people like me or people like anyone in this audience can go look at the 1534.57s - 1538.91s | source code and pull it apart and understand not only how it works, but maybe find some 1538.91s - 1543.71s | more security issues in it. So we're not shipping products that are enabling bad things 1543.71s - 1547.75s | to happen on windows or if you're on the other side of it, using it to make bad things


chunk_id: 159_chunk_30
chunk_text:
has a mode to have it insult you. 1503.08s - 1507.78s | If you don't have legitimate access to run a command, uh, I want that in windows cause I 1507.78s - 1515.65s | like my computers to be mean to me when I'm silly. So summary of everything we just 1515.65s - 1519.85s | talked about, sudo for windows is coming soon. Again, it is scheduled to be in mainline 1519.85s - 1525.79s | windows 11 and I think windows server, don't quote me on that one. Uh, end of September 1525.79s - 1530.83s | ish in the, in the H2 update, uh, it's open source. Again, we, we love to see that. It 1530.83s - 1534.53s | makes it so people like me or people like anyone in this audience can go look at the 1534.57s - 1538.91s | source code and pull it apart and understand not only how it works, but maybe find some 1538.91s - 1543.71s | more security issues in it. So we're not shipping products that are enabling bad things 1543.71s - 1547.75s | to happen on windows or if you're on the other side of it, using it to make bad things 1547.75s - 1553.63s | happen on windows. I don't know. I don't judge. Um, it is meant to be a drop in replacement 1553.63s - 1557.27s | for the way sudo works on Linux. So it lets you actually have standard in standard out 1557.27s - 1561.03s | standard air piped and redirected and all that stuff within your command prompt or your 1561.03s - 1566.61s | PowerShell prompt. Um, and it does all of that using user account control to elevate 1566.61s - 1572.85s | processes and inner process, uh, communication to actually coordinate that across the not 1572.85s - 1578.15s | a trust boundary because that's not what Microsoft calls it of UAC. Uh, sort of the big 1578.15s - 1583.45s | takeaway for me and it's informing some more stuff I'm looking into is you cannot call a 1583.45s - 1588.47s | windows native API without going into unsafe rust. If you want to do that or for anything 1588.87s - 1595.37s | that uses a windows API, that means there is now the potential for you to get memory 1595.37s - 1601.35s | corruption vulnerabilities in something written in rust, which is counter to what everyone


chunk_id: 159_chunk_31
chunk_text:
1547.75s - 1553.63s | happen on windows. I don't know. I don't judge. Um, it is meant to be a drop in replacement 1553.63s - 1557.27s | for the way sudo works on Linux. So it lets you actually have standard in standard out 1557.27s - 1561.03s | standard air piped and redirected and all that stuff within your command prompt or your 1561.03s - 1566.61s | PowerShell prompt. Um, and it does all of that using user account control to elevate 1566.61s - 1572.85s | processes and inner process, uh, communication to actually coordinate that across the not 1572.85s - 1578.15s | a trust boundary because that's not what Microsoft calls it of UAC. Uh, sort of the big 1578.15s - 1583.45s | takeaway for me and it's informing some more stuff I'm looking into is you cannot call a 1583.45s - 1588.47s | windows native API without going into unsafe rust. If you want to do that or for anything 1588.87s - 1595.37s | that uses a windows API, that means there is now the potential for you to get memory 1595.37s - 1601.35s | corruption vulnerabilities in something written in rust, which is counter to what everyone 1601.35s - 1605.05s | tells you about rust. So be on the lookout for that if you're a bug hunter that if you see 1605.05s - 1609.03s | something calling a windows native API from a rust program, somewhere in that code it is 1609.03s - 1615.87s | unsafe. Poke at that boundary. And then I'll show some references and if anyone has any 1615.87s - 1620.17s | questions, you can step up to that mic in the middle and I'll be happy to answer them. I 1620.17s - 1635.08s | don't know how much time I have left, but I'll answer any questions I can. Thank you. Cool. 1635.08s - 1636.08s | Well, thanks everyone.


chunk_id: 159_chunk_32
chunk_text:
1601.35s - 1605.05s | tells you about rust. So be on the lookout for that if you're a bug hunter that if you see 1605.05s - 1609.03s | something calling a windows native API from a rust program, somewhere in that code it is 1609.03s - 1615.87s | unsafe. Poke at that boundary. And then I'll show some references and if anyone has any 1615.87s - 1620.17s | questions, you can step up to that mic in the middle and I'll be happy to answer them. I 1620.17s - 1635.08s | don't know how much time I have left, but I'll answer any questions I can. Thank you. Cool. 1635.08s - 1636.08s | Well, thanks everyone.


chunk_id: 160_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=-Z34ya4rb8A", "title": "DEF CON 32 - Manipulating Shim and Office for Code Injection - Ron Ben-Yizhak, David Shandalov", "description": "This talk brings back from the dead an attack surface that security vendors believed they had addressed a long time ago.\n\nWe will introduce a novel and stealthy technique to apply malicious shims on a process that does not require registry modification or SDB files and leaves no traces on the disk.\n\nThe reverse engineering of the shim infrastructure will be shown while focusing on undocumented API and the kernel driver of the infrastructure.\n\nThe various operations offered by the infrastructure will be analyzed from an offensive point of view, and the course we took to achieve this unique technique will be presented.\n\nIn addition, we will unveil an attack surface research that resulted in a noteworthy attack that manipulates 2 different OS components into performing DLL injection and privilege escalation.\n\nResearching the undocumented RPC interfaces of the service OfficeClickToRun.exe uncovered a method that can inject a DLL into another process running as \u201cNT AUTHORITY\\SYSTEM\u201d, which achieves privilege escalation. For this to work, specific conditions had to be met.\n\nThe conditions we tailored will be displayed as we abuse the Opportunistic Lock and App Compatibility (shim) mechanisms.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2472, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.82s - 4.38s | This text was transcribed using whisper model: large-v2 Hello everyone, thank you for coming to our talk, 4.38s - 5.94s | Shimmy What You Got, 5.94s - 9.18s | Manipulating Shim and Office for Code Injection. 9.18s - 11.06s | We're very excited to be here. 11.06s - 12.58s | Let's introduce ourselves. 13.86s - 15.74s | My name is Ron Ben-Yitzhak. 15.74s - 17.86s | I'm a security researcher at Deep Instinct. 17.86s - 19.58s | And this is the third year in a row 19.58s - 25.85s | I'm speaking here at DEF CON. 25.85s - 27.93s | And my name is David Shandalov. 27.93s - 30.45s | I'm also a security researcher at Deep Instinct. 30.45s - 39.13s | And this is my first time here. 39.17s - 41.69s | This is what we're going to talk about today. 41.69s - 43.25s | I'll start with an intro 43.25s - 45.53s | about the App Compatibility Framework, 45.53s - 48.77s | what it is made of and known techniques to abuse it. 48.77s - 52.17s | Then I'll dive into


chunk_id: 160_chunk_1
chunk_text:
(shim) mechanisms.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2472, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.82s - 4.38s | This text was transcribed using whisper model: large-v2 Hello everyone, thank you for coming to our talk, 4.38s - 5.94s | Shimmy What You Got, 5.94s - 9.18s | Manipulating Shim and Office for Code Injection. 9.18s - 11.06s | We're very excited to be here. 11.06s - 12.58s | Let's introduce ourselves. 13.86s - 15.74s | My name is Ron Ben-Yitzhak. 15.74s - 17.86s | I'm a security researcher at Deep Instinct. 17.86s - 19.58s | And this is the third year in a row 19.58s - 25.85s | I'm speaking here at DEF CON. 25.85s - 27.93s | And my name is David Shandalov. 27.93s - 30.45s | I'm also a security researcher at Deep Instinct. 30.45s - 39.13s | And this is my first time here. 39.17s - 41.69s | This is what we're going to talk about today. 41.69s - 43.25s | I'll start with an intro 43.25s - 45.53s | about the App Compatibility Framework, 45.53s - 48.77s | what it is made of and known techniques to abuse it. 48.77s - 52.17s | Then I'll dive into our attack surface research 52.17s - 53.81s | on Microsoft Office. 53.81s - 56.81s | I'll show how we found an interesting RPC method 56.81s - 60.45s | and combined several manipulations into a single attack 60.45s - 64.77s | that achieves both code injection and privilege escalation. 64.77s - 67.69s | Then we'll show another novel attack. 67.69s - 70.73s | We'll show the reverse engineering process of the driver 70.73s - 72.69s | and the undocumented structures 72.69s - 75.13s | that make the App Compatibility Mechanism 75.13s - 77.53s | and how we discovered the finest technique 77.53s - 80.05s | to apply a malicious shim on a process. 80.05s - 81.57s | At the conclusion of the talk, 81.57s - 85.41s | we'll discuss how to detect the attacks shown here 85.41s - 90.22s | and how the community can continue our research. 90.22s - 91.74s | The App Compatibility Framework 91.74s - 94.46s | is used for backwards compatibility. 94.46s - 97.26s | Software developed for old versions of Windows 97.26s - 100.30s | might behave unexpectedly on newer versions. 100.30s - 103.10s | Microsoft offers many compatibility modes 103.10s - 106.26s | that might


chunk_id: 160_chunk_2
chunk_text:
our attack surface research 52.17s - 53.81s | on Microsoft Office. 53.81s - 56.81s | I'll show how we found an interesting RPC method 56.81s - 60.45s | and combined several manipulations into a single attack 60.45s - 64.77s | that achieves both code injection and privilege escalation. 64.77s - 67.69s | Then we'll show another novel attack. 67.69s - 70.73s | We'll show the reverse engineering process of the driver 70.73s - 72.69s | and the undocumented structures 72.69s - 75.13s | that make the App Compatibility Mechanism 75.13s - 77.53s | and how we discovered the finest technique 77.53s - 80.05s | to apply a malicious shim on a process. 80.05s - 81.57s | At the conclusion of the talk, 81.57s - 85.41s | we'll discuss how to detect the attacks shown here 85.41s - 90.22s | and how the community can continue our research. 90.22s - 91.74s | The App Compatibility Framework 91.74s - 94.46s | is used for backwards compatibility. 94.46s - 97.26s | Software developed for old versions of Windows 97.26s - 100.30s | might behave unexpectedly on newer versions. 100.30s - 103.10s | Microsoft offers many compatibility modes 103.10s - 106.26s | that might look familiar from this window. 106.26s - 108.78s | Programs might access registry paths 108.78s - 111.34s | or directories that no longer exist, 111.34s - 114.62s | such as the C documented settings for those who remember. 115.58s - 118.46s | Those issues are fixed with API hooking, 118.46s - 120.50s | patching the assembly of the program itself 120.50s - 122.50s | and other runtime modifications. 123.78s - 126.90s | Behind the scenes, this is how the mechanism works. 127.58s - 130.82s | The OS uses shim database files, or SDB files, 130.82s - 132.46s | that contain the fixes and modes 132.46s - 134.46s | various applications require. 134.46s - 137.18s | The main file is sysmain.sdb. 137.18s - 139.02s | It is maintained by Microsoft 139.02s - 142.26s | and can only be modified by system updates. 142.26s - 144.70s | We can view those files using a graphic software 144.70s - 148.14s | provided by Microsoft, the Compatibility Administrator. 149.86s - 152.22s | Here we can see that Age of Empires III 152.22s - 155.54s | requires the compatibility mode High DPI Aware. 155.54s - 158.34s | Users can also install custom SDB files 158.34s


chunk_id: 160_chunk_3
chunk_text:
look familiar from this window. 106.26s - 108.78s | Programs might access registry paths 108.78s - 111.34s | or directories that no longer exist, 111.34s - 114.62s | such as the C documented settings for those who remember. 115.58s - 118.46s | Those issues are fixed with API hooking, 118.46s - 120.50s | patching the assembly of the program itself 120.50s - 122.50s | and other runtime modifications. 123.78s - 126.90s | Behind the scenes, this is how the mechanism works. 127.58s - 130.82s | The OS uses shim database files, or SDB files, 130.82s - 132.46s | that contain the fixes and modes 132.46s - 134.46s | various applications require. 134.46s - 137.18s | The main file is sysmain.sdb. 137.18s - 139.02s | It is maintained by Microsoft 139.02s - 142.26s | and can only be modified by system updates. 142.26s - 144.70s | We can view those files using a graphic software 144.70s - 148.14s | provided by Microsoft, the Compatibility Administrator. 149.86s - 152.22s | Here we can see that Age of Empires III 152.22s - 155.54s | requires the compatibility mode High DPI Aware. 155.54s - 158.34s | Users can also install custom SDB files 158.34s - 160.74s | by writing them to these registry paths. 162.54s - 164.50s | Like every component of the OS, 164.50s - 166.70s | people looked for ways to abuse it. 166.70s - 168.58s | There were several talks over the years 168.58s - 171.74s | about the malicious implications to the shim framework. 171.74s - 175.02s | Here you can see a DEF CON talk from almost 10 years ago 175.02s - 177.98s | that shows shims can be used for credential access, 177.98s - 180.30s | network redirection, and more. 180.30s - 183.46s | Also, Alex UNESCO released several articles 183.46s - 186.50s | about this subject back in 2007. 186.50s - 189.10s | Because this is such an old attack vector, 189.10s - 192.38s | most security products should detect malicious shim usage. 192.38s - 194.10s | And the easiest way to do it 194.10s - 196.14s | is by monitoring the registry paths 196.14s - 198.70s | used for installing custom SDB files. 200.06s - 203.10s | So once upon a time, David and I 203.10s - 205.26s | wanted to start a new research. 205.26s - 207.82s | Initially, we thought about bypassing an EDR


chunk_id: 160_chunk_4
chunk_text:
- 160.74s | by writing them to these registry paths. 162.54s - 164.50s | Like every component of the OS, 164.50s - 166.70s | people looked for ways to abuse it. 166.70s - 168.58s | There were several talks over the years 168.58s - 171.74s | about the malicious implications to the shim framework. 171.74s - 175.02s | Here you can see a DEF CON talk from almost 10 years ago 175.02s - 177.98s | that shows shims can be used for credential access, 177.98s - 180.30s | network redirection, and more. 180.30s - 183.46s | Also, Alex UNESCO released several articles 183.46s - 186.50s | about this subject back in 2007. 186.50s - 189.10s | Because this is such an old attack vector, 189.10s - 192.38s | most security products should detect malicious shim usage. 192.38s - 194.10s | And the easiest way to do it 194.10s - 196.14s | is by monitoring the registry paths 196.14s - 198.70s | used for installing custom SDB files. 200.06s - 203.10s | So once upon a time, David and I 203.10s - 205.26s | wanted to start a new research. 205.26s - 207.82s | Initially, we thought about bypassing an EDR 207.82s - 209.86s | or even disabling it. 209.90s - 213.38s | But apparently, some products just disable themselves. 214.26s - 216.14s | So instead of EDR bypass, 216.14s - 218.82s | we decided to start an attack surface research, 218.82s - 220.54s | and we needed the targets. 220.54s - 223.86s | One of the first choices we came up with is Office. 223.86s - 225.94s | This software is very popular. 225.94s - 228.78s | It can be found on almost every Windows machine. 228.78s - 230.62s | It is also very complex. 230.62s - 233.14s | It has com objects, scripting engines, 233.14s - 235.26s | cloud synchronization, and more. 235.26s - 236.98s | The more components there are, 236.98s - 239.54s | the higher the chances to find an issue. 239.54s - 241.86s | And the most promising feature about Office 241.86s - 244.06s | is the backwards compatibility. 244.06s - 246.54s | It was released over 30 years ago, 246.54s - 249.62s | and legacy code is usually the problematic one, 249.62s - 251.06s | which is good for us. 252.14s - 254.46s | Now let's talk about the research itself. 255.94s - 259.38s |


chunk_id: 160_chunk_5
chunk_text:
207.82s - 209.86s | or even disabling it. 209.90s - 213.38s | But apparently, some products just disable themselves. 214.26s - 216.14s | So instead of EDR bypass, 216.14s - 218.82s | we decided to start an attack surface research, 218.82s - 220.54s | and we needed the targets. 220.54s - 223.86s | One of the first choices we came up with is Office. 223.86s - 225.94s | This software is very popular. 225.94s - 228.78s | It can be found on almost every Windows machine. 228.78s - 230.62s | It is also very complex. 230.62s - 233.14s | It has com objects, scripting engines, 233.14s - 235.26s | cloud synchronization, and more. 235.26s - 236.98s | The more components there are, 236.98s - 239.54s | the higher the chances to find an issue. 239.54s - 241.86s | And the most promising feature about Office 241.86s - 244.06s | is the backwards compatibility. 244.06s - 246.54s | It was released over 30 years ago, 246.54s - 249.62s | and legacy code is usually the problematic one, 249.62s - 251.06s | which is good for us. 252.14s - 254.46s | Now let's talk about the research itself. 255.94s - 259.38s | We wanted to find RPC servers related to Office, 259.38s - 262.62s | and that led us to the service ClickToRunSVC. 263.70s - 267.18s | Here you can see the RPC interfaces it exposes. 267.22s - 270.54s | And narrowing down this list to files related to Office 270.54s - 272.38s | results in three files. 272.38s - 275.46s | The actual executable of the service, 275.46s - 277.42s | OfficeClickToRun.exe, 277.42s - 279.74s | and let's skip the long prefix 279.74s - 282.86s | and just call them virtualization.dll 282.86s - 287.59s | and subsystemcontroller.dll. 287.59s - 289.47s | We started looking into these files 289.47s - 291.71s | to see what functionality they provide, 291.71s - 294.87s | and we found an interesting string in the virtualization.dll. 295.87s - 299.15s | Could not inject subsystem.dll to child process. 299.15s - 302.51s | And lucky us, this string is used by a function 302.51s - 304.83s | that is exposed through RPC. 304.83s - 307.43s | This means that you can easily invoke it. 307.43s - 310.31s | Still, before we start reverse engineering 310.31s - 313.23s | the RPC interface and its methods, 313.23s - 317.11s | we


chunk_id: 160_chunk_6
chunk_text:
We wanted to find RPC servers related to Office, 259.38s - 262.62s | and that led us to the service ClickToRunSVC. 263.70s - 267.18s | Here you can see the RPC interfaces it exposes. 267.22s - 270.54s | And narrowing down this list to files related to Office 270.54s - 272.38s | results in three files. 272.38s - 275.46s | The actual executable of the service, 275.46s - 277.42s | OfficeClickToRun.exe, 277.42s - 279.74s | and let's skip the long prefix 279.74s - 282.86s | and just call them virtualization.dll 282.86s - 287.59s | and subsystemcontroller.dll. 287.59s - 289.47s | We started looking into these files 289.47s - 291.71s | to see what functionality they provide, 291.71s - 294.87s | and we found an interesting string in the virtualization.dll. 295.87s - 299.15s | Could not inject subsystem.dll to child process. 299.15s - 302.51s | And lucky us, this string is used by a function 302.51s - 304.83s | that is exposed through RPC. 304.83s - 307.43s | This means that you can easily invoke it. 307.43s - 310.31s | Still, before we start reverse engineering 310.31s - 313.23s | the RPC interface and its methods, 313.23s - 317.11s | we wanted to make sure it actually performs DLL injection. 317.11s - 318.79s | So we debugged it, 318.79s - 321.91s | put breakpoints on API used for code injection, 321.91s - 323.71s | and then we launched Word. 323.71s - 327.15s | That caused the service to call write-process-memory. 327.15s - 330.99s | This diagram shows the call stack that led to this API. 330.99s - 334.19s | The RPC call went through several undocumented functions 334.19s - 339.43s | in a few DLL files until it reached write-process-memory. 339.43s - 341.79s | So what is this DLL? 341.79s - 344.35s | The file description is Microsoft Application 344.35s - 348.03s | Virtualization Client Virtualization Manager Component. 348.03s - 350.79s | And yes, it says virtualization twice. 351.79s - 355.43s | This file exposes two undocumented RPC methods. 355.43s - 357.87s | Instead of diving headfirst into the code, 357.87s - 359.27s | we wanted to find symbols 359.27s - 362.03s | that can shed some light on these functions. 362.03s - 364.63s | We used PowerShell to find RPC clients, 364.63s - 369.63s | and that led us to a file that has symbols, subsystem64.dll. 370.15s - 372.43s |


chunk_id: 160_chunk_7
chunk_text:
wanted to make sure it actually performs DLL injection. 317.11s - 318.79s | So we debugged it, 318.79s - 321.91s | put breakpoints on API used for code injection, 321.91s - 323.71s | and then we launched Word. 323.71s - 327.15s | That caused the service to call write-process-memory. 327.15s - 330.99s | This diagram shows the call stack that led to this API. 330.99s - 334.19s | The RPC call went through several undocumented functions 334.19s - 339.43s | in a few DLL files until it reached write-process-memory. 339.43s - 341.79s | So what is this DLL? 341.79s - 344.35s | The file description is Microsoft Application 344.35s - 348.03s | Virtualization Client Virtualization Manager Component. 348.03s - 350.79s | And yes, it says virtualization twice. 351.79s - 355.43s | This file exposes two undocumented RPC methods. 355.43s - 357.87s | Instead of diving headfirst into the code, 357.87s - 359.27s | we wanted to find symbols 359.27s - 362.03s | that can shed some light on these functions. 362.03s - 364.63s | We used PowerShell to find RPC clients, 364.63s - 369.63s | and that led us to a file that has symbols, subsystem64.dll. 370.15s - 372.43s | Again, I'm going to skip the long names. 372.43s - 375.59s | The functions in the client are called notifyNewProcess 375.59s - 377.67s | and notifyNewChildProcess. 377.67s - 380.43s | We didn't find anything interesting about the first one. 381.11s - 382.67s | The second function causes the server 382.67s - 386.97s | to call write-process-memory. 386.97s - 388.69s | Now we want to understand the flow 388.69s - 390.65s | that leads to the DLL injection. 390.65s - 393.25s | So we'll start by debugging the client. 393.25s - 395.85s | We notice that before Word performs the call, 395.85s - 400.85s | it spawns ai.exe as a child process in a suspended state. 400.93s - 402.81s | Then we reach the call itself. 402.81s - 406.05s | We reverse-engineered it and came with its definition. 406.05s - 408.49s | This syntax is for the IDL file. 408.49s - 410.37s | It sends two parameters. 410.41s - 415.41s | The process ID of ai.exe and the string subsystem64.dll, 415.81s - 417.89s | the name of the DLL that made the call. 419.41s - 422.21s | Time to switch sides to the RPC server. 422.21s - 426.09s | Like I


chunk_id: 160_chunk_8
chunk_text:
Again, I'm going to skip the long names. 372.43s - 375.59s | The functions in the client are called notifyNewProcess 375.59s - 377.67s | and notifyNewChildProcess. 377.67s - 380.43s | We didn't find anything interesting about the first one. 381.11s - 382.67s | The second function causes the server 382.67s - 386.97s | to call write-process-memory. 386.97s - 388.69s | Now we want to understand the flow 388.69s - 390.65s | that leads to the DLL injection. 390.65s - 393.25s | So we'll start by debugging the client. 393.25s - 395.85s | We notice that before Word performs the call, 395.85s - 400.85s | it spawns ai.exe as a child process in a suspended state. 400.93s - 402.81s | Then we reach the call itself. 402.81s - 406.05s | We reverse-engineered it and came with its definition. 406.05s - 408.49s | This syntax is for the IDL file. 408.49s - 410.37s | It sends two parameters. 410.41s - 415.41s | The process ID of ai.exe and the string subsystem64.dll, 415.81s - 417.89s | the name of the DLL that made the call. 419.41s - 422.21s | Time to switch sides to the RPC server. 422.21s - 426.09s | Like I said before, those DLL files are undocumented, 426.09s - 428.93s | and we want to save time on reverse-engineering them. 428.93s - 431.13s | We searched for all the files that are related 431.13s - 433.21s | to the app virtualization platform 433.21s - 435.65s | and found out that there are files with similar names 435.65s - 437.81s | in the system32 directory. 437.81s - 439.89s | Those files have symbols, 439.89s - 443.09s | and they show that the DTools library is being used. 443.09s - 446.73s | This is an official library by Microsoft used for hooking, 446.73s - 449.97s | and it can also inject code into another process. 449.97s - 453.21s | The functions DToolUpdateProcessWithDLL 453.21s - 455.85s | and DToolCopyPayloadToProcess are used 455.85s - 458.65s | to patch the import address table of the target process 458.65s - 460.65s | and force it to load a DLL. 460.65s - 462.73s | Comparing the two files with bindif 462.73s - 464.85s | further proves the similarities. 464.85s - 467.93s | The name primary column belongs to the office file, 467.93s - 471.77s | and the name secondary column belongs to the system32 file. 471.77s -


chunk_id: 160_chunk_9
chunk_text:
said before, those DLL files are undocumented, 426.09s - 428.93s | and we want to save time on reverse-engineering them. 428.93s - 431.13s | We searched for all the files that are related 431.13s - 433.21s | to the app virtualization platform 433.21s - 435.65s | and found out that there are files with similar names 435.65s - 437.81s | in the system32 directory. 437.81s - 439.89s | Those files have symbols, 439.89s - 443.09s | and they show that the DTools library is being used. 443.09s - 446.73s | This is an official library by Microsoft used for hooking, 446.73s - 449.97s | and it can also inject code into another process. 449.97s - 453.21s | The functions DToolUpdateProcessWithDLL 453.21s - 455.85s | and DToolCopyPayloadToProcess are used 455.85s - 458.65s | to patch the import address table of the target process 458.65s - 460.65s | and force it to load a DLL. 460.65s - 462.73s | Comparing the two files with bindif 462.73s - 464.85s | further proves the similarities. 464.85s - 467.93s | The name primary column belongs to the office file, 467.93s - 471.77s | and the name secondary column belongs to the system32 file. 471.77s - 473.93s | Those functions are a perfect match. 475.73s - 478.25s | We can easily understand how the injection is done 478.25s - 480.05s | with the source code of DTools. 480.05s - 482.21s | The optional header is modified to point 482.21s - 484.17s | to a new copy of the import table 484.17s - 486.53s | that includes an additional import descriptor 486.53s - 488.29s | to the injected DLL. 488.29s - 490.89s | This is how WinDebug displays the headers. 490.89s - 494.45s | We can see the full path to the DLL, which is unusual. 494.45s - 498.16s | Compilers link the base name. 498.16s - 500.88s | This is everything done by the RPC server. 500.88s - 502.48s | Now let's go back to the client 502.48s - 504.80s | and finish going through this process. 504.80s - 506.96s | Word resumes ai.txt, 506.96s - 509.56s | and since the process is not yet initialized, 509.56s - 511.84s | the loader uses the new import table. 511.84s - 516.48s | Because of that, subsystem64 is loaded into the process. 516.48s - 520.20s | We looked at what happens if we imitate the RPC call 520.20s


chunk_id: 160_chunk_10
chunk_text:
473.93s | Those functions are a perfect match. 475.73s - 478.25s | We can easily understand how the injection is done 478.25s - 480.05s | with the source code of DTools. 480.05s - 482.21s | The optional header is modified to point 482.21s - 484.17s | to a new copy of the import table 484.17s - 486.53s | that includes an additional import descriptor 486.53s - 488.29s | to the injected DLL. 488.29s - 490.89s | This is how WinDebug displays the headers. 490.89s - 494.45s | We can see the full path to the DLL, which is unusual. 494.45s - 498.16s | Compilers link the base name. 498.16s - 500.88s | This is everything done by the RPC server. 500.88s - 502.48s | Now let's go back to the client 502.48s - 504.80s | and finish going through this process. 504.80s - 506.96s | Word resumes ai.txt, 506.96s - 509.56s | and since the process is not yet initialized, 509.56s - 511.84s | the loader uses the new import table. 511.84s - 516.48s | Because of that, subsystem64 is loaded into the process. 516.48s - 520.20s | We looked at what happens if we imitate the RPC call 520.20s - 523.40s | but specify a 32-bit process as the target. 523.40s - 525.24s | In this case, Office Click-to-Run 525.24s - 528.40s | isn't writing to the memory of this process directly. 528.40s - 530.96s | It launches the tool mavinject32, 530.96s - 533.24s | which is known as a living off-the-land binary, 533.24s - 537.40s | but the injection is exactly the same. 537.40s - 539.36s | Now we want to understand exactly, 539.36s - 542.36s | now that we know exactly how the DLL is injected, 542.36s - 544.16s | what can we gain from it? 544.16s - 547.76s | Security products detect all kinds of malicious behavior, 547.76s - 551.72s | file encryption, shellcode execution, and code injection. 551.72s - 554.52s | But sometimes legitimate programs do that. 554.52s - 556.16s | We just saw an example. 556.16s - 559.72s | And to avoid generating false positive events for customers, 559.72s - 563.00s | such programs will be excluded by the products. 563.00s - 565.36s | This means that if we force Office Click-to-Run 565.36s - 568.48s | to inject the DLL, we'll be able to bypass detection. 569.56s - 572.04s | We know the definition


chunk_id: 160_chunk_11
chunk_text:
- 523.40s | but specify a 32-bit process as the target. 523.40s - 525.24s | In this case, Office Click-to-Run 525.24s - 528.40s | isn't writing to the memory of this process directly. 528.40s - 530.96s | It launches the tool mavinject32, 530.96s - 533.24s | which is known as a living off-the-land binary, 533.24s - 537.40s | but the injection is exactly the same. 537.40s - 539.36s | Now we want to understand exactly, 539.36s - 542.36s | now that we know exactly how the DLL is injected, 542.36s - 544.16s | what can we gain from it? 544.16s - 547.76s | Security products detect all kinds of malicious behavior, 547.76s - 551.72s | file encryption, shellcode execution, and code injection. 551.72s - 554.52s | But sometimes legitimate programs do that. 554.52s - 556.16s | We just saw an example. 556.16s - 559.72s | And to avoid generating false positive events for customers, 559.72s - 563.00s | such programs will be excluded by the products. 563.00s - 565.36s | This means that if we force Office Click-to-Run 565.36s - 568.48s | to inject the DLL, we'll be able to bypass detection. 569.56s - 572.04s | We know the definition of the RPC method, 572.04s - 576.00s | and we can imitate it to inject subsystem64.dll. 576.00s - 580.36s | But the big question is, can we inject another DLL? 580.36s - 583.32s | As I showed before, the function receives a string, 583.32s - 586.28s | so we can just change the name of the file. 586.28s - 588.32s | But that means we'll have to write our DLL 588.32s - 591.36s | to the office directory, which is very suspicious, 591.36s - 593.68s | and it also requires admin privileges. 595.40s - 597.80s | We tried providing a full path to the file 597.80s - 601.40s | instead of the base name, and this is what happened. 601.40s - 604.64s | We changed the string to ctemp-injected.dll, 604.64s - 608.00s | and it was appended as it is to the office directory. 608.00s - 611.20s | This should raise a flag for every security researcher. 611.20s - 614.60s | It means that there are no sanity checks on the inputs. 614.60s - 619.30s | So we can go back to the 90s and use directory traversal. 619.30s - 620.92s | We can manipulate the file lookup 620.92s -


chunk_id: 160_chunk_12
chunk_text:
of the RPC method, 572.04s - 576.00s | and we can imitate it to inject subsystem64.dll. 576.00s - 580.36s | But the big question is, can we inject another DLL? 580.36s - 583.32s | As I showed before, the function receives a string, 583.32s - 586.28s | so we can just change the name of the file. 586.28s - 588.32s | But that means we'll have to write our DLL 588.32s - 591.36s | to the office directory, which is very suspicious, 591.36s - 593.68s | and it also requires admin privileges. 595.40s - 597.80s | We tried providing a full path to the file 597.80s - 601.40s | instead of the base name, and this is what happened. 601.40s - 604.64s | We changed the string to ctemp-injected.dll, 604.64s - 608.00s | and it was appended as it is to the office directory. 608.00s - 611.20s | This should raise a flag for every security researcher. 611.20s - 614.60s | It means that there are no sanity checks on the inputs. 614.60s - 619.30s | So we can go back to the 90s and use directory traversal. 619.30s - 620.92s | We can manipulate the file lookup 620.92s - 623.36s | to a completely different place. 623.36s - 625.50s | Let's display the headers of the process again 625.50s - 629.34s | with WinDebug, this time after we manipulated the call. 629.34s - 631.32s | We can see our malicious string was appended 631.32s - 633.20s | to the office directory and written 633.20s - 634.84s | to the memory of the process. 636.36s - 639.78s | With this trick, we can inject any DLL we want. 639.78s - 642.14s | But there are still a few limitations. 642.14s - 644.62s | The modified import address table will be used 644.62s - 647.06s | only if the process was launched as suspended 647.06s - 649.58s | and wasn't resumed until the injection was done. 649.58s - 651.82s | It must be uninitialized. 651.82s - 653.72s | Right now, we have a new technique 653.72s - 656.94s | to force a legitimate program to inject a DLL for us, 656.94s - 659.82s | but what more can we achieve from this? 659.82s - 662.34s | A nice thing about RPC is that the client 662.34s - 665.06s | can have lower privileges than the server. 665.06s - 668.22s | The


chunk_id: 160_chunk_13
chunk_text:
623.36s | to a completely different place. 623.36s - 625.50s | Let's display the headers of the process again 625.50s - 629.34s | with WinDebug, this time after we manipulated the call. 629.34s - 631.32s | We can see our malicious string was appended 631.32s - 633.20s | to the office directory and written 633.20s - 634.84s | to the memory of the process. 636.36s - 639.78s | With this trick, we can inject any DLL we want. 639.78s - 642.14s | But there are still a few limitations. 642.14s - 644.62s | The modified import address table will be used 644.62s - 647.06s | only if the process was launched as suspended 647.06s - 649.58s | and wasn't resumed until the injection was done. 649.58s - 651.82s | It must be uninitialized. 651.82s - 653.72s | Right now, we have a new technique 653.72s - 656.94s | to force a legitimate program to inject a DLL for us, 656.94s - 659.82s | but what more can we achieve from this? 659.82s - 662.34s | A nice thing about RPC is that the client 662.34s - 665.06s | can have lower privileges than the server. 665.06s - 668.22s | The office service runs this anti-authority system, 668.22s - 679.15s | so can we perform privilege escalation? 679.15s - 681.63s | Well, the short answer is no. 681.63s - 684.23s | The server calls RPC impersonate client 684.23s - 686.15s | before the injection is done. 686.15s - 688.67s | This means that the thread that handles our request 688.67s - 691.75s | will use our token, and not the token 691.75s - 693.15s | of anti-authority system. 694.15s - 695.99s | This is done to verify that the client 695.99s - 699.15s | has enough permissions to access the remote process. 699.15s - 701.75s | After the impersonation, the request reaches 701.75s - 705.31s | a subsystem controller.dll, which calls open process 705.31s - 707.47s | to gain a handle to the remote process. 707.47s - 710.99s | If we can't get this handle, so will the RPC server, 710.99s - 712.63s | and the call will fail. 712.63s - 715.83s | But still, maybe we can escalate from admin to system. 717.35s - 721.11s | The first step to do that will be to launch a process 721.11s - 724.45s | with the privileges of system in a suspended


chunk_id: 160_chunk_14
chunk_text:
office service runs this anti-authority system, 668.22s - 679.15s | so can we perform privilege escalation? 679.15s - 681.63s | Well, the short answer is no. 681.63s - 684.23s | The server calls RPC impersonate client 684.23s - 686.15s | before the injection is done. 686.15s - 688.67s | This means that the thread that handles our request 688.67s - 691.75s | will use our token, and not the token 691.75s - 693.15s | of anti-authority system. 694.15s - 695.99s | This is done to verify that the client 695.99s - 699.15s | has enough permissions to access the remote process. 699.15s - 701.75s | After the impersonation, the request reaches 701.75s - 705.31s | a subsystem controller.dll, which calls open process 705.31s - 707.47s | to gain a handle to the remote process. 707.47s - 710.99s | If we can't get this handle, so will the RPC server, 710.99s - 712.63s | and the call will fail. 712.63s - 715.83s | But still, maybe we can escalate from admin to system. 717.35s - 721.11s | The first step to do that will be to launch a process 721.11s - 724.45s | with the privileges of system in a suspended state. 724.45s - 727.17s | We used API monitoring to find such calls, 727.17s - 729.27s | and we found that the task scheduler service 729.27s - 731.23s | does exactly that. 731.23s - 733.23s | Scheduled tasks are a great target 733.23s - 735.15s | because there are many default ones 735.99s - 737.39s | that are configured to run a system, 737.39s - 739.91s | and even some that are related to Office, 741.39s - 744.79s | such as this one, Office Automatic Updates 2.0. 744.79s - 746.99s | Our injection will be even less suspicious 746.99s - 749.89s | if the service will inject a DLL to another process 749.89s - 751.71s | that is related to Office, 751.71s - 754.11s | but we still have a few challenges ahead. 754.11s - 756.59s | The task scheduler service resumes the process 756.59s - 758.41s | shortly after it is launched. 758.41s - 760.79s | We need to find a way to hold the execution 760.79s - 762.71s | of the task scheduler service, 762.71s - 767.93s | and we can do that with an opportunistic lock. 767.93s - 770.97s | Opportunistic locks, or OP locks for short,


chunk_id: 160_chunk_15
chunk_text:
state. 724.45s - 727.17s | We used API monitoring to find such calls, 727.17s - 729.27s | and we found that the task scheduler service 729.27s - 731.23s | does exactly that. 731.23s - 733.23s | Scheduled tasks are a great target 733.23s - 735.15s | because there are many default ones 735.99s - 737.39s | that are configured to run a system, 737.39s - 739.91s | and even some that are related to Office, 741.39s - 744.79s | such as this one, Office Automatic Updates 2.0. 744.79s - 746.99s | Our injection will be even less suspicious 746.99s - 749.89s | if the service will inject a DLL to another process 749.89s - 751.71s | that is related to Office, 751.71s - 754.11s | but we still have a few challenges ahead. 754.11s - 756.59s | The task scheduler service resumes the process 756.59s - 758.41s | shortly after it is launched. 758.41s - 760.79s | We need to find a way to hold the execution 760.79s - 762.71s | of the task scheduler service, 762.71s - 767.93s | and we can do that with an opportunistic lock. 767.93s - 770.97s | Opportunistic locks, or OP locks for short, 770.97s - 772.41s | are a special kind of locks 772.41s - 774.37s | that are used to keep data coherency 774.37s - 777.09s | across computers accessing a file server. 777.09s - 778.81s | A client can lock a file, 778.81s - 781.81s | and when another client tries to access the same file, 781.81s - 783.17s | it will wait. 783.17s - 784.89s | The server will break the lock 784.89s - 786.93s | and notify the first client. 786.93s - 788.71s | The new data will be flushed, 788.71s - 790.07s | the file will be closed, 790.07s - 791.93s | and only then the second client 791.93s - 793.89s | will be able to access it. 793.89s - 795.45s | The nice thing about OP locks 795.45s - 796.85s | is that they can be requested 796.85s - 799.81s | from the local file system by a process. 799.81s - 802.13s | This usage is effectively a semaphore 802.13s - 803.97s | managed by the local file system 803.97s - 805.93s | that synchronizes multiple processes. 807.57s - 810.21s | So how does it relate to our attack? 810.21s - 811.57s | If we could find


chunk_id: 160_chunk_16
chunk_text:
770.97s - 772.41s | are a special kind of locks 772.41s - 774.37s | that are used to keep data coherency 774.37s - 777.09s | across computers accessing a file server. 777.09s - 778.81s | A client can lock a file, 778.81s - 781.81s | and when another client tries to access the same file, 781.81s - 783.17s | it will wait. 783.17s - 784.89s | The server will break the lock 784.89s - 786.93s | and notify the first client. 786.93s - 788.71s | The new data will be flushed, 788.71s - 790.07s | the file will be closed, 790.07s - 791.93s | and only then the second client 791.93s - 793.89s | will be able to access it. 793.89s - 795.45s | The nice thing about OP locks 795.45s - 796.85s | is that they can be requested 796.85s - 799.81s | from the local file system by a process. 799.81s - 802.13s | This usage is effectively a semaphore 802.13s - 803.97s | managed by the local file system 803.97s - 805.93s | that synchronizes multiple processes. 807.57s - 810.21s | So how does it relate to our attack? 810.21s - 811.57s | If we could find a file 811.57s - 814.37s | that is accessed by the task scheduler service 814.37s - 815.97s | after the process is created, 815.97s - 817.65s | but before it is resumed, 817.65s - 818.69s | we could lock it, 818.69s - 822.23s | and it will stop the service from resuming the process. 822.23s - 823.57s | Keeping the process suspended 824.25s - 826.37s | will allow us to inject a DLL to it. 826.37s - 829.33s | We monitor the system for file access 829.33s - 832.81s | while launching the scheduled tasks, 832.81s - 835.97s | and we saw that sysmain.sdb was accessed. 835.97s - 838.25s | In this image, we can see the call stack. 838.25s - 840.01s | Inside createProcessInternal, 840.01s - 842.95s | functions related to the app compatibility were called, 842.95s - 847.10s | and then the shim database was opened. 847.10s - 849.28s | At this point, we know that the task scheduler 849.28s - 851.76s | sometimes reads sysmain.sdb, 851.76s - 854.90s | but we need to understand which tasks lead to that. 855.70s - 857.62s | We need to find a task that executes a file 857.62s - 859.78s |


chunk_id: 160_chunk_17
chunk_text:
a file 811.57s - 814.37s | that is accessed by the task scheduler service 814.37s - 815.97s | after the process is created, 815.97s - 817.65s | but before it is resumed, 817.65s - 818.69s | we could lock it, 818.69s - 822.23s | and it will stop the service from resuming the process. 822.23s - 823.57s | Keeping the process suspended 824.25s - 826.37s | will allow us to inject a DLL to it. 826.37s - 829.33s | We monitor the system for file access 829.33s - 832.81s | while launching the scheduled tasks, 832.81s - 835.97s | and we saw that sysmain.sdb was accessed. 835.97s - 838.25s | In this image, we can see the call stack. 838.25s - 840.01s | Inside createProcessInternal, 840.01s - 842.95s | functions related to the app compatibility were called, 842.95s - 847.10s | and then the shim database was opened. 847.10s - 849.28s | At this point, we know that the task scheduler 849.28s - 851.76s | sometimes reads sysmain.sdb, 851.76s - 854.90s | but we need to understand which tasks lead to that. 855.70s - 857.62s | We need to find a task that executes a file 857.62s - 859.78s | with app compatibility settings. 859.78s - 862.74s | To do that, we locked the sdb file, 862.74s - 865.62s | launched every task registered on the machine, 865.62s - 869.06s | and checked when we were notified about the lock breaking. 869.06s - 873.36s | This led us to a task that executes Microsoft Edge updates. 873.36s - 875.46s | This file has app compatibility settings 875.46s - 877.26s | because of the following entry. 878.10s - 880.26s | The generic installer fix will be applied 880.26s - 883.54s | on every process that has the word update in it. 883.54s - 884.68s | So this is good, 885.46s - 886.58s | but still, it's not good enough. 886.58s - 889.60s | This file is under Program Files x86, 889.60s - 892.12s | which means it is a 32-bit process. 892.12s - 894.70s | We want to find a target for 64-bit as well. 896.40s - 898.28s | We continued digging into this subject 898.28s - 900.88s | to understand under which circumstances 900.88s - 902.72s | the sdb file will be read, 902.72s - 904.40s | and we noticed a strange behavior 904.40s - 906.48s | that applies to


chunk_id: 160_chunk_18
chunk_text:
with app compatibility settings. 859.78s - 862.74s | To do that, we locked the sdb file, 862.74s - 865.62s | launched every task registered on the machine, 865.62s - 869.06s | and checked when we were notified about the lock breaking. 869.06s - 873.36s | This led us to a task that executes Microsoft Edge updates. 873.36s - 875.46s | This file has app compatibility settings 875.46s - 877.26s | because of the following entry. 878.10s - 880.26s | The generic installer fix will be applied 880.26s - 883.54s | on every process that has the word update in it. 883.54s - 884.68s | So this is good, 885.46s - 886.58s | but still, it's not good enough. 886.58s - 889.60s | This file is under Program Files x86, 889.60s - 892.12s | which means it is a 32-bit process. 892.12s - 894.70s | We want to find a target for 64-bit as well. 896.40s - 898.28s | We continued digging into this subject 898.28s - 900.88s | to understand under which circumstances 900.88s - 902.72s | the sdb file will be read, 902.72s - 904.40s | and we noticed a strange behavior 904.40s - 906.48s | that applies to the OS as a whole, 906.48s - 909.12s | not just the task scheduler service. 909.12s - 912.24s | The sdb file was read the first time an executable ran 912.24s - 913.76s | since the machine started, 913.76s - 915.80s | even if it didn't need a fix. 915.80s - 918.70s | And after that, in all other runs, it wasn't. 920.16s - 922.52s | If we could guarantee that the sdb file 922.52s - 925.20s | will be read any time an executable runs, 925.20s - 928.40s | we could choose any scheduled task as our targets. 928.40s - 931.76s | And of course, we could register a custom sdb file 931.76s - 934.44s | that applies some fix to every process, 934.44s - 936.22s | but that is too noisy. 936.22s - 937.40s | We want to avoid actions 937.40s - 940.08s | that are monitored by security products. 940.08s - 941.08s | We need to find a way 941.12s - 944.00s | to manage the app compatibility mechanism. 944.00s - 946.20s | We looked for files related to this mechanism 946.20s - 948.88s | and found apphelp.dll. 948.88s - 950.64s | By looking at the code


chunk_id: 160_chunk_19
chunk_text:
the OS as a whole, 906.48s - 909.12s | not just the task scheduler service. 909.12s - 912.24s | The sdb file was read the first time an executable ran 912.24s - 913.76s | since the machine started, 913.76s - 915.80s | even if it didn't need a fix. 915.80s - 918.70s | And after that, in all other runs, it wasn't. 920.16s - 922.52s | If we could guarantee that the sdb file 922.52s - 925.20s | will be read any time an executable runs, 925.20s - 928.40s | we could choose any scheduled task as our targets. 928.40s - 931.76s | And of course, we could register a custom sdb file 931.76s - 934.44s | that applies some fix to every process, 934.44s - 936.22s | but that is too noisy. 936.22s - 937.40s | We want to avoid actions 937.40s - 940.08s | that are monitored by security products. 940.08s - 941.08s | We need to find a way 941.12s - 944.00s | to manage the app compatibility mechanism. 944.00s - 946.20s | We looked for files related to this mechanism 946.20s - 948.88s | and found apphelp.dll. 948.88s - 950.64s | By looking at the code of this DLL, 950.64s - 953.24s | we understood that it wraps various operations 953.24s - 956.90s | with the API anti-apphelp-cache-control. 956.90s - 960.70s | Let's try to understand how to use it. 960.70s - 964.72s | This is an undocumented API that is exported by anti-DLL. 964.72s - 967.40s | We searched for references to this API online 967.40s - 969.52s | and in several DLL files 969.52s - 972.28s | until we found that the symbols of combase.dll 973.08s - 974.60s | contain information about it. 974.60s - 977.16s | This is a screenshot of a function from combase 977.16s - 979.52s | without any reverse engineering. 979.52s - 982.20s | We can see that the first parameter is an integer 982.20s - 985.00s | that represents the type of operation to be performed, 985.00s - 987.06s | and the second parameter is a structure 987.06s - 988.76s | with various members that are filled 988.76s - 992.97s | based on the operation chosen. 992.97s - 995.57s | We extracted those definitions 995.57s - 997.21s | and that revealed to us everything 997.21s - 999.17s | that can be done with this API. 999.17s - 1002.85s |


chunk_id: 160_chunk_20
chunk_text:
of this DLL, 950.64s - 953.24s | we understood that it wraps various operations 953.24s - 956.90s | with the API anti-apphelp-cache-control. 956.90s - 960.70s | Let's try to understand how to use it. 960.70s - 964.72s | This is an undocumented API that is exported by anti-DLL. 964.72s - 967.40s | We searched for references to this API online 967.40s - 969.52s | and in several DLL files 969.52s - 972.28s | until we found that the symbols of combase.dll 973.08s - 974.60s | contain information about it. 974.60s - 977.16s | This is a screenshot of a function from combase 977.16s - 979.52s | without any reverse engineering. 979.52s - 982.20s | We can see that the first parameter is an integer 982.20s - 985.00s | that represents the type of operation to be performed, 985.00s - 987.06s | and the second parameter is a structure 987.06s - 988.76s | with various members that are filled 988.76s - 992.97s | based on the operation chosen. 992.97s - 995.57s | We extracted those definitions 995.57s - 997.21s | and that revealed to us everything 997.21s - 999.17s | that can be done with this API. 999.17s - 1002.85s | We applied the definitions on calls from other DLL files 1002.85s - 1005.17s | and that helped us understand them better. 1005.17s - 1008.01s | Let's look at create-process, for example. 1008.01s - 1010.61s | Now we know that it performs the lookup operation 1010.61s - 1013.49s | and what information it requires. 1013.49s - 1016.61s | Like I said before, we encountered a strange behavior. 1016.61s - 1019.97s | The SDB file was read the first time in an executable run 1019.97s - 1023.13s | since the machine started, even if it didn't need a fix, 1023.13s - 1024.89s | and then it wasn't. 1024.89s - 1027.13s | At this point, we had enough information 1027.13s - 1030.01s | to come up with an assumption on why it happens. 1031.01s - 1034.85s | In this scenario, CMD is going to launch calc, 1034.85s - 1036.69s | so we have these two processes, 1036.69s - 1040.71s | and also the app-help cache, which is empty at this point. 1040.71s - 1042.73s | We know that when we call create-process, 1042.73s - 1045.25s | the lookup operation is done on the cache, 1045.25s - 1048.81s | so CMD is going to


chunk_id: 160_chunk_21
chunk_text:
We applied the definitions on calls from other DLL files 1002.85s - 1005.17s | and that helped us understand them better. 1005.17s - 1008.01s | Let's look at create-process, for example. 1008.01s - 1010.61s | Now we know that it performs the lookup operation 1010.61s - 1013.49s | and what information it requires. 1013.49s - 1016.61s | Like I said before, we encountered a strange behavior. 1016.61s - 1019.97s | The SDB file was read the first time in an executable run 1019.97s - 1023.13s | since the machine started, even if it didn't need a fix, 1023.13s - 1024.89s | and then it wasn't. 1024.89s - 1027.13s | At this point, we had enough information 1027.13s - 1030.01s | to come up with an assumption on why it happens. 1031.01s - 1034.85s | In this scenario, CMD is going to launch calc, 1034.85s - 1036.69s | so we have these two processes, 1036.69s - 1040.71s | and also the app-help cache, which is empty at this point. 1040.71s - 1042.73s | We know that when we call create-process, 1042.73s - 1045.25s | the lookup operation is done on the cache, 1045.25s - 1048.81s | so CMD is going to look for an entry about calc. 1048.81s - 1052.73s | The cache is empty, so the response is no entry found. 1052.73s - 1055.45s | That causes CMD to read the SDB file 1055.45s - 1057.41s | to check if it contained information 1057.41s - 1059.81s | about fixes calc requires. 1060.61s - 1061.89s | It doesn't require any fix. 1061.89s - 1064.37s | So the next step is that the cache is updated 1064.37s - 1066.13s | and an entry is added. 1066.13s - 1068.57s | Calc, no fix needed. 1068.57s - 1072.09s | Then, let's say CMD launches calc again, 1072.09s - 1075.71s | so it queries that cache one more time. 1075.71s - 1079.01s | This time, the response is no fix needed, 1079.01s - 1083.19s | and that is why CMD doesn't read sysmin.sdb again. 1083.19s - 1084.89s | Based on this assumption, 1084.89s - 1087.17s | if we could remove this entry from the cache, 1087.17s - 1091.10s | the SDB file will be read again. 1091.10s - 1094.18s | We looked at various calls to empty app-help cache control 1094.18s - 1097.50s | and found out that both kernel32 and app-help 1097.50s - 1099.70s


chunk_id: 160_chunk_22
chunk_text:
look for an entry about calc. 1048.81s - 1052.73s | The cache is empty, so the response is no entry found. 1052.73s - 1055.45s | That causes CMD to read the SDB file 1055.45s - 1057.41s | to check if it contained information 1057.41s - 1059.81s | about fixes calc requires. 1060.61s - 1061.89s | It doesn't require any fix. 1061.89s - 1064.37s | So the next step is that the cache is updated 1064.37s - 1066.13s | and an entry is added. 1066.13s - 1068.57s | Calc, no fix needed. 1068.57s - 1072.09s | Then, let's say CMD launches calc again, 1072.09s - 1075.71s | so it queries that cache one more time. 1075.71s - 1079.01s | This time, the response is no fix needed, 1079.01s - 1083.19s | and that is why CMD doesn't read sysmin.sdb again. 1083.19s - 1084.89s | Based on this assumption, 1084.89s - 1087.17s | if we could remove this entry from the cache, 1087.17s - 1091.10s | the SDB file will be read again. 1091.10s - 1094.18s | We looked at various calls to empty app-help cache control 1094.18s - 1097.50s | and found out that both kernel32 and app-help 1097.50s - 1099.70s | performs the remove operation. 1099.70s - 1102.76s | In this pseudocode, we can see the information required. 1102.76s - 1105.66s | It requires the path and the handle to the file. 1105.66s - 1107.62s | Kernel32 exports a function 1107.62s - 1109.54s | that does most of the work for us, 1109.54s - 1110.72s | and it saves us the effort 1110.72s - 1112.68s | of recreating this call in our code. 1113.74s - 1115.94s | After this call, the execution of the file 1115.94s - 1118.88s | will once again trigger reading the SDB file. 1120.70s - 1123.50s | Okay, so we talked about a lot of stuff. 1123.50s - 1126.90s | RPC methods, locks, and undocumented API. 1126.90s - 1130.24s | So in case you lost track, let's put everything together. 1130.24s - 1132.22s | This is the flow of the attack. 1132.22s - 1135.30s | We'll start by writing the DLL that will be injected. 1135.30s - 1137.14s | Then, we'll pick a schedule task. 1137.14s - 1140.42s | Let's say Office Automatic Updates 2.0. 1140.42s - 1142.38s | We need to take care of the shim cache. 1142.38s - 1145.36s | The file that will


chunk_id: 160_chunk_23
chunk_text:
| performs the remove operation. 1099.70s - 1102.76s | In this pseudocode, we can see the information required. 1102.76s - 1105.66s | It requires the path and the handle to the file. 1105.66s - 1107.62s | Kernel32 exports a function 1107.62s - 1109.54s | that does most of the work for us, 1109.54s - 1110.72s | and it saves us the effort 1110.72s - 1112.68s | of recreating this call in our code. 1113.74s - 1115.94s | After this call, the execution of the file 1115.94s - 1118.88s | will once again trigger reading the SDB file. 1120.70s - 1123.50s | Okay, so we talked about a lot of stuff. 1123.50s - 1126.90s | RPC methods, locks, and undocumented API. 1126.90s - 1130.24s | So in case you lost track, let's put everything together. 1130.24s - 1132.22s | This is the flow of the attack. 1132.22s - 1135.30s | We'll start by writing the DLL that will be injected. 1135.30s - 1137.14s | Then, we'll pick a schedule task. 1137.14s - 1140.42s | Let's say Office Automatic Updates 2.0. 1140.42s - 1142.38s | We need to take care of the shim cache. 1142.38s - 1145.36s | The file that will be executed might have an entry, 1145.36s - 1147.24s | so we're going to remove it. 1148.14s - 1152.43s | Then, we'll lock sysmain.sdb. 1152.43s - 1154.89s | The next step will be to start the task, 1154.89s - 1157.03s | and that will launch a suspended process 1157.03s - 1159.19s | with the privileges of system. 1159.19s - 1162.67s | The task scheduler will try to read the SDB file 1162.67s - 1164.59s | and start waiting. 1164.59s - 1167.63s | That will send us a notification about the lock breaking, 1167.63s - 1170.15s | which means it's time to send the RPC request 1170.15s - 1172.31s | to the Office service. 1172.31s - 1174.55s | The service will patch the import table 1174.55s - 1178.55s | of the suspended process and link it to our DLL. 1178.55s - 1181.07s | The last step will be to release the lock, 1181.07s - 1182.79s | and that will cause the task scheduler 1182.79s - 1188.21s | to resume the process, and our DLL will be loaded. 1188.21s - 1195.06s | Ready to see if it works? 1195.06s - 1198.02s | First, we'll copy our tool to the machine. 1198.02s -


chunk_id: 160_chunk_24
chunk_text:
be executed might have an entry, 1145.36s - 1147.24s | so we're going to remove it. 1148.14s - 1152.43s | Then, we'll lock sysmain.sdb. 1152.43s - 1154.89s | The next step will be to start the task, 1154.89s - 1157.03s | and that will launch a suspended process 1157.03s - 1159.19s | with the privileges of system. 1159.19s - 1162.67s | The task scheduler will try to read the SDB file 1162.67s - 1164.59s | and start waiting. 1164.59s - 1167.63s | That will send us a notification about the lock breaking, 1167.63s - 1170.15s | which means it's time to send the RPC request 1170.15s - 1172.31s | to the Office service. 1172.31s - 1174.55s | The service will patch the import table 1174.55s - 1178.55s | of the suspended process and link it to our DLL. 1178.55s - 1181.07s | The last step will be to release the lock, 1181.07s - 1182.79s | and that will cause the task scheduler 1182.79s - 1188.21s | to resume the process, and our DLL will be loaded. 1188.21s - 1195.06s | Ready to see if it works? 1195.06s - 1198.02s | First, we'll copy our tool to the machine. 1198.02s - 1201.49s | And let's even scan it. 1201.49s - 1203.49s | And of course, Defender won't detect it. 1204.55s - 1206.29s | Now, just to make it clear, 1206.29s - 1212.07s | we are running the latest version of Office 365, 1212.07s - 1216.67s | and also the latest Windows 11 build. 1216.67s - 1218.27s | Now that we made it clear, 1218.27s - 1224.39s | let's start monitoring the system and launch our tool. 1224.39s - 1228.51s | We can see that Office C to our client loaded our DLL, 1228.51s - 1231.95s | and that we gained a console with the privileges of 1231.95s - 1239.93s | anti-authority system. 1239.93s - 1241.41s | Time to summarize. 1241.41s - 1243.75s | We decided to make an attack surface research 1243.75s - 1245.27s | on Microsoft Office. 1245.27s - 1247.83s | We manipulated several components of the OS 1247.83s - 1250.07s | into a single functioning attack. 1250.11s - 1253.43s | And these are the advantages of it. 1253.43s - 1256.47s | Security products will most likely ignore code injection 1256.47s - 1260.45s | done by Office Click to Run, because this is its purpose. 1260.45s - 1262.39s | So


chunk_id: 160_chunk_25
chunk_text:
1201.49s | And let's even scan it. 1201.49s - 1203.49s | And of course, Defender won't detect it. 1204.55s - 1206.29s | Now, just to make it clear, 1206.29s - 1212.07s | we are running the latest version of Office 365, 1212.07s - 1216.67s | and also the latest Windows 11 build. 1216.67s - 1218.27s | Now that we made it clear, 1218.27s - 1224.39s | let's start monitoring the system and launch our tool. 1224.39s - 1228.51s | We can see that Office C to our client loaded our DLL, 1228.51s - 1231.95s | and that we gained a console with the privileges of 1231.95s - 1239.93s | anti-authority system. 1239.93s - 1241.41s | Time to summarize. 1241.41s - 1243.75s | We decided to make an attack surface research 1243.75s - 1245.27s | on Microsoft Office. 1245.27s - 1247.83s | We manipulated several components of the OS 1247.83s - 1250.07s | into a single functioning attack. 1250.11s - 1253.43s | And these are the advantages of it. 1253.43s - 1256.47s | Security products will most likely ignore code injection 1256.47s - 1260.45s | done by Office Click to Run, because this is its purpose. 1260.45s - 1262.39s | So we'll bypass detection. 1262.39s - 1265.97s | It will be difficult to link this attack back to us, 1265.97s - 1269.31s | because not only the injection is done by another process, 1269.31s - 1272.35s | but the target process is spawned under the task scheduler, 1272.35s - 1274.43s | not under us. 1274.43s - 1277.65s | We escalate our privileges from admin to system, 1277.65s - 1279.87s | and the rest of the actions we perform 1280.55s - 1281.39s | aren't suspicious. 1281.39s - 1284.07s | It is very unlikely that someone monitor calls 1284.07s - 1288.13s | to anti-app-help-cache-control or monitors using Oprox. 1289.15s - 1291.49s | So this is the end of my part of the talk. 1291.49s - 1301.05s | Now please welcome David Chandalov. 1301.05s - 1302.49s | Thank you, Ron. 1302.49s - 1305.49s | As we concluded our first attack surface research, 1305.49s - 1308.21s | we identified a significant knowledge gap 1308.21s - 1311.25s | regarding anti-app-help-cache-control. 1311.25s - 1314.61s | Despite extensive information available online, 1314.61s - 1317.77s | we found that crucial details about some data structures 1317.77s - 1319.71s | and flows remain unclear. 1320.61s - 1324.05s | Additionally, with


chunk_id: 160_chunk_26
chunk_text:
we'll bypass detection. 1262.39s - 1265.97s | It will be difficult to link this attack back to us, 1265.97s - 1269.31s | because not only the injection is done by another process, 1269.31s - 1272.35s | but the target process is spawned under the task scheduler, 1272.35s - 1274.43s | not under us. 1274.43s - 1277.65s | We escalate our privileges from admin to system, 1277.65s - 1279.87s | and the rest of the actions we perform 1280.55s - 1281.39s | aren't suspicious. 1281.39s - 1284.07s | It is very unlikely that someone monitor calls 1284.07s - 1288.13s | to anti-app-help-cache-control or monitors using Oprox. 1289.15s - 1291.49s | So this is the end of my part of the talk. 1291.49s - 1301.05s | Now please welcome David Chandalov. 1301.05s - 1302.49s | Thank you, Ron. 1302.49s - 1305.49s | As we concluded our first attack surface research, 1305.49s - 1308.21s | we identified a significant knowledge gap 1308.21s - 1311.25s | regarding anti-app-help-cache-control. 1311.25s - 1314.61s | Despite extensive information available online, 1314.61s - 1317.77s | we found that crucial details about some data structures 1317.77s - 1319.71s | and flows remain unclear. 1320.61s - 1324.05s | Additionally, with the continuous updates and changes 1324.05s - 1326.77s | in Windows versions over the years, 1326.77s - 1328.65s | many publicly shared insights 1328.65s - 1330.97s | have been altered by Microsoft. 1330.97s - 1334.49s | Today, I'll provide a comprehensive overview 1334.49s - 1337.07s | of the mechanism and the modernized attack. 1337.07s - 1338.81s | So let's dive right in. 1340.61s - 1342.91s | As we embarked on our research journey, 1342.91s - 1345.51s | we were driven by a fundamental question. 1345.51s - 1349.77s | What can we achieve with the anti-app-help-cache-control API? 1349.77s - 1352.03s | This inquiry became our guiding light, 1352.03s - 1356.39s | sparking our curiosity and determination to delve deeper. 1356.39s - 1359.01s | Our initial exploration gave us a foothold, 1359.01s - 1360.91s | but we knew we needed more. 1360.91s - 1364.67s | We needed to understand the technical intricacies. 1364.67s - 1368.09s | After all, this API controls shim fixes. 1368.09s - 1370.05s | Maybe we can bend it to our will 1370.05s - 1372.31s | and control which shim fixes are applied 1372.71s - 1376.04s | to specific processes. 1376.04s - 1378.52s | Our second question was more


chunk_id: 160_chunk_27
chunk_text:
the continuous updates and changes 1324.05s - 1326.77s | in Windows versions over the years, 1326.77s - 1328.65s | many publicly shared insights 1328.65s - 1330.97s | have been altered by Microsoft. 1330.97s - 1334.49s | Today, I'll provide a comprehensive overview 1334.49s - 1337.07s | of the mechanism and the modernized attack. 1337.07s - 1338.81s | So let's dive right in. 1340.61s - 1342.91s | As we embarked on our research journey, 1342.91s - 1345.51s | we were driven by a fundamental question. 1345.51s - 1349.77s | What can we achieve with the anti-app-help-cache-control API? 1349.77s - 1352.03s | This inquiry became our guiding light, 1352.03s - 1356.39s | sparking our curiosity and determination to delve deeper. 1356.39s - 1359.01s | Our initial exploration gave us a foothold, 1359.01s - 1360.91s | but we knew we needed more. 1360.91s - 1364.67s | We needed to understand the technical intricacies. 1364.67s - 1368.09s | After all, this API controls shim fixes. 1368.09s - 1370.05s | Maybe we can bend it to our will 1370.05s - 1372.31s | and control which shim fixes are applied 1372.71s - 1376.04s | to specific processes. 1376.04s - 1378.52s | Our second question was more technical. 1378.52s - 1380.80s | As you can see from the screenshots, 1380.80s - 1383.44s | during the reading of sysmain.sdb, 1383.44s - 1386.24s | we noticed that anti-app-help-cache-control 1386.24s - 1388.28s | interacts with the kernel. 1388.28s - 1392.44s | This API calls a driver named ahcache.sys, 1392.44s - 1396.40s | which contains some intriguingly named functions. 1396.40s - 1399.12s | Functions like api-lookup and write-to-process 1399.12s - 1401.16s | and cache-lookup stood out, 1401.16s - 1403.78s | suggesting deeper mechanisms at play. 1404.76s - 1407.48s | These findings hinted at something significant 1407.48s - 1409.60s | inside of ahcache.sys, 1409.60s - 1411.88s | something that required us to dig deeper. 1412.78s - 1417.12s | So, down the rabbit hole we go. 1417.12s - 1419.44s | All right, let's lay the foundation. 1419.44s - 1422.64s | To understand how ahcache.sys operates, 1422.64s - 1424.36s | we need to start with the basics 1424.36s - 1426.76s | of its initialization process. 1426.76s - 1430.42s | When the system boots up, ahcache.sys is loaded, 1430.42s - 1434.58s | and it requires some initial setup to function properly. 1434.58s - 1436.90s | This is where the registry comes into play. 1438.26s -


chunk_id: 160_chunk_28
chunk_text:
technical. 1378.52s - 1380.80s | As you can see from the screenshots, 1380.80s - 1383.44s | during the reading of sysmain.sdb, 1383.44s - 1386.24s | we noticed that anti-app-help-cache-control 1386.24s - 1388.28s | interacts with the kernel. 1388.28s - 1392.44s | This API calls a driver named ahcache.sys, 1392.44s - 1396.40s | which contains some intriguingly named functions. 1396.40s - 1399.12s | Functions like api-lookup and write-to-process 1399.12s - 1401.16s | and cache-lookup stood out, 1401.16s - 1403.78s | suggesting deeper mechanisms at play. 1404.76s - 1407.48s | These findings hinted at something significant 1407.48s - 1409.60s | inside of ahcache.sys, 1409.60s - 1411.88s | something that required us to dig deeper. 1412.78s - 1417.12s | So, down the rabbit hole we go. 1417.12s - 1419.44s | All right, let's lay the foundation. 1419.44s - 1422.64s | To understand how ahcache.sys operates, 1422.64s - 1424.36s | we need to start with the basics 1424.36s - 1426.76s | of its initialization process. 1426.76s - 1430.42s | When the system boots up, ahcache.sys is loaded, 1430.42s - 1434.58s | and it requires some initial setup to function properly. 1434.58s - 1436.90s | This is where the registry comes into play. 1438.26s - 1440.58s | The registry provides essential values 1440.58s - 1444.34s | that ahcache.sys reads and stores data to. 1444.34s - 1446.70s | These values act as a safe location 1446.70s - 1448.56s | for the driver's operations. 1450.18s - 1452.50s | This path contains binary data 1452.50s - 1455.90s | that the driver sorts into an AVL table. 1455.90s - 1458.22s | The cache needs to be properly initialized 1458.22s - 1460.02s | through the Windows API 1460.02s - 1464.70s | before these components can start working. 1464.70s - 1468.18s | The opposite process happens a shutdown and restart. 1468.18s - 1470.82s | The AVL table is dumped into the registry 1470.82s - 1475.32s | into the AppCompatCache value. 1475.32s - 1477.16s | Let's take a moment to understand 1477.16s - 1481.40s | the link between sysmain.sdb, registry entries, 1481.40s - 1483.92s | and the AppCompatibility cache. 1483.92s - 1486.56s | Each entry in the registry's values data 1486.56s - 1489.96s | is representing either a file that needs a shimfix 1489.96s - 1491.88s | or a file that doesn't. 1491.88s - 1493.76s | We'll revisit the decision-making process 1493.76s - 1496.20s | for applying fixes, but for now, 1496.20s


chunk_id: 160_chunk_29
chunk_text:
1440.58s | The registry provides essential values 1440.58s - 1444.34s | that ahcache.sys reads and stores data to. 1444.34s - 1446.70s | These values act as a safe location 1446.70s - 1448.56s | for the driver's operations. 1450.18s - 1452.50s | This path contains binary data 1452.50s - 1455.90s | that the driver sorts into an AVL table. 1455.90s - 1458.22s | The cache needs to be properly initialized 1458.22s - 1460.02s | through the Windows API 1460.02s - 1464.70s | before these components can start working. 1464.70s - 1468.18s | The opposite process happens a shutdown and restart. 1468.18s - 1470.82s | The AVL table is dumped into the registry 1470.82s - 1475.32s | into the AppCompatCache value. 1475.32s - 1477.16s | Let's take a moment to understand 1477.16s - 1481.40s | the link between sysmain.sdb, registry entries, 1481.40s - 1483.92s | and the AppCompatibility cache. 1483.92s - 1486.56s | Each entry in the registry's values data 1486.56s - 1489.96s | is representing either a file that needs a shimfix 1489.96s - 1491.88s | or a file that doesn't. 1491.88s - 1493.76s | We'll revisit the decision-making process 1493.76s - 1496.20s | for applying fixes, but for now, 1496.20s - 1500.08s | let's focus on entries indicating files that need a fix. 1500.08s - 1503.36s | These entries contain several fields, 1503.36s - 1506.08s | the most significant being the exit tag, 1506.08s - 1508.76s | which points to a specific shimfix. 1508.76s - 1511.24s | By examining the data within these entries, 1511.24s - 1514.20s | we can observe notable differences. 1514.20s - 1517.72s | Specifically, three bytes vary across entries, 1517.72s - 1521.12s | and in the last entry, the three bytes are zeroized. 1521.12s - 1524.44s | Is it a sign for a file not needing a fix? 1524.44s - 1527.20s | Considering the data's little-endian format, 1527.20s - 1533.03s | converting it could reveal connections to sysmain.sdb. 1533.03s - 1536.91s | With SDB Explorer, we can search for these converted values 1536.91s - 1539.99s | in a readable version of sysmain.sdb. 1539.99s - 1542.71s | Zooming in on the fields that appear in the SDB, 1542.71s - 1544.83s | we have the name of the file field, 1544.83s - 1547.39s | and we can see the matching file field. 1547.39s - 1550.35s | The matching file field contains just an asterisk, 1550.35s - 1554.63s |


chunk_id: 160_chunk_30
chunk_text:
- 1500.08s | let's focus on entries indicating files that need a fix. 1500.08s - 1503.36s | These entries contain several fields, 1503.36s - 1506.08s | the most significant being the exit tag, 1506.08s - 1508.76s | which points to a specific shimfix. 1508.76s - 1511.24s | By examining the data within these entries, 1511.24s - 1514.20s | we can observe notable differences. 1514.20s - 1517.72s | Specifically, three bytes vary across entries, 1517.72s - 1521.12s | and in the last entry, the three bytes are zeroized. 1521.12s - 1524.44s | Is it a sign for a file not needing a fix? 1524.44s - 1527.20s | Considering the data's little-endian format, 1527.20s - 1533.03s | converting it could reveal connections to sysmain.sdb. 1533.03s - 1536.91s | With SDB Explorer, we can search for these converted values 1536.91s - 1539.99s | in a readable version of sysmain.sdb. 1539.99s - 1542.71s | Zooming in on the fields that appear in the SDB, 1542.71s - 1544.83s | we have the name of the file field, 1544.83s - 1547.39s | and we can see the matching file field. 1547.39s - 1550.35s | The matching file field contains just an asterisk, 1550.35s - 1554.63s | so the whole name field will be compared as it appears. 1554.63s - 1557.63s | And lastly, we find the shimreference field. 1557.63s - 1560.95s | Each shimreference has a name and an ID. 1560.95s - 1564.43s | Some have a command line for additional arguments. 1564.43s - 1567.51s | Each field has a hexadecimal number attached. 1567.51s - 1570.38s | Why? 1570.38s - 1572.98s | It represents the address in the SDB 1572.98s - 1574.94s | that contains the exit tag 1574.94s - 1580.16s | as it prefixes the shimfix information block. 1580.16s - 1582.80s | Now that we understand what an exit tag is 1582.80s - 1586.48s | and how the registry cache and sysmain.sdb are linked, 1586.48s - 1590.36s | we wanted to look under the hood of ahcache.sys. 1590.36s - 1592.64s | We started looking at the dispatch routines 1592.64s - 1594.84s | for device ahcache, 1594.84s - 1597.36s | and we found that, among other things, 1597.36s - 1600.40s | anti-app-help-cache-control can 1600.40s - 1603.20s | update the table with hc-api-update 1603.20s - 1606.92s | that utilizes insert-element-api, 1606.92s - 1610.52s | lookup a table entry with hc-api-lookup-cdb 1610.52s - 1612.60s | that uses lookup-element-api,


chunk_id: 160_chunk_31
chunk_text:
so the whole name field will be compared as it appears. 1554.63s - 1557.63s | And lastly, we find the shimreference field. 1557.63s - 1560.95s | Each shimreference has a name and an ID. 1560.95s - 1564.43s | Some have a command line for additional arguments. 1564.43s - 1567.51s | Each field has a hexadecimal number attached. 1567.51s - 1570.38s | Why? 1570.38s - 1572.98s | It represents the address in the SDB 1572.98s - 1574.94s | that contains the exit tag 1574.94s - 1580.16s | as it prefixes the shimfix information block. 1580.16s - 1582.80s | Now that we understand what an exit tag is 1582.80s - 1586.48s | and how the registry cache and sysmain.sdb are linked, 1586.48s - 1590.36s | we wanted to look under the hood of ahcache.sys. 1590.36s - 1592.64s | We started looking at the dispatch routines 1592.64s - 1594.84s | for device ahcache, 1594.84s - 1597.36s | and we found that, among other things, 1597.36s - 1600.40s | anti-app-help-cache-control can 1600.40s - 1603.20s | update the table with hc-api-update 1603.20s - 1606.92s | that utilizes insert-element-api, 1606.92s - 1610.52s | lookup a table entry with hc-api-lookup-cdb 1610.52s - 1612.60s | that uses lookup-element-api, 1614.16s - 1616.52s | or it can remove an entry from the table 1616.52s - 1620.20s | with hc-api-remove using delete-element-api. 1621.24s - 1626.78s | We decided to continue looking for the dispatch routines. 1626.78s - 1628.62s | As we already have shown, 1628.62s - 1632.98s | anti-app-help-cache-control uses the ahc-service class enum, 1632.98s - 1636.26s | but it is also being used in the dispatch routine 1636.26s - 1638.82s | inside of ahcache.sys. 1638.82s - 1642.42s | The enum has an interestingly sounding member 1642.42s - 1644.46s | in its process data for short. 1644.46s - 1647.02s | We traced a function that is using this value. 1648.42s - 1650.42s | We were surprised to see no mentions 1650.42s - 1652.24s | of AVL table manipulation. 1653.98s - 1656.04s | Maybe this is what we were looking for, 1656.04s - 1658.26s | writing to a process for a kernel driver? 1658.26s - 1659.30s | Sounds awesome. 1660.94s - 1663.30s | But before we check if we got the good news, 1663.30s - 1665.74s | let's go through some definitions. 1665.74s - 1667.38s | Almost every dispatch routine 1667.38s - 1669.62s | has a unique structure for its operation. 1671.38s


chunk_id: 160_chunk_32
chunk_text:
1614.16s - 1616.52s | or it can remove an entry from the table 1616.52s - 1620.20s | with hc-api-remove using delete-element-api. 1621.24s - 1626.78s | We decided to continue looking for the dispatch routines. 1626.78s - 1628.62s | As we already have shown, 1628.62s - 1632.98s | anti-app-help-cache-control uses the ahc-service class enum, 1632.98s - 1636.26s | but it is also being used in the dispatch routine 1636.26s - 1638.82s | inside of ahcache.sys. 1638.82s - 1642.42s | The enum has an interestingly sounding member 1642.42s - 1644.46s | in its process data for short. 1644.46s - 1647.02s | We traced a function that is using this value. 1648.42s - 1650.42s | We were surprised to see no mentions 1650.42s - 1652.24s | of AVL table manipulation. 1653.98s - 1656.04s | Maybe this is what we were looking for, 1656.04s - 1658.26s | writing to a process for a kernel driver? 1658.26s - 1659.30s | Sounds awesome. 1660.94s - 1663.30s | But before we check if we got the good news, 1663.30s - 1665.74s | let's go through some definitions. 1665.74s - 1667.38s | Almost every dispatch routine 1667.38s - 1669.62s | has a unique structure for its operation. 1671.38s - 1675.02s | This structure contains an undocumented data field. 1675.02s - 1677.36s | We tried to search the web for definitions, 1677.36s - 1680.52s | and with some more in-house reverse engineering, 1682.22s - 1683.98s | we got shim data. 1683.98s - 1687.74s | It contains a fixed magic value and a fixed size value. 1687.74s - 1692.86s | Remember this struct as we will come to visit it later. 1692.86s - 1695.28s | Dive in deeper inside the function. 1695.28s - 1697.68s | The calling process and the target process 1697.68s - 1698.74s | are being checked. 1700.40s - 1701.88s | Now here is the tricky part. 1701.88s - 1705.24s | We need to have protected signer app and PPL. 1706.62s - 1709.24s | And these two values will be important later. 1710.50s - 1714.56s | But the call fails in psget process protection. 1714.56s - 1717.80s | Looking at every process in Windows 11, 1717.80s - 1720.10s | we concluded that no Windows apps 1720.10s - 1723.52s | with this kind of protection exist. 1723.52s - 1724.92s | We came to a dead end. 1725.52s - 1729.12s | But the undocumented structure I talked about before, 1729.12s


chunk_id: 160_chunk_33
chunk_text:
- 1675.02s | This structure contains an undocumented data field. 1675.02s - 1677.36s | We tried to search the web for definitions, 1677.36s - 1680.52s | and with some more in-house reverse engineering, 1682.22s - 1683.98s | we got shim data. 1683.98s - 1687.74s | It contains a fixed magic value and a fixed size value. 1687.74s - 1692.86s | Remember this struct as we will come to visit it later. 1692.86s - 1695.28s | Dive in deeper inside the function. 1695.28s - 1697.68s | The calling process and the target process 1697.68s - 1698.74s | are being checked. 1700.40s - 1701.88s | Now here is the tricky part. 1701.88s - 1705.24s | We need to have protected signer app and PPL. 1706.62s - 1709.24s | And these two values will be important later. 1710.50s - 1714.56s | But the call fails in psget process protection. 1714.56s - 1717.80s | Looking at every process in Windows 11, 1717.80s - 1720.10s | we concluded that no Windows apps 1720.10s - 1723.52s | with this kind of protection exist. 1723.52s - 1724.92s | We came to a dead end. 1725.52s - 1729.12s | But the undocumented structure I talked about before, 1729.12s - 1730.68s | it piqued our interest. 1732.48s - 1735.04s | We decided to take that strange name we found 1735.04s - 1738.56s | and try to look for references of this structure. 1738.56s - 1741.72s | Maybe we can understand by which operation it is being used 1741.72s - 1745.28s | and who can be the target. 1745.28s - 1747.18s | There were a few hits. 1747.18s - 1749.12s | Reverse engineering the functions 1749.12s - 1751.76s | that reference shim data revealed 1751.76s - 1754.44s | that this structure represents the shim fixes 1754.44s - 1756.52s | that need to be applied to a process. 1758.34s - 1760.44s | Let's see how a new process is born. 1761.88s - 1764.44s | Notepad.exe is the child process 1764.44s - 1768.98s | that is created on behalf of the parent process cmd.exe. 1768.98s - 1770.92s | The parent queries the app help cache 1770.92s - 1774.68s | to check if the child process requires shim fixes 1774.68s - 1776.82s | as we have shown in the first attack. 1778.00s - 1780.80s | The parent process readsysmain.sdb 1780.80s - 1783.88s | to retrieve the complete information about the fixes. 1785.93s -


chunk_id: 160_chunk_34
chunk_text:
- 1730.68s | it piqued our interest. 1732.48s - 1735.04s | We decided to take that strange name we found 1735.04s - 1738.56s | and try to look for references of this structure. 1738.56s - 1741.72s | Maybe we can understand by which operation it is being used 1741.72s - 1745.28s | and who can be the target. 1745.28s - 1747.18s | There were a few hits. 1747.18s - 1749.12s | Reverse engineering the functions 1749.12s - 1751.76s | that reference shim data revealed 1751.76s - 1754.44s | that this structure represents the shim fixes 1754.44s - 1756.52s | that need to be applied to a process. 1758.34s - 1760.44s | Let's see how a new process is born. 1761.88s - 1764.44s | Notepad.exe is the child process 1764.44s - 1768.98s | that is created on behalf of the parent process cmd.exe. 1768.98s - 1770.92s | The parent queries the app help cache 1770.92s - 1774.68s | to check if the child process requires shim fixes 1774.68s - 1776.82s | as we have shown in the first attack. 1778.00s - 1780.80s | The parent process readsysmain.sdb 1780.80s - 1783.88s | to retrieve the complete information about the fixes. 1785.93s - 1787.73s | The parent builds the structure 1787.73s - 1790.41s | according to the specific fixes 1790.41s - 1796.12s | and writes it to the memory of the child process. 1796.12s - 1797.76s | The parent modifies the value 1797.76s - 1800.80s | of the process environment blocks pshim data 1800.80s - 1805.47s | to point to the new structure. 1805.47s - 1808.57s | NTDLL is already loaded in the child process. 1810.23s - 1813.63s | So NTDLL's loader loads app help.dll 1813.63s - 1816.47s | if pshim data is not empty. 1817.47s - 1821.63s | App help identifies which shim fixes are to be applied. 1823.11s - 1826.23s | And so app help.dll applies the shim fixes 1826.23s - 1830.19s | according to the structure. 1830.19s - 1832.47s | We also wanted to share the flow 1832.47s - 1836.99s | of the shim data structure creation for future references. 1836.99s - 1841.45s | The flow starts with create process internal in kernel base, 1841.45s - 1843.05s | goes through kernel 32, 1843.05s - 1847.25s | and finally ends with app help.dll. 1847.25s - 1849.25s | The finished struct is built 1849.25s - 1852.53s | in the sdb pack up


chunk_id: 160_chunk_35
chunk_text:
1787.73s | The parent builds the structure 1787.73s - 1790.41s | according to the specific fixes 1790.41s - 1796.12s | and writes it to the memory of the child process. 1796.12s - 1797.76s | The parent modifies the value 1797.76s - 1800.80s | of the process environment blocks pshim data 1800.80s - 1805.47s | to point to the new structure. 1805.47s - 1808.57s | NTDLL is already loaded in the child process. 1810.23s - 1813.63s | So NTDLL's loader loads app help.dll 1813.63s - 1816.47s | if pshim data is not empty. 1817.47s - 1821.63s | App help identifies which shim fixes are to be applied. 1823.11s - 1826.23s | And so app help.dll applies the shim fixes 1826.23s - 1830.19s | according to the structure. 1830.19s - 1832.47s | We also wanted to share the flow 1832.47s - 1836.99s | of the shim data structure creation for future references. 1836.99s - 1841.45s | The flow starts with create process internal in kernel base, 1841.45s - 1843.05s | goes through kernel 32, 1843.05s - 1847.25s | and finally ends with app help.dll. 1847.25s - 1849.25s | The finished struct is built 1849.25s - 1852.53s | in the sdb pack up compa data function 1852.53s - 1856.05s | inside of app help.dll. 1857.49s - 1861.29s | Okay, let's consider the implications 1861.29s - 1863.65s | of manipulating a system component 1863.65s - 1867.13s | to build and trigger unauthorized fixes. 1867.13s - 1870.85s | This could potentially allow us to inject or alter code 1870.85s - 1874.13s | in a way that bypasses typical security measures. 1875.13s - 1878.45s | Our investigation into pshim data 1878.45s - 1881.01s | begins with understanding what data 1881.01s - 1883.37s | is being written to this specific part 1883.37s - 1887.70s | of the process environment block. 1887.70s - 1890.70s | We utilized the compatibility administrator 1890.70s - 1895.61s | to create and apply custom rules. 1895.61s - 1900.55s | By extracting the shim data directly from process memory, 1900.55s - 1904.07s | we gained a first insight into how the data is organized. 1904.79s - 1909.79s | We chose to fuzz the inputs to see the effect on the data. 1909.79s - 1912.39s | This process helped us identify patterns 1912.39s - 1915.15s | in the data handling. 1915.15s - 1916.63s | By following these steps, 1916.63s - 1918.75s | we gained a


chunk_id: 160_chunk_36
chunk_text:
compa data function 1852.53s - 1856.05s | inside of app help.dll. 1857.49s - 1861.29s | Okay, let's consider the implications 1861.29s - 1863.65s | of manipulating a system component 1863.65s - 1867.13s | to build and trigger unauthorized fixes. 1867.13s - 1870.85s | This could potentially allow us to inject or alter code 1870.85s - 1874.13s | in a way that bypasses typical security measures. 1875.13s - 1878.45s | Our investigation into pshim data 1878.45s - 1881.01s | begins with understanding what data 1881.01s - 1883.37s | is being written to this specific part 1883.37s - 1887.70s | of the process environment block. 1887.70s - 1890.70s | We utilized the compatibility administrator 1890.70s - 1895.61s | to create and apply custom rules. 1895.61s - 1900.55s | By extracting the shim data directly from process memory, 1900.55s - 1904.07s | we gained a first insight into how the data is organized. 1904.79s - 1909.79s | We chose to fuzz the inputs to see the effect on the data. 1909.79s - 1912.39s | This process helped us identify patterns 1912.39s - 1915.15s | in the data handling. 1915.15s - 1916.63s | By following these steps, 1916.63s - 1918.75s | we gained a comprehensive understanding 1918.75s - 1922.84s | of how shim data looks like. 1922.84s - 1924.60s | And so at last, 1924.60s - 1927.82s | we have reversed engineered the shim data structure, 1927.82s - 1929.34s | essential for understanding 1929.34s - 1932.06s | how to manipulate shims to our advantage. 1933.06s - 1936.44s | Here we can see the previous version of the shim data. 1936.44s - 1937.86s | If you can recall, 1937.86s - 1940.60s | this is the struct I ask you to remember. 1940.60s - 1942.38s | There are quite a few changes. 1942.38s - 1945.20s | Most notably, the exit up type field, 1945.20s - 1946.52s | the exit tag field, 1946.52s - 1948.54s | and the exit count field. 1948.54s - 1954.95s | All are essential for correct use of shim fix manipulation. 1954.95s - 1955.99s | At this stage, 1955.99s - 1958.67s | we are preparing to use all of our accumulated knowledge 1958.67s - 1960.05s | for an attack. 1960.05s - 1962.67s | We can make a target process load the shim fix 1962.67s - 1965.45s | simply by building our own shim data struct 1965.45s - 1968.67s | and pointing to the


chunk_id: 160_chunk_37
chunk_text:
comprehensive understanding 1918.75s - 1922.84s | of how shim data looks like. 1922.84s - 1924.60s | And so at last, 1924.60s - 1927.82s | we have reversed engineered the shim data structure, 1927.82s - 1929.34s | essential for understanding 1929.34s - 1932.06s | how to manipulate shims to our advantage. 1933.06s - 1936.44s | Here we can see the previous version of the shim data. 1936.44s - 1937.86s | If you can recall, 1937.86s - 1940.60s | this is the struct I ask you to remember. 1940.60s - 1942.38s | There are quite a few changes. 1942.38s - 1945.20s | Most notably, the exit up type field, 1945.20s - 1946.52s | the exit tag field, 1946.52s - 1948.54s | and the exit count field. 1948.54s - 1954.95s | All are essential for correct use of shim fix manipulation. 1954.95s - 1955.99s | At this stage, 1955.99s - 1958.67s | we are preparing to use all of our accumulated knowledge 1958.67s - 1960.05s | for an attack. 1960.05s - 1962.67s | We can make a target process load the shim fix 1962.67s - 1965.45s | simply by building our own shim data struct 1965.45s - 1968.67s | and pointing to the target pshim data to it. 1968.67s - 1970.77s | The process won't check any condition 1970.77s - 1972.89s | the original rule has configured. 1972.89s - 1976.37s | This allows us to apply any fix we want. 1976.37s - 1978.93s | We chose to inject the DLL, 1978.93s - 1983.93s | to inject the DLL into the target process by itself. 1987.28s - 1988.20s | Okay. 1988.20s - 1990.58s | We chose to inject the DLL 1990.58s - 1993.28s | into the target process by itself. 1993.30s - 1996.68s | This effectively makes the attack a file-less 1996.68s - 1998.78s | and registry-less DLL injection 1998.78s - 2000.28s | that can evade detection. 2002.02s - 2003.66s | According to this entry, 2003.66s - 2006.34s | rtvideo.dll will be injected 2006.34s - 2009.70s | if the process name starts with glj, 2009.70s - 2011.66s | ends with the temp extension, 2011.66s - 2013.78s | and it has the correct checksum. 2013.78s - 2017.38s | Luckily, these checks are done by the parent process 2017.38s - 2019.72s | and not by the child process. 2019.72s - 2022.78s | This means that once the exit tag in shim data 2022.78s - 2024.16s |


chunk_id: 160_chunk_38
chunk_text:
target pshim data to it. 1968.67s - 1970.77s | The process won't check any condition 1970.77s - 1972.89s | the original rule has configured. 1972.89s - 1976.37s | This allows us to apply any fix we want. 1976.37s - 1978.93s | We chose to inject the DLL, 1978.93s - 1983.93s | to inject the DLL into the target process by itself. 1987.28s - 1988.20s | Okay. 1988.20s - 1990.58s | We chose to inject the DLL 1990.58s - 1993.28s | into the target process by itself. 1993.30s - 1996.68s | This effectively makes the attack a file-less 1996.68s - 1998.78s | and registry-less DLL injection 1998.78s - 2000.28s | that can evade detection. 2002.02s - 2003.66s | According to this entry, 2003.66s - 2006.34s | rtvideo.dll will be injected 2006.34s - 2009.70s | if the process name starts with glj, 2009.70s - 2011.66s | ends with the temp extension, 2011.66s - 2013.78s | and it has the correct checksum. 2013.78s - 2017.38s | Luckily, these checks are done by the parent process 2017.38s - 2019.72s | and not by the child process. 2019.72s - 2022.78s | This means that once the exit tag in shim data 2022.78s - 2024.16s | points to this entry, 2024.16s - 2027.68s | the child process's app.ldll will apply the fix 2027.68s - 2029.78s | without checking the conditions. 2031.48s - 2032.76s | Having said all that, 2032.76s - 2035.20s | our tech has three limitations. 2035.20s - 2038.86s | The target process must be started as a suspended process. 2040.36s - 2043.16s | If the injected process executable file 2043.16s - 2045.28s | resides in this specific path 2045.28s - 2048.68s | or the security identifier of the file's owner 2048.68s - 2050.42s | is trusted installer, 2050.42s - 2052.42s | the shim fix won't be loaded. 2053.68s - 2057.80s | Injected DLL is not available to 64-bit processes 2057.80s - 2059.92s | as acgeneral.dll revealed. 2061.08s - 2062.40s | And you won't believe it, 2062.40s - 2063.92s | we found the target. 2063.92s - 2066.96s | And it's the Microsoft Edge updater we have shown before. 2068.40s - 2070.72s | Microsoft has made our lives easier 2070.72s - 2073.24s | as all three limitations are not present. 2073.24s - 2074.28s | Let's inject. 2075.84s - 2077.00s | At this point, 2077.00s - 2078.52s | we have enough knowledge 2078.52s - 2080.88s | to


chunk_id: 160_chunk_39
chunk_text:
points to this entry, 2024.16s - 2027.68s | the child process's app.ldll will apply the fix 2027.68s - 2029.78s | without checking the conditions. 2031.48s - 2032.76s | Having said all that, 2032.76s - 2035.20s | our tech has three limitations. 2035.20s - 2038.86s | The target process must be started as a suspended process. 2040.36s - 2043.16s | If the injected process executable file 2043.16s - 2045.28s | resides in this specific path 2045.28s - 2048.68s | or the security identifier of the file's owner 2048.68s - 2050.42s | is trusted installer, 2050.42s - 2052.42s | the shim fix won't be loaded. 2053.68s - 2057.80s | Injected DLL is not available to 64-bit processes 2057.80s - 2059.92s | as acgeneral.dll revealed. 2061.08s - 2062.40s | And you won't believe it, 2062.40s - 2063.92s | we found the target. 2063.92s - 2066.96s | And it's the Microsoft Edge updater we have shown before. 2068.40s - 2070.72s | Microsoft has made our lives easier 2070.72s - 2073.24s | as all three limitations are not present. 2073.24s - 2074.28s | Let's inject. 2075.84s - 2077.00s | At this point, 2077.00s - 2078.52s | we have enough knowledge 2078.52s - 2080.88s | to abuse the app compatibility mechanism. 2080.88s - 2083.28s | So let's go over all of the steps. 2084.46s - 2086.58s | We need to write our own DLL 2086.58s - 2088.64s | as the name of the rule specifies. 2090.14s - 2093.34s | We launch our binary as a suspended process. 2094.46s - 2097.78s | The struct is built with the correct tag 2097.78s - 2101.08s | as in our example. 2101.08s - 2103.86s | We write the struct to the target process's memory. 2104.72s - 2107.12s | We point to the struct. 2108.16s - 2110.68s | We resume the execution. 2110.70s - 2112.76s | And so app help will help us 2112.76s - 2114.82s | and apply our desired fix. 2114.82s - 2117.98s | And RTVideo will load to the target process. 2117.98s - 2123.98s | Let's see how it looks in action. 2123.98s - 2129.27s | shim injector.exe is dropped. 2129.27s - 2131.71s | And so we can see the hello message 2131.71s - 2134.55s | from inside of the child process. 2134.55s - 2137.87s | RTVideo.dll is loaded by our target. 2137.87s - 2141.19s | We can see our call stack going from install after init 2141.19s


chunk_id: 160_chunk_40
chunk_text:
abuse the app compatibility mechanism. 2080.88s - 2083.28s | So let's go over all of the steps. 2084.46s - 2086.58s | We need to write our own DLL 2086.58s - 2088.64s | as the name of the rule specifies. 2090.14s - 2093.34s | We launch our binary as a suspended process. 2094.46s - 2097.78s | The struct is built with the correct tag 2097.78s - 2101.08s | as in our example. 2101.08s - 2103.86s | We write the struct to the target process's memory. 2104.72s - 2107.12s | We point to the struct. 2108.16s - 2110.68s | We resume the execution. 2110.70s - 2112.76s | And so app help will help us 2112.76s - 2114.82s | and apply our desired fix. 2114.82s - 2117.98s | And RTVideo will load to the target process. 2117.98s - 2123.98s | Let's see how it looks in action. 2123.98s - 2129.27s | shim injector.exe is dropped. 2129.27s - 2131.71s | And so we can see the hello message 2131.71s - 2134.55s | from inside of the child process. 2134.55s - 2137.87s | RTVideo.dll is loaded by our target. 2137.87s - 2141.19s | We can see our call stack going from install after init 2141.19s - 2143.19s | to NSInject.dll. 2143.19s - 2145.75s | And lastly, to load library. 2146.57s - 2148.37s | We also have some logs on the command prompt. 2148.37s - 2151.03s | You can see the unique size, magic, 2151.03s - 2161.89s | exit type, and exit tag we defined earlier. 2161.89s - 2163.83s | Let's recap our second attack. 2163.83s - 2166.13s | There is a long history of shim attacks 2166.13s - 2168.89s | and how security products typically detect 2168.89s - 2172.49s | and mitigate malicious shim attacks, attack vectors. 2174.01s - 2176.55s | We were able to uncover new definitions 2176.55s - 2179.51s | and insights on the app compatibility component. 2179.51s - 2181.81s | And we used them to change what we think 2181.81s - 2183.47s | about this attack vector. 2184.99s - 2186.75s | This new perspective allowed us 2186.75s - 2189.91s | to create a new file-less and registry-less attack. 2191.53s - 2193.55s | We essentially took care of the problem 2193.55s - 2196.19s | of creating a custom SDB on a system 2196.19s - 2198.01s | with all that comes with it, 2198.01s - 2203.24s | namely registry and disk tracks. 2203.24s -


chunk_id: 160_chunk_41
chunk_text:
- 2143.19s | to NSInject.dll. 2143.19s - 2145.75s | And lastly, to load library. 2146.57s - 2148.37s | We also have some logs on the command prompt. 2148.37s - 2151.03s | You can see the unique size, magic, 2151.03s - 2161.89s | exit type, and exit tag we defined earlier. 2161.89s - 2163.83s | Let's recap our second attack. 2163.83s - 2166.13s | There is a long history of shim attacks 2166.13s - 2168.89s | and how security products typically detect 2168.89s - 2172.49s | and mitigate malicious shim attacks, attack vectors. 2174.01s - 2176.55s | We were able to uncover new definitions 2176.55s - 2179.51s | and insights on the app compatibility component. 2179.51s - 2181.81s | And we used them to change what we think 2181.81s - 2183.47s | about this attack vector. 2184.99s - 2186.75s | This new perspective allowed us 2186.75s - 2189.91s | to create a new file-less and registry-less attack. 2191.53s - 2193.55s | We essentially took care of the problem 2193.55s - 2196.19s | of creating a custom SDB on a system 2196.19s - 2198.01s | with all that comes with it, 2198.01s - 2203.24s | namely registry and disk tracks. 2203.24s - 2206.64s | By writing to a child process, which is not suspicious, 2206.64s - 2208.32s | and by loading the target DLL 2208.32s - 2210.36s | from the suspended child process 2210.36s - 2213.76s | before any EDR hook can be established, 2213.76s - 2219.21s | we effectively bypassed EDR detection. 2219.21s - 2221.47s | We chose this specific shim fix 2221.47s - 2224.51s | because it is applicable to many scenarios 2224.51s - 2226.91s | and demonstrates our attack in a clear way. 2227.95s - 2229.75s | There are many more shim fixes 2229.75s - 2231.95s | that can be used for malicious purposes. 2231.95s - 2233.75s | This was only one of them. 2235.43s - 2236.75s | We've come a long way. 2236.75s - 2238.31s | Let's summarize both attacks 2238.31s - 2243.04s | and see what we can take away from this research. 2243.04s - 2245.28s | As for detections, let's go over 2245.28s - 2247.88s | how should someone detect these kinds of attacks. 2248.88s - 2251.00s | For the first attack, 2251.00s - 2254.44s | RPC is a big and early part of the first attack, 2254.44s - 2257.56s | so monitoring remote procedure calls


chunk_id: 160_chunk_42
chunk_text:
2206.64s | By writing to a child process, which is not suspicious, 2206.64s - 2208.32s | and by loading the target DLL 2208.32s - 2210.36s | from the suspended child process 2210.36s - 2213.76s | before any EDR hook can be established, 2213.76s - 2219.21s | we effectively bypassed EDR detection. 2219.21s - 2221.47s | We chose this specific shim fix 2221.47s - 2224.51s | because it is applicable to many scenarios 2224.51s - 2226.91s | and demonstrates our attack in a clear way. 2227.95s - 2229.75s | There are many more shim fixes 2229.75s - 2231.95s | that can be used for malicious purposes. 2231.95s - 2233.75s | This was only one of them. 2235.43s - 2236.75s | We've come a long way. 2236.75s - 2238.31s | Let's summarize both attacks 2238.31s - 2243.04s | and see what we can take away from this research. 2243.04s - 2245.28s | As for detections, let's go over 2245.28s - 2247.88s | how should someone detect these kinds of attacks. 2248.88s - 2251.00s | For the first attack, 2251.00s - 2254.44s | RPC is a big and early part of the first attack, 2254.44s - 2257.56s | so monitoring remote procedure calls 2257.56s - 2259.28s | made to click-to-run service 2259.28s - 2262.48s | can reveal the use of non-standard DLL paths. 2263.32s - 2265.96s | Requests for opportunistic locks 2265.96s - 2272.26s | on critical system files like sysmain.sdb should be flagged. 2272.26s - 2274.40s | Implementing security policies 2275.38s - 2278.36s | that restrict such high-level memory write operations 2278.36s - 2280.36s | as it is very suspicious, 2280.36s - 2282.60s | click-to-run service shouldn't write 2282.60s - 2286.94s | to this type of processes on its own. 2286.94s - 2288.52s | Regarding the second attack, 2289.70s - 2292.20s | keeping an eye on file system activity, 2292.20s - 2295.30s | particularly for the creation of DLL files 2295.30s - 2298.22s | which are listed in sysmain.sdb 2298.22s - 2302.30s | and are in directories unrelated to the original files, 2302.30s - 2306.16s | to the original rules. 2306.16s - 2309.36s | Also, we invite the community to take our findings 2309.36s - 2312.94s | to refine our attacks and make new and better ones. 2314.24s - 2315.68s | Some ideas. 2315.68s - 2317.36s | The community could find a target 2317.36s - 2322.00s | for the init process data


chunk_id: 160_chunk_43
chunk_text:
2257.56s - 2259.28s | made to click-to-run service 2259.28s - 2262.48s | can reveal the use of non-standard DLL paths. 2263.32s - 2265.96s | Requests for opportunistic locks 2265.96s - 2272.26s | on critical system files like sysmain.sdb should be flagged. 2272.26s - 2274.40s | Implementing security policies 2275.38s - 2278.36s | that restrict such high-level memory write operations 2278.36s - 2280.36s | as it is very suspicious, 2280.36s - 2282.60s | click-to-run service shouldn't write 2282.60s - 2286.94s | to this type of processes on its own. 2286.94s - 2288.52s | Regarding the second attack, 2289.70s - 2292.20s | keeping an eye on file system activity, 2292.20s - 2295.30s | particularly for the creation of DLL files 2295.30s - 2298.22s | which are listed in sysmain.sdb 2298.22s - 2302.30s | and are in directories unrelated to the original files, 2302.30s - 2306.16s | to the original rules. 2306.16s - 2309.36s | Also, we invite the community to take our findings 2309.36s - 2312.94s | to refine our attacks and make new and better ones. 2314.24s - 2315.68s | Some ideas. 2315.68s - 2317.36s | The community could find a target 2317.36s - 2322.00s | for the init process data operation that we didn't find. 2323.64s - 2325.60s | There is much more to understand 2325.60s - 2327.38s | about the shim data structure 2327.38s - 2329.72s | and how it can affect the execution 2329.72s - 2333.92s | of the ahcache.sys functions. 2333.92s - 2335.12s | There are many more flows 2335.12s - 2338.04s | that can potentially manipulate the AVL table, 2338.04s - 2340.48s | which in turn will affect which process 2340.48s - 2345.94s | will get what shim fix. 2345.94s - 2350.76s | In conclusion, in our presentation, 2350.76s - 2353.00s | we detailed our comprehensive methodology 2353.00s - 2355.40s | for conducting attack surface research. 2357.12s - 2360.52s | By leveraging and manipulating various system components, 2360.52s - 2363.16s | including services, op locks, 2363.16s - 2365.20s | and compatibility mechanisms, 2365.20s - 2368.08s | we demonstrated how to consolidate these elements 2368.08s - 2372.85s | into a singular, cohesive attack strategy. 2372.85s - 2375.73s | The op lock and the compatibility mechanisms 2375.73s - 2379.57s | could be integral parts of other multi-component, 2379.57s - 2382.73s | sophisticated, and complex attacks. 2382.73s - 2386.57s | Op lock can be used in many scenarios as


chunk_id: 160_chunk_44
chunk_text:
operation that we didn't find. 2323.64s - 2325.60s | There is much more to understand 2325.60s - 2327.38s | about the shim data structure 2327.38s - 2329.72s | and how it can affect the execution 2329.72s - 2333.92s | of the ahcache.sys functions. 2333.92s - 2335.12s | There are many more flows 2335.12s - 2338.04s | that can potentially manipulate the AVL table, 2338.04s - 2340.48s | which in turn will affect which process 2340.48s - 2345.94s | will get what shim fix. 2345.94s - 2350.76s | In conclusion, in our presentation, 2350.76s - 2353.00s | we detailed our comprehensive methodology 2353.00s - 2355.40s | for conducting attack surface research. 2357.12s - 2360.52s | By leveraging and manipulating various system components, 2360.52s - 2363.16s | including services, op locks, 2363.16s - 2365.20s | and compatibility mechanisms, 2365.20s - 2368.08s | we demonstrated how to consolidate these elements 2368.08s - 2372.85s | into a singular, cohesive attack strategy. 2372.85s - 2375.73s | The op lock and the compatibility mechanisms 2375.73s - 2379.57s | could be integral parts of other multi-component, 2379.57s - 2382.73s | sophisticated, and complex attacks. 2382.73s - 2386.57s | Op lock can be used in many scenarios as a building block, 2386.57s - 2388.17s | and there are many more shim fixes 2388.17s - 2390.53s | that can be used with malicious intent, 2390.53s - 2395.76s | even with 64-bit processes. 2395.76s - 2398.40s | Our extensive research uncovered new techniques 2398.44s - 2402.20s | for stealthy injection and privileged escalation, 2402.20s - 2407.37s | enhancing the effectiveness of these attacks. 2407.37s - 2411.85s | We demonstrated two attacks that won't be monitored by EDRs. 2411.85s - 2414.97s | The injection occurs in a very early stage, 2414.97s - 2421.18s | a stage where EDRs can't establish a hook yet. 2421.18s - 2424.26s | Through reverse engineering and undocumented API 2424.26s - 2426.38s | and its associated structures, 2426.38s - 2429.02s | we gained valuable insights that contributed 2429.02s - 2431.10s | to the development of these methods. 2432.90s - 2434.70s | Additionally, we modernized 2434.70s - 2437.10s | a previously known malicious technique, 2437.10s - 2439.62s | transforming it into a more elusive, 2439.62s - 2441.66s | file-less, and registry-less attack. 2442.86s - 2445.74s | Lastly, we once again encourage the community 2445.74s - 2448.14s | to continue building on our research, 2448.14s - 2450.18s | exploring


chunk_id: 160_chunk_45
chunk_text:
a building block, 2386.57s - 2388.17s | and there are many more shim fixes 2388.17s - 2390.53s | that can be used with malicious intent, 2390.53s - 2395.76s | even with 64-bit processes. 2395.76s - 2398.40s | Our extensive research uncovered new techniques 2398.44s - 2402.20s | for stealthy injection and privileged escalation, 2402.20s - 2407.37s | enhancing the effectiveness of these attacks. 2407.37s - 2411.85s | We demonstrated two attacks that won't be monitored by EDRs. 2411.85s - 2414.97s | The injection occurs in a very early stage, 2414.97s - 2421.18s | a stage where EDRs can't establish a hook yet. 2421.18s - 2424.26s | Through reverse engineering and undocumented API 2424.26s - 2426.38s | and its associated structures, 2426.38s - 2429.02s | we gained valuable insights that contributed 2429.02s - 2431.10s | to the development of these methods. 2432.90s - 2434.70s | Additionally, we modernized 2434.70s - 2437.10s | a previously known malicious technique, 2437.10s - 2439.62s | transforming it into a more elusive, 2439.62s - 2441.66s | file-less, and registry-less attack. 2442.86s - 2445.74s | Lastly, we once again encourage the community 2445.74s - 2448.14s | to continue building on our research, 2448.14s - 2450.18s | exploring the leads we have provided 2450.18s - 2454.19s | to further advance this field. 2454.19s - 2455.03s | Thank you. 2455.99s - 2459.35s | Thank you so much for being here and hearing our talk. 2459.35s - 2462.11s | The source code of our tools is now public. 2462.11s - 2464.23s | If you have any questions, you are free to ask. 2464.23s - 2466.83s | You can also find us on Twitter and LinkedIn. 2466.83s - 2467.67s | Thanks again.


chunk_id: 160_chunk_46
chunk_text:
the leads we have provided 2450.18s - 2454.19s | to further advance this field. 2454.19s - 2455.03s | Thank you. 2455.99s - 2459.35s | Thank you so much for being here and hearing our talk. 2459.35s - 2462.11s | The source code of our tools is now public. 2462.11s - 2464.23s | If you have any questions, you are free to ask. 2464.23s - 2466.83s | You can also find us on Twitter and LinkedIn. 2466.83s - 2467.67s | Thanks again.


chunk_id: 161_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=1Hx-PzyGtX0", "title": "DEF CON 32 - Process Injection Attacks w ROP - Bramwell Brizendine, Shiva Shashank Kusuma", "description": "This talk showcases techniques for process injection using advanced return-oriented programming (ROP). Process injection via ROP introduces significant hurdles, requiring many WinAPIs to be chained together, each with complex parameters and return values. We give practical details on how to best manage this. One seemingly insurmountable challenge is in identifying the target binary, as string comparison can be extremely difficult in ROP, as needed ROP gadgets may be lacking. We unveil a unique, universal solution, giving a reliable means of string comparison via ROP, which works all the time, allowing a specific process to be pinpointed and injected into via ROP.\n\nWe created numerous patterns for different WinAPIs, allowing for as many as a dozen ways of preparing a specific WinAPI via ROP, if using an approach centered around the PUSHAD instruction. With some WinAPIs, there are zero patterns for PUSHAD, forcing us to rely upon the much lauded \u201csniper\u201d approach. We document all such variations of patterns for the WinAPIs in our demonstrated process injection. This research is not intended to demo a one-off example of process injection via ROP, but to provide a methodology that can be used time and time again, providing unique templates for others to use the same WinAPIs when attempting process injection via ROP.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 1367, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 1.52s - 6.52s | This text was transcribed using whisper model: large-v2 Welcome, welcome, welcome to DEF CON. My name is Dr. Bramal Brizendine. I am the director of 8.86s - 14.34s | the Verona Lab, which deals with vulnerability research. Creator of the Shell Wasp, which 14.34s - 19.88s | allows us to utilize Windows syscalls in shellcode. I've created the Jop Rocket and Rop 19.88s - 24.32s | Rocket, both of which deal with return oriented programming and jump oriented programming. 24.32s - 28.72s | And I've also created an NSA funded research project called Sherem, which allows us to 28.72s - 34.96s | analyze, uh, shellcode. Uh, I've spoken at many different conferences in the past, um, and 34.96s - 39.96s | I'm also an assistant professor of cyber security. I have a PhD in cyber operations, which 42.40s - 48.58s | is a highly technical degree. And all of those, uh, previous projects have, um, previously


chunk_id: 161_chunk_1
chunk_text:
but to provide a methodology that can be used time and time again, providing unique templates for others to use the same WinAPIs when attempting process injection via ROP.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 1367, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 1.52s - 6.52s | This text was transcribed using whisper model: large-v2 Welcome, welcome, welcome to DEF CON. My name is Dr. Bramal Brizendine. I am the director of 8.86s - 14.34s | the Verona Lab, which deals with vulnerability research. Creator of the Shell Wasp, which 14.34s - 19.88s | allows us to utilize Windows syscalls in shellcode. I've created the Jop Rocket and Rop 19.88s - 24.32s | Rocket, both of which deal with return oriented programming and jump oriented programming. 24.32s - 28.72s | And I've also created an NSA funded research project called Sherem, which allows us to 28.72s - 34.96s | analyze, uh, shellcode. Uh, I've spoken at many different conferences in the past, um, and 34.96s - 39.96s | I'm also an assistant professor of cyber security. I have a PhD in cyber operations, which 42.40s - 48.58s | is a highly technical degree. And all of those, uh, previous projects have, um, previously 48.58s - 53.58s | been presented at DEF CON, so check them out. My co-speaker is, uh, Shiver Shashank Kusama. 53.58s - 58.58s | He is a research assistant and, uh, he has a master's in computer science and is pursuing a 61.58s - 66.12s | master's in cyber security. Uh, he's looking for internship opportunities for the summer as 66.12s - 71.12s | well. So, our agenda. What are we going to focus on? Well, firstly, we'll talk briefly about a 73.96s - 79.76s | general approach to shellcodeless ROP. How do we create unique patterns to facilitate 79.76s - 85.68s | process injection? Some generic ROP techniques for process injection. And then we will look 85.68s - 90.70s | at a sample process injection technique that has a, uh, highly novel solution to a rather 93.40s - 100.40s | significant problem. We'll have a demo and then we'll have another brief, uh, uh, process 100.40s - 106.34s | injection and then we'll, we will conclude. So, some, uh, preliminary words on our 106.36s - 112.16s | experiment. Now this, when we, we conducted this research, we did it on a contrived binary, uh, 112.16s - 116.90s | one


chunk_id: 161_chunk_2
chunk_text:
48.58s - 53.58s | been presented at DEF CON, so check them out. My co-speaker is, uh, Shiver Shashank Kusama. 53.58s - 58.58s | He is a research assistant and, uh, he has a master's in computer science and is pursuing a 61.58s - 66.12s | master's in cyber security. Uh, he's looking for internship opportunities for the summer as 66.12s - 71.12s | well. So, our agenda. What are we going to focus on? Well, firstly, we'll talk briefly about a 73.96s - 79.76s | general approach to shellcodeless ROP. How do we create unique patterns to facilitate 79.76s - 85.68s | process injection? Some generic ROP techniques for process injection. And then we will look 85.68s - 90.70s | at a sample process injection technique that has a, uh, highly novel solution to a rather 93.40s - 100.40s | significant problem. We'll have a demo and then we'll have another brief, uh, uh, process 100.40s - 106.34s | injection and then we'll, we will conclude. So, some, uh, preliminary words on our 106.36s - 112.16s | experiment. Now this, when we, we conducted this research, we did it on a contrived binary, uh, 112.16s - 116.90s | one of those intentionally vulnerable and is filled with convenient gadgets because we want 116.90s - 122.18s | our work to be applicable not just to one particular vulnerable binary, but to 122.18s - 126.48s | potentially, uh, any binary. So, we want to discover everything that is possible. And this 126.48s - 133.32s | research is really focused on, uh, ROP from the standpoint of you compromise a binary. It's 133.36s - 137.70s | not something where we're trying to integrate ROP and some kind of custom malware or some 137.70s - 144.14s | kind of custom red team software. So, let's introduce the idea of shellcodeless ROP. What 144.14s - 149.04s | does it mean exactly? Well, it's this idea of instead of a bypassing data execution 149.04s - 154.86s | prevention DEP, we are instead going to invoke the, uh, functionality of a shellcode 154.86s - 159.86s | directly via ROP gadgets. And it's something that has very seldom been done in the Windows 160.24s - 165.24s | ecosystem. And when you see it, it's almost always two, three APIs chained together. But 169.88s - 176.18s | you'll see, uh, later today that we have, uh, vastly, uh,


chunk_id: 161_chunk_3
chunk_text:
of those intentionally vulnerable and is filled with convenient gadgets because we want 116.90s - 122.18s | our work to be applicable not just to one particular vulnerable binary, but to 122.18s - 126.48s | potentially, uh, any binary. So, we want to discover everything that is possible. And this 126.48s - 133.32s | research is really focused on, uh, ROP from the standpoint of you compromise a binary. It's 133.36s - 137.70s | not something where we're trying to integrate ROP and some kind of custom malware or some 137.70s - 144.14s | kind of custom red team software. So, let's introduce the idea of shellcodeless ROP. What 144.14s - 149.04s | does it mean exactly? Well, it's this idea of instead of a bypassing data execution 149.04s - 154.86s | prevention DEP, we are instead going to invoke the, uh, functionality of a shellcode 154.86s - 159.86s | directly via ROP gadgets. And it's something that has very seldom been done in the Windows 160.24s - 165.24s | ecosystem. And when you see it, it's almost always two, three APIs chained together. But 169.88s - 176.18s | you'll see, uh, later today that we have, uh, vastly, uh, more APIs to achieve what we want to 176.18s - 181.26s | do. Some also, uh, some previous work on shellcodeless job. There's a video link in the 181.26s - 187.52s | slides, so I do encourage you to, uh, check it out if you're interested. So, in terms of 187.52s - 191.42s | approaching shellcodeless job there, or shellcodeless ROP, there are a couple approaches we 191.42s - 198.20s | could take. One is utilizing push add, where we're going to populate values on, uh, certain 198.20s - 204.44s | registers, uh, with certain predefined values. Um, and then that causes them to be loaded 204.44s - 209.18s | onto the stack in a, a certain predefined order. And we'll also use move dereference or the 209.18s - 214.08s | sniper technique. And this allows us to precisely write our values to the stack and we can 214.08s - 220.98s | then increment or decrement to the next, uh, slot that we want to provide values for. So, 220.98s - 226.66s | those are both critically, uh, important for us. And I want to reemphasize the importance of 226.66s - 230.50s | this idea of finding patterns. Because again,


chunk_id: 161_chunk_4
chunk_text:
more APIs to achieve what we want to 176.18s - 181.26s | do. Some also, uh, some previous work on shellcodeless job. There's a video link in the 181.26s - 187.52s | slides, so I do encourage you to, uh, check it out if you're interested. So, in terms of 187.52s - 191.42s | approaching shellcodeless job there, or shellcodeless ROP, there are a couple approaches we 191.42s - 198.20s | could take. One is utilizing push add, where we're going to populate values on, uh, certain 198.20s - 204.44s | registers, uh, with certain predefined values. Um, and then that causes them to be loaded 204.44s - 209.18s | onto the stack in a, a certain predefined order. And we'll also use move dereference or the 209.18s - 214.08s | sniper technique. And this allows us to precisely write our values to the stack and we can 214.08s - 220.98s | then increment or decrement to the next, uh, slot that we want to provide values for. So, 220.98s - 226.66s | those are both critically, uh, important for us. And I want to reemphasize the importance of 226.66s - 230.50s | this idea of finding patterns. Because again, we're not really just approaching one process 230.50s - 235.04s | injection technique, but we want our work to be applicable broadly to many different 235.04s - 240.74s | techniques. How do we do this in terms of return oriented programming? So, we really want to 240.74s - 245.58s | emphasize that, you know, we have these particular slots, uh, where we have, uh, registers 245.58s - 251.28s | going in a certain order. Uh, so we really, uh, weaponize this in terms of developing new 251.28s - 257.66s | patterns for different APIs, uh, both Windows APIs as well as native APIs to allow us to invoke 257.66s - 265.16s | those easily using return oriented programming. So, and when using many different APIs, we 265.18s - 270.46s | want to be able to chain them together. Lar- kind of like in the sense where you have a, uh, a 270.46s - 273.56s | ROP chain, you have different, uh, ROP gadgets chained together. We'll be chaining different 273.56s - 279.86s | APIs together. So, you may get one, uh, return value. Uh, in this case, uh, open process 279.86s - 286.14s | runtime address is provided to us


chunk_id: 161_chunk_5
chunk_text:
we're not really just approaching one process 230.50s - 235.04s | injection technique, but we want our work to be applicable broadly to many different 235.04s - 240.74s | techniques. How do we do this in terms of return oriented programming? So, we really want to 240.74s - 245.58s | emphasize that, you know, we have these particular slots, uh, where we have, uh, registers 245.58s - 251.28s | going in a certain order. Uh, so we really, uh, weaponize this in terms of developing new 251.28s - 257.66s | patterns for different APIs, uh, both Windows APIs as well as native APIs to allow us to invoke 257.66s - 265.16s | those easily using return oriented programming. So, and when using many different APIs, we 265.18s - 270.46s | want to be able to chain them together. Lar- kind of like in the sense where you have a, uh, a 270.46s - 273.56s | ROP chain, you have different, uh, ROP gadgets chained together. We'll be chaining different 273.56s - 279.86s | APIs together. So, you may get one, uh, return value. Uh, in this case, uh, open process 279.86s - 286.14s | runtime address is provided to us in EAX. We can use that subsequently in a pattern for open 286.14s - 291.14s | process because of course we need to call open process. So, a large part of our research is 291.36s - 297.56s | really focused on generating a lot of these different types of patterns and actually we've 297.56s - 302.58s | developed more than 150 unique patterns to provide a lot of opportunities. Um, we'll talk 305.58s - 309.72s | more in depth about some of them and we'll give some examples, but historically, uh, some of 309.72s - 315.12s | the tools that have done this have been things like, uh, Mona, Mona, you know, Virtual Alloc, 315.12s - 320.20s | Virtual Protect, and you have a couple patterns. So, it's not a significant number of patterns. 320.22s - 326.10s | So, let's talk now briefly about some generic ROP techniques that we can use to help us with, 326.10s - 331.10s | uh, process injection. So, one is the idea of using function output, using that function 333.50s - 339.90s | output as a way to, um, to be a parameter. So, get product address and a little library 339.90s - 345.74s


chunk_id: 161_chunk_6
chunk_text:
in EAX. We can use that subsequently in a pattern for open 286.14s - 291.14s | process because of course we need to call open process. So, a large part of our research is 291.36s - 297.56s | really focused on generating a lot of these different types of patterns and actually we've 297.56s - 302.58s | developed more than 150 unique patterns to provide a lot of opportunities. Um, we'll talk 305.58s - 309.72s | more in depth about some of them and we'll give some examples, but historically, uh, some of 309.72s - 315.12s | the tools that have done this have been things like, uh, Mona, Mona, you know, Virtual Alloc, 315.12s - 320.20s | Virtual Protect, and you have a couple patterns. So, it's not a significant number of patterns. 320.22s - 326.10s | So, let's talk now briefly about some generic ROP techniques that we can use to help us with, 326.10s - 331.10s | uh, process injection. So, one is the idea of using function output, using that function 333.50s - 339.90s | output as a way to, um, to be a parameter. So, get product address and a little library 339.90s - 345.74s | often go hand in hand and they're very familiar and well known. Uh, so with a little library, 345.76s - 351.96s | we can get a handle to a module, uh, which is the, the base address of a certain DLL and that's 351.96s - 357.60s | required for get product address. So, we take the output from the one, which is going to be 357.60s - 364.44s | returned to us in EAX and then we use that subsequently in, uh, get product address. And 364.44s - 368.94s | we'll do this time and time again. So, return values as well as other out parameters if 368.94s - 374.32s | you're dealing with native APIs. And then this gets a little bit more complex. So, 374.36s - 379.64s | structures is parameters. Can we do that with return oriented programming? And we actually 379.64s - 384.50s | can. So, with a structure, we need to look clearly at the, the definition of the structure and 384.50s - 388.38s | then we need to build that byte by byte through return oriented programming. And we'll 388.38s - 392.44s | typically do that with a series of move dereferences and


chunk_id: 161_chunk_7
chunk_text:
| often go hand in hand and they're very familiar and well known. Uh, so with a little library, 345.76s - 351.96s | we can get a handle to a module, uh, which is the, the base address of a certain DLL and that's 351.96s - 357.60s | required for get product address. So, we take the output from the one, which is going to be 357.60s - 364.44s | returned to us in EAX and then we use that subsequently in, uh, get product address. And 364.44s - 368.94s | we'll do this time and time again. So, return values as well as other out parameters if 368.94s - 374.32s | you're dealing with native APIs. And then this gets a little bit more complex. So, 374.36s - 379.64s | structures is parameters. Can we do that with return oriented programming? And we actually 379.64s - 384.50s | can. So, with a structure, we need to look clearly at the, the definition of the structure and 384.50s - 388.38s | then we need to build that byte by byte through return oriented programming. And we'll 388.38s - 392.44s | typically do that with a series of move dereferences and we can just increment and 392.44s - 398.52s | decrement to the, to the next slot as we slowly build our, uh, our structure. And in some 398.52s - 403.00s | cases, we may actually have nested structures. So, take a look at adjust hook and privileges. 403.00s - 408.98s | We have several nested structures and it needs to be done exactly correctly or else it 408.98s - 413.98s | simply will just not work. Um, one thing that is also, uh, immensely important is this idea 417.42s - 422.42s | of storing important values, um, addresses, handles, things which may be obtained by 425.96s - 430.40s | calling a Windows API. If we call a Windows API to obtain one of these values, well that 430.44s - 434.60s | takes a lot of effort. And if we needed it again, well of course we don't want to call it a 434.60s - 441.04s | second time. So, we will make an effort to save that value somewhere in memory and then we 441.04s - 445.82s | can retrieve it later. So, we might have a common reference point. We move ESP to a 445.82s - 450.28s | location,


chunk_id: 161_chunk_8
chunk_text:
we can just increment and 392.44s - 398.52s | decrement to the, to the next slot as we slowly build our, uh, our structure. And in some 398.52s - 403.00s | cases, we may actually have nested structures. So, take a look at adjust hook and privileges. 403.00s - 408.98s | We have several nested structures and it needs to be done exactly correctly or else it 408.98s - 413.98s | simply will just not work. Um, one thing that is also, uh, immensely important is this idea 417.42s - 422.42s | of storing important values, um, addresses, handles, things which may be obtained by 425.96s - 430.40s | calling a Windows API. If we call a Windows API to obtain one of these values, well that 430.44s - 434.60s | takes a lot of effort. And if we needed it again, well of course we don't want to call it a 434.60s - 441.04s | second time. So, we will make an effort to save that value somewhere in memory and then we 441.04s - 445.82s | can retrieve it later. So, we might have a common reference point. We move ESP to a 445.82s - 450.28s | location, maybe we advance forward 500 bytes and we just start writing different values 450.28s - 455.26s | there. And that common, uh, reference point can, will change from gadget to gadget but we 455.26s - 460.26s | can manually calculate that and make adjustments, uh, as need be. So, again you'll have 460.26s - 465.46s | lots of important values and you can save them and then retrieve them subsequently, uh, 465.46s - 470.66s | later on. So, one other thing we did is, and this is actually, uh, completely novel, 470.66s - 476.10s | combining move dereference and push add in terms of building a pattern. So, we can use that 476.10s - 482.74s | to create a, a, a ROP chain pattern. Uh, push add you can have a maximum of 4 parameters, 5 482.74s - 488.86s | if you use ESP but that can be rather, uh, challenging to do. Um, so we can do push add and 488.88s - 494.52s | then do the remainder. We can supply those via move dereference. Now, if you have the option 494.52s - 499.50s | to, uh, place your strings and data in the payload directly, then by all


chunk_id: 161_chunk_9
chunk_text:
maybe we advance forward 500 bytes and we just start writing different values 450.28s - 455.26s | there. And that common, uh, reference point can, will change from gadget to gadget but we 455.26s - 460.26s | can manually calculate that and make adjustments, uh, as need be. So, again you'll have 460.26s - 465.46s | lots of important values and you can save them and then retrieve them subsequently, uh, 465.46s - 470.66s | later on. So, one other thing we did is, and this is actually, uh, completely novel, 470.66s - 476.10s | combining move dereference and push add in terms of building a pattern. So, we can use that 476.10s - 482.74s | to create a, a, a ROP chain pattern. Uh, push add you can have a maximum of 4 parameters, 5 482.74s - 488.86s | if you use ESP but that can be rather, uh, challenging to do. Um, so we can do push add and 488.88s - 494.52s | then do the remainder. We can supply those via move dereference. Now, if you have the option 494.52s - 499.50s | to, uh, place your strings and data in the payload directly, then by all means do it. 499.50s - 504.06s | Because it's going to save you effort. Again, if you have a common reference point, you can 504.06s - 507.90s | use these. You have a pointer to a string. And you, some of you might be saying, well, what 507.90s - 513.24s | about EDR? Well, yes, EDR will be an issue at times and so this may not always be plausible. 513.24s - 518.24s | If you have no payload size restrictions, one option is to obfuscate some of this and then 518.26s - 524.94s | you could use a ROP to go and de-obfuscate it as need be. So, let's get into an actual, uh, 524.94s - 529.00s | process injection technique. Now, this is based on something that I actually did at Hack in the 529.00s - 535.44s | Box Amsterdam 2023. That was all Windows syscalls and shellcode. This obviously is not. It's 535.44s - 539.64s | return oriented programming. And so these are more, uh, these are Windows APIs and native 539.64s - 544.66s | APIs. It's not necessarily strikingly original. Um, but in any case, we have a new URL. We're 544.88s - 551.48s | going


chunk_id: 161_chunk_10
chunk_text:
means do it. 499.50s - 504.06s | Because it's going to save you effort. Again, if you have a common reference point, you can 504.06s - 507.90s | use these. You have a pointer to a string. And you, some of you might be saying, well, what 507.90s - 513.24s | about EDR? Well, yes, EDR will be an issue at times and so this may not always be plausible. 513.24s - 518.24s | If you have no payload size restrictions, one option is to obfuscate some of this and then 518.26s - 524.94s | you could use a ROP to go and de-obfuscate it as need be. So, let's get into an actual, uh, 524.94s - 529.00s | process injection technique. Now, this is based on something that I actually did at Hack in the 529.00s - 535.44s | Box Amsterdam 2023. That was all Windows syscalls and shellcode. This obviously is not. It's 535.44s - 539.64s | return oriented programming. And so these are more, uh, these are Windows APIs and native 539.64s - 544.66s | APIs. It's not necessarily strikingly original. Um, but in any case, we have a new URL. We're 544.88s - 551.48s | going to create that. It's going to slither up inside of our victim target and external 551.48s - 556.92s | process and then we're going to write our shellcode there and then cause it to launch. So, in 556.92s - 562.72s | terms of ROP, the actual complete chain of gadgets that we have, 29 gadgets. It's an 562.72s - 569.36s | extraordinary amount. Uh, I'm not familiar with any, uh, ROP chain in the Windows ecosystem 569.36s - 574.60s | that has anywhere near this level of gadgets. And so it's a lot of work to, to maintain 574.60s - 580.18s | these from, um, from API, API call to API call. And it would be a lot more, actually, if we 580.18s - 586.42s | did not use that technique of storing and retrieving certain values that we need. So, let's 586.42s - 591.18s | talk about load library. We can use that with, uh, push add and a pattern. So, we load the 591.18s - 596.96s | particular values into, uh, registers and then we go and do push add. Then that causes it to 596.96s - 603.24s | go in a predefined, uh, location. And so, let's


chunk_id: 161_chunk_11
chunk_text:
to create that. It's going to slither up inside of our victim target and external 551.48s - 556.92s | process and then we're going to write our shellcode there and then cause it to launch. So, in 556.92s - 562.72s | terms of ROP, the actual complete chain of gadgets that we have, 29 gadgets. It's an 562.72s - 569.36s | extraordinary amount. Uh, I'm not familiar with any, uh, ROP chain in the Windows ecosystem 569.36s - 574.60s | that has anywhere near this level of gadgets. And so it's a lot of work to, to maintain 574.60s - 580.18s | these from, um, from API, API call to API call. And it would be a lot more, actually, if we 580.18s - 586.42s | did not use that technique of storing and retrieving certain values that we need. So, let's 586.42s - 591.18s | talk about load library. We can use that with, uh, push add and a pattern. So, we load the 591.18s - 596.96s | particular values into, uh, registers and then we go and do push add. Then that causes it to 596.96s - 603.24s | go in a predefined, uh, location. And so, let's see what happens exactly. So, we, we have our 603.24s - 607.80s | stack values there and those correspond to our pattern. So, we have red 8. That means we're 607.80s - 612.48s | going to do this ROP NOP. We're going to skip 8 bytes. So, we skip that. We do a jump EVP 612.48s - 616.94s | dereference. We, therefore, invoke load library. We have a return address. We have a 616.94s - 623.26s | parameter. Everything checks out. And then we get a result. Exact result that we want. So, 623.26s - 629.86s | we get the base address of NTDLL. And then we can use that subsequently for git proc 629.86s - 633.60s | address, which, which is our next one. And we'll do the same thing. We'll populate different 633.60s - 639.00s | values into the registers that we can then call push add. And we get the runtime address. In 639.00s - 645.32s | this case, we're doing create tool help 32 snapshot. An extremely important thing that we'll 645.32s - 649.62s | talk about momentarily. So, these are the patterns for load library. We have a lot of them, 649.62s - 655.32s |


chunk_id: 161_chunk_12
chunk_text:
see what happens exactly. So, we, we have our 603.24s - 607.80s | stack values there and those correspond to our pattern. So, we have red 8. That means we're 607.80s - 612.48s | going to do this ROP NOP. We're going to skip 8 bytes. So, we skip that. We do a jump EVP 612.48s - 616.94s | dereference. We, therefore, invoke load library. We have a return address. We have a 616.94s - 623.26s | parameter. Everything checks out. And then we get a result. Exact result that we want. So, 623.26s - 629.86s | we get the base address of NTDLL. And then we can use that subsequently for git proc 629.86s - 633.60s | address, which, which is our next one. And we'll do the same thing. We'll populate different 633.60s - 639.00s | values into the registers that we can then call push add. And we get the runtime address. In 639.00s - 645.32s | this case, we're doing create tool help 32 snapshot. An extremely important thing that we'll 645.32s - 649.62s | talk about momentarily. So, these are the patterns for load library. We have a lot of them, 649.62s - 655.32s | 9. And git proc address, we have 11. So, that gives us a lot of flexibilities because if you're 655.32s - 660.22s | trying to do something, you don't have a particular gadget while you just give up. If you do, 660.22s - 665.90s | then the chain is incomplete. But having multiple patterns, we can drill down deeper and 665.90s - 671.26s | maybe find something that actually works. In any case, our next API is create tool help 32 671.26s - 675.60s | snapshot, which will allow us to take a snapshot of all the active processes that are out 675.62s - 681.12s | there. And it's immensely important. We need it to discover, uh, the different PIDs. We're 681.12s - 687.10s | going to target one of those. So, there are actually 11 patterns. So, a lot of flexibility 687.10s - 692.30s | there in terms of how you can invoke it with the push add instruction. Um, there's an example 692.30s - 697.08s | of the ROP and we got the push add at the bottom. Virtual alloc, um, it's one way to allocate 697.08s - 701.32s | memory. Yes, some EDR can block it. There


chunk_id: 161_chunk_13
chunk_text:
9. And git proc address, we have 11. So, that gives us a lot of flexibilities because if you're 655.32s - 660.22s | trying to do something, you don't have a particular gadget while you just give up. If you do, 660.22s - 665.90s | then the chain is incomplete. But having multiple patterns, we can drill down deeper and 665.90s - 671.26s | maybe find something that actually works. In any case, our next API is create tool help 32 671.26s - 675.60s | snapshot, which will allow us to take a snapshot of all the active processes that are out 675.62s - 681.12s | there. And it's immensely important. We need it to discover, uh, the different PIDs. We're 681.12s - 687.10s | going to target one of those. So, there are actually 11 patterns. So, a lot of flexibility 687.10s - 692.30s | there in terms of how you can invoke it with the push add instruction. Um, there's an example 692.30s - 697.08s | of the ROP and we got the push add at the bottom. Virtual alloc, um, it's one way to allocate 697.08s - 701.32s | memory. Yes, some EDR can block it. There are other ways you could do it. Uh, the pattern for 701.34s - 705.78s | that is very, uh, familiar. Uh, one of, one of the most familiar goes back probably about 15 705.78s - 710.94s | years. Um, but with this, we're going to allocate a region of memory. We're going to use that 710.94s - 717.52s | for a couple very, uh, important, uh, things. One of which is to build the process entry 32. 717.52s - 723.22s | The process entry 32 is where we're going to go in and check our PID and we're going to check 723.22s - 729.15s | our, uh, string. So, the first thing is going to be process 32 first. It's going to kick 729.17s - 736.13s | everything off. It's going to initiate the whole, uh, process. So, how are we going to do 736.13s - 739.61s | that? Uh, first we actually need to build the structure. So, we can go ahead and build the 739.61s - 744.05s | structure via ROP and our move dereferences. Most of it are null bytes, so it's relatively 744.05s - 749.55s | simple. We have a DW size. Uh, it's an arbitrary


chunk_id: 161_chunk_14
chunk_text:
are other ways you could do it. Uh, the pattern for 701.34s - 705.78s | that is very, uh, familiar. Uh, one of, one of the most familiar goes back probably about 15 705.78s - 710.94s | years. Um, but with this, we're going to allocate a region of memory. We're going to use that 710.94s - 717.52s | for a couple very, uh, important, uh, things. One of which is to build the process entry 32. 717.52s - 723.22s | The process entry 32 is where we're going to go in and check our PID and we're going to check 723.22s - 729.15s | our, uh, string. So, the first thing is going to be process 32 first. It's going to kick 729.17s - 736.13s | everything off. It's going to initiate the whole, uh, process. So, how are we going to do 736.13s - 739.61s | that? Uh, first we actually need to build the structure. So, we can go ahead and build the 739.61s - 744.05s | structure via ROP and our move dereferences. Most of it are null bytes, so it's relatively 744.05s - 749.55s | simple. We have a DW size. Uh, it's an arbitrary value, so you can make it whatever you want. 749.55s - 754.25s | And then once we're done, we get a pointer to that. We supply that pointer as the parameter. 754.29s - 759.93s | So, all of that work and we just get a pointer to that. So, again, the idea of being able to, uh, 759.93s - 763.67s | dynamically locate something in memory and use that as kind of like a pointer can be very 763.67s - 769.37s | useful. And then the patterns for process 32 first and process 32 next are actually 769.37s - 774.75s | interchangeable. So, one of the biggest challenges is this idea of string comparison. How do 774.75s - 780.51s | we do that with ROP? Well, the gadgets are not really very common, so that can be very, uh, 780.55s - 786.19s | problematic. We need to identify a specific process, otherwise you really can't proceed 786.19s - 791.55s | forward. So, you're kind of at a, an, uh, you can't really go forward without this. So, we 791.55s - 795.39s | came up with a solution. We're going to build our own custom function in memory. It's an 795.39s


chunk_id: 161_chunk_15
chunk_text:
value, so you can make it whatever you want. 749.55s - 754.25s | And then once we're done, we get a pointer to that. We supply that pointer as the parameter. 754.29s - 759.93s | So, all of that work and we just get a pointer to that. So, again, the idea of being able to, uh, 759.93s - 763.67s | dynamically locate something in memory and use that as kind of like a pointer can be very 763.67s - 769.37s | useful. And then the patterns for process 32 first and process 32 next are actually 769.37s - 774.75s | interchangeable. So, one of the biggest challenges is this idea of string comparison. How do 774.75s - 780.51s | we do that with ROP? Well, the gadgets are not really very common, so that can be very, uh, 780.55s - 786.19s | problematic. We need to identify a specific process, otherwise you really can't proceed 786.19s - 791.55s | forward. So, you're kind of at a, an, uh, you can't really go forward without this. So, we 791.55s - 795.39s | came up with a solution. We're going to build our own custom function in memory. It's an 795.39s - 800.63s | enumerate process function. And we're actually writing the raw assembly. So, remember we 800.63s - 805.77s | made a writable memory with virtual alloc. We can write our code there. You can do it other 805.77s - 809.91s | ways as well. And so, this will cycle through process 32 next. It can do it hundreds of 809.91s - 816.79s | times. It'll loop until it finds the exact, uh, string, VU player. We can supply that and 816.79s - 820.89s | then once it does that, it'll go ahead and exit out. So, how do we write that? Well, we 820.89s - 825.79s | simply just compile it. We can then write our bytes to memory using the move dereference 825.79s - 830.23s | technique one by one until they're all written. Make sure the code is executable and there 830.23s - 833.67s | are multiple ways in which you can do that. And then we need to supply the appropriate 833.67s - 839.13s | values. So, things like our HP snapshot, our, our VU player string, uh, dereference 839.13s - 845.03s | process 32 address. And then how do we kick it off? Uh, again,


chunk_id: 161_chunk_16
chunk_text:
- 800.63s | enumerate process function. And we're actually writing the raw assembly. So, remember we 800.63s - 805.77s | made a writable memory with virtual alloc. We can write our code there. You can do it other 805.77s - 809.91s | ways as well. And so, this will cycle through process 32 next. It can do it hundreds of 809.91s - 816.79s | times. It'll loop until it finds the exact, uh, string, VU player. We can supply that and 816.79s - 820.89s | then once it does that, it'll go ahead and exit out. So, how do we write that? Well, we 820.89s - 825.79s | simply just compile it. We can then write our bytes to memory using the move dereference 825.79s - 830.23s | technique one by one until they're all written. Make sure the code is executable and there 830.23s - 833.67s | are multiple ways in which you can do that. And then we need to supply the appropriate 833.67s - 839.13s | values. So, things like our HP snapshot, our, our VU player string, uh, dereference 839.13s - 845.03s | process 32 address. And then how do we kick it off? Uh, again, multiple ways, but in this 845.03s - 848.37s | case, we're going to do a simple push ret, which will then push the address onto the stack 848.37s - 853.71s | and then return to that. And then we can, uh, immediately start executing our custom code 853.71s - 860.25s | that we just wrote there. And so, that'll invoke process 32, uh, repeatedly until it finds 860.25s - 867.13s | our particular PID. In this case, we have VU player. It's going to look at offset 24 and 867.13s - 872.13s | once it finds offset 24, then again, it's going to break out of that loop. And, um, from 872.13s - 877.03s | there, the base of the structure, we can just go to simply offset 8. Offset 8 will then hold 877.03s - 882.05s | the PID. We can capture that PID. In this case, it's 668. And how do we do that via return 884.45s - 888.89s | oriented programming? Well, we just basically take exactly what I said, translate it to ROP. 888.89s - 895.29s | So, some move dereferences, some POPs, uh, sequence of 8, uh, increments. And, uh, in this 895.29s - 901.39s


chunk_id: 161_chunk_17
chunk_text:
multiple ways, but in this 845.03s - 848.37s | case, we're going to do a simple push ret, which will then push the address onto the stack 848.37s - 853.71s | and then return to that. And then we can, uh, immediately start executing our custom code 853.71s - 860.25s | that we just wrote there. And so, that'll invoke process 32, uh, repeatedly until it finds 860.25s - 867.13s | our particular PID. In this case, we have VU player. It's going to look at offset 24 and 867.13s - 872.13s | once it finds offset 24, then again, it's going to break out of that loop. And, um, from 872.13s - 877.03s | there, the base of the structure, we can just go to simply offset 8. Offset 8 will then hold 877.03s - 882.05s | the PID. We can capture that PID. In this case, it's 668. And how do we do that via return 884.45s - 888.89s | oriented programming? Well, we just basically take exactly what I said, translate it to ROP. 888.89s - 895.29s | So, some move dereferences, some POPs, uh, sequence of 8, uh, increments. And, uh, in this 895.29s - 901.39s | case, we have a different PID, B98. And, uh, we can supply that. Uh, we can save that to 901.39s - 907.37s | memory so we can use that later. Remember the idea of save and then retrieve. And then that 907.37s - 916.49s | brings us to our next API. And with that, we're going to have Shiva, uh, take the podium. 916.49s - 921.43s | Here we take this PID that we just obtained after all of that hard work and, uh, we are going 921.43s - 926.43s | to convert that into the handle to the process. We got to have this. It's impossible to move 926.43s - 931.89s | forward if you don't have a PID to your target process. And we don't want to just randomly 931.89s - 936.77s | inject into some other unknown process. Uh, so this one we are going to use both push add as 936.77s - 941.77s | well as move dereference technique. So, here we have multiple patterns for open process. And 943.43s - 948.61s | then we'll follow that up after push add. And we also have a move dereference with the 948.61s - 953.61s | process


chunk_id: 161_chunk_18
chunk_text:
| case, we have a different PID, B98. And, uh, we can supply that. Uh, we can save that to 901.39s - 907.37s | memory so we can use that later. Remember the idea of save and then retrieve. And then that 907.37s - 916.49s | brings us to our next API. And with that, we're going to have Shiva, uh, take the podium. 916.49s - 921.43s | Here we take this PID that we just obtained after all of that hard work and, uh, we are going 921.43s - 926.43s | to convert that into the handle to the process. We got to have this. It's impossible to move 926.43s - 931.89s | forward if you don't have a PID to your target process. And we don't want to just randomly 931.89s - 936.77s | inject into some other unknown process. Uh, so this one we are going to use both push add as 936.77s - 941.77s | well as move dereference technique. So, here we have multiple patterns for open process. And 943.43s - 948.61s | then we'll follow that up after push add. And we also have a move dereference with the 948.61s - 953.61s | process ID. In this ROP chain, the process ID has been provided by move dereference, uh, with 954.43s - 959.43s | everything else being done via push add. Next, we'll open a handle to our current process with 962.61s - 968.75s | open process token. And then we'll use that. So, right here we have a handle and we are using 968.75s - 976.12s | ROP to create a pointer to hold the access token that we'll retrieve. With adjust token 976.12s - 981.06s | privileges, uh, we are going to take that token handle and we can then change the privileges as 981.08s - 987.78s | we need. We need to do this to avoid some problems that could happen otherwise. And this 987.78s - 993.40s | requires multiple complex structures such as token privileges, such as, uh, where we can 993.40s - 1001.20s | specify the AC privilege and AC debug privilege. With adjust token privileges, uh, here we 1001.20s - 1006.74s | have a ROP. So, we are setting disable all privileges to false. And what that means is that 1006.74s - 1013.32s | whatever we specify inside the new state structure will be then done. With adjust


chunk_id: 161_chunk_19
chunk_text:
ID. In this ROP chain, the process ID has been provided by move dereference, uh, with 954.43s - 959.43s | everything else being done via push add. Next, we'll open a handle to our current process with 962.61s - 968.75s | open process token. And then we'll use that. So, right here we have a handle and we are using 968.75s - 976.12s | ROP to create a pointer to hold the access token that we'll retrieve. With adjust token 976.12s - 981.06s | privileges, uh, we are going to take that token handle and we can then change the privileges as 981.08s - 987.78s | we need. We need to do this to avoid some problems that could happen otherwise. And this 987.78s - 993.40s | requires multiple complex structures such as token privileges, such as, uh, where we can 993.40s - 1001.20s | specify the AC privilege and AC debug privilege. With adjust token privileges, uh, here we 1001.20s - 1006.74s | have a ROP. So, we are setting disable all privileges to false. And what that means is that 1006.74s - 1013.32s | whatever we specify inside the new state structure will be then done. With adjust token 1013.36s - 1019.30s | privileges, we can then go inspect via the debugger and see if it has all of our values. Like 1019.30s - 1024.64s | AC privilege enabled and AC debug privilege. And then everything is going according to the 1024.64s - 1029.64s | plan. Our goal with this is to take a common DLL URL mon, create a file for it, and then go 1032.14s - 1037.32s | ahead and map that out. And then we can inject our payload into that, then causing that to be 1037.32s - 1042.32s | executed. And we'll do this with these APIs which we'll be talking about. So, create file A is 1044.52s - 1049.86s | the first. We get a handle to the URL mon, which is our file. We are going to be using this 1049.86s - 1056.54s | later on, uh, but we are going to do this with sequence of moody references. And here we are 1056.54s - 1061.78s | providing the absolute address, the string pointer to that, and also generic read. We are 1061.78s - 1066.78s | doing generic read to avoid some possible detections. And then NT create section, a lower 1069.28s


chunk_id: 161_chunk_20
chunk_text:
token 1013.36s - 1019.30s | privileges, we can then go inspect via the debugger and see if it has all of our values. Like 1019.30s - 1024.64s | AC privilege enabled and AC debug privilege. And then everything is going according to the 1024.64s - 1029.64s | plan. Our goal with this is to take a common DLL URL mon, create a file for it, and then go 1032.14s - 1037.32s | ahead and map that out. And then we can inject our payload into that, then causing that to be 1037.32s - 1042.32s | executed. And we'll do this with these APIs which we'll be talking about. So, create file A is 1044.52s - 1049.86s | the first. We get a handle to the URL mon, which is our file. We are going to be using this 1049.86s - 1056.54s | later on, uh, but we are going to do this with sequence of moody references. And here we are 1056.54s - 1061.78s | providing the absolute address, the string pointer to that, and also generic read. We are 1061.78s - 1066.78s | doing generic read to avoid some possible detections. And then NT create section, a lower 1069.28s - 1074.28s | level native API will allow us to then create a section object for URL mon DLL, and here we are 1075.92s - 1080.92s | doing page read only. And then with drop we are specifying the sec image. NT map your 1083.80s - 1089.64s | section. Now that we have the URL mon section handle, we can now map that view of the 1089.66s - 1095.10s | section into address space of VU player. We'll do this purely through moody references, 1095.10s - 1102.00s | because, uh, we have many nulls and also we have page read only, so it's a bit more limited. 1102.00s - 1106.78s | One more important thing is providing the base address or pointer to the base address, and 1106.78s - 1113.28s | that will receive a base address inside of VU player. So that will be provided to us, as you 1113.28s - 1120.77s | can see in this example, which we'll be talking about later, so it is very important. 1120.79s - 1125.79s | Virtual protect EX will then allow us to change the target DLL URL mon to RWX, and so we are 1127.97s - 1132.53s | going to


chunk_id: 161_chunk_21
chunk_text:
- 1074.28s | level native API will allow us to then create a section object for URL mon DLL, and here we are 1075.92s - 1080.92s | doing page read only. And then with drop we are specifying the sec image. NT map your 1083.80s - 1089.64s | section. Now that we have the URL mon section handle, we can now map that view of the 1089.66s - 1095.10s | section into address space of VU player. We'll do this purely through moody references, 1095.10s - 1102.00s | because, uh, we have many nulls and also we have page read only, so it's a bit more limited. 1102.00s - 1106.78s | One more important thing is providing the base address or pointer to the base address, and 1106.78s - 1113.28s | that will receive a base address inside of VU player. So that will be provided to us, as you 1113.28s - 1120.77s | can see in this example, which we'll be talking about later, so it is very important. 1120.79s - 1125.79s | Virtual protect EX will then allow us to change the target DLL URL mon to RWX, and so we are 1127.97s - 1132.53s | going to do this with sequence of moody references, because remember we have limited 1132.53s - 1138.47s | permissions for it. And so we'll get the handle to the VU player as well as the base address 1138.47s - 1145.42s | that we just retrieved, and then once it's done, we'll have the page execute read write. Here 1145.42s - 1149.66s | is a route where we can provide the pointer to the base address. We then go and dereference 1149.74s - 1155.64s | that and we'll pull the base address out of that, and then we do the moody reference. Write 1155.64s - 1161.42s | process memory allows us to inject the shellcode into the process memory of VU player. We are 1161.42s - 1166.82s | doing this via push add as well as moody references, which you can see right here, so 1166.82s - 1173.56s | pointing to the shellcode up there, and also providing the size. Same thing here, we are, we 1173.56s - 1178.56s | have the shellcode and the size and then the remaining parameters with push add. Write 1178.56s - 1183.40s | process memory at this point, once this is done, then our shellcode will be


chunk_id: 161_chunk_22
chunk_text:
do this with sequence of moody references, because remember we have limited 1132.53s - 1138.47s | permissions for it. And so we'll get the handle to the VU player as well as the base address 1138.47s - 1145.42s | that we just retrieved, and then once it's done, we'll have the page execute read write. Here 1145.42s - 1149.66s | is a route where we can provide the pointer to the base address. We then go and dereference 1149.74s - 1155.64s | that and we'll pull the base address out of that, and then we do the moody reference. Write 1155.64s - 1161.42s | process memory allows us to inject the shellcode into the process memory of VU player. We are 1161.42s - 1166.82s | doing this via push add as well as moody references, which you can see right here, so 1166.82s - 1173.56s | pointing to the shellcode up there, and also providing the size. Same thing here, we are, we 1173.56s - 1178.56s | have the shellcode and the size and then the remaining parameters with push add. Write 1178.56s - 1183.40s | process memory at this point, once this is done, then our shellcode will be injected into 1183.40s - 1188.60s | inside of URL mon, which is an external process. So we have gone from one process to a 1188.60s - 1194.88s | completely different process, and the shellcode is just sitting there waiting for us. So how 1194.88s - 1199.02s | do we cause it to execute? The answer is very simple, it's create remote thread, but the 1199.02s - 1203.76s | actual technique is not so simple. So we'll have a moody reference and also push add 1203.76s - 1209.86s | pattern, and then we'll have a sequence of moody references. We'll go inside the other 1209.86s - 1218.04s | space of VU player, and then we do the push add. So here is some of our ROP, we can 1218.04s - 1222.64s | provide the LP parameter as well as the address, and then we follow that up after push 1222.64s - 1228.48s | add, and finally with create remote thread, our injected shellcode will execute. We have 1228.48s - 1236.52s | achieved our goal. Let's do a demo. We start the things with create help 32 snapshot and 1236.52s - 1241.78s | we have been given a handle. Let's write the


chunk_id: 161_chunk_23
chunk_text:
injected into 1183.40s - 1188.60s | inside of URL mon, which is an external process. So we have gone from one process to a 1188.60s - 1194.88s | completely different process, and the shellcode is just sitting there waiting for us. So how 1194.88s - 1199.02s | do we cause it to execute? The answer is very simple, it's create remote thread, but the 1199.02s - 1203.76s | actual technique is not so simple. So we'll have a moody reference and also push add 1203.76s - 1209.86s | pattern, and then we'll have a sequence of moody references. We'll go inside the other 1209.86s - 1218.04s | space of VU player, and then we do the push add. So here is some of our ROP, we can 1218.04s - 1222.64s | provide the LP parameter as well as the address, and then we follow that up after push 1222.64s - 1228.48s | add, and finally with create remote thread, our injected shellcode will execute. We have 1228.48s - 1236.52s | achieved our goal. Let's do a demo. We start the things with create help 32 snapshot and 1236.52s - 1241.78s | we have been given a handle. Let's write the enum process function to memory byte by 1241.78s - 1248.42s | byte. We invoke the function using push thread. Now we are inside the function, special 1248.42s - 1254.56s | function that we created, and let's take the process entry. Let's see what we have as the 1254.56s - 1261.58s | first entry. We have system. Let's move forward until we find our desired PID, and we 1261.64s - 1268.34s | finally found the PID for VU player. That's good. We'll keep moving forward, and we'll do 1268.34s - 1274.78s | the create file A. We'll get a handle from create file A. Let's verify what we have. We 1274.78s - 1279.62s | have the URL mount, that's good. Let's map that out using empty map section, and let's 1279.62s - 1283.52s | check the base address. Right now we don't have any base address, but right after the 1283.52s - 1291.65s | function execution, we'll get the base address, and base address has been provided. We'll 1291.67s - 1297.11s | change the permissions for the base address, and we'll see, we have, we have the base 1297.11s - 1304.99s | execute read write permissions. We have the MZ, it's


chunk_id: 161_chunk_24
chunk_text:
enum process function to memory byte by 1241.78s - 1248.42s | byte. We invoke the function using push thread. Now we are inside the function, special 1248.42s - 1254.56s | function that we created, and let's take the process entry. Let's see what we have as the 1254.56s - 1261.58s | first entry. We have system. Let's move forward until we find our desired PID, and we 1261.64s - 1268.34s | finally found the PID for VU player. That's good. We'll keep moving forward, and we'll do 1268.34s - 1274.78s | the create file A. We'll get a handle from create file A. Let's verify what we have. We 1274.78s - 1279.62s | have the URL mount, that's good. Let's map that out using empty map section, and let's 1279.62s - 1283.52s | check the base address. Right now we don't have any base address, but right after the 1283.52s - 1291.65s | function execution, we'll get the base address, and base address has been provided. We'll 1291.67s - 1297.11s | change the permissions for the base address, and we'll see, we have, we have the base 1297.11s - 1304.99s | execute read write permissions. We have the MZ, it's a PE file, and let's inject the shellcode 1304.99s - 1311.89s | using write process memory. And let's see what we have. We have successfully injected the 1311.89s - 1316.89s | shellcode into external process. And finally, create remote thread. We got it. 1325.73s - 1332.80s | Thank you Shiva. So we're going to wrap things up very briefly here. So, I just want to say, 1333.02s - 1337.48s | our, you know, our goal is not to enumerate all process injection techniques. We've seen 1337.48s - 1341.86s | talks like that before, but we really want to provide a methodology in terms of how we can do 1341.86s - 1346.16s | that with ROP, and focus on the practicalities. We want to provide a novel concept of 1346.16s - 1352.20s | building a enumerate processes function purely via ROP, which can be extendable to other 1352.20s - 1356.68s | process injection techniques, and then create a rich set of patterns that we can utilize 1356.68s - 1360.98s | for that purpose. With that, we'd like to thank you, and invite you to check out the ROP 1360.98s - 1361.58s | Rocket tool.


chunk_id: 161_chunk_25
chunk_text:
a PE file, and let's inject the shellcode 1304.99s - 1311.89s | using write process memory. And let's see what we have. We have successfully injected the 1311.89s - 1316.89s | shellcode into external process. And finally, create remote thread. We got it. 1325.73s - 1332.80s | Thank you Shiva. So we're going to wrap things up very briefly here. So, I just want to say, 1333.02s - 1337.48s | our, you know, our goal is not to enumerate all process injection techniques. We've seen 1337.48s - 1341.86s | talks like that before, but we really want to provide a methodology in terms of how we can do 1341.86s - 1346.16s | that with ROP, and focus on the practicalities. We want to provide a novel concept of 1346.16s - 1352.20s | building a enumerate processes function purely via ROP, which can be extendable to other 1352.20s - 1356.68s | process injection techniques, and then create a rich set of patterns that we can utilize 1356.68s - 1360.98s | for that purpose. With that, we'd like to thank you, and invite you to check out the ROP 1360.98s - 1361.58s | Rocket tool.


chunk_id: 162_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=-KXgcWuv-Ug", "title": "DEF CON 32 - Secrets & Shadows: Leveraging Big Data for Vulnerability Discovery - Bill Demirkapi", "description": "When we consider the conventional approaches to vulnerability discovery, be it in software or websites, we tend to confine ourselves to a specific target or platform. In the case of software, we might reverse engineer an application's attack surfaces for untrusted input, aiming to trigger edge cases. For websites, we might enumerate a domain for related assets and seek out unpatched, less defended, or occasionally abandoned resources.\n\nThis presentation explores the untapped potential of scaling security research by leveraging unconventional data sources. We'll walk through design flaws that enable two examples: forgotten cloud assets and leaked secrets. Instead of starting with a target and finding vulnerabilities, we'll find vulnerabilities and relate them to our targets. We won't just stop at discovery. We'll also discuss the incentives that create them and how to solve the ecosystem issues as an industry.\n\nWhile you can't easily scale every issue, this project has led to tens of thousands of highly significant yet seemingly trivial weaknesses in some of the world's largest organizations. Prepare to shift your perspective on vulnerability discovery, learn scalable approaches to address commonly overlooked bugs, and understand how even the simplest misconfiguration can have a devastating impact.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2544, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 6.46s | This text was transcribed using whisper model: large-v2 You're killing me, dude. 6.46s - 7.30s | All right, everyone. 7.30s - 9.86s | Thank you so much for coming out to this talk. 9.86s - 11.54s | It's called Secrets and Shadows, 11.54s - 15.36s | Leveraging Big Data for Vulnerability Discovery at Scale. 15.36s - 17.52s | I'm so excited to be here for another year 17.52s - 19.02s | at another DEF CON, 19.02s - 22.38s | and I really do have something in store for you today. 22.38s - 26.91s | Let's get right into it. 26.91s - 29.21s | So just a disclaimer, 29.21s - 30.83s | everything we're gonna talk about today 30.83s - 33.59s | was done completely independent of my employer, 33.59s - 38.27s | outside of work, with my own money, my own resources. 38.27s - 39.97s | If you wanna talk about this work 39.97s - 41.87s | outside of this presentation, 41.87s - 42.83s | just please refer to me


chunk_id: 162_chunk_1
chunk_text:
commonly overlooked bugs, and understand how even the simplest misconfiguration can have a devastating impact.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2544, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 6.46s | This text was transcribed using whisper model: large-v2 You're killing me, dude. 6.46s - 7.30s | All right, everyone. 7.30s - 9.86s | Thank you so much for coming out to this talk. 9.86s - 11.54s | It's called Secrets and Shadows, 11.54s - 15.36s | Leveraging Big Data for Vulnerability Discovery at Scale. 15.36s - 17.52s | I'm so excited to be here for another year 17.52s - 19.02s | at another DEF CON, 19.02s - 22.38s | and I really do have something in store for you today. 22.38s - 26.91s | Let's get right into it. 26.91s - 29.21s | So just a disclaimer, 29.21s - 30.83s | everything we're gonna talk about today 30.83s - 33.59s | was done completely independent of my employer, 33.59s - 38.27s | outside of work, with my own money, my own resources. 38.27s - 39.97s | If you wanna talk about this work 39.97s - 41.87s | outside of this presentation, 41.87s - 42.83s | just please refer to me 42.83s - 44.91s | as an independent security researcher. 44.91s - 51.44s | It helps me be able to do work just like this. 51.44s - 53.70s | So my name is Bill Demerkappa, 53.70s - 57.60s | and I am a security researcher with a diverse background 57.60s - 61.36s | in low-level software security and also cloud security. 62.38s - 63.82s | Could we boost the mic a bit? 64.82s - 67.94s | I'm interested in defense and offense. 67.94s - 70.82s | I love solving hard security problems, 70.82s - 74.54s | and while I did start with a software security background, 74.54s - 76.26s | I feel like the impact we can have 76.26s - 79.48s | with cloud security is much wider. 79.48s - 80.74s | For example, you could have 80.74s - 83.50s | the most complex software vulnerability in the world, 83.50s - 84.96s | but at the end of the day, 84.96s - 89.40s | a simple ID check or missing ID check in a cloud environment 89.40s - 92.10s | can lead to a much broader impact. 92.14s - 94.74s | And that's what really got me interested in the cloud.


chunk_id: 162_chunk_2
chunk_text:
42.83s - 44.91s | as an independent security researcher. 44.91s - 51.44s | It helps me be able to do work just like this. 51.44s - 53.70s | So my name is Bill Demerkappa, 53.70s - 57.60s | and I am a security researcher with a diverse background 57.60s - 61.36s | in low-level software security and also cloud security. 62.38s - 63.82s | Could we boost the mic a bit? 64.82s - 67.94s | I'm interested in defense and offense. 67.94s - 70.82s | I love solving hard security problems, 70.82s - 74.54s | and while I did start with a software security background, 74.54s - 76.26s | I feel like the impact we can have 76.26s - 79.48s | with cloud security is much wider. 79.48s - 80.74s | For example, you could have 80.74s - 83.50s | the most complex software vulnerability in the world, 83.50s - 84.96s | but at the end of the day, 84.96s - 89.40s | a simple ID check or missing ID check in a cloud environment 89.40s - 92.10s | can lead to a much broader impact. 92.14s - 94.74s | And that's what really got me interested in the cloud. 94.74s - 97.22s | It's the ability to have an impact 97.22s - 100.18s | without the same technical complexity 100.18s - 105.79s | that comes with exploiting low-level vulnerabilities. 105.79s - 106.91s | So in this talk, 106.91s - 111.47s | we're gonna discuss vulnerability discovery at scale. 111.47s - 113.87s | And what I mean by that is we're gonna take a look 113.87s - 117.19s | at how we traditionally approach vulnerability discovery 117.19s - 119.51s | with two common bug classes, 119.51s - 123.55s | dangling cloud resources and leaked secrets. 123.55s - 125.79s | The goal is to identify the limitations 125.79s - 128.03s | of our historical approach 128.03s - 135.42s | and shift our perspective through some practical examples. 135.42s - 138.86s | So some background. 138.86s - 140.10s | Now, from a high level, 140.10s - 142.46s | everyone knows what cloud computing is. 142.46s - 145.94s | It's basically a way where you can create infrastructure 145.94s - 148.06s | like servers, websites, and more 148.06s - 150.38s | without needing to actually purchase 150.38s - 152.18s | your own physical server rack. 153.42s - 156.38s | The cool part is


chunk_id: 162_chunk_3
chunk_text:
94.74s - 97.22s | It's the ability to have an impact 97.22s - 100.18s | without the same technical complexity 100.18s - 105.79s | that comes with exploiting low-level vulnerabilities. 105.79s - 106.91s | So in this talk, 106.91s - 111.47s | we're gonna discuss vulnerability discovery at scale. 111.47s - 113.87s | And what I mean by that is we're gonna take a look 113.87s - 117.19s | at how we traditionally approach vulnerability discovery 117.19s - 119.51s | with two common bug classes, 119.51s - 123.55s | dangling cloud resources and leaked secrets. 123.55s - 125.79s | The goal is to identify the limitations 125.79s - 128.03s | of our historical approach 128.03s - 135.42s | and shift our perspective through some practical examples. 135.42s - 138.86s | So some background. 138.86s - 140.10s | Now, from a high level, 140.10s - 142.46s | everyone knows what cloud computing is. 142.46s - 145.94s | It's basically a way where you can create infrastructure 145.94s - 148.06s | like servers, websites, and more 148.06s - 150.38s | without needing to actually purchase 150.38s - 152.18s | your own physical server rack. 153.42s - 156.38s | The cool part is this can save you a lot of money. 156.38s - 158.10s | If you're just creating your own blog, 158.62s - 161.50s | you really don't need that many resources at all. 161.50s - 163.58s | Why not borrow someone else's? 163.58s - 165.66s | And that's really the fundamental principle 165.66s - 167.62s | of cloud computing. 167.62s - 170.62s | All you're doing is borrowing from someone else's pool 170.62s - 177.19s | of shared resources. 177.19s - 179.95s | So cloud environments are managed over the internet, 179.95s - 183.15s | but how do we actually secure this access? 183.15s - 185.55s | Well, for AWS, the way it works 185.55s - 188.83s | is that you can use something called an access key. 188.83s - 192.59s | An access key can be short-lived or long-term token 192.59s - 194.95s | that specifies credentials for your account 194.95s - 198.03s | and allows you to manage your AWS resources 198.03s - 200.79s | depending on the role and permissions assigned to you. 202.39s - 204.95s | Can we please increase the microphone sound? 205.95s - 209.03s | And for other platforms, it's similar. 209.03s - 211.11s |


chunk_id: 162_chunk_4
chunk_text:
this can save you a lot of money. 156.38s - 158.10s | If you're just creating your own blog, 158.62s - 161.50s | you really don't need that many resources at all. 161.50s - 163.58s | Why not borrow someone else's? 163.58s - 165.66s | And that's really the fundamental principle 165.66s - 167.62s | of cloud computing. 167.62s - 170.62s | All you're doing is borrowing from someone else's pool 170.62s - 177.19s | of shared resources. 177.19s - 179.95s | So cloud environments are managed over the internet, 179.95s - 183.15s | but how do we actually secure this access? 183.15s - 185.55s | Well, for AWS, the way it works 185.55s - 188.83s | is that you can use something called an access key. 188.83s - 192.59s | An access key can be short-lived or long-term token 192.59s - 194.95s | that specifies credentials for your account 194.95s - 198.03s | and allows you to manage your AWS resources 198.03s - 200.79s | depending on the role and permissions assigned to you. 202.39s - 204.95s | Can we please increase the microphone sound? 205.95s - 209.03s | And for other platforms, it's similar. 209.03s - 211.11s | For example, for Google Cloud, 211.11s - 214.67s | the types of authentication include service accounts, 214.67s - 216.79s | you can use CLI credentials, 216.79s - 220.83s | and in general, tokens are how we're able to operate 220.83s - 222.83s | with these cloud environments. 223.79s - 229.68s | Unfortunately, tokens also present a pretty severe risk. 229.68s - 232.00s | So cloud provider tokens are dangerous 232.00s - 236.04s | because by default, there's little restriction 236.04s - 238.56s | on who can use those tokens. 238.56s - 240.44s | For example, by default, 240.44s - 243.52s | if you create a root access key in AWS, 243.52s - 246.44s | anyone from any IP can use that access key 246.44s - 249.04s | to manage your cloud environment. 249.04s - 252.32s | Now, obviously, the impact of a leaked cloud credential 252.32s - 254.84s | will really depend on the context. 254.84s - 256.52s | For example, a lot of websites 256.52s - 259.28s | hard-code a Google Maps API key, 259.28s - 261.28s | and in reality, despite the fact 261.28s - 264.80s | that it can lead to billing overcharges and abuse, 264.80s -


chunk_id: 162_chunk_5
chunk_text:
For example, for Google Cloud, 211.11s - 214.67s | the types of authentication include service accounts, 214.67s - 216.79s | you can use CLI credentials, 216.79s - 220.83s | and in general, tokens are how we're able to operate 220.83s - 222.83s | with these cloud environments. 223.79s - 229.68s | Unfortunately, tokens also present a pretty severe risk. 229.68s - 232.00s | So cloud provider tokens are dangerous 232.00s - 236.04s | because by default, there's little restriction 236.04s - 238.56s | on who can use those tokens. 238.56s - 240.44s | For example, by default, 240.44s - 243.52s | if you create a root access key in AWS, 243.52s - 246.44s | anyone from any IP can use that access key 246.44s - 249.04s | to manage your cloud environment. 249.04s - 252.32s | Now, obviously, the impact of a leaked cloud credential 252.32s - 254.84s | will really depend on the context. 254.84s - 256.52s | For example, a lot of websites 256.52s - 259.28s | hard-code a Google Maps API key, 259.28s - 261.28s | and in reality, despite the fact 261.28s - 264.80s | that it can lead to billing overcharges and abuse, 264.80s - 266.72s | the impact is still fairly limited. 267.64s - 269.88s | But with a root AWS key, 269.88s - 273.08s | the dangers are much more problematic. 273.08s - 276.72s | For example, if you stored your database in AWS 276.72s - 279.56s | or you store your computing in AWS, 279.56s - 281.84s | an attacker could use your credentials 281.84s - 284.72s | to not only access customer data, 284.72s - 289.81s | but to interfere with your production workflows. 289.81s - 292.29s | Now, when we talk about how everything in the cloud 292.29s - 294.01s | is shared and borrowed, 294.01s - 297.81s | what I mean by that is by nature, by its nature, 297.81s - 302.21s | the cloud model introduces risk from this sharing model. 302.21s - 304.97s | So, for example, when you create a virtual machine, 304.97s - 307.61s | what's really happening is you're borrowing time 307.61s - 311.29s | on a physical server that your cloud provider has bought. 311.29s - 313.61s | And on this physical resource, 313.61s - 317.17s | you get assigned a network IP, for example. 317.17s - 318.61s | And the reason this


chunk_id: 162_chunk_6
chunk_text:
266.72s | the impact is still fairly limited. 267.64s - 269.88s | But with a root AWS key, 269.88s - 273.08s | the dangers are much more problematic. 273.08s - 276.72s | For example, if you stored your database in AWS 276.72s - 279.56s | or you store your computing in AWS, 279.56s - 281.84s | an attacker could use your credentials 281.84s - 284.72s | to not only access customer data, 284.72s - 289.81s | but to interfere with your production workflows. 289.81s - 292.29s | Now, when we talk about how everything in the cloud 292.29s - 294.01s | is shared and borrowed, 294.01s - 297.81s | what I mean by that is by nature, by its nature, 297.81s - 302.21s | the cloud model introduces risk from this sharing model. 302.21s - 304.97s | So, for example, when you create a virtual machine, 304.97s - 307.61s | what's really happening is you're borrowing time 307.61s - 311.29s | on a physical server that your cloud provider has bought. 311.29s - 313.61s | And on this physical resource, 313.61s - 317.17s | you get assigned a network IP, for example. 317.17s - 318.61s | And the reason this is dangerous 318.61s - 321.65s | is because once you're done with a resource, 321.65s - 324.17s | if you still have dangling DNS records 324.17s - 325.85s | pointing at that resource, 325.85s - 328.73s | suddenly that exposes an opportunity 328.73s - 331.57s | for an attacker to take advantage of. 331.57s - 332.97s | So, from a high level, 332.97s - 335.73s | I view cloud resources in two categories, 335.73s - 338.73s | primitive resources and shared resources. 338.73s - 341.45s | So, a primitive resource is something like a virtual machine 341.45s - 344.65s | where you get assigned a dedicated IP address. 344.65s - 348.65s | That IP address is not used by any other customer but you. 348.65s - 350.45s | Whereas with a shared resource, 350.45s - 353.45s | what's really going on is it's a serverless application 353.45s - 355.85s | that serves multiple customers. 355.85s - 358.73s | For example, if you have a serverless function 358.73s - 360.85s | that you can call on your cloud provider, 360.85s - 364.37s | that URL you used to connect to that serverless function 364.37s - 366.17s | probably corresponds to an


chunk_id: 162_chunk_7
chunk_text:
is dangerous 318.61s - 321.65s | is because once you're done with a resource, 321.65s - 324.17s | if you still have dangling DNS records 324.17s - 325.85s | pointing at that resource, 325.85s - 328.73s | suddenly that exposes an opportunity 328.73s - 331.57s | for an attacker to take advantage of. 331.57s - 332.97s | So, from a high level, 332.97s - 335.73s | I view cloud resources in two categories, 335.73s - 338.73s | primitive resources and shared resources. 338.73s - 341.45s | So, a primitive resource is something like a virtual machine 341.45s - 344.65s | where you get assigned a dedicated IP address. 344.65s - 348.65s | That IP address is not used by any other customer but you. 348.65s - 350.45s | Whereas with a shared resource, 350.45s - 353.45s | what's really going on is it's a serverless application 353.45s - 355.85s | that serves multiple customers. 355.85s - 358.73s | For example, if you have a serverless function 358.73s - 360.85s | that you can call on your cloud provider, 360.85s - 364.37s | that URL you used to connect to that serverless function 364.37s - 366.17s | probably corresponds to an IP 366.17s - 368.65s | that serves a lot of other customers. 368.65s - 370.69s | The reason this distinction is important 370.69s - 374.33s | is because it impacts what type of dangling DNS records 374.33s - 375.89s | you need to worry about. 375.89s - 377.21s | So, for primitive resources 377.21s - 380.21s | where you have that unique IP address, 380.21s - 382.69s | that includes pretty much every type of DNS record 382.69s - 384.93s | that could be dangling, like an A record, 384.93s - 387.93s | a C name record, a name server, and et cetera. 387.93s - 390.05s | But whereas if it's a shared resource 390.05s - 392.85s | where the endpoint is shared across customers, 392.85s - 395.81s | that's gonna be limited to C names, name server, 395.81s - 397.97s | MX, those types of records. 397.97s - 399.69s | And the distinction there is that 399.69s - 401.65s | when the endpoint is shared, 401.65s - 404.29s | suddenly you don't have to worry about the A record 404.29s - 407.49s | pointing at a IP address you no longer control. 408.65s - 411.77s | So, what can


chunk_id: 162_chunk_8
chunk_text:
IP 366.17s - 368.65s | that serves a lot of other customers. 368.65s - 370.69s | The reason this distinction is important 370.69s - 374.33s | is because it impacts what type of dangling DNS records 374.33s - 375.89s | you need to worry about. 375.89s - 377.21s | So, for primitive resources 377.21s - 380.21s | where you have that unique IP address, 380.21s - 382.69s | that includes pretty much every type of DNS record 382.69s - 384.93s | that could be dangling, like an A record, 384.93s - 387.93s | a C name record, a name server, and et cetera. 387.93s - 390.05s | But whereas if it's a shared resource 390.05s - 392.85s | where the endpoint is shared across customers, 392.85s - 395.81s | that's gonna be limited to C names, name server, 395.81s - 397.97s | MX, those types of records. 397.97s - 399.69s | And the distinction there is that 399.69s - 401.65s | when the endpoint is shared, 401.65s - 404.29s | suddenly you don't have to worry about the A record 404.29s - 407.49s | pointing at a IP address you no longer control. 408.65s - 411.77s | So, what can an attacker do with that domain control? 411.77s - 413.89s | Well, from a high level, it can enable phishing, 413.89s - 416.41s | malware distribution, scams, et cetera. 416.41s - 418.89s | It can lead to cross-site scripting. 418.89s - 421.57s | And there's going to be context-specific impact, 421.57s - 424.53s | like you can bypass the trusted host names check 424.53s - 426.45s | in a software update installer. 426.45s - 428.33s | That's something I've seen pretty common. 428.33s - 432.17s | You can abuse the brand trust and reputation 432.17s - 434.73s | in order to spread misinformation. 434.73s - 437.89s | Now, I included a quote below from APNIC 437.89s - 441.65s | on an article talking about this potential abuse. 441.65s - 444.37s | So, from a high level, they found that 444.37s - 446.93s | when it came to dangling DNS record abuse, 447.89s - 451.73s | in general, 75% of the hijacked dangling resources 451.73s - 456.53s | were being used for black hat search engine optimization 456.53s - 458.29s | and really promoting bad websites 458.29s - 463.88s | you don't want anyone going to. 463.88s - 467.40s | So,


chunk_id: 162_chunk_9
chunk_text:
an attacker do with that domain control? 411.77s - 413.89s | Well, from a high level, it can enable phishing, 413.89s - 416.41s | malware distribution, scams, et cetera. 416.41s - 418.89s | It can lead to cross-site scripting. 418.89s - 421.57s | And there's going to be context-specific impact, 421.57s - 424.53s | like you can bypass the trusted host names check 424.53s - 426.45s | in a software update installer. 426.45s - 428.33s | That's something I've seen pretty common. 428.33s - 432.17s | You can abuse the brand trust and reputation 432.17s - 434.73s | in order to spread misinformation. 434.73s - 437.89s | Now, I included a quote below from APNIC 437.89s - 441.65s | on an article talking about this potential abuse. 441.65s - 444.37s | So, from a high level, they found that 444.37s - 446.93s | when it came to dangling DNS record abuse, 447.89s - 451.73s | in general, 75% of the hijacked dangling resources 451.73s - 456.53s | were being used for black hat search engine optimization 456.53s - 458.29s | and really promoting bad websites 458.29s - 463.88s | you don't want anyone going to. 463.88s - 467.40s | So, to be clear, past approaches 467.40s - 470.80s | for these types of bugs already exist. 470.80s - 473.52s | Where with dangling cloud resources, 473.52s - 476.40s | we've seen that attackers can go ahead 476.40s - 478.48s | and enumerate cloud IP pools 478.48s - 481.00s | and capture these resources that are dangling. 481.00s - 484.00s | But with leaked secrets, what we've seen is 484.00s - 487.80s | that a lot of work really relies on a limited scope. 487.80s - 490.12s | So, what I mean by that is, 490.12s - 492.76s | everything that happens with leaked secrets 492.76s - 495.08s | is always about a specific target, 495.08s - 498.56s | like a specific folder, a specific repository, 498.56s - 500.12s | or a specific directory. 501.20s - 503.52s | And the problem with this is, 503.52s - 506.00s | to start with dangling resources, 506.00s - 508.92s | some past work includes, you can buy DNS data 508.92s - 512.20s | and then enumerate your cloud provider's IP pool 512.20s - 514.40s | in order to find what's dangling. 514.40s - 517.00s | So, if I go ahead and create a resource


chunk_id: 162_chunk_10
chunk_text:
to be clear, past approaches 467.40s - 470.80s | for these types of bugs already exist. 470.80s - 473.52s | Where with dangling cloud resources, 473.52s - 476.40s | we've seen that attackers can go ahead 476.40s - 478.48s | and enumerate cloud IP pools 478.48s - 481.00s | and capture these resources that are dangling. 481.00s - 484.00s | But with leaked secrets, what we've seen is 484.00s - 487.80s | that a lot of work really relies on a limited scope. 487.80s - 490.12s | So, what I mean by that is, 490.12s - 492.76s | everything that happens with leaked secrets 492.76s - 495.08s | is always about a specific target, 495.08s - 498.56s | like a specific folder, a specific repository, 498.56s - 500.12s | or a specific directory. 501.20s - 503.52s | And the problem with this is, 503.52s - 506.00s | to start with dangling resources, 506.00s - 508.92s | some past work includes, you can buy DNS data 508.92s - 512.20s | and then enumerate your cloud provider's IP pool 512.20s - 514.40s | in order to find what's dangling. 514.40s - 517.00s | So, if I go ahead and create a resource 517.00s - 519.56s | over and over again in a cloud environment, 519.56s - 521.32s | I'll be assigned IP addresses 521.32s - 523.88s | that are not assigned to any other customer. 523.88s - 527.68s | And if one of these IP addresses matches a DNS record 527.68s - 529.92s | that I found in DNS data 529.92s - 532.40s | that threat intelligence providers sell, 532.40s - 534.60s | well, that's one way you can capture 534.60s - 536.80s | a dangling DNS record. 537.68s - 539.96s | And other attempts also include 539.96s - 541.88s | going after a specific target. 541.88s - 543.96s | So, instead of using DNS data you buy 543.96s - 545.80s | from threat intelligence providers, 545.80s - 548.64s | you'll instead go ahead and enumerate that provider pool, 548.64s - 550.64s | but this time compare against subdomains 550.64s - 555.49s | you've enumerated for that specific provider. 555.49s - 557.69s | So, to give you some examples, 557.69s - 559.53s | there's been a lot of work in this area. 559.53s - 562.97s | Bishop Fox originally came out in 2015 with an article 562.97s - 565.57s | where they


chunk_id: 162_chunk_11
chunk_text:
517.00s - 519.56s | over and over again in a cloud environment, 519.56s - 521.32s | I'll be assigned IP addresses 521.32s - 523.88s | that are not assigned to any other customer. 523.88s - 527.68s | And if one of these IP addresses matches a DNS record 527.68s - 529.92s | that I found in DNS data 529.92s - 532.40s | that threat intelligence providers sell, 532.40s - 534.60s | well, that's one way you can capture 534.60s - 536.80s | a dangling DNS record. 537.68s - 539.96s | And other attempts also include 539.96s - 541.88s | going after a specific target. 541.88s - 543.96s | So, instead of using DNS data you buy 543.96s - 545.80s | from threat intelligence providers, 545.80s - 548.64s | you'll instead go ahead and enumerate that provider pool, 548.64s - 550.64s | but this time compare against subdomains 550.64s - 555.49s | you've enumerated for that specific provider. 555.49s - 557.69s | So, to give you some examples, 557.69s - 559.53s | there's been a lot of work in this area. 559.53s - 562.97s | Bishop Fox originally came out in 2015 with an article 562.97s - 565.57s | where they used this passive DNS data, 565.57s - 567.29s | or at least a variant of it, 567.29s - 570.65s | in order to enumerate an AWS cloud IP pool 570.65s - 573.85s | and then capture AWS IPs that corresponded 573.85s - 576.49s | to a specific domain they were interested in. 576.49s - 578.37s | So, in that case they used bing.com 578.37s - 580.57s | to find those dangling DNS records. 582.25s - 586.21s | Some other work includes flying a false flag 586.21s - 587.65s | from Black Hat, it's a talk, 587.65s - 589.85s | where they used passive DNS data 589.85s - 591.77s | from these threat intelligence providers 591.77s - 596.64s | to determine whether IPs they captured were dangling. 597.08s - 600.56s | This project was, again, focused on creating these backends 600.56s - 602.86s | for C2 malware platforms. 602.86s - 605.34s | They wanted to take control of legitimate domains 605.34s - 607.12s | so that they could abuse those domains 607.12s - 609.00s | for a false level of trust. 610.76s - 612.56s | One interesting note about this project 612.56s - 615.22s | is that they noted that after


chunk_id: 162_chunk_12
chunk_text:
used this passive DNS data, 565.57s - 567.29s | or at least a variant of it, 567.29s - 570.65s | in order to enumerate an AWS cloud IP pool 570.65s - 573.85s | and then capture AWS IPs that corresponded 573.85s - 576.49s | to a specific domain they were interested in. 576.49s - 578.37s | So, in that case they used bing.com 578.37s - 580.57s | to find those dangling DNS records. 582.25s - 586.21s | Some other work includes flying a false flag 586.21s - 587.65s | from Black Hat, it's a talk, 587.65s - 589.85s | where they used passive DNS data 589.85s - 591.77s | from these threat intelligence providers 591.77s - 596.64s | to determine whether IPs they captured were dangling. 597.08s - 600.56s | This project was, again, focused on creating these backends 600.56s - 602.86s | for C2 malware platforms. 602.86s - 605.34s | They wanted to take control of legitimate domains 605.34s - 607.12s | so that they could abuse those domains 607.12s - 609.00s | for a false level of trust. 610.76s - 612.56s | One interesting note about this project 612.56s - 615.22s | is that they noted that after releasing it, 615.22s - 619.16s | it would appear that AWS and GCP now assign IPs 619.16s - 621.52s | from a limited pool for your account. 621.52s - 623.16s | We'll touch on this more later, 623.16s - 624.90s | but this is what we're gonna be focusing on 624.90s - 627.44s | when it comes to dangling DNS resources. 627.44s - 629.16s | The topic is well-traversed, 629.16s - 630.42s | but what's not well-traversed 630.42s - 632.18s | are the modern deterrents against it 632.18s - 633.66s | and how we can bypass them. 635.22s - 637.18s | And finally, there's still a lot of work 637.18s - 640.82s | where attackers simply enumerate your domain's subdomains 640.82s - 644.92s | and then find IPs that match them. 644.92s - 646.62s | Now, when it comes to leaked secrets, 646.62s - 648.50s | the story's a bit different. 648.50s - 652.70s | It's not as well-traversed as dangling DNS records at all. 652.70s - 655.48s | So, for example, there's tools that you can use 655.52s - 659.00s | to search a Git repository for these secret patterns. 659.00s - 661.56s | And even GitHub has a


chunk_id: 162_chunk_13
chunk_text:
releasing it, 615.22s - 619.16s | it would appear that AWS and GCP now assign IPs 619.16s - 621.52s | from a limited pool for your account. 621.52s - 623.16s | We'll touch on this more later, 623.16s - 624.90s | but this is what we're gonna be focusing on 624.90s - 627.44s | when it comes to dangling DNS resources. 627.44s - 629.16s | The topic is well-traversed, 629.16s - 630.42s | but what's not well-traversed 630.42s - 632.18s | are the modern deterrents against it 632.18s - 633.66s | and how we can bypass them. 635.22s - 637.18s | And finally, there's still a lot of work 637.18s - 640.82s | where attackers simply enumerate your domain's subdomains 640.82s - 644.92s | and then find IPs that match them. 644.92s - 646.62s | Now, when it comes to leaked secrets, 646.62s - 648.50s | the story's a bit different. 648.50s - 652.70s | It's not as well-traversed as dangling DNS records at all. 652.70s - 655.48s | So, for example, there's tools that you can use 655.52s - 659.00s | to search a Git repository for these secret patterns. 659.00s - 661.56s | And even GitHub has a system 661.56s - 663.78s | where they'll scan every content, 663.78s - 666.88s | every piece of code uploaded to their platform 666.88s - 668.96s | for these secret patterns. 668.96s - 670.72s | But the limitation with this work 670.72s - 674.68s | is that it's really a very small scope. 674.68s - 676.22s | I mean, think about how much code 676.22s - 678.04s | is really gonna end up on GitHub. 678.04s - 680.28s | You know, most enterprises aren't gonna put 680.28s - 683.28s | their closed-source applications on GitHub 683.28s - 687.67s | where this scanning would occur in the first place. 687.67s - 690.33s | Now, going on to defender approaches 690.33s - 692.09s | to mitigate these vulnerabilities, 692.09s - 694.81s | well, there have been pretty limited as well. 694.81s - 698.21s | Oftentimes, these are treated as customer vulnerabilities, 698.21s - 700.37s | which technically is correct. 700.37s - 701.93s | If you think about it from a high level, 701.93s - 705.37s | if you leak a secret or leave a DNS record dangling, 705.37s - 707.39s | that is your responsibility. 707.39s - 709.25s | But what I think


chunk_id: 162_chunk_14
chunk_text:
system 661.56s - 663.78s | where they'll scan every content, 663.78s - 666.88s | every piece of code uploaded to their platform 666.88s - 668.96s | for these secret patterns. 668.96s - 670.72s | But the limitation with this work 670.72s - 674.68s | is that it's really a very small scope. 674.68s - 676.22s | I mean, think about how much code 676.22s - 678.04s | is really gonna end up on GitHub. 678.04s - 680.28s | You know, most enterprises aren't gonna put 680.28s - 683.28s | their closed-source applications on GitHub 683.28s - 687.67s | where this scanning would occur in the first place. 687.67s - 690.33s | Now, going on to defender approaches 690.33s - 692.09s | to mitigate these vulnerabilities, 692.09s - 694.81s | well, there have been pretty limited as well. 694.81s - 698.21s | Oftentimes, these are treated as customer vulnerabilities, 698.21s - 700.37s | which technically is correct. 700.37s - 701.93s | If you think about it from a high level, 701.93s - 705.37s | if you leak a secret or leave a DNS record dangling, 705.37s - 707.39s | that is your responsibility. 707.39s - 709.25s | But what I think that is often missed 709.25s - 711.33s | is the provider's responsibility 711.33s - 714.57s | in how they encourage these insecure defaults. 715.33s - 718.85s | So for example, tokens are really, really easy to use. 718.85s - 721.03s | Have you ever thought about how easy it is 721.03s - 723.19s | to use a token in your code? 723.19s - 726.41s | And that's how it can get leaked in the first place. 726.41s - 728.49s | Now, Fortune 500 companies might have 728.49s - 731.51s | those standard secure development lifecycle practices 731.51s - 732.97s | where they can avoid this, 732.97s - 736.53s | but in reality, a lot of small to medium-sized businesses 736.53s - 738.17s | might not understand this nuance 738.17s - 744.09s | or be able to apply it uniform across their organization. 744.09s - 746.53s | Now, this is something we're gonna talk about later, 747.21s - 748.77s | but I want you to keep it in mind. 748.77s - 752.69s | Remember, even though it's a cloud customer vulnerability, 752.69s - 754.45s | there's incentives that lead to them 754.45s - 756.09s | being created in the first place.


