Readers!

From last couple of weeks I have been doing some analysing of malware. Mostly, are via phishing attempts. What our adversaries are doing is to first gain easy access to the machine via phishing and creating background processes that calls the compromised domains that downloads the executable, packed with malicious payload. Below is basic timeline of a phishing email with attachment.

The technique is neither new or unique, however if we are to come up with a trend we can see that most of them have similar tools and procedures.One such tool is PowerShell. The blog is not about what PowerShell is, but how our adversaries are using the tool that was just created to automate admin tasks within Windows environment. As automation is was one of the key points PowerShell was given scripting. The scripting allows to automate admin tasks such as configuration management etc. Here I go explaining what PowerShell is.

Microsoft definitely didn’t intended the tool to be security aware, and therefore till this date one can use PowerShell to perform malicious activities. However, certain controls or functionality within PowerShell can assist us in controlling type of scripts that can run on the systems.

There are indeed multiple security controls that we will discuss later in the blog but first let’s see what our adversaries are doing. I will not be going in specific analysis of a malware as I am trying to reach out to the teams which are responsible to detect/prevent these type of attacks by placing feasible and actionable security controls with regards to PowerShell.

Below is a sample PowerShell command seen in most cases :

Frequently used parameters :

1. ExecutionPolicy bypass – Execution policies  in  PowerShell determines whether a script can run and what type of scripts can run and also sets default policy. Microsoft added a Flag called ‘bypass’, which when used bypasses any currently assigned execution policy and runs the script without any warnings. There are 4 types of Execution policies:
   1. Restricted
   2. Unrestricted
   3. AllSigned
   4. RemoteSigned
2. windowstyle hidden – This parameter is used when PowerShell script requires to be run in background without the users knowledge.
3. noprofile – PowerShell profile are set profile or commands (it is actually a PowerShell script), normally for current user and host. Setting -noprofile will just launch any script and will not look for profiles.
4. DownloadFile – For downloading the file via web

Tools, Technique and Procedures:

1. The attachments as shown in the first screenshot, are mostly Word/Excel doc with Macros or zip files with JavaScripts.
2. The Macros or JS are heavily obfuscated and sometimes lightly. For heavily deobfuscated scripts I rely on dynamic analysis(the best way to know what malware is written for). Some scripts, due to practice, I can deobfuscate within minutes.
3. PowerShell command to download the file are mostly on sites with HTTP rather on HTTPS (there are some sophisticated adversaries created/compromised HTTPS websites). Sometimes, also have noticed use of cmd.exe /c being used which will invoke specified command and terminates it.
4. File on the compromised domain are mostly windows executables with ‘.exe’ or sometimes the extension is hidden. This depends on the adversary and the packers that they have used. Sometimes, you can unpack the ‘exe’ via 7zip.
5. Based on the commands the file will be first downloaded and executed. In certain cases I have seen the file gets deleted after execution. Again, it depends on the command.
6. Most malwares that I have analysed were either ransomware or trying to steal information and sometimes combination of both.

Above TTPs are very simple to understand however, implementing security controls, lets say for each steps to detect and prevent, is much harder. We as a team or individual are working towards reducing the impact of the incident. Consider the phases of cyber kill-chain and perform an analysis of incidents within your team, and understand at which phase you are able to catch the adversary and can you do that earlier?

Observables such as IP addresses, domains, URLs and file hashes with context are the IOCs that normally we look for and use it for detection and prevention. Some people call that Threat Intelligence. Darwin would have gone here Seriously?

Security controls such as Endpoint solutions, Proxy, IDPS and FW can help us but they are heavily dependent on what they know and history has shown us that they can be bypassed. However, they are indeed very good controls to either reduce the impact and/or preventing the known attacks or IOCs.

What we need is security controls based on TTPs. So let’s see some of the following controls that can be implemented to either detect and/or prevent such attacks :

