Recently, I was using Netwitness Endpoint (ECAT) to help triage a large environment. During this time, I identified a few systems that were exploited by malicious html file. It was part of a phishing campaign that came in via email. Unfortunately, I was unable to find the file because it was no longer in the Outlook Temporary Internet Files folder. However, since we have tracking data coming in from the agents, I was able to recreate the scene even without the initial malicious code.
The original compromise showed tracking data like the one below:
Here we can see that Outlook starts up Chrome to open a file in the Outlook Temporary Internet Files directory. From there we see regsvr32.exe kicked off that had a URL in it's launch arguments. The regsvr32.exe is a legitimate and signed Microsoft file used to register DLL's and other controls into the Windows Registry. Last year, researcher Casey Smith described how this component could take a URL to a remote file as an argument to bypass various security controls. The URL could be over HTTP or HTTPS and would point to an SCT file. This SCT file is really just an XML file with instructions on what regsvr32.exe should do.
With the tracking data showing us step by step what occurred on the system, we can use these commands on a different system and attempt to recreate the infection.
On my analysis system, I opened a command prompt and ran that started this off.
This URL took us to the malicious script on a Google API site over SSL. The contents of that SCT file can be seen below:
In there we see the syntax the JSRat is going to execute leveraging mshta as well as another URL. This new 'terra' URL sends another XML scriptlet to download and install a malicious dll called 'rubyonrais.dll'.
Tracking data in our analysis system looks very similar to what our original host showed along with the registering of the DLL.
If we take a look at the network traffic associated with this, we can get insight into what was happening as well.
We can see the request to 'storage.googleapis.com' over SSL and then the connection to 'meubackup.terra[.]com[.]br'. This downloaded a 1.4mb file based on the network traffic. Even though this is an SSL connection, we can still see the meta data about that session. I can now go and find the file where the script told us it would be. In the C:\Users\Public\Administrator folder.
Currently this could be picked up with the IIOC "Runs mshta with javascript arguments".
Another we could create is slightly different than one out of the box to cover both HTTP and HTTPS connections.
| Regsvr32_runs_with_HTTP_argument |
|---|
--Runs_REGSVR32_HTTP.sql Runs REGSVR32.EXE with HTTP argument /* DB Query
SELECT mn.MachineName, se.EventUTCTime, sfn.Filename, se.FileName_Target, se.Path_Target, se.LaunchArguments_Target, sla.LaunchArguments
FROM [dbo].[WinTrackingEvents_P0] AS [se] WITH(NOLOCK) -- Also try P1 WHERE [se].[BehaviorProcessCreateProcess] = 1 AND --ORDER BY se.EventUTCTime desc
-- IIOC SELECT DISTINCT [se].[FK_Machines], -- If you are using 4.3.0.4, remove the comment dash above
[dbo].[WinTrackingEventsCache] AS [se] WITH(NOLOCK) WHERE [se].[BehaviorProcessCreateProcess] = 1 AND OPTION (RECOMPILE); |
|
I hope you find this useful and as always, happy hunting.
Chris
