Nytro

Greerasu nu poate veni, nu e in Romania. Da-mi ID-ul tau pe MP.

Lasati complimentele. Deci, cine e din VL si da de baut?

Nu ruleaza pe masina virtuala, se inchide imediat la rulare, deci ban

Mi-a venit si mie update-ul pentru asta de la OpenSUSE. Avantajul open-source-ingului... Si mi-au venit mai multe update-uri de securitate pentru kernel, faceti update.

E de la rewrite 1337 e ID-ul acelui topic.

Dai de baut? 2-3 beri acolo.

dwtf v1.0 and its Features dwtf creates a fake.dll from real.dll Features: 1- It exports all symbols of real.dll (also Forwarder). 2- It imports all exports of real.dll (also Forwarder). 3- It creates an area code with a JMP DWORD [ADDRESS] for each export. 4- The exports of fake dll is assigned to a JMP area which jumps to original export of real.dll. Working of dwtf v1.0 If you are making PEB HOOKING, when the APP calls to fake dll export it jumps to original export, everything works fine: Before PEB HOOKING: APP -> IAT OF APP -> REAL DLL EXPORT After PEB HOOKING: APP -> IAT OF APP -> FAKE DLL EXPORT -> IAT OF FAKE DLL -> REAL DLL EXPORT You can add or remove payloads with any IAT HOOKING in the IAT of the fake dll: APP -> IAT OF APP -> FAKE DLL EXPORT -> IAT OF FAKE DLL -> PAYLOAD STACK -> (or never) REAL DLL EXPORT Syntax: dwtf.exe fake_dll real_dll Example: dwtf.exe k32.dll c:\windows\system32\kernel32.dll All .exes are in bin folder: You can execute the: Generate fake kernel32.bat This bat executes dwtf creating a fake kernel32.dll called k32.dll from c:\windows\system32\kernel32.dll After, you can make a pebhooking executing: PEB hooking poc with fake kernel32.bat IMPORTANT: You need the NETCAT for send commands to the console: This bat inject a console.dll in the poc.exe process using InjectorDll.exe This console listen by default in 127.0.0.1 1234, This console is the interface to do PEB Hooking: Next, the bat connect to 127.0.0.1 1234 using nc command (netcat) In the console with netcat you can write: pebhook kernel32.dll k32.dll resume exit In this moment poc.exe is running and it is waiting a user enter: poc.exe try creates files with two APIs of kernel32.dll: CreateFileW and CreateFileA When you press enter all works fine (good lucky) and the process exits creating files. In this scenario all works by this way: poc.exe -> IAT of POC.EXE -> k32.dll (fake kernel32.dll) -> IAT of k32.dll -> kernel32.dll Loading payloads dynamically: For this scenario: poc.exe -> IAT of POC.EXE -> k32.dll (fake kernel32.dll) -> IAT of k32.dll -> payload/s Remember: You can add a payload stack with IAT HOOKING over IAT HOOKING ... The payloads can calls to original kernel32.dll export. You need: Generate fake kernel32.bat PEB hooking poc with fake kernel32.bat command: pebhook kernel32.dll k32.dll Add a payload for CreateFileW, inserting a iat hook in k32.dll: Inject the dll: InjectorDll.exe poc_dll.dll -p PID_OF_POC_EXE In the POC.EXE you can see: Creating files... press enter DLL INJECTED! ADDR OF OwnCreateFileA: 0x70651030 < --- For EXAMPLE It is the time of IAT hooking of CreateFileA of k32.dll to OwnCreateFileA of poc_dll.dll Example of searching CreateFileA IAT ADDR in k32: Using peview (google: download peview): Search the oridinal of CreateFileA like this image: Search IAT ADDR in k32 of CreateFileA like this image: In the IMAGE the IAT ADDR is: 0x1000C1A6 Change the IAT to payload addr: write_process_memory.exe PID_OF_POC_EXE 0x1000C1A6 0x70651030 0x70651030 is the addr of OwnCreateFileA of poc_dll.dll injected in POC.exe In the console with netcat you can write: resume exit Credits dwtf 1.0 (MIT License) engine by Dreg, from evil fingers: - making FULL dll (PEB/file) hooking more easy... - Greetz: Lacon 2k9 Spain & Hispasec team. - Note: Use with real DLLs, a lot of bugs in this version contact me: dreg@fr33project.org Video: http://www.youtube.com/watch?v=t7UXEJieliM Download: http://rootkitanalytics.com/downloadCounter.php?id=7

