Year: 2017

Don’t Forget about Domain Trusts

I recently was talking to an organization about their security posture and mostly everything I recommended to them, they had already implemented and plus some. The audits I conducted for them seconded what they were saying. I must say, I was thoroughly impressed. There was, however, one gray area that stood out to me and that was Domain Trusts. In their eyes, they didn’t have any but the Domain Controller displayed otherwise.

I’m sure everyone knows how to check via the GUI but did you also know it can be done through PowerShell? If not, let’s proceed.

From within a Domain Controller of a system with Remote System Administration Tools (RSAT) installed, we can utilize the Active Directory module which contains the Get-AdTrust cmdlet. For us to view Trusts, we can do the following:

From the above, we see the trust is with the Multiverse domain. We can also see that the direction is bi-directional, meaning it is a Two-Way Trust. It is also non-transitive, noted by the numerical one listed in the Trust Attributes property.

We can also get this same information using WMI, which we will use on the same server. To do so, we can do the following:

A simple script for this can be found at HERE.

From the above, we see the Trust Attributes property again along with a Trusted Domain property, which depicts the name of the domain we have a trust with. In addition, we see the Trust Direction property with a value of three, which depicts two-way.

For future reference, the meanings for each available value in Trusted Attributes and Trusted Direction are below.

Hidden Gems in McAfee ePO Audit Logs

There is no shortage of organizations these days running McAfee’s ePolicy Orchestrator in an effort to combat maliciousness. Much like any endpoint security platform, it has its strengths and weaknesses. One of the great features of the application is that it contains an audit log containing authentication information to include any supplied usernames, as shown below.

As weird as it may seem, sometimes people will type in their username AND their password on the same line and submit them for authentication, not realizing the mistake. Well, McAfee ePO logs that information as is. In the example below, the password is likely ‘PA$$word1337’.

This happens more often than what you may think and users with the applicable permissions can see this information in the audit logs. From a blue team perspective, being cognizant of the likelihood of this artifact is vital. As a red team member, this is easy pickings. Not only will it likely get you into the application with the user’s information in the logs but that user could also have more rights than the user you may be currently using. Also, whatever the password is for the user whose information is in the log, it is also likely to be that user’s password to their local or domain account or possibly to other applications in the network.

Finding Reflective DLL Injections

DLL injections that originate from a malicious DLL written to a disk are commonly detected by any decent AV product. Detecting reflective DLL injection, however, are not as straightforward. Malware injected directly into a process using reflective DLL injection typically will not exist on disk. A co-worker of mine developed a tool called Evil Injection Finder (EIF), which is designed to help you find those evil injections! Administrative rights are currently necessary to adequately examine the memory of running processes. Some memory pages will be unreadable if marked as protected processes by the OS, such as LSASS.

The example below demonstrates using EIF with a signature file to find injects in all processes on the system. A meterpreter has been loaded into MicrosoftEdge using reflective injection.

I wanted to run EIF on remote systems but it didn’t have that capability so I developed EIF_Parser, which provides the following capabilities:

  • Executes Evil Inject Finder (EIF) on a remote system or systems
  • Retrieves the data gathered by EIF on remote systems
  • On the local system, presents only the processes with ‘yes’ in the MZ or DOS column
  • Logs systems not accessible, for one reason or another

The tools can be found at the below links:

Hunting Self-signed Certificates

Self-signed certificates could be indicative of malicious behavior on a system and being able to identify them is a key task in responding to an incident. Having self-signed certificates in an environment isn’t always a bad thing but not being able to identify them and their purpose is! Nonetheless, taking to PowerShell we can search for them and there is a Certificate PSDrive that will assist with our process. A key indication of self-signed certificates is the issuer and subject being the same. It is also worth noting that a CA may issue a certificate to itself to support key rollover or changes in certificate policies.

This and more PowerShell scripts can be found on my GitHub.

Hashes of All Running Processes

A great starting point for anyone analyzing a system is the running processes. Taking the time to not only retrieve the command line execution of the process but also the parent process will enable you to find outliers. Taking it a step further, retrieving the hashes of the binary of each process expand your aperture substantially. Especially when you are able to group and stack those hashes against those from other machines. With that in mind, I’ve written a simple little script that will get the hashes of all running processes.

Link to code:

PowerShell Cheat Sheet

I recall when I started out in PowerShell coming from Python. Some aspects of the language I was able to pick up on rather quickly while other aspects took some take. I found myself writing down notes until I was able to remember them on my own. Reminiscing on that inspired me to develop a cheat sheet for others who are aspiring to make the jump. The cheat sheet is not an all incompassing list but it touches on most of the important areas of the language to get a person started.

PS Cheat Sheet

Find Malicious Versions of CCleaner

