Asmany people have said, some tasks seem to be particularly difficult which can be very frustrating, although giving the opportunity to hone micro techniques (being what I keep in mind to provide motivation), this question has got the better of me for too long now.
From which I try to initiate a pass the hash (PTH) using mimikatz and with MS01 creds (this is to enable the lister with MS01 as the user as the question states that the machine will only connect back to MS01). This executes with no errors, however when whoami is passed, the user printed is still julio (to try and mitigate error I tried the same process when RDPing using admin creds which allowed me to PTH into MS01). This was done using the following command:
I had some issues to with this and these steps helped me:
removed the -domain flag.
kept the user as julio
added -verbose to troubleshoot
did an Import-Module .\Invoke-TheHash.psd1 in Powershell.
The Eset AMSI .dll could be highjacked i.e. provide and use a custom.dll and call that one from custom .exe as noted here: -amsi-using-powershell-5-dll.html. This article applies to amsi.dll that is used by Windows Defender but appears it would be equally effective against Eset's AMSI .dll.
As far as reference no. 1 goes, I am running PowerShell in "Constrained Language" mode which will block all its API call methods. Appears reference no. 2 use was what Eset was having an issue with in the MRG ad hoc test.:
"This method is fast and very effective at the time of this presentation," Mitall explained. AMSI flaws extend beyond the ability to bypass the system. AMSI can also be exploited by attackers that have elevated permissions to the Windows machine running AMSI. Mitall presented two options, referencing two separate researchers:
Also of note is that Microsoft is removing Powershell 2.0 in Win 10 CE fall update. By default, it is presently installed on all Win 10 versions. More important is all the attacker has to is run PowerShell for example by specifying its version number via command shell at startup time, and AMSI will be bypassed as noted here:
The Anti-Malware Scan Interface (AMSI) interface in Windows 10, which is supported out-of-the-box by Windows Defender and available to other antimalware products, can perform deep scans on obfuscated PowerShell code. This is code that has been encoded specifically for the purposes of avoiding detection. If a hacker manages to force the use of PowerShell 2.0, then AMSI is unable to de-obfuscate the code.
As far as the obfuscated in-memory script execution of PowerShell that Eset missed in the MRG test, running PowerShell in "Constrained Language" mode will block the Invoke-Mimikatz method used as shown in the below screenshot from another article on PowerShell exploiting here: =2921
As far as setting Constrained Language mode within Powershell itself as shown in the screenshot, that is a temporary setting and will be lost at the next system boot. There is an undocumented way of making the setting permanent w/o the need for AppLocker which is only available on the Enterprise versions of Windows. It involves the creation of an environment variable.
Invoke-Obfuscation is a PowerShell script obfuscator. As the use of in-memory PowerShell malware has grown, implementation of in-memory AV scanning of PowerShell scripts has begun. Invoke-Obfuscation challenges all assumptions these in-memory PowerShell AV signatures have been making.
My intention in releasing this tool integration is to demonstrate to defenders the obfuscation tactics that are already being used in the wild. This will provide pentesters and red teamers the ability to provide more value to their clients by using already available obfuscation techniques when establishing their C2 channel. The end goal here is to improve security.
PowerShell Empire is one of those tools that keep on giving to the Penetration Community for as long as it was first introduced. Any other tool that we could remember that has more utility than anything is the Mimikatz. It has been years since the release of both of these tools but their ability to consistently attack the Windows Machine is unmatched. We know that neither PowerShell Empire nor Mimikatz is being used in the wild currently because of their signature that has been added to almost all of the Anti-Virus Software and across Virus Total. This has although made them less useful as compared to Cobalt Strike and other alternatives but when it comes to understanding the basics of Windows Authentication Systems such as SAM and LSASS and attack them and extract credentials there is no tool that can work as efficiently as Mimikatz.
Loading the dcsync module will invoke the mimikatz PowerShell script to execute the dcsync attack to obtain the credential by asking from an other domain controller in the domain. Here, we are requesting KRBTGT account Hashes and as result, it will retrieve the KRBTGT NTLM HASH.
Similar to the DC Sync attack we just performed on a particular user so the NTLM hash returned is also of that particular user. But in case the attacker wants to extract the hash of the entirety of all the users created on the Domain Controller. This is when the hashdump module comes into action. It will perform the DC Sync attack for each and every user and then provide the hashes for all of them in a consolidated view as shown in the image below.
Default local accounts are built-in accounts that are created automatically when a Windows Server domain controller is installed, and the domain is created. These default local accounts have counterparts in Active Directory. The default local accounts in the Users container include: Administrator, Guest, and KRBTGT. In the Active Directory domain, every domain controller runs a KDC (Kerberos Distribution Center) service that processes all requests for tickets to Kerberos. For Kerberos tickets, AD uses the KRBTGT account in the AD domain. A legitimate user begins the communication for a service request to the Application Server. The KBRTGT account acts as a service account for the Key Distribution Center (KDC) and separated into three parts: Database (db), Authentication Server (AS) and Ticket Granting Server (TGS). The Authentication Server (AS) verifies client authentication. If the logged user is authenticated successfully the AS issues a ticket called TGT which confirms to other servers that the user has been authenticated. Then the User request TGS from the KDC that will be used to access the service of the application server.
This is a dynamic way to generate ticket because this module can be run without having an admin privilege session and it will inject the ticket into the current session and the attacker can get direct access to the server.
The list goes on as on a rough estimate any system that is under use might contain a short of 400 certificates and this number increases based on the user activity on the system. The details extracted by Mimikatz is of subsequent value.
Token impersonation technique can be used as a local administrator to impersonate another user logged on to a system. In case we compromised a local admin on the target machine then we can use it to impersonate another logged on user e.g., domain controller using Mimitokens.
The keys module of the PowerShell Empire works on the back of the crypto module of Mimikatz, It is one of the oldest modules that still works in the wild. It directs on the CryptoAPI functions of the target. In a general sense, the usability is like the certutil binary that is present in the Windows Machine by default. It uses the token impersonation to its advantage and then patches the legacy CryptoAPI functions to patch the CNG key isolation service that makes the keys exportable. After that, it just exports those keys in a PVK file.
Mimikatz has the ability to retrieve clear text password as well as hashes. This is done by exploiting the Local Security Authority Service on the Windows. After a machine is compromised, the attacker can use the PowerShell Empire to load the logon passwords module to extract the clear text passwords. These passwords can be used to create Golden Tickets, Account Take Over or just a preliminary step to another attack. As we can see the image shown that we have successfully extracted the password for Yashika and Aarti Users.
SAM is short for the Security Account Manager which manages all the user accounts and their passwords. It acts as a database. All the passwords are hashed and then stored SAM. It is the responsibility of LSA (Local Security Authority) to verify user login by matching the passwords with the database maintained in SAM. SAM starts running in the background as soon as the Windows boots up. The sam module of the PowerShell Empire can be used to extract the SAM file and the associated password hash.
After Credential Dumping Series which contained different tools that can be used against a specific vulnerability, it felt like there is a gap for a guide that can help a person who is trying to get the reins of PowerShell Empire and to showcase the ability of Mimikatz to target the wide range of Windows Authentication Systems with compatibility to integrate with different frameworks such as Metasploit, PowerShell Empire, Koadic etc.
I need some help; when I try the script for mimikatz, I have a lot of errors in powershell. I tried on two different computers and always full of errors. What I do is, I run the script in powershell ISE and I type Invoke-Mimikatz and after that it shows me all the errors. What am I doing wrong?
Normally Mimikatz uses wcout to output data to the user; due to PowerShell limitations, if the DLL outputs data to stdout it cannot be seen by a user using remote PowerShell, you will only be able to see the output if you run the script locally. Luckily, it is very easy to modify the mimikatz DLL to output to a format which can be retrieved remotely. Here is how to do it:
This needs to be changed to output to outputStream instead of wcout. By default, outputStream will output to wcout (because that is the default we set in global.cpp). We can change that behavior (and will change it later).
3a8082e126