Lateral Movement - Phreaknik 2016

Editor's Notes

• #4: Reconnaissance – Learning about the target using many techniques. Weaponization – Combining your vector of attack with a malicious payload. Delivery – Actually transmitting the payload via some communications vector. Exploitation – Taking advantage of some software or human weakness to get your payload to run. Installation – The payload establishes persistence of an individual host. Command & Control (C2) – The malware calls home, providing attacker control. Actions on Objectives – The bad actor steals or does whatever he was planning on doing.
• #7: Passive Information Gathering: Passive Information Gathering is generally only useful if there is a very clear requirement that the information gathering activities never be detected by the target. This type of profiling is technically difficult to perform as we are never sending any traffic to the target organization neither from one of our hosts or “anonymous” hosts or services across the Internet. This means we can only use and gather archived or stored information. As such this information can be out of date or incorrect as we are limited to results gathered from a third party.  Semi-passive Information Gathering: The goal for semi-passive information gathering is to profile the target with methods that would appear like normal Internet traffic and behavior. We query only the published name servers for information, we aren’t performing in-depth reverse lookups or brute force DNS requests, we aren’t searching for “unpublished” servers or directories. We aren’t running network level portscans or crawlers and we are only looking at metadata in published documents and files; not actively seeking hidden content. The key here is not to draw attention to our activities. Post mortem the target may be able to go back and discover the reconnaissance activities but they shouldn’t be able to attribute the activity back to anyone.  Active Information Gathering: Active information gathering should be detected by the target and suspicious or malicious behavior. During this stage we are actively mapping network infrastructure (think full port scans nmap –p1-65535), actively enumerating and/or vulnerability scanning the open services, we are actively searching for unpublished directories, files, and servers. Most of this activity falls into your typically “reconnaissance” or “scanning” activities for your standard pentest.
• #8: Note that the value in %USERDOMAIN% may not be the same as the one returned by systeminfo command. %USERDOMAIN% gives the domain name the user account belongs to, it could be different from the domain of the computer. Also, this may give you the NetBios name of the computer, not DNS/FQDN name.
• #11: When the box you compromise is connected to a domain it is well worth looking for the Groups.xml file which is stored in SYSVOL. Any authenticated user will have read access to this file. The password in the xml file is "obscured" from the casual user by encrypting it with AES, I say obscured because the static key is published on the msdn website allowing for easy decryption of the stored value. The next thing we will look for is a strange registry setting "AlwaysInstallElevated", if this setting is enabled it allows users of any privilege level to install *.msi files as NT AUTHORITY\SYSTEM. It seems like a strange idea to me that you would create low privilege users (to restrict their use of the OS) but give them the ability to install programs as SYSTEM. 
• #12: Metasplot can be used to
• #16: Script block logging – logs the PowerShell code actually executed by PowerShell. Without this enabled, obfuscated code is logged, making it far more difficult to create useful indicators. System-wide transcripts – When enabled, a transcript file can be written to a write-only share for each PowerShell user per computer. If the share is offline, the computer will cache the file data until it’s back online.Constrained PowerShell enforced with AppLocker – When PowerShell v5 installed and AppLocker in Allow mode, PowerShell operates in constrained language mode which is a limited language mode preventing and Windows API access. For more on this, keep reading.  The Anti-Malware Scan Interface (AMSI) in Windows 10 enables all script code to be scanned prior to execution by PowerShell and other Windows scripting engines. The Anti-Virus/Anti-Malware solution on the system must support AMSI for it to scan the code. The great benefit is that all code delivered to the PowerShell engine is scanned, even code injected into memory that was downloaded from the internet. As of mid-2016, only Microsoft Defender and AVG support AMSI.
• #18: Invoke-CredentialInjection.ps1 - This script allows an attacker to create logons with clear-text credentials without triggering a suspicious Event ID 4648 (Explicit Credential Logon). The script either creates a suspended winlogon.exe process running as SYSTEM, or uses an existing WinLogon process. Then, it injects a DLL in to winlogon.exe which calls LsaLogonUser to create a logon from within winlogon.exe (which is where it is called from when a user logs in using RDP or logs on locally). The injected DLL then impersonates the new logon token with its current thread so that it can be kidnapped using Invoke-TokenManipulation.
• #19: His first blog on this subject is cleverly titled "Pass the pass(word)". In this blog, he discusses the fact that Windows Vista and higher feature a Security Support Provider (SSP) for Terminal Services named TsPkg, which provides single sign-on functionality to terminal servers. This feature can also be added to Windows XP SP3, as discussed here. Furthermore, this TechNet article discusses how to enable this SSO feature for specified terminal servers via GPO. However, as the author of the tool stated in his blog, and as my testing confirms, Windows will store the password in memory whether this feature is "enabled" via GPO or not. In other words, by default it's always on. A few weeks later, the author posted an update titled "Re-pass the pass(word)", where he discusses another SSP providing similar SSO capability, named WDigest. This time it's not only in Vista and higher, but in XP and Server 2003 also! WDigest provides for "digest access authentication", an extension to HTTP specified by RFC 2069 and later in RFC 2617. Direct access authentication improves upon basic access authentication, which sends credentials in the clear. Wdigest specifically supports RFC 2617, as well as RFC 2831, which is a more generic authentication mechanism (useful beyond HTTP) called Simple Authentication and Security Layer (SASL). The general idea here is that these specifications provide challenge-response authentication, whereby a challenge is issued and the responding party answers the challenge using a hashing routine that takes the clear-text password as an input.  On there other hand, there will obviously be one or more trusted machines for which you will need to perform an interactive logon. For those machines, I suggest you remove the TsPkg and WDigest SSPs to avoid a blatent security risk. Update: Removing SSPs is no longer valid advice since Kerberos also stores the password. Therefore, the most effective protection is to avoid interactive logons to any untrusted hosts. Other solutions such as one-time-passwords should also be considered.
• #21: This method is the simplest since no special “hacking” tool is required. All the attacker has to do is open up Windows explorer and search the domain SYSVOL DFS share for XML files. Most of the time, the following XML files will contain credentials: groups.xml, scheduledtasks.xml, & Services.xml. Put simply, exploiting MS14-068 takes less than 5 minutes and enables an attacker to effectively re-write a valid Kerberos TGT authentication ticket to make them a Domain Admin (and Enterprise Admin). As shown in the above graphic, this is like taking a valid boarding password and before boarding, writing “pilot” on it. Then while boarding the plane, you are escorted to the cockpit and asked if you would like coffee before taking off. This attack involves requesting a Kerberos service ticket(s) (TGS) for the Service Principal Name (SPN) of the target service account. This request uses a valid domain user’s authentication ticket (TGT) to request one or several service tickets for a target service running on a server. The Domain Controller doesn’t track if the user ever actually connects to these resources (or even if the user has access). The Domain Controller looks up the SPN in Active Directory and encrypts the ticket using the service account associated with the SPN in order for the service to validate user access. The encryption type of the requested Kerberos service ticket is RC4_HMAC_MD5 which means the service account’s NTLM password hash is used to encrypt the service ticket. This means that Kerberoast can attempt to open the Kerberos ticket by trying different NTLM hashes and when the ticket is successfully opened, the correct service account password is discovered. Note: No elevated rights are required to get the service tickets and no traffic is sent to the target. 
• #24: PS>Attack is a self contained custom PowerShell console which includes many offensive PowerShell tools which calls PowerShell (System.Management.Automation.dll) through .Net. The PowerShell attack tools are encrypted (AV evasion) and decrypted to memory at run-time. There’s also a custom build tool for ensuring every built exe is different (AV bypass). While PS>Attack is simply one method that an attacker can leverage PowerShell offensive tools without running PS>Attack PowerShell code runs in the earlier version of the PowerShell engine, if available.This means that if a system has PowerShell v2 (Windows 7 & Windows Server 2008 R2), then any PowerShell code executed is not logged. Event if PowerShell v5 is installed with system-wide transcript or script block logging. Windows 10 provides the ability to remove PowerShell v2.0 (no, this doesn’t remove PowerShell). Once PowerShell v2 is removed from Windows 10, PS>Attack usage is clearly logged.