1. DO NOT give admin privileges to the local account. If required based on their role give have a Admin pass generator with User Access Control (UAC) enabled, that will prompt to enter password for Administrator every time a system change such as installing a program, running an Admin task etc is created.
2. Group policies to have certain tasks especially script execution and writing to registry and windows directory only allowed by Administrator. Can use Administrative Templates.
3. Group policy to not allow any executables in TEMP directory to be saved/executed.
4. Sign all PowerShell script. If not possible or the team not willing to sign at restriction placed via above mentioned points can assist.
5. Can also set the Execution Policy to Restricted, PowerShell can only be used interactively to run the script. Organisation who are not pushing any policies via PowerShell can choose this option.
6. Application whitelisting – Windows AppLocker. The tools can assist to define what level of access a user can have on the system with regards to executables, scripts and DLLs.
7. Having AppLocker in Allow Mode can assist the team with a rule that only scripts at trusted location can run on the system. A attacker can re-write the rule provided, he/she has access on the system with Admin privileges.
8. PowerShell Language Mode – Admin can setup the language modes to Constrained Language Mode that permits all Windows cmdlets and all Windows PowerShell language elements, but it limits permitted types. It has list of types that are allowed within a PowerShell script. For example, New-Object type cmdlet can only be used with allowed types which does not contain system.net.webclient.
9. Logging of PowerShell is also important. Here, in my opinion Sysmon is a must have. The logs can be forwarded to SIEM for correlation. If Sysmon is not feasible, enabling PowerShell Module logging is highly recommended. Enhanced logging is always recommended and will  write another blog on that.
10. Organisation proxy to be configured properly to detect/prevent web request invoked via PowerShell. Have tested with command Invoke-request that can show WindowsPowerShell within User-Agent. However, no User-Agent string is noted when above mentioned to DownloadFile is used. May be Proxies can be configured to disallow any traffic without User-Agent – still have to verify whether such functionality exists. If not a SIEM rule can be used to alert on web traffic that has no User-Agent string, going to external sites and downloading files.

Please note, that AppLocker and Powershell constrained mode are not security feature but another layer of defense which can help to reduce the impact of the attack and in some cases completely prevent the execution of foreign scripts.

When making a business case to the board or C-Level executives to make any changes in the organisation the presenter should use language they understand. As part of the evidence it highly recommended to show actually incidents where current security controls failed which impacted the productivity of the user, loss of data and hours spent to recover and restore systems. They want to know how any new mentioned or suggested changes will help in reducing impact to the user or business.

If there are other methods that other organisations are using please let me know.

A good read – PowerShell for Blue Team

 

Readers!

Last year one of the member on SANS DFIR posted a question with regards to identifying whether there was any data leakage occurred in the environment via a USB thumb drive. As for the evidence investigator had USBStor artefacts. Shell bag analysis(TZ Works sbag) showed a large number of files touched (reg-UTC) within a very short time period and a few with the MRU (Most recently used list) flag set with different times.

This blog is a concise article of the tips provided by myself and other members. Provided tips assisted the investigator to support the theory of data leakage.

1. Evaluating USB dates as a group.  If any number of artefacts is detected with the same exact time stamp, investigate it further. Having such artefacts indicates that they were somehow modified. It is also, worth the effort to carve the data for deleted registry files and look for relevant keys there.
2. Normal users will/may access the files again after copying to any removable media to make sure the files were copied correctly and are not corrupted. This operation leaves shell items in the form of shell bags and link (.lnk) files. One can use Windows Time Rule to for evidence of file copy. Using the time rule examine the link files with target data pointing to files on removable media (tz works ‘lp’ is excellent for this). If the modified date of the target file data in the link file precedes the created date of the target file data in the link file, then this is an indication that the file was opened from the removable media, after the file was copied to the removable media. This means that even without access to the removable media, you can state that files were copied to the removable media and then they were opened from the removable media. The created date of the target data in the link file is when the file was copied to the removable media. One can state that the files were copied, but cannot state where the file was copied from, as that is not tracked.
3. Now to determine when the file was opened from the removable media, look at the times of the link file itself. The created date of the link files will be the first time the file was opened and the modified date of the link file will be last time the file was opened. To discover the removable media, locate the volume serial number of the removable media’s file system which will be stored in the link file’s data. Correlate the volume serial number to the data from your USB drive analysis and you will get the manufacturers unique serial number for that removable media. Find that unique serial number across your enterprise and you will discover other machines where that drive was connected to. Correlate the link file target data to the shell bag data and you should be able to get a neat timeline of what happened on the system.
4. Memory analysis of the system can assist. If the files were copied it should have data on the clipboard. Drag and drop will not likely have any artefacts.
5. Registry hives –  one can use FTK registry viewer for ease. Usbstor have last written values – dates when the last device was accessed or connected.
6. Look at the recent files in Windows section. Although if one is not able to open the file it may show which file from which volume – it may not prove that file was copied however if the document name is ‘organisationconfidential‘ than you can argue what was the file doing on USB? The link files should also contain volume serial that one can match/compare with removable media serials.
7. Registry restore points can also be used to check last written dates.
8. Look at the MFT records – they have sourceMFT and destinationMFT.

Tools mentioned : SBE – Shellbag Explorer and MFTparser

Links mentioned :