flynn017

Windows needs to ensure that untrusted code and untrusted users aren't accessing important areas of the operating system, and creating problems which would ultimately lead to a vast number of BSODs. Windows manages this through Access Tokens which are used to identify the security context of a process/thread and a user. Access Tokens take two main forms: a Primary access token and a Impersonation access token. The Access Token additionally has two important features which are integral to security validation: SIDs (Security Identifiers) and a Privilege Array which contains the privileges allowed for that object. The token type can be found within a enumeration called TOKEN_TYPE.   The data structure can be found under the TokenType field within the _TOKEN structure. The Primary type determines the security context of the process for the currently logged on user, and the Impersonation type allows a thread to temporarily use a different security context. The Token type can also ...

From Windows Vista onwards, Microsoft has placed a substantially greater focus on the security of the operating system, which is one of the areas most users will neglect and then later come to complain about. In this article I'm going to talk about Windows Integrity Levels, and how we can view this information in WinDbg and through some SysInternals Tools. In another article, I will going into more depth about access tokens and how they are used to increase system security. These security measures were introduced since it was relatively easy to modify memory and remove any security identification, thus leads to code modification and injection being used to allow illegitimate access to important system data structures etc. User-Mode processes often require the use of system services and system resources which reside within the Kernel-Mode. To stop any illegitimate access or any poor programming from creating havoc in Kernel-Mode, some security validation procedures have been introd...

I may have created a small list of tools before, however, I would like to expand this list and provide some better descriptions for each of the tools listed. These tools are either completely free or have a limited free version which provides enough functionality for those like myself, who aren't professional security researchers, escalation engineers or get paid for doing reverse engineering/debugging. These tools can and are used by professionals and enthusiasts alike. If you have any recommendations then please add a link to the comments section. WinDbg - Reverse Engineering/Debugging This tool is my most favorite, it provides complete functionality for enthusiasts and is for free. There is a wide range of extension and commands for viewing data structures, memory addresses and call stacks. It can be used for both reverse engineering and debugging BSODs (Blue Screens of Death). There is good documentation for WinDbg for finding hidden rootkits, examining data structures and loo...

Malicious Software is able to detect if it's running within a debugging environment or a debugger has been attached to the process, and thus will not generate of it's malicious behaviors in order to avoid detection from the security analyst or whoever is attempting to debug the process. In this article, I'm going to describe some of the common anti-debugging techniques which are used to detect the presence of a debugger.   NtGlobalFlag: The NtGlobalFlag is located within the Process Environment Block (PEB) at offset 0x68 on x86 Windows, and at offset 0xBC on x64 Windows. Windows 7 SP1 x86 The default value is always 0, and doesn't change when a debugger is attached to the process. There are several methods in which the NtGlobalFlag can be changed to detect the presence of a debugger. The NtGlobalFlag contains many flags which affect the running of a process. The most common flags which are set with NtGlobalFlag when a debugger creates a process, is the heap checking fl...