SpyDLLRemover v3 SpyDLLRemover is the standalone tool to effectively detect and delete spywares from the system. It comes with advanced spyware scanner which quickly discovers hidden Rootkit processes as well suspcious/injected DLLs within all running processes. It not only performs sophisticated auto analysis on process DLLs but also displays them with various threatlevels, which greatly helps in quick identification of malicious DLLs. The DLL search feature helps in finding DLL within all running processes using just partial or full name. Then user can choose to remove the dll from single process or from all loaded processes with just one click. One of the unique feature of SpyDLLRemover is its capability to free the DLL from remote process using advanced DLL injection method which can defeat any existing Rootkit tricks. It also uses sophisticated low level anti-rootkit techniques to uncover hidden userland Rootkit processes as well as to terminate them. SpyDLLRemover comes with support for Microsoft's latest operating system, Windows 7. Apart from this, it introduces new 'Scan Settings' option to allow the user to fine tune the scanning operation. Also it features improved heurestic analysis, enriched user interface, Intelli-Refresh of 'Process Viewer' and more. Current version provides support for malicious DLL removal from system processes across session boundaries breaking the limitations imposed in Vista/Win7. Features of SpyDLLRemover v3 Here are some of the prominent and unique features of SpyDLLRemover which set it apart from any other tool of its kind. * Advanced Spyware Scanner which efficiently discovers hidden Rootkit processes as well as suspicious/injected DLLs within all running processes in the system. * Detection and removal of hidden userland Rootkit processes using sophisticated techniques such as - Direct NT System Call Implementation - Process ID Bruteforce Method (PIDB) as first used by BlackLight - CSRSS Process Handle Enumeration Method * State of art technique for completely freeing the injected DLL from remote process based on advanced DLL injection method using low level implementation which defeats any blocking attempts by Rootkits. This is one of those unique features found only in SpyDLLRemover. * Sophisticated DLL auto analysis which helps in seperating out the legitimate modules/DLLs from the malicious ones. Such DLLs are displayed using different colors representing various threat levels for quicker and easier identification. * 'Scan Settings' option to fine tune the scanning operation based on user needs. * Inteli-Refresh of 'Process Viewer' leading to flicker free user experience. * Integrated online verification mechanism through ProcessLibrary.com to validate any suspcious DLLs. This makes it easy to differentiate between the spyware & legitimate DLLs. * DLL Tracer feature to search for dll within the running processes using partial or full name. Then user can choose to remove the dll from single process or from all loaded processes with just one click. * Sort the process/DLL in the list based on various parameters for easier and quicker analysis. * Detailed report generation of Spyware scanning result as well as process/DLL list in standard HTML format for offline investigation. * View the process/DLL properties for more information by just double clicking on the process/DLL entry in the list. * Feature to show all running processes in the system which has loaded the selected DLL. Also user can click on "Remove DLL from ALL' button to quickly remove any such malicious DLL from all loaded processes. * Termination of suspicious or hidden process based on low level implementation which makes it very effective against any Rootkit techniques. * Support for malicious DLL removal from system processes across session boundaries breaking the limitations imposed in Vista/Win7. * Displays detailed information about all running processes on the system - Process name - Process Id - Session Id - Company Name - Product Name - Process Description - Memory Utilization - Process Binary Path - Process File Size - File Install Date * Shows detailed information about each loaded DLLs within process to make it easier for manual analysis. - DLL Name - Company Name - Description - Comment about type of DLL (System, Hidden, Suspicious) - Load/reference count of DLL - Loading Type (static/dynamic) - DLL File Size - File Install Date - Base Address of DLL - Entry point of DLL - Full DLL File Path * It is standalone tool which does not require any installation and can be executed directly. * Enriched user interface along with more user friendly options makes it the cool tool. Download: http://rootkitanalytics.com/downloadCounter.php?id=6

A, credeam ca esti tu. Ca tu esti singurul din VL de aici pe care il stiu. Daca dai o bere, doua vin Oricum, cred ca avem prieteni comuni, cred ca am vazut poze cu tine pe facebook-urile unor amici, nu mai stiu.

E din Valcea? Cred ca Axu ala e.

E vechi de 2 ani, nici nu cred ca il mai am (nu l-am gasit). Oricum e inutil, nu ai ce face cu el.

Toata lumea "cearta" cartegoria Offtopic. Ok, ce ziceti daca va dau ban daca va prind pe acolo (Online list)? Cine e de acord sa primeasca ban daca intra acolo? In mare, nu o sa fie mari schimabari. Nu forumul trebuie schimbat ci mentalitatea membrilor. Nu pot obliga pe nimeni sa citeasca un tutorial sau sa scrie un articol. Incepeti prin a da propriul exemplu. Chiar vreau sa va vad in zilele ce urmeaza "la treaba". Nu stiu de ce, dar sunt sigur ca nu o sa vad nimic. Vreti o schimbare? Incepeti prin a va schimba pe voi insiva.

