Abstract Application whitelisting and blacklisting is an interesting topic because depending on how it has been configured this can drastically increase the difficulty of an attacker to gain initial code execution. With Windows XP and Windows Server 2013, Microsoft released Software Restriction Policy (SRP), which was a great idea but a massive pain to configure with little to no flexibility. This is where AppLocker is coming into play, this is the successor of SRP. AppLocker has been introduced in Windows 10, originally only for Enterprise and Education versions. AppLocker offers a lot of flexibility because the allow/deny rules are set to a SID and therefore can be applied to any security principal (i.e. user, groups). AppLocker has also multiple rule types, which are as follows: Executable rules, for executable files (e.g. C:\Windows\System32\cmd.exe ); Windows Installer rules, for installation files (e.g. C:\Users\Public\myinstaller.msi ); Script rules, for Windows Script H

Abstract Over the past few months I've been using Cobalt Strike (CS) quite extensively, both during Simulated Attack engagements and for R&D and offensive security projects. I subsequently used more than what I expected the famous Aggressor script engine. Throughout the different versions of CS, Raphael Mudge developed multiple features that allow operators to extend the standard capabilities of CS: C2 malleable profile, to modify the behaviours of the implant (e.g. SMB name pipe, HTTP/S URI, process spawned for shellcode injection, etc...); Aggressor Scripts to modify the CS client (e.g. adding new beacon commands, creating new popups, handling events, etc ...); and More recently, beacon object files to execute non-linked C code within a running beacon. The aim of this small post is not to explain how all these amazing features works, even if this would be super interesting. Instead, I will discuss how I managed to l

Abstract I used to be a Java/PHP/PolymerJS developer for 2 years before joining the wonderful information security industry and developing in C/C++ and C#. I'm probably not a great programmer but a least I'm documenting my code! Trust me, well documented code will save your butt. I have subscribed to a professional GitHub account few weeks back, which gave me access to the 3000 minutes of GitHub Actions per months. GitHub Action is awesome because this allow developers to create custom software development life cycle (SDLC) workflows, directly from GitHub. For each workflow you can define custom jobs and tasks. My plan was to use GitHub Actions to automatically generate and deploy Doxygen documentation when I push code to a master branch. In our case we will have one job with two tasks. To archive that, I am using the following GitHub Actions: mattnotmitt/doxygen-action@v1.1.0; and peaceiris/actions-gh-pages@v3 First one will be used to generate the HTML documentati

0x00 Abstract Allowing direct access to named or un-named executive objects to user mode and kernel mode applications would be extremely dangerous as it would interfere with, and render the duty of the executive subsystems obsolete. As a result, this would put the whole system at risk and make the management of executive objects almost impossible. Additionally, executive objects resides in kernel memory, which means that if user mode applications could directly modify data structure in kernel memory this would also be extremely dangerous and chances of a BSOD would be high. Driver and kernel applications can obviously directly access these data structures, however, most of the objects are undocumented and therefore it is highly recommended not to do so. Instead drivers and kernel applications should (must) use kernel APIs exposed by the different executive subsystems. Finally, they should also increase (i.e. ObfReferenceObject ) or decrease (i.e. ObfDereferenceObject ) the executiv

I know that I know nothing - ipse se nihil scire id unum sciat - ἓν οἶδα ὅτι οὐδὲν οἶδα - Socrates Life is nothing more than an endless wandering, it would be foolish if not childish to think we know everything, at any point in life. Embrace the constant unknown and be skeptical to sate a untarisable desire of knowledge.

0x00 Abstract Almost all the actions carried out by user mode applications and Windows executive subsystems (e.g. I/O Manager, Memory Manager) have to deal with Windows resources (aka objects). These actions can be related to physical objects like devices or logical objects such as processes, threads, tokens and files. For this specific reason, the Object Manager, which is a executive subsystem, is responsible for providing a standardised, uniform and singular way to manage, create, release and access objects. Among other things, this ensures that other user mode applications and executive subsystems do not re-invent the wheel when they are interacting with objects, which might cause duplication of code and logic, resulting in security issues and logical errors. Even if everything related to objects has to go through the Object Manager, defining Windows as an object oriented operating system would be an overstatement as many kernel structures are not objects. Additionally, the Objec