Hi,
I have not posted anything for a while, but I am going to be posting from now. I apologize for the long delay, I did not really get around to posting any interesting topics recently however I plan on also writing few blogs regarding security soon or later.
Nevertheless, I am going to be writing about physics, cosmology as well after people requested me to write few blogs pertaining about physics and space.
Anyway, in security I will be covering:
- Theories of Anti-Virus development (Heuristics)
- How DDoS works
- Theory of Network analysis
- Self-Protection mechanisms
I also have a long list of planned topics to cover in future:
- AI (Non-Game based)
- Encryptions
- Science of Sci-Fi
- Simulation Programming
That being said, stay tuned.
Wednesday, 9 April 2014
Sunday, 5 January 2014
Global Remote Detour: KiFastSystemCall
Hi,
I am not planning on explaining my code too much but rather give code, which is more or less straightforward in terms of the functions used and the simple logic.
Unlike the previous remote detour given I am not really creating a running thread as that will just be too slow and unneeded work.
There are 2 functions needed for the global injection: Provider(void) & Injector(DWORD Pid)
The function Provider(void) is responsible for providing each process's PID to the Injector function, then the Injector function will:
I am not planning on explaining my code too much but rather give code, which is more or less straightforward in terms of the functions used and the simple logic.
Unlike the previous remote detour given I am not really creating a running thread as that will just be too slow and unneeded work.
There are 2 functions needed for the global injection: Provider(void) & Injector(DWORD Pid)
The function Provider(void) is responsible for providing each process's PID to the Injector function, then the Injector function will:
- Open the PID via a call to OpenProcess
- Using the handle it will suspend the process, ready for injection
- It will then write the callback into the process memory space
- Then will create a char array of machine code (JMP ---) then will annotate the remote callback address on to the char array.
- The char array will be then written on KiFastSystemCall address,
We have detoured KiFastSystemCall, the uses of such detours are endless:
- Self-Protection
- Proactive AV scanning
- Complete Control over system
- Helpful Debugging Information
The Code Metrics:
Line Count: 105 Lines
Size: 3.05 KB (3,125 bytes)
Link: KiGlobalHook.cpp
Stay Tuned,
Saturday, 30 November 2013
Detoruing x64 System Call Stub: X86SwitchTo64BitMode
Hi,
It's been a while since I posted anything, anyway now that I am here I am going to be giving a detour for: X86SwitchTo64BitMode.
X86SwthTo64BitMode is the deepest call before everything switches into 64 bit mode and other inaccessible DLL files. Additionally X86SwitchTo64BitMode can be detoured fairly easily unlike KiFastSystemCall, a usual JMP would do the job especially because we don't care if we overwrite instructions because we are not jumping back to the original instruction.
The Code is more or less pretty straightforward for any Windows savvy users.
Link: X86SwitchTo64BitMode.cpp
As said before, this code can be easily incorporated into a Global detour, additionally you may find this suitable to incorporate into your projects with credits to - Code Empire.
Regards,
It's been a while since I posted anything, anyway now that I am here I am going to be giving a detour for: X86SwitchTo64BitMode.
X86SwthTo64BitMode is the deepest call before everything switches into 64 bit mode and other inaccessible DLL files. Additionally X86SwitchTo64BitMode can be detoured fairly easily unlike KiFastSystemCall, a usual JMP would do the job especially because we don't care if we overwrite instructions because we are not jumping back to the original instruction.
The Code is more or less pretty straightforward for any Windows savvy users.
Link: X86SwitchTo64BitMode.cpp
As said before, this code can be easily incorporated into a Global detour, additionally you may find this suitable to incorporate into your projects with credits to - Code Empire.
Regards,
Wednesday, 13 November 2013
Security: Process Injection & detouring
Hi,
I will be posting on how to inject into foreign processes then place a detour on specific API's, our example being MessageBoxA however this technique can be adapted to any API detour with slight change. Some useful API calls to detour would be:
- NtOpenProcess
- NtTerminateProcess
- NtQueryDirectoryFile
- NtQuerySystemInformation
more exotic API's include:
- TurboDispatchJumpAddressStart
- KiFastSystemCall
- X86SwitchTo64BitMode
- Wow64SystemServiceEx
- CpuSimulate
As you may guess, there is again both malicious and positive purposes. It is always beneficial to understand these things, especially in case these task raise up.
The injection is modified slightly from the Mozilla Firefox post which was posted last month. I could have placed a detour directly on the API address using few easy workarounds however I simply created a entire thread which places the detour, just to show it as a Proof-Of-Concept code to newbie security analysts & security developers.
The code follows:
I will be posting on how to inject into foreign processes then place a detour on specific API's, our example being MessageBoxA however this technique can be adapted to any API detour with slight change. Some useful API calls to detour would be:
- NtOpenProcess
- NtTerminateProcess
- NtQueryDirectoryFile
- NtQuerySystemInformation
more exotic API's include:
- TurboDispatchJumpAddressStart
- KiFastSystemCall
- X86SwitchTo64BitMode
- Wow64SystemServiceEx
- CpuSimulate
As you may guess, there is again both malicious and positive purposes. It is always beneficial to understand these things, especially in case these task raise up.
The injection is modified slightly from the Mozilla Firefox post which was posted last month. I could have placed a detour directly on the API address using few easy workarounds however I simply created a entire thread which places the detour, just to show it as a Proof-Of-Concept code to newbie security analysts & security developers.
The code follows:
- Open the process with flag set to PROCESS_ALL_ACCESS however this can be reduced to bare minimum
- Create and fill a _CODE structure ready to be added as a parameter to our injected thread
- Then allocate all the space needed for the processes which include - Thread, Parameter
- Create the remote thread
The explanation above shows the procedure to inject code into foreign process but the thread performs something more or less the most important part of the program:
- Use the _CODE structure then store the appropriate members in specific typedefs to be called
- Calls MessageBoxA with parameters being set to those given from the _CODE structure
- Finally patches MessageBoxA to redirect the control to a callback
- Additionally the thread also patches the callback to ensure the callback returns the control back to original
Now I will elaborate on the job of the callback:
- The callback reinstates the lost bytes of the original instructions
- Jumps back to original MessageBoxA
- Returns
You would get a good idea on how it works, however for those who still have no clue here is the download:
Until Next Time,
Thursday, 31 October 2013
Security: Social Engineering using UAC
Hi,
Today, we will be exploiting the UAC Architecture - for developers wanting to become savvy on Windows, UAC is a abbreviation for User Account Control it is designed to allow individual processes to run in various Account Levels, additionally it protects the host from malicious software from gaining higher privileges without consent.
However Microsoft while developing UAC, and perform bug checks they forgot to notice Windows Command Preprocessor, functionality which defeats the purpose of Command Prompt.
As you know Windows Command Preprocessor has extremely rich parameter usage, which can be exploited in order to run a different program but UAC shows that the program is trusted:
*** The Username is blurred out, for obvious reasons ***
The above UAC is the default UAC which pops up, this UAC is also set to the highest level to show it works effectively on the most harshest\secure PC's.
While this look completely trustable, you can see the real-trick when we click on the "Show details" expander control located bottom-left.
Once we click that the true identity is shown:
As you may observed, only when we press "Show details" expander control located bottom-left we can see the true identity of this UAC alert, however majority of the time 80-90% of the Users tend to never click on show details especially if the UAC has a trusted software wanting elevation.
To show even more, if we press publishers, it shows Certificate is OK, many may think this is about the Malware but the certificate is CMD.exe's therefore we have performed Social Engineering Attack.
We can easily perform this via a simple call to ShellExecuteExA\W, with the lpVerb set to - "runas" and lpFile set to - location of Cmd.exe however to start our Malware as well we can use lpParameters to elevate our Malware like so - /c start %Malware Path%.
This technique will not only reduce huge amount of code and effort but is useful when deploying untrusted applications in the sense that it does not contain any digital signatures.
Source code:
As you may see I have not included entire source file such as headers as those can be added upon easily.
Prevention;
UAC is pretty secure itself such as prevents buffer overflows (to a certain extent of course) and such similar attacks however, it need more stricter settings by maybe show a label suggesting a parameter is added or showing additional details by default rather than giving user a choice.
As for the current UAC, it can still be "hacked" via a code injection into UAC when it pops up to hide the "show details" tab therefore evading prying eyes even further.
Stay Tuned,
Today, we will be exploiting the UAC Architecture - for developers wanting to become savvy on Windows, UAC is a abbreviation for User Account Control it is designed to allow individual processes to run in various Account Levels, additionally it protects the host from malicious software from gaining higher privileges without consent.
However Microsoft while developing UAC, and perform bug checks they forgot to notice Windows Command Preprocessor, functionality which defeats the purpose of Command Prompt.
As you know Windows Command Preprocessor has extremely rich parameter usage, which can be exploited in order to run a different program but UAC shows that the program is trusted:
*** The Username is blurred out, for obvious reasons ***
The above UAC is the default UAC which pops up, this UAC is also set to the highest level to show it works effectively on the most harshest\secure PC's.
While this look completely trustable, you can see the real-trick when we click on the "Show details" expander control located bottom-left.
Once we click that the true identity is shown:
As you may observed, only when we press "Show details" expander control located bottom-left we can see the true identity of this UAC alert, however majority of the time 80-90% of the Users tend to never click on show details especially if the UAC has a trusted software wanting elevation.
To show even more, if we press publishers, it shows Certificate is OK, many may think this is about the Malware but the certificate is CMD.exe's therefore we have performed Social Engineering Attack.
We can easily perform this via a simple call to ShellExecuteExA\W, with the lpVerb set to - "runas" and lpFile set to - location of Cmd.exe however to start our Malware as well we can use lpParameters to elevate our Malware like so - /c start %Malware Path%.
This technique will not only reduce huge amount of code and effort but is useful when deploying untrusted applications in the sense that it does not contain any digital signatures.
Source code:
As you may see I have not included entire source file such as headers as those can be added upon easily.
Prevention;
UAC is pretty secure itself such as prevents buffer overflows (to a certain extent of course) and such similar attacks however, it need more stricter settings by maybe show a label suggesting a parameter is added or showing additional details by default rather than giving user a choice.
As for the current UAC, it can still be "hacked" via a code injection into UAC when it pops up to hide the "show details" tab therefore evading prying eyes even further.
Stay Tuned,
Monday, 28 October 2013
Security: Blocking DLL Injections
Hi,
Today - we will be discussing about Injections and prevention of Injections, malware in generally notorious for stealing vital information from Softwares - This causes concern for most Developers working in the Security and Financial Industry as in these field, safeguarding customer data is a very important goal.
Malware(s) perform DLL Injection into the target, the DLL loaded would be a malicious DLL which would steal personal information, the generic malware authors tend to use LoadLibrary and WriteProcessMemory in a combination in order to successfully load a DLL into the Processes memory space, although this many Security Developers and Financial Developers simply detour LoadLibrary and expect the Application to be safe, however a simple call to a lower level function would bypass your layered protection, thus breaching the security.
However if we wanted to block the injection, without ourselves injection then performing a system-wide patch - we can use a LDR function which is function used to load DLL onto our Application, placing a nasty detour on that function would completely safeguard us against many User-Level Malware including Citadel.
The "magic" function is called LdrLoadDll, after we detour this function - we will be able to block many Injector(s) example - WinInject.
Let's Get Coding, First we will start by the function responsible for patching LdrLoadDll:
As you see, we are not doing any special detouring method but the usual jmp method, I did not re-protect the memory address space as you can do anything more like add your own code\replace code.
Next we will be covering the Callback, the callback itself is more or less, simple filtering mechanism however you can customize the mechanism to your own liking:
As you may have noticed the callback simply blocks all DLL locations\names in the C: drive however if the DLL's exist in System32, we cannot block it. All this does is allow trusted DLL to load, but this can be bypassed if a Malware sets its DLL in System32:
The code above is quite straightforward so, not much to explain apart from the LdrAddress variable is a global variable therefore, you cannot see the variable.
These are only real\important piece of code as you may know as all main does is call the Install detour functions and thats all - from then on the callback handles it all.
The code, as I could not fit it into a single screenshot, I am going to give the code in a *.cpp file:
LdrLoadDllBlock.cpp
Next, time I will be covering how to block Code\Process Injections.
Until Next Time,
Today - we will be discussing about Injections and prevention of Injections, malware in generally notorious for stealing vital information from Softwares - This causes concern for most Developers working in the Security and Financial Industry as in these field, safeguarding customer data is a very important goal.
Malware(s) perform DLL Injection into the target, the DLL loaded would be a malicious DLL which would steal personal information, the generic malware authors tend to use LoadLibrary and WriteProcessMemory in a combination in order to successfully load a DLL into the Processes memory space, although this many Security Developers and Financial Developers simply detour LoadLibrary and expect the Application to be safe, however a simple call to a lower level function would bypass your layered protection, thus breaching the security.
However if we wanted to block the injection, without ourselves injection then performing a system-wide patch - we can use a LDR function which is function used to load DLL onto our Application, placing a nasty detour on that function would completely safeguard us against many User-Level Malware including Citadel.
The "magic" function is called LdrLoadDll, after we detour this function - we will be able to block many Injector(s) example - WinInject.
Let's Get Coding, First we will start by the function responsible for patching LdrLoadDll:
As you see, we are not doing any special detouring method but the usual jmp method, I did not re-protect the memory address space as you can do anything more like add your own code\replace code.
Next we will be covering the Callback, the callback itself is more or less, simple filtering mechanism however you can customize the mechanism to your own liking:
As you may have noticed the callback simply blocks all DLL locations\names in the C: drive however if the DLL's exist in System32, we cannot block it. All this does is allow trusted DLL to load, but this can be bypassed if a Malware sets its DLL in System32:
The code above is quite straightforward so, not much to explain apart from the LdrAddress variable is a global variable therefore, you cannot see the variable.
These are only real\important piece of code as you may know as all main does is call the Install detour functions and thats all - from then on the callback handles it all.
The code, as I could not fit it into a single screenshot, I am going to give the code in a *.cpp file:
LdrLoadDllBlock.cpp
Next, time I will be covering how to block Code\Process Injections.
Until Next Time,
Saturday, 26 October 2013
Kernel Drivers: Hiding True Identity
Hi,
Today I will be discussing a method to hide true identity of a Kernel Mode Driver. This method is not well known but exploited by ZeroAccess Trojan quite well. I will add my own "unique" touch to it in order to make it more effective. This is not for malicious purposes but for security researchers.
This trick does not only useful for Security Developer(s) but also may be somewhat use to Driver Developer especially because to test & run drivers quickly rather than getting it test signed or disabling Driver Signature Enforcement.
***NOTE*** This blog\post is only a method and does not involve code.
ZeroAccess Trojan, a notorious trojan responsible for thousands of infection world wide, uses various methods in order to stay resilient and it does by placing Kernel detours on the system using a driver (*.SYS) . Normally, all we need to do is startup the driver using Windows API on x86 systems as there is no sort of protection which guards the Kernel except maybe few AV which again can be bypassed using custom load technique, however this trick would fail miserably on x64 Systems as PatchGuard protects the Kernel from loading "rouge" drivers, but circumventing this is pretty much easy.
If you analyse ZeroAccess Trojan you will see that on x86 systems it get's a driver and copies it to the ZeroAccess Trojan's installation directory then replaces the bytes\information with it's own rootkit code, this is a excellent technique - but this technique is never needed to load the driver on x86 as it has no protection on the kernel but just as a safety precaution to avoid prying eyes of the host user. This same method can be used to bypass patch guard on but to maintain more safety, you need to add garbage code EOF as if you write something on the EOF nothing can be destroyed or corrupted therefore it can bypass few run-time checks and in addition you can add a lot of NOPS on front of your driver in order to confuse and reduce the detection ratio. Then before hand feel free to use a crypter on it inorder to encrypt the file and DON'T ever pack the Driver as most AV solutions use their heuristic behaviour detection in order to detect this as most Malware tend to pack it. If you really want to pack it do not use famous packers such as UPX as these are mostly used by Malware authors.
Next, if your application is in sandbox and to bypass the sandbox, you can perform a far jump into 0x33:[$+5], this would simply change the code next code's into 0x64 code then re-form a far jump into 0x23:[$+5], this would change the following code back into 0x86. I realised the potential for this trick when trying to test a anti-debug trick I created, I tested this on VirusTotal and it is unable to scan\emulate the file in order to give me results as multi code-segment changes messed up the most AV sandboxes and Online File Scanning service. This is one of the brilliant tricks to implement in order to bypass most if not all proactives.
To conclude, there is many many more methods to bypass these security solutions and other protection software.
Keep Looking
Until Next Time,
Today I will be discussing a method to hide true identity of a Kernel Mode Driver. This method is not well known but exploited by ZeroAccess Trojan quite well. I will add my own "unique" touch to it in order to make it more effective. This is not for malicious purposes but for security researchers.
This trick does not only useful for Security Developer(s) but also may be somewhat use to Driver Developer especially because to test & run drivers quickly rather than getting it test signed or disabling Driver Signature Enforcement.
***NOTE*** This blog\post is only a method and does not involve code.
ZeroAccess Trojan, a notorious trojan responsible for thousands of infection world wide, uses various methods in order to stay resilient and it does by placing Kernel detours on the system using a driver (*.SYS) . Normally, all we need to do is startup the driver using Windows API on x86 systems as there is no sort of protection which guards the Kernel except maybe few AV which again can be bypassed using custom load technique, however this trick would fail miserably on x64 Systems as PatchGuard protects the Kernel from loading "rouge" drivers, but circumventing this is pretty much easy.
If you analyse ZeroAccess Trojan you will see that on x86 systems it get's a driver and copies it to the ZeroAccess Trojan's installation directory then replaces the bytes\information with it's own rootkit code, this is a excellent technique - but this technique is never needed to load the driver on x86 as it has no protection on the kernel but just as a safety precaution to avoid prying eyes of the host user. This same method can be used to bypass patch guard on but to maintain more safety, you need to add garbage code EOF as if you write something on the EOF nothing can be destroyed or corrupted therefore it can bypass few run-time checks and in addition you can add a lot of NOPS on front of your driver in order to confuse and reduce the detection ratio. Then before hand feel free to use a crypter on it inorder to encrypt the file and DON'T ever pack the Driver as most AV solutions use their heuristic behaviour detection in order to detect this as most Malware tend to pack it. If you really want to pack it do not use famous packers such as UPX as these are mostly used by Malware authors.
Next, if your application is in sandbox and to bypass the sandbox, you can perform a far jump into 0x33:[$+5], this would simply change the code next code's into 0x64 code then re-form a far jump into 0x23:[$+5], this would change the following code back into 0x86. I realised the potential for this trick when trying to test a anti-debug trick I created, I tested this on VirusTotal and it is unable to scan\emulate the file in order to give me results as multi code-segment changes messed up the most AV sandboxes and Online File Scanning service. This is one of the brilliant tricks to implement in order to bypass most if not all proactives.
To conclude, there is many many more methods to bypass these security solutions and other protection software.
Keep Looking
Until Next Time,
Subscribe to:
Posts (Atom)