Nu cred ca e mai bun nici decat Cain & Abel nici decat Wireshark, nici decat CommView sau altele. E simplu si asta imi place cel mai mult la el. In plus, e open-source. Oricum, nu am spus ca este mai bun decat Cain & Abel.

Tot legat de acest subiect, ar fi frumos sa fie promovat open-source-ingul si pe Windows... Hmm, cred ca aici incepe sa apara legatura hacking <-> Linux.

Cum sa spun... Programul probabil apeleaza niste functii pe care le apeleaza si niste troieni. Si probabil semnatura antivirusilor facuta pe aceste apeluri. Asta cred ca este cauza. Nu l-am incercat, dar eu am incredere in cei de la securityxploded.

Evitati astfel de comentarii. ICEBREAKER101010: De ce nu ai postat tu ultima versiune? In plus, eu poate vreau versiunea asta. OnTopic: E foarte bun programul asta, vi-l recomand.

By Mark Russinovich 8 Jul 2009 2:21 AM This is the fourth post in my Pushing the Limits of Windows series that explores the boundaries of fundamental resources in Windows. This time, I’m going to discuss the limits on the maximum number of threads and processes supported on Windows. I’ll briefly describe the difference between a thread and a process, survey thread limits and then investigate process limits. I cover thread limits first since every active process has at least one thread (a process that’s terminated, but is kept referenced by a handle owned by another process won’t have any), so the limit on processes is directly affected by the caps that limit threads. Unlike some UNIX variants, most resources in Windows have no fixed upper bound compiled into the operating system, but rather derive their limits based on basic operating system resources that I’ve already covered. Process and threads, for example, require physical memory, virtual memory, and pool memory, so the number of processes or threads that can be created on a given Windows system is ultimately determined by one of these resources, depending on the way that the processes or threads are created and which constraint is hit first. I therefore recommend that you read the preceding posts if you haven’t, because I’ll be referring to reserved memory, committed memory, the system commit limit and other concepts I’ve covered. Here’s the index of the entire Pushing the Limits series. While they can stand on their own, they assume that you read them in order. Pushing the Limits of Windows: Physical Memory Pushing the Limits of Windows: Virtual Memory Pushing the Limits of Windows: Paged and Nonpaged Pool Pushing the Limits of Windows: Processes and Threads Pushing the Limits of Windows: Handles Pushing the Limits of Windows: USER and GDI Objects – Part 1 Pushing the Limits of Windows: USER and GDI Objects – Part 2 Processes and Threads A Windows process is essentially container that hosts the execution of an executable image file. It is represented with a kernel process object and Windows uses the process object and its associated data structures to store and track information about the image’s execution. For example, a process has a virtual address space that holds the process’s private and shared data and into which the executable image and its associated DLLs are mapped. Windows records the process’s use of resources for accounting and query by diagnostic tools and it registers the process’s references to operating system objects in the process’s handle table. Processes operate with a security context, called a token, that identifies the user account, account groups, and privileges assigned to the process. Finally, a process includes one or more threads that actually execute the code in the process (technically, processes don’t run, threads do) and that are represented with kernel thread objects. There are several reasons applications create threads in addition to their default initial thread: processes with a user interface typically create threads to execute work so that the main thread remains responsive to user input and windowing commands; applications that want to take advantage of multiple processors for scalability or that want to continue executing while threads are tied up waiting for synchronous I/O operations to complete also benefit from multiple threads. Thread Limits Besides basic information about a thread, including its CPU register state, scheduling priority, and resource usage accounting, every thread has a portion of the process address space assigned to it, called a stack, which the thread can use as scratch storage as it executes program code to pass function parameters, maintain local variables, and save function return addresses. So that the system’s virtual memory isn’t unnecessarily wasted, only part of the stack is initially allocated, or committed and the rest is simply reserved. Because stacks grow downward in memory, the system places guard pages beyond the committed part of the stack that trigger an automatic commitment of additional memory (called a stack expansion) when accessed. This figure shows how a stack’s committed region grows down and the guard page moves when the stack expands, with a 32-bit address space as an example (not drawn to scale): The Portable Executable (PE) structures of the executable image specify the amount of address space reserved and initially committed for a thread’s stack. The linker defaults to a reserve of 1MB and commit of one page (4K), but developers can override these values either by changing the PE values when they link their program or for an individual thread in a call to CreateThread. You can use a tool like Dumpbin that comes with Visual Studio to look at the settings for an executable. Here’s the Dumpbin output with the /headers option for the executable generated by a new Visual Studio project: Converting the numbers from hexadecimal, you can see the stack reserve size is 1MB and the initial commit is 4K and using the new Sysinternals VMMap tool to attach to this process and view its address space, you can clearly see a thread stack’s initial committed page, a guard page, and the rest of the reserved stack memory: Because each thread consumes part of a process’s address space, processes have a basic limit on the number of threads they can create that’s imposed by the size of their address space divided by the thread stack size. 32-bit Thread Limits Even if the thread had no code or data and the entire address space could be used for stacks, a 32-bit process with the default 2GB address space could create at most 2,048 threads. Here’s the output of the Testlimit tool running on 32-bit Windows with the –t switch (create threads) confirming that limit: Again, since part of the address space was already used by the code and initial heap, not all of the 2GB was available for thread stacks, thus the total threads created could not quite reach the theoretical limit of 2,048. I linked the Testlimit executable with the large address space-aware option, meaning that if it’s presented with more than 2GB of address space (for example on 32-bit systems booted with the /3GB or /USERVA Boot.ini option or its equivalent BCD option on Vista and later increaseuserva), it will use it. 32-bit processes are given 4GB of address space when they run on 64-bit Windows, so how many threads can the 32-bit Testlimit create when run on 64-bit Windows? Based on what we’ve covered so far, the answer should be roughly 4096 (4GB divided by 1MB), but the number is actually significantly smaller. Here’s 32-bit Testlimit running on 64-bit Windows XP: The reason for the discrepancy comes from the fact that when you run a 32-bit application on 64-bit Windows, it is actually a 64-bit process that executes 64-bit code on behalf of the 32-bit threads, and therefore there is a 64-bit thread stack and a 32-bit thread stack area reserved for each thread. The 64-bit stack has a reserve of 256K (except that on systems prior to Vista, the initial thread’s 64-bit stack is 1MB). Because every 32-bit thread begins its life in 64-bit mode and the stack space it uses when starting exceeds a page, you’ll typically see at least 16KB of the 64-bit stack committed. Here’s an example of a 32-bit thread’s 64-bit and 32-bit stacks (the one labeled “Wow64” is the 32-bit stack): 32-bit Testlimit was able to create 3,204 threads on 64-bit Windows, which given that each thread uses 1MB+256K of address space for stack (again, except the first on versions of Windows prior to Vista, which uses 1MB+1MB), is exactly what you’d expect. I got different results when I ran 32-bit Testlimit on 64-bit Windows 7, however: The difference between the Windows XP result and the Windows 7 result is caused by the more random nature of address space layout introduced in Windows Vista, Address Space Load Randomization (ASLR), that leads to some fragmentation. Randomization of DLL loading, thread stack and heap placement, helps defend against malware code injection. As you can see from this VMMap output, there’s 357MB of address space still available, but the largest free block is only 128K in size, which is smaller than the 1MB required for a 32-bit stack: As I mentioned, a developer can override the default stack reserve. One reason to do so is to avoid wasting address space when a thread’s stack usage will always be significantly less than the default 1MB. Testlimit sets the default stack reservation in its PE image to 64K and when you include the –n switch along with the –t switch, Testlimit creates threads with 64K stacks. Here’s the output on a 32-bit Windows XP system with 256MB RAM (I did this experiment on a small system to highlight this particular limit): Note the different error, which implies that address space isn’t the issue here. In fact, 64K stacks should allow for around 32,000 threads (2GB/64K = 32,768). What’s the limit that’s being hit in this case? A look at the likely candidates, including commit and pool, don’t give any clues, as they’re all below their limits: It’s only a look at additional memory information in the kernel debugger that reveals the threshold that’s being hit, resident available memory, which has been exhausted: Resident available memory is the physical memory that can be assigned to data or code that must be kept in RAM. Nonpaged pool and nonpaged drivers count against it, for example, as does memory that’s locked in RAM for device I/O operations. Every thread has both a user-mode stack, which is what I’ve been talking about, but they also have a kernel-mode stack that’s used when they run in kernel mode, for example while executing system calls. When a thread is active its kernel stack is locked in memory so that the thread can execute code in the kernel that can’t page fault. A basic kernel stack is 12K on 32-bit Windows and 24K on 64-bit Windows. 14,225 threads require about 170MB of resident available memory, which corresponds to exactly how much is free on this system when Testlimit isn’t running: Once the resident available memory limit is hit, many basic operations begin failing. For example, here’s the error I got when I double-clicked on the desktop’s Internet Explorer shortcut: As expected, when run on 64-bit Windows with 256MB of RAM, Testlimit is only able to create 6,600 threads – roughly half what it created on 32-bit Windows with 256MB RAM - before running out of resident available memory: The reason I said “basic” kernel stack earlier is that a thread that executes graphics or windowing functions gets a “large” stack when it executes the first call that’s 20K on 32-bit Windows and 48K on 64-bit Windows. Testlimit’s threads don’t call any such APIs, so they have basic kernel stacks. 64-bit Thread Limits Like 32-bit threads, 64-bit threads also have a default of 1MB reserved for stack, but 64-bit processes have a much larger user-mode address space (8TB), so address space shouldn’t be an issue when it comes to creating large numbers of threads. Resident available memory is obviously still a potential limiter, though. The 64-bit version of Testlimit (Testlimit64.exe) was able to create around 6,600 threads with and without the –n switch on the 256MB 64-bit Windows XP system, the same number that the 32-bit version created, because it also hit the resident available memory limit. However, on a system with 2GB of RAM, Testlimit64 was able to create only 55,000 threads, far below the number it should have been able to if resident available memory was the limiter (2GB/24K = 89,000): In this case, it’s the initial thread stack commit that causes the system to run out of virtual memory and the “paging file is too small” error. Once the commit level reached the size of RAM, the rate of thread creation slowed to a crawl because the system started thrashing, paging out stacks of threads created earlier to make room for the stacks of new threads, and the paging file had to expand. The results are the same when the –n switch is specified, because the threads have the same initial stack commitment. Process Limits The number of processes that Windows supports obviously must be less than the number of threads, since each process has one thread and a process itself causes additional resource usage. 32-bit Testlimit running on a 2GB 64-bit Windows XP system created about 8,400 processes: A look in the kernel debugger shows that it hit the resident available memory limit: If the only cost of a process with respect to resident available memory was the kernel-mode thread stack, Testlimit would have been able to create far more than 8,400 threads on a 2GB system. The amount of resident available memory on this system when Testlimit isn’t running is 1.9GB: Dividing the amount of resident memory Testlimit used (1.9GB) by the number of processes it created (8,400) yields 230K of resident memory per process. Since a 64-bit kernel stack is 24K, that leaves about 206K unaccounted for. Where’s the rest of the cost coming from? When a process is created, Windows reserves enough physical memory to accommodate the process’s minimum working set size. This acts as a guarantee to the process that no matter what, there will enough physical memory available to hold enough data to satisfy its minimum working set. The default working set size happens to be 200KB, a fact that’s evident when you add the Minimum Working Set column to Process Explorer’s display: The remaining roughly 6K is resident available memory charged for additional non-pageable memory allocated to represent a process. A process on 32-bit Windows will use slightly less resident memory because its kernel-mode thread stack is smaller. As they can for user-mode thread stacks, processes can override their default working set size with the SetProcessWorkingSetSize function. Testlimit supports a –n switch, that when combined with –p, causes child processes of the main Testlimit process to set their working set to the minimum possible, which is 80K. Because the child processes must run to shrink their working sets, Testlimit sleeps after it can’t create any more processes and then tries again to give its children a chance to execute. Testlimit executed with the –n switch on a Windows 7 system with 4GB of RAM hit a limit other than resident available memory: the system commit limit: Here you can see the kernel debugger reporting not only that the system commit limit had been hit, but that there have been thousands of memory allocation failures, both virtual and paged pool allocations, following the exhaustion of the commit limit (the system commit limit was actually hit several times as the paging file was filled and then grown to raise the limit): The baseline commitment before Testlimit ran was about 1.5GB, so the threads had consumed about 8GB of committed memory. Each process therefore consumed roughly 8GB/6,600, or 1.2MB. The output of the kernel debugger’s !vm command, which shows the private memory allocated by each active process, confirms that calculation: The initial thread stack commitment, described earlier, has a negligible impact with the rest coming from the memory required for the process address space data structures, page table entries, the handle table, process and thread objects, and private data the process creates when it initializes. How Many Threads and Processes are Enough? So the answer to the questions, “how many threads does Windows support?” and “how many processes can you run concurrently on Windows?” depends. In addition to the nuances of the way that the threads specify their stack sizes and processes specify their minimum working sets, the two major factors that determine the answer on any particular system include the amount of physical memory and the system commit limit. In any case, applications that create enough threads or processes to get anywhere near these limits should rethink their design, as there are almost always alternate ways to accomplish the same goals with a reasonable number. For instance, the general goal for a scalable application is to keep the number of threads running equal to the number of CPUs (with NUMA changing this to consider CPUs per node) and one way to achieve that is to switch from using synchronous I/O to using asynchronous I/O and rely on I/O completion ports to help match the number of running threads to the number of CPUs.