In light of the recent discovery about the malicious versions of CCleaner and the millions affected, it felt like a great time to write some PowerShell scripts that enable a person to identify if the malicious versions of CCleaner are on a system and if so, provides a method to delete the software.

The below checks a local machine for the malicious versions of CCleaner.

Using PS Remoting, the below allows you to get a list of systems with the infected versions.

Using PS Remoting, the below allows you to remove CCleaner with the infected versions.

Using WMI, the below allows you to look for the infected versions. It also writes a log of infected and not infected machines along with deleting the software from the infected machines.



Determining WinRM connections to a Machine

PSRemoting is an awesome feature in Microsoft Windows that serves as a ssh-like function. In Server 2012 and newer, it is enabled by default. You will, however, need to enable the feature on any client system you’d want to use it on. Some organizations feel having the service enabled throughout their organization is more of the burden than something that will increase productivity. Most of those of thoughts stem from not knowing who and is connecting or connected to systems. Luckily, there is a built-in cmdlet to should ease the worrying.

With suitable rights on a system, we can use the below to see who is connected to our system.

Below are the results.

To clean this up a little, we can do the following:

Our results are shown below and are a little easier to understand.

You could easily setup this up on some reoccurring schedule and output it to a file for further analysis.

Base64 with PowerShell

All too often I find myself on a Windows system and need to either encode or decode base64. Rather than using an online service, installing a program, or going to a *nix based system, I took to PowerShell. In PowerShell, we can use .NET to accomplish this.


The result is this base64 encoded text:



Getting hashes with Microsoft’s File Checksum Integrity Verifier (FCIV)

Are you responding to an incident? Are you trying to hash particular portions of the disk for comparison with a known good hashes? Are you questioning whether or not to trust the binaries on the possibly compromised system disk in order to get said hashes? Well have no fear, Microsoft has a portable program called File Checksum Integrity Verifier (FCIV) that can help and it can be downloaded here. Since it comes from Microsoft, it will by signed by them as well.

The portable program can be executed from a CD\DVD, flash drive, or network share. With it, we can get MD5 and\or SHA1 hashes files on a system by either printing them to screen or outputting them to another file or database. With this in mind, we can feel better about our capture source and method and easily save the day! We can accomplish this using the below.

Recursively capturing hashes from a specified directory.


Get Registry Hives and Keys Remotely

Talking with a buddy of mine, the conversation about retrieving Registry Hives and Keys remotely came up. He initially was looking for something he could use and eventually sided with an open-source program on the web. I, myself, tested said program as well and it for the most part did what it said it would. In the end though, that is just another product I could be adding to someone’s network. With that said, I took to PowerShell! Which I ended up using reg.exe wrapped in PowerShell to export to Hives and Keys. I now needed something as the workhorse to execute this remotely and that’s where WMI came in. I used it to start a process-call against a supplied list of systems and once complete, Get-ChildItem is used to pull the .reg file back to my system. The code can be found HERE.

Finding Passwords in Text Files with PowerShell

Using PowerShell, we can look in text files for strings that fit the criteria for passwords and return the potential password, file path, and line number. The criteria that is being search uses regex expressions and looks for at least four characters but no more than 15 with at least one character being upper, lower, a number, and a special character. The data is returned in a xml file and is best read back into PowerShell using out-gridview (my fav.). The code is on my GitHub located HERE.

Mass Import of McAfee Firewall Domains to block

As of late, I’ve been experimenting more and more with the McAfee HIPS Firewall with the McAfee ePO. So far, I think it is decent. It is at least stateful, so that’s a plus. The firewall has a feature to block domains and using the GUI, you can only add them one at a time. There is an option to import them but that would require us to have it in a readable format the McAfee could understand. Thinking outside the box, I decided to put an entry in the firewall and export that policy in order to get a feel for the structure. Once I did that, I was able to take a list of domains from, change some formatting in their file, and fit it into the McAfee format. The result is a perfectly formatted firewall policy ready to import. The workhorse of it all, PowerShell!

In my testing from testing with, I imported over 14000 entries and while McAfee HIPS took it, I don’t think it can handle that much as the server became incredibly slow. Nonetheless, you could now take my script, make some minor adjustments and use it with your malware domain listing of choice. Since we are on the subject, below are a few other sites that are good sources as well.

The code, by the way, is on my github at

Sinkhole Domains Using DNS with the help of PowerShell

Thanks to Jason Fossen, there was no need to create a PowerShell script to input domains to sink. He had already created one called Sinkhole-DNS.ps1 (located here). One of the options in the script is to read in a file with domains listed. I like to frequent for my listing of bad domains and wanted to use that to feed it into the PowerShell script so I fired up ISE and begin knocking out some code. In the end, I developed a script located here that will download from, uncompress it and take only the domain names out, and output them to a file. The file can then be used with the Sinkhole-DNS.ps1 script to import the domains into DNS. The syntax for this is shown below.