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
So let's map out controls we can put in place to prevent the attack lifecycle.
-- Tom Webb @twsecblog |
Tom 59 Posts ISC Handler Nov 23rd 2016 |
Thread locked Subscribe |
Nov 23rd 2016 5 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 5 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 5 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 5 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 59 Posts ISC Handler |
Quote |
Nov 23rd 2016 5 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 59 Posts ISC Handler |
Quote |
Nov 23rd 2016 5 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 5 years ago |
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 |
Quote |
Nov 24th 2016 5 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 5 years ago |
Quoting Brandon:"Application control policy: Don't allow MS office executable to drop .exe, .vbs, .vbe, .wsf and .js files." 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 5 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 5 years ago |
Sign Up for Free or Log In to start participating in the conversation!