CyberWolf08: Iei un tutorial in engleza, care iti place tie si ti se pare interesant, il traduci si il postezi. Nu e chiar atat de greu. Ideea e sa fie mai multi membri care sa contribuie, care sa ajute comunitatea. Si daca nu fac asta din placere, e degeaba... Uitati cum fac eu de cateva zile: Am gasit cateva site-uri interesante, si ce gasesc interesant pe ele, postez si aici. E un inceput. O sa mai scriu cate un articol, vedeti voi

Nu inteleg de ce va complicati. Nu stiti SQL, nu veti sti niciodata SQL Injection. Invatat SQL (orice, MySQL, Postgre, Oracle...), apoi va apucati de SQL Injection.

Backdoor.Win32.UltimateDefender.gtz - Reversing In this paper (Backdoor.Win32.UltimateDefender.gtz - Reversing) we analyze install.exe that presents the typical structure of an Medium Evoluted Malware, with basical Obfuscated-Dummy Code, some layer of Encryption decoded at Runtime and Custom Hash Functions used as Integrity Check. We can also see an intersting technique that retrieves API's Addresses OnDemand through a series of hardcoded values that corresponds to some API, the correspondent API Address is computated at runtime and chosen in function of the Hardcoded Value. Download: http://rootkitanalytics.com/papers/pdf/Backdoor-UltimateDefender.pdf

