Series entries: First part, Second part, Third part, Fourth part, Fifth part
In the previous article, we left the investigation with the IP 10.11.2.14 as the source of the connections to the DC (and with connections to the C2 101.143.122.216 as well as the antivirus disabled prior to the generalized attack).
Since we are talking about connections and considering that we have the RAM memory, the first thing Angela does is to use the Volatility netscan plugin to remove the network connections (the memory profile is Win10x64_17134) and confirm the connections with the C2:
Netscan returns a few additional results:
A connection to a remote SSH?
What is this computer doing providing a service on port 443/TCP? Has it gone mad? Clearly we need to dig deeper into these connections to find out what is behind them.
Angela decides to check the Sysmon logs, which should show the network connections… but it seems that the FFP (remember, the Federation of Patron Festivities) did not correctly apply the standard MINAF Sysmon configuration, so no such data is being collected (grrrrrrr).
However, it does pick up process creations (EventID 1), so after a bit of rummaging she can find the process that makes the SSH connection:
plink.exe is a companion to putty.exe (the Windows SSH thin client par excellence), and is used to make SSH connections in an automated way.
What is being launched with this command is basically a tunnel between the attacker’s computer and the local computer, so that all the traffic passing through port 12345/tcp of the attacker’s computer is redirected to port 443/tcp of this computer (which is the other weird connection we had seen).
Two important details: the parent of this computer is launch_plink.bat, which implies that we may have other processes involved … and that plink is running as admin, the local FFP admin user that Angela checks seems to be still active (instead of having been eliminated with the integration with the single password service via MINAF LAPS). A pending talk with the sysadmins of FFP is pending. With knifes.
Upon further review of the Sysmon events, Angela finds the other command from launch_plink.bat, and understands the purpose of port 443:
The netsh command is used in Windows to manipulate network settings, and in this case what it specifies is a port redirection from local port 443/tcp to port 3389/tcp (the MINAF domain controller). In short, the two commands form an elegant SSH-RDP pivot, which allows attackers to remotely enter the DC from their attacking computer).
If we keep looking, we find the launch of the launch_plink.bat script:
More obfuscated Powershell code. The attackers were probably not very imaginative, so Angela looks for more launcher.bat executions … and whoever seeks, finds:
This log gives us a very important piece of information: the Empire stager was launched via PsExec, one of the tools par excellence for lateral movement, and as a local administrator.
This event tells Angela two things. First, that we have at least one more compromised computer on the network. And secondly, that it is most likely from the FFP, because at this point she is pretty sure that the local admin password is the same on every user’s workstation.
Since PsExec employs SMB, Angela can retrieve the netscan and investigate the connections to the 445/tcp:
Two computers appear, but one of them (10.11.2.16, also from the FFP) is the third computer that suffered a “premature death” of the antivirus, so Angela now knows where to continue her investigation.
A question arises: if the attackers already had control of another computer, why did they attack this one? What’s so special about this computer to make it a target? Angela imagines the answer, but she needs data to confirm her hypothesis so she takes from the Security event log a list of all users who have logged on to the computer: (Event ID 4624), exports it to text and does a grep for the account names:
maria.feliz and dolores.jolgorio are administrative staff of the FFP, admin is the local administrator of the computer… and dom.adm is the domain administrator that we had seen the attackers use to connect to the DC. Angela is sure that if she asks the FFP system administrators about that login, they will answer her “we’ve always managed the computers like this, it’s the easiest way.” The meeting will require the use of the guillotine…
Knowing that we have a domain administrator here, it is more than possible that the attackers have logged in to do a credentials dump. From what she knows of Ryuk’s TTPs, they usually use LaZagne or Mimikatz, so Angela can employ the Volatility strings plugin to see if she can find strings typical of either of those two programs.
After 15 minutes of waiting for Volatility (she doesn’t know why, but sometimes it gets stuck), Angela thinks: “I don’t really need the Volatility plugin because I don’t need to know what process is launching the tool, only if it has been launched or not, and I can get that from the base strings”.
She stops the tool and searches for chains from both programs … and she finds the dreaded “kiwi of death” from Mimikatz:
At least the computers are Windows 10, and having Wdigest disabled by default prevents the password from being clear. Looking carefully, she finds the part related to the dom.adm account:
The password does not appear either… how were they able to connect via RDP to the DC if they only had the NTLM hash?
Angela checks with Salvador, who responds rapidly: PtH! PtH! Apparently, it is possible to perform a Pass-the-Hash attack against the RDP protocol … but only if the “Restricted Admin” security feature is enabled on the target computer (which is used to prevent the credentials from being stored on the computer, and thus protect against possible dumps). That explains that NTLM authentication that Angela saw in the DC…
Pissed off that the attackers have leveraged a security measure against her, Angela decides not to leave a stone unturned. She already knows where the attackers come from, where they went and what they did. She just needs to check if they have left any “gifts” on the computer in the form of persistence.
There are many ways to check persistence, but Angela decides to use the attackers’ weapons against them: since they are using free tools (Empire)… The source code is available, so she can download the Powershell in charge of managing persistence and study it:
https://github.com/EmpireProject/Empire/blob/master/data/module_source/persistence/Persistence.psm1
The main function says the following:
New-ElevatedPersistenceOption allows for the configuration of elevated persistence options. The output of this function is a required parameter of Add-Persistence. Available persistence options in order of stealth are the following: permanent WMI subscription, scheduled task, and registry.
Since they had admin privileges, and WMI is the stealthiest persistence, let’s try our luck. The source code indicates that this is the actual command that sets persistence:
$ElevatedTrigger = "`"```$Filter=Set-WmiInstance -Class __EventFilter -Namespace ```"root\subscription```" -Arguments
@{name='Updater';EventNameSpace='root\CimV2';QueryLanguage=```"WQL```";
So we can search for it in the memory strings and… bingo!
There is no doubt whatsoever that this computer must be in the purifying fire. Taking a moment to step back and see the incident globally, Angela begins to see clearly what is happening: the attackers entered this computer because they possibly knew it had a domain administrator login, obtained the NTLM hash, and set up the SSH-RDP pivot in order to enter the DC.
It remains to be seen what the analysis of the 10.11.2.16 computer has waiting for us… which we will see in the next article.
