 Good afternoon, everyone. First and foremost, a little bit of housekeeping. If anyone has lost a pair of sunglasses and can describe them to me, come see me. Otherwise, I have a new set of sunglasses and thank you for that. Next up, I just want to point out that if you are looking for seats because you're coming in, there are seats up here in the front and there's some to the side as well. Now, we are in track three for Netripper smart traffic sniffing for penetration testers. And without further ado, I give you Janusz Popescu. Hi, everyone. First of all, a bit about me. I'm Janusz Popescu. I'm from Romania. And I work as a senior security consultant at KPMG Romania. Also, I'm a blogger at securitycafe.ro and the administrator of the biggest, largest security community from the Eastern Europe. A few things about my country. It's located in the Eastern Europe. It's a country of Dracula. We have the first stand in Olympics. We invented the jet plane. And we have probably the most beautiful girls in the world. Don't trust me. Come and check. Here is the agenda, what we're going to talk about. An introduction about this tool. A few details about how it works. Some details about the reflective DLL injection. The method used to inject the DLL. The API, API hooking. Some hooking examples. Demo. And hopefully everything will be okay. The introduction. What is Netripper? Netripper is a post-exploitation tool for Windows systems that captures the network traffic even if it is encrypted or not. It captures the traffic before it is encrypted or after it is decrypted at the application layer by injecting a DLL and using API hooking and hooking specific functions. The most important thing about this is that it works without an administrator. It works for a low-privileged user. Here is the main scenario. In our projects we encountered this situation multiple times. We had access to administrator laptops and we didn't know what to do to pivot to the other servers. So this is where the idea came from. This is the general example of how it works. Let's say for outlook. Someone writes an email. The email is encrypted and the encrypted data is sent through the network. So the user layer is where the user types the email. The network layer contains the encrypted data and Netripper is injected at the encryption layer. Here is an example. The user writes the email. This example is for outlook. Outlook uses encrypt.dll and SSL encrypt packet and SSL decrypt packet in order to encrypt and decrypt the data. The data is then sent encrypted after with send or WSA send Windows API functions. Here is what happens when the Netripper.dll is injected. It hooks this function from encrypt.dll and it gets the data before it is encrypted. This also happens for the decryption. It hooks the SSL decrypt packet and after the data is decrypted by the SSL decrypt packet function, it can access the plain text data. This is the main idea. I use reflective DLL injection to inject the DLL. API hooking to hook specific functions and save the data locally. This is how classic DLL injection works. The application opens the remote process. It writes in the process memory the full DLL, the full path of the DLL in the process memory and call the library to load the DLL. So the library will load the DLL into the process memory. But this has some disadvantages. The DLL must be written on disk and the antivirus can pick them. And the DLL is listed in the process modules. The reflective DLL injection was implemented by Stephen Fuhrer of Harmony Security. And this is how it works. The DLL contents are copied, the full DLL, the content is copied into the target process memory. However, the DLL doesn't look the same in the process memory like on the disk. So it has to out-load itself correctly. For this, the reflective DLL injection uses a function called reflective loader. This function does all the steps necessary to correctly load the DLL. The advantages of this method is that the DLL doesn't touch the disk. So you can easily bypass the antivirus. And that the DLL is not listed in the process modules. Because it's not loaded with the library. And the window system uses the process environment block to keep a linked list with all process modules. I hope you can read this. This is first step for the DLL injection. This is actually the injection of the DLL using reflective DLL injection. If you can see, there's a method called, a function called, get a reflective loader offset. This function just search the reflective loader functions and returns the offset in the DLL. After this step, we allocate space in the process memory, in the target process memory for the, with the full size of the DLL. The DLL is now written with the process, write process memory function. And we call using create remote thread the reflective loader function. This code, actually full reflective DLL injection code is from Stephen Fuer of harmony security. After this function is called, what it does is to search for the image base of the process. Actually, it search where the DLL is mapped in the memory. It search for the windows portable executable header. So it starts from the current location and search for the header. After it find the header, it needs to know some functions required to properly load itself into memory. So it finds, it have to find functions like load library, get proc address, virtual lock and NTFlash instruction cache. Next step is to load the DLL headers and sections in a new location. The section must be aligned in memory, so this step is required. It's not difficult to parse the PE, the portable executable headers. So it just parsed the PE header and get each section and map it into a place of memory. After the sections are loaded, the next step is to process the imports. You may create a DLL that use some, I don't know, specific DLL from windows. In order to make sure everything will work, you have to make sure every DLL is loaded into memory. Every imported DLL is loaded into memory. So what it does is to parse the data directory, the directory imports. The directory imports is a location in the PE header that describes each DLL that should be loaded in order to make sure the DLL is loaded properly. Those things are automatically done by the Windows PE loader, but we want to avoid using it. Next step is to process the image relocation. Images relocations are some addresses that are directly pushed on the stack or directly used in the code. For example, if you have a push location, this location have to be relocated in case of the DLL is not loaded at the request of the DLL. Each PE file, DLL or executable have a preferred image base, but at least for the DLLs, it may happen to load the DLL at another location. So this is required. After the DLL is completely loaded into memory correctly, it just need to call the main function of the DLL. The main function is DLL main for DLLs. Okay. API hooking. We take the same example with Outlook and Encrypt.DLL. So we want to redirect the SSL Encrypt packet to our hooking function. So we will redirect function from Encrypt.DLL to Netripper.DLL. These are the steps that we have to follow in order to do this. We have to find the function address and this in some cases may be the difficult part. We place a call instruction right at the beginning of the function and we call a generic hooking function instead. We restore the original bytes because we modify them. Call a call back function, a function that process the data from our target function, in this case SSL Encrypt packet. And in that function, we have the plain text data. We save data to a file and then restore the hook for additional calls. This is the normal assembly for a function. As you can see, start with a MOVDI and the classic function prologue push EPP, MOV, EPP, ESP. After we hook this function, first five bytes are replaced by our call. Call and that specific address. That address is actually the address of our generic hooking function. A few details about how this works. This is how we place the hook. We create a call instruction. The call for the call instruction is E8. And we calculate the distance between the original function and our callback function, our hooking function. And we save the original bytes in order to restore them later. Flash instruction cache, actually I'm not sure if this is strictly required on Windows because it doesn't seem to do anything. Here is our generic hooking function. Every time we place a hook, we call this function. And this is how it works. First of all, we have a hook structure. In this structure, we save the callback address, our function, the original address, the address that we hooked, the original bytes and the call bytes. If you can see, an important thing about call and not jump is that call automatically pushes on the stack the next instruction. What we have to do is to subtract five from that return address. And we have the original address of the hooked function. So we can just iterate through all hooks and find the structure for that specific hook. The hooker, get hooked by the original address, do this for us. After we found our hook structure, we can access the original address and the original bytes. So we can call memcpi in order to restore the original bytes. So the function is now not hooked and it is like original function. After we restore the original bytes, what we have to do is to call our callback function. Our callback function, as you will see, saves locally the data and restores the hook. We have all the required information in that structure. This is how a callback function works. It must have the same prototype and also must specify the calling convention. WinAPI are using STD call. Some other functions use Cdeklu calling convention. And what it does is to write to a temporary file the unencrypted data. The SSL encrypt packet wants to encrypt the data. The data is specified by the PB input parameter. And after the data is saved, we call the original function. So make sure the data is correctly sent through the network. And we restore the hook. First example, the easiest one for Mozilla Firefox and some other applications. We find the DLLs that encrypt and decrypt the data and send it through the network. Those are NSS3.DLL and NSPR4.DLL. We find the read and PR write functions and hook them. Also PR receive and PR send may be used by some other applications. Another useful example would be putty. A lot of people use putty. So this is going to be useful. Adrian Furton, my colleague from Cape NG Romania wrote a really cool tool called puttyrider that does the same thing. It hooks some functions, L-disk send and term data. That send, L-disk send will send each character and term data will be called with the receive data in order to be displayed on putty. Puttyrider can do a lot of other things. So you may take a look at it. Adrian wrote the signatures for the function. So I only had to use the signatures, actually the first byte of the functions in order to find the function. So I just find the dot text section, the code section from putty.xy. And I search those functions and hook them. For WinFCP also really used in real life, I found the easiest way to compile the source code. I got the source code, it took me a few hours but I was able to compile it. It also took me some time to find the correct functions because there are a lot of functions. But I found in SSH.C the functions that looks to send the network traffic before it is encrypted or to decrypt the traffic. So we have just to find the send receive functions. We place an interrupt 03 that will break point in the debugger, compile the application and run and see the data in the debugger. Those are the functions used by WinSTP. SSH packets send, have a parameter called pkt that structure that contains the data and the data size. And the SSH2 RD packet will return a packet structure that will contain a pointer to the data and the data size. This is how the send and receive functions look like. And I had to just copy the first byte of each function and search it in the code section. So I was able to hook them and find their location. The main problem is that not all the applications use a DLL in order to call some functions to encrypt and decrypt the data. And the WinSTP is one of these tools. They are statically linked with some different libraries and it may be really difficult to find the correct function and the function prototype to be able to hook them. So this is the code that hooks the WinSTP send and receive functions. Like Putty, I created signatures for these functions and I searched the process memory for these functions and placed our hook. Chrome may be, I think it may be difficult to compile Chrome. I didn't try to do this. Instead I used some ideas from some underground forums. And this can be more complicated that it looks like. Chrome uses a table called SSL methods where the SSL functions are set. So we have to find that SSL methods structure that contains the SSL read and SSL write functions. In the source code of Chrome, this is for Chrome NSS. Until version 37, Chrome uses a table called NSS. NSS is the Netscape security services from Mozilla. After some problems, they wanted to change to open SSL but with open SSL there are also a lot of problems and they decided to create a round fork of open SSL. So in the code of NSS, you can find a call to a function called SSL set up IO methods. This will call the get default IO methods. However, we have to find the start of the SSL methods pointer. And in order to find this, we rely on the PR desklared attribute which have the value 4. So we find the call of the function by searching the SSL string. As you can see in the SSL init IO layer, there's a method called PR get unique identity with a parameter called SSL. We find that string on the data section of the executable and we can find the call for this function. Then we find the call for the set up IO methods where we can find the SSL methods table. So after we found the SSL string, we find the method that sets the SSL methods and highlighted with red in bottom right, you can see a value of 4 attributed to a location. That is the location of an SSL table and we use that table to find the SSL read and SSL write functions. This is the code. We find the string into the process memory and we find that specific method and using that specific method, we are able to find the SSL read and SSL write functions. Then starting with version 38, Chrome uses a fork of open SSL called boring SSL. Also it's statically linked and all functions are available in Chrome.dll. It's a huge dll. And in order to find the correct functions, I relied on an error on the error message that was available in both SSL read and SSL write functions. This string is specified by the open SSL put error macro. So the dll will contain a location in the data section, a string that contain the compiled file. So we search in the data section this string, that's called the CW backslash, build, slave, win, build and so on. And we have to find the correct call of the function. There are about 20 calls with this string. So we have to find the 15 and the 17 location. Those are the SSL read and SSL write functions. This is the code that search the specific string in the data section. And it search for the 17 and 15 location of that string. So we are able to find the SSL send and SSL read and SSL write functions. I thought it might be useful to create some plugins for this tool that will process both send and receive data. There are only three plugins but I hope they are useful. The plain text specifies if we want to save only the plain text data or to send all the data. The data limit is used to avoid large log files. And we set the maximum file request size. And string finder is a plugin that will write in a specific file some new lines, some strings that we can specify there. So for example, if the data contains the word pass, we can log in in another file. The plain text plugin may be useful in order to avoid a large amount of data. This is just an example that we avoid a lot of data within an image file. That's not our interest. The data limit may be used to trim the data and save only the first 4,000 bytes of the data. And the string finder can find our words in the data. In this example, it finds the password and the login information for a specific account. The Netripper have two components. The Windows module that can configure the DLL and inject the DLL. The DLL configurations mean just to specify specific values for the plugins. To specify if you want plain text or not, specify the data limit or find in the request some strings using the string finder plugin. And you can also test to use it to inject the DLL in a specific process. Like in this example, we inject the DLL in Firefox. This can be useful in order to test some specific application. For example, you are not a penetration tester. You don't want to pivot to the network, but you want to find what the application is sending through the network. So it may be useful to analyze such applications. And down you can see an example with Firefox. Here is the metasploit module. It is a post exploitation module, so we have to, we need to have access to the compromise machine. And there are the same configuration options like in the Windows module. We have to specify values for the string finder, plain text, and data limit plugins. The data path represents where to save the data. The string temp will automatically detect the local temporary folder. And we can specify either the process IDs or the process names where we want to inject the DLL. Now for the demo, I have two virtual machines. One with Kali Linux, the penetration tester machine. And the other one Windows 7 64 bit. And the other one will be the victim. Yeah, I'm not sure if you can see. Yeah, it works now. Okay. Okay. We should have a metapreder session. And I chose an easy way to get this. So we have access to our victim machine. This will be the pen tester. And this will be the victim, the c-sadmin. So it is a normal user. And we have to have access to the post-exploitation module. We just have to inject this in specific processes. Here is the example list. And run. Yeah, sorry. I think it's too. Okay. And the module will inject the DLL in all processes with specific process names. And let's take some examples. For example, it can use putty and do some stuff. It can use WinSCP. And let's say it will modify a file. A configuration file. The transfer is not complete. Just wait to send a modified file. Okay. It can connect to my SQL database. And it can execute a query. It can search some data on Skype or talk to someone. It can use Yahoo Messenger. This was really used in Romania. It can use SQL server to connect to a database. And execute some queries. It can use FileZilla. And let's say it will modify some confidential data file. He may send an email. It may browse some secure server. Let's say DevCon. Or even from Facebook, log in to an account also on SSL. An important advantage of this method is this one. The certificate is not modified. And you don't see another signer or a certificate. So someone may look at the certificate and may not be sure that if everything is okay. Okay. And now the attacker. What it has to do? It have to download the log files specified in the local directory. This is in C. Users. Local user. App data. And then local. And temp. Here it will create a folder called netripper. And here should be all the files. We just download all of them. Each file name contains the process ID, the process name and the function used in order to capture the data. This may be useful because the processes may also, the netripper can also catch both the encrypted data and the data before it is encrypted. So you may have some junk data there. You'll have to filter the results. Just a moment to finish the execution. The string file, a string finder plugin creates those files, then specifies the string finder identifier. Okay. Now we have the files. Let's see what we can find. HiDSQL, the MySQL client received some data. And we executed the select star from MySQL.user which contains the hash of the admin. This may be useful. The data sent and our query. The string finder finds our strings and one of them is password. And this contains the hash of the user. For Chrome, we may find useful information in SSL read and SSL write functions. And SSL write. Those are for the plain text. So we may not find useful information here. Putty. This is what Putty received. And you can see the contents of the pass WD file here. And this is what Putty sent. So we can find the username and the root password. The receiving sender don't contain any useful information. Also string finder found some useful information for us. WinSCP also send and receive will not contain useful information but the SSH packet send will contain the contents of the modified file. And the read packet will also contain the file read from the server. So everything is plain text. For Outlook, the encrypt message packet. I think this is the password encoded in base 64. So and here is the content of the email. This is the data received from Outlook servers. For Firefox, PL read is right. It's used to read the information. You can see some junk information there because a lot of content is exiting compressed. And the PL write. Here are the Facebook requests, I think. And here is the login information we are searching for. The username and the password. For the SQL server management studio, we can also find some queries automatically executed. And the data received. You may, I don't know, you may find new things about the SQL server using this. And for file 0, this also the whole traffic is plain text. And you can find all the information here. Here is the send data. So the username and the password. The tool is not complete. I want to make it support 6x64 processes. And to support a lot of other applications and even older versions of the applications. The hook is also not thread safe. So I have to work on this. And I also want a regular expression platform. For the defense, I think this is a Microsoft operating system issue. But for example, my Kaspersky actually wants me if an application in user land tries to modify the process memory of another application. And I think all antiviruses should do this. Here is the project. It's private now, but in a few minutes I'll make it public. So we'll have the source code binaries and metasploit module. As a conclusion, this is a post-exploitation tool. It uses reflective injection and API hooking and hook specific functions that encrypt and encrypt the data in order to capture the network in plain text. And it should be easy to use. If you have any questions, I can't hear you, sorry. Oh, okay. It doesn't work now. I'll make it public in a few minutes. And here is my contact information if you need help or if you have suggestions or everything else. Thank you.