Kernelland Rootkits Kernel rootkits are the tools that run in the kernel, hence making it really hard to detect. The entire operating system would be altered in the process, which would help in the process of hiding the fact that the system is compromised. Kernel rootkits are of the most malicious nature -- they completely undermine a systems integrity and capacity for self-diagnosis. Essentially any tool that could be used for detecting such a rootkit is susceptible to false results due to syscall hijacking. Some tools however does not have to run in memory of the target system itself may benefit from running on a remote machine to avoid certain syscalls (i.e over NFS) -- this can be explained in more detail sometime. There are a many ways to subvert. Here are some of them: -- Directly modifying the syscall table -- Syscall jump -- IDT -- IA32 Debug Kernel - Working To understand the working of kernel rootkit, it is important to understand how a kernel works. Though we talk a lot more about Linux related samples at most cases, all kernels behave the same way. Kernel is a mediator between user apps and the hardware. Hence, kernel should interact/talk-to both the user-mode apps and the hardware. To do this in a secure way, operating systems has ensured that all processes communicate with the kernel through system libraries and the system libraries sends system calls to the kernel mode, which reaches the system call table. The system call table then interacts with the text or data segment of the kernel depending on the nature of Syscall or the function to be performed. Once that is processed in the kernel, the kernel then interacts with the hardware accordingly. The following figure shows a simple interaction diagram: Kernel Rootkit - Ring Terminology In the ring terminology, kernel rootkits run on ring0. Since, ring0 is under all the other layers, monitoring kernel rootkits is almost impossible if the monitoring software is run on the same system, except for certain detection techniques that compares the different states or interacts with kernel using different stimulus signals and compares the response. Though once again, since the kernel rootkit modifies the entire operating system properties, functions and anything and everything possible to deceive a user from noticing the compromise by completely hiding itself, detection is quite hard in case of kernelland rootkits. As said in the ring terminology section, ring0 has the highest privilege and ring3 has the least privilege. Most anti-rootkit tools that are created to detect kernel rootkits, really do not do the stuff that they were created for if the kernel rootkit does its job as it was meant to. Kernel Modification Techniques Kernelland rootkits are known for overwriting the entire operating system. They do this by modifying the kernel. Loadable Kernel Module [LKM] is used to expand the kernel for adding new hardware or Filesystem without a system reboot. LKM is used only when required and when they are used, they run in the memory and when done they are removed. In this process, an attacker/rootkit can run the infected process that would load the EVIL_LKM to modify the kernel. LKM runs in ring0 of the system as it is running on the kernel itself, which means that it is running on the highest privilege. To do this, the EVIL_PROCESS loads the EVIL_LKM. There are several ways to do this and there are several things that can be done once this is done. Syscall hijack is one way that we talk about in our other paper and also the Syscall modification too. Once this is loaded, the rootkits can alter the Syscall to EVIL_SYSCALL or intercept the good Syscall with EVIL_FUNCTION, depending on the technique that the rootkit chooses to use. Once this is done, the kernel access is obtained by running the code that the rootkit tries to access in the Text segment. Another way to subvert the kernel is to alter kernel memory. /dev/kmem is used for mapping the kernel memory at run-time in Linux. In Windows systems, Hence to change the kernel at runtime, direct memory I/O could alter kmem. Even though there are patches to protect kmem, there are other ways to override the patches for the rootkits to do what they were meant to. Directly modifying the Syscall table The syscall table is generally an array of function pointers; these function pointers can be redirected to point to functions implemented in the rootkit, often times an LKM. This type of kernel rootkit is easy to detect compared to other kernel rootkits. A hands on approach is to analyze /proc/kcore with gdb and verify the syscalls against the System.map file (A file created at kernel compilation time for debugging purposes). A simpler approach is to run a tool like ktraq, which also has the benefit of disabling this type of rootkit by resetting the syscall function pointers. Syscall jump This is a more stealth method of syscall hijacking without having to directly modify the syscall table; instead the first 7 bytes of the syscall are overwritten with a jump to the new code -- i.e "movl $0x0, %eax; jmp *%eax". Keep in mind the original 7 bytes are saved and copied back into the original syscall so that it may be called within the evil syscall. This type of syscall hijacking cannot be detected by tools like ktraq, however a tool like ElfStat which analyzes the text segment of the running kernel and compares it to vmlinux can detect this method. This method is also used in kernel function hijacking (Not only syscalls). Sursa: Kernelland - Linux kernel rootkit - RootkitAnalytics.com

About RemoteDLL RemoteDLL is the tool which makes it easy to inject the DLL or free the DLL from remote process. This tool is based on popular DLL Injection technique which has already been used in many top programs such as pwdump. Many spyware programs uses this technique to hide their presence. Many of these comes as DLL and injects themselves to legitimate windows process and operates from that process so that normal user will not suspect its presence. Using RemoteDLL you can easily remove such DLL from the process and then delete it from the system completely. How RemoteDLL works? This tool is entirely based upon the DLL Injection concept. In short DLL Injection uses CreateRemoteThread API to invoke LoadLibrary or FreeLibrary on remote process. Here is a very good article which explains this technique in detail. I suggest you to read that article to better understand working of RemoteDLL. Injecting the DLL into Remote Process Below are the steps for injecting the DLL into another process using RemoteDLL. * Select the "Load DLL" option. * Now select the process to which you want to inject the DLL. * Next specify the the DLL and press the "Load DLL" button * The specified DLL will be injected into the target process and the result of entire operation will be displayed in status window. Removing the DLL from Remote Process Follow the below mentioned steps to remove DLL from any process using RemoteDLL. Note that removing DLL from process may crash it or destabilize the entire system. So make sure you know what you are doing before using it. * Select the "Free DLL" option from the main screen. * Next select the process from which you want to remove the DLL. * Now select the DLL to be removed from the process using DLL selection dialog. It displays following information about each DLL o DLL Name o Base Address o Entry Point of DLL o Size of the DLL in memory o Load count or Reference Count of DLL o Static or dynamically loaded * Next press the "Free DLL" button to remove the DLL from process. Result will be displayed step by step in the status window. Note that only dynamically loaded DLLs can be removed from the process. Reference count : Unique feature of RemoteDLL Reference count or load count indicates how many times the DLL is loaded into the process. Each time the DLL is loaded , process increases that DLL's reference count. So when you want to remove the DLL from the process, you have to invoke the FreeLibrary function that many times to completely free it. Reference count is the unique feature of RemoteDLL which is not present in any other similar tools. This is because there is no direct way or API function to get this information. Reference count for the DLL is stored in the PEB (Process Environment Block) for that process. PEB contains the linked list of DLL Module Structure which contain complete information about that particular DLL. One can retrieve the PEB data of remote process by using ReadProcessMemory() API. For detailed information on finding reference count read the detailed article here. Download: http://securityxploded.com/getfile.php?id=7111

About ProcHeapViewer This is the tool to enumerate process heaps on windows. It uses much better technique than slower Windows heap API functions which makes it faster and efficient. You can enumerate the heaps from normal Windows processes as well as system services. Its very useful tool for anyone involved in analyzing process heaps. Vulnerability researchers can use it as a side tool for discovering heap related vulnerabilities. The new version provides support for Windows 7. It also presents the enhanced user interface with cool look & feel. Making of ProcHeapViewer Some time back I was doing password strength related research on Yahoo Messenger. It used to store the password on the heap and I wrote an sample tool using normal heap functions to locate and retrieve the password. The password was basically located on one of the heap block which was near the end of 60,000th block. So I had to traverse all the 60,000 heap blocks using Heap32Next function and it took more than 10 minutes..! I tried running the program on multiple machines but it took almost same amount of time. I was getting irritated as I had to wait for so long every time I run my program. To find a way around this timing problem, I tried looking on the internet for answers but found nothing. Then I finally resort to finding the truth myself and started reverse engineering the Windows heap functions. Finally after few hours of work, I found the reason behind the delay and wrote my own implementation which took little more than few seconds. For the complete story behind the creation of ProcHeapViewer, read the detailed article here. Download: http://securityxploded.com/getfile.php?id=7211

About WinSniff WinSniff is the basic network packets sniffer for Windows developed using Winpcap library. It displays all the packets that are transmitted on the local network and gives detailed information about each header in the packet. In order to keep it simple, I am not dealing with application level protocols. If you are interested, you can add features to support various application level protocols such as SMTP, FTP, NETBIOS etc. Working of WinSniff When your machine is on the network, packets with different destinations arrive. By default (i.e., when the network adapter is in normal mode) these packets are rejected by the network adapter since they are intended to different hosts. But if you want, you can receive these packets by putting the network adapter in promiscuous mode. In this mode, it will accept all the packets irrespective of the destination address. Hence you can analyze the packets transmitted on your network. This trick is used for network management to determine the network traffic... etc. However, there is one problem here...!!! You will receive the packets with different destinations if you are using HUB. Since, HUB uses broadcasting technique for transmitting packets to all the hosts attached to it. However, if you are using SWITCH (an intelligent device), then you won't receive any packet sent to other hosts on the network. Best place to install this application is on the gateway where you can keep track of incoming and outgoing packets Implementation This part is meant for developers who are interested in coding their own sniffer. You may wants read to understand the internals of WinSniff. To start with, first step is to find out the right network interface and and then open it in promiscuous mode. While opening the device, you can also specify the size of the packet and time out value. //Get all devices for capturing the packet pcap_findalldevs(&devlist,err); //Open device in promiscous mode hdev=pcap_open_live( devname[index], //name of the device 65536, //size ->Capture whole packet 1, //promiscous mode 1000, //read timeout err ); Once you have opened the device, you will receive all packets. If you are interested in a particular packet, for example, only QUAKE packets (port 27960), ARP packets (ARP) etc., then you can specify the filter expression. For more details on filter expression, you can refer WinPcap documentation. // compile the filter pcap_compile(hdev,&fcode,filter,1,netmask); // now set the filter pcap_setfilter(hdev,&fcode); Once you have opened the device and set the filter, now you are ready to receive the packets. Once the packet is received, header contains the length, time and other information about the packet. Structure pkt_data contains the exact contents of the packet starting from Ethernet header. while(true) { pcap_next_ex(hdev,&header,&pkt_data); /* play with the captured packet */ } In order to analyze the packet contents, you must be familiar with various header formats. Mainly, you must know the format of the following headers... ETHERNET, ARP, IP, TCP, UDP, ICMP and IGMP. I have included the file 'protocol.h' which contains the format information about all these headers. If you want more details, you can refer RFCs for respective protocols. Once you have done the job, it's time to safely close the device. //close the device... pcap_close(hdev); Requirements 1) Developers can find all the header files and libraries in 'Winpcap developer pack' 3.0 or higher version. Don't forget to specify the include and lib files within the project settings. 2) Before running this application you need to install Winpcap version 3.0 or higher. Download: http://securityxploded.com/getfile.php?id=9121 Source code: http://securityxploded.com/getfile.php?id=9155

AdvancedWinServiceManager About AdvancedWinServiceManager 'Windows Service' is a program designed to perform specific service which is started automatically when Windows boots and runs as long as System is up and running. Services normally run with 'System' privilege thus enabling them to execute higher privilege operations which otherwise cannot be performed by normal processes. Due to these advantages, often malware applications use services to monitor and control the target system. In this direction, AdvancedWinServiceManager makes it easy to eliminate such malicious services by separating out third party services from Windows services. By default it shows only third party services along with more details such as Company Name, Description, Install Date, File Path etc at one place which helps in quickly differentiating between legitimate and malicious services. It comes with rich features such as detecting hidden rootkit services, exporting the service list to html based log file, displaying only third party services etc. All these unique things make it stand apart when compared to 'Windows Service Management Console'. Features of AdvancedWinServiceManager Here is the complete feature list of AdvancedWinServiceManager * Detection of hidden Rootkit services It can detect the services hidden by malicious Rootkit applications using bypass hook method. Such hidden services will be shown in red color to differentiate it from normal services. * Enhanced user interface with dynamic resize functionality. It comes with really cool GUI interface with catchy banner. Also it has dynamic resizing capability which makes it to adjust the screen according to the user needs. * Arrange the services based on various parameters It comes with sorting functionality to arrange the services based on service name, description, status, user account, company name, binary path, file size etc. This helps in quick searching of the service. * Easier detection of malicious service By default only third party services are displayed along with detailed information which makes it easy to differentiate between legitimate and malicious services. * Export the services list to standard html format 'Export to File' option provides easy way to save the displayed service list to html based log file for offline analysis. * Show services based on status and vendor. User can view the services based on its status. For example one can view only third party services or all running services. * Smooth and quick management of services It provides option to start, stop, enable or disable services with just a click. * Displays detailed information for each service For each service following information is shown, o Service Name o Description o Company Name o Service Status o User account o File version o File Size o Install Date o Full Binary Path Download: http://securityxploded.com/getfile.php?id=8275