
Out of sight but not invisible: Defeating fileless malware - peter_d_sherman
https://www.microsoft.com/security/blog/2018/09/27/out-of-sight-but-not-invisible-defeating-fileless-malware-with-behavior-monitoring-amsi-and-next-gen-av/
======
codedokode
AMSI, as I understand, is a way for an interpreter to cooperate with an
antivirus and send code for a check. This means that if you have non-Microsoft
interpreter, for example, Java or Python, then AMSI won't work (memory
scanning could help though).

But what I didn't understand is why Microsoft allows users to run random JS
code from Internet with full privileges. Why would anyone need to do this?
This looks like a usecase made specifically for malware. If they didn't allow
this, there would be no need for AMSI in the first place.

If you look at Android, there is no need for techologies like AMSI, because
users cannot download and run scripts. And all applications are sandboxed and
are run with minimal pivileges. Windows architecture was made for airgapped
corporate environments of 80s, where there were no malware and it doesn't work
in the modern era.

I wanted to write that there is no need for an antivirus on Android, but this
is not true. As there are many malicious apps in Google Play and on the
Internet, and users don't really understand the permission system, an
antivirus that can detect malicious applications, is useful.

~~~
FreakLegion
_> what I didn't understand is why Microsoft allows users to run random JS
code from Internet with full privileges_

The short version is they don't. Cscript and wscript are akin to PowerShell
and they aren't talking about JS from the Web.

The way it works is, say, the attacker sends the script (direct) as an email
attachment and tricks the target into running it, or sends a document
(indirect) that drops and runs the script, and tricks the target into opening
that. They've even taken to having executables drop and run scripts to offload
malicious activity into otherwise trusted processes without setting off
alarms, like injection does.

In the indirect cases, cscript/wscript aren't the only options for JS. You can
also:

    
    
        rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";new%20ActiveXObject('Shell.Application').ShellExecute('calc.exe');
    

But Microsoft is overstating the difficulty of detecting these attacks. For
example obfuscation isn't a barrier to detection; in fact obfuscation can
itself be detected and is a fantastic signal for blocking this stuff. General
Windows system behavior, on the other hand, is chaotic[1], so in practice
you're limited to writing rules for e.g. what child processes winword.exe
isn't allowed to create, but even then you'll need exemptions for certain
teams.

1\. uTorrent for example creates child processes in a way that's practically
indistinguishable from malware:

    
    
        C:\WINDOWS\System32\mshta.exe C:\WINDOWS\System32\mshta.exe" "C:\DOCUME~1\<USER>~1\LOCALS~1\Temp\HYD4.tmp.1548293039\HTA\index.hta?utorrent" "C:\5ee283553c4ab530c77f19785f6092cabfd8e48a5eefd808cb53aecea4399dd9" /LOG "C:\DOCUME~1\<USER>~1\LOCALS~1\Temp\HYD4.tmp.1548293039\index.hta.log" /PID "1076" /CID "sDbhVc2tIx6wzwCd" /VERSION "111849449" /BUCKET "0" /SSB "1" /COUNTRY "US" /OS "5.1" /BROWSERS "\"C:\Program Files\Internet Explorer\iexplore.exe\"" /USERTYPE "admin" /ARCHITECTURE "32" /LANG "en" /USERNAME "<USER>" /CLIENT "utorrent""
        C:\WINDOWS\system32\cscript.exe C:\WINDOWS\system32\cscript.exe" "shell_scripts/check_if_cscript_is_working.js""
        C:\WINDOWS\system32\cscript.exe C:\WINDOWS\system32\cscript.exe" shell_scripts/shell_ping_after_close.js "http://i-50.b-000.XYZ.bench.utorrent.com/e?i=50&e=eyJldmVudE5hbWUiOiJoeWRyYTEiLCJhY3Rpb24iOiJmYWlsR2VuZXJhbCIsInR5cGUiOiJpIiwiZXJyb3IiOiJFcnJvcjogVW5hYmxlIHRvIHdhaXQgZm9yIHByb2Nlc3MuOyBmaWxlOiBmaWxlOi8vLmpzOyBsaW5lOiAxMCJ9" "

~~~
tinus_hn
Pretty easy to defeat: don’t allow executable attachments.

~~~
FreakLegion
Most companies don't, for actual executables (PE files) and scripts. So for
example:

1\. Attackers use documents, because it isn't realistic to disallow documents
over email as a matter of policy.

2\. Attackers use download links (Box, OneDrive, etc.), because it isn't
realistic to disallow URLs in email as a matter of policy.

3\. Attackers put the naughty bits in password-protected archives, which
aren't realistic for most companies to disallow over email as a matter of
policy. Some will, though.

On and on. Policy is great and you should use it as much as possible, but at
some point usability always wins out. Obviously there's a business opportunity
there, and companies like Proofpoint and Mimecast have stepped in to fill the
gap.

~~~
tinus_hn
Pretty easy to defeat: downloaded and extracted executables are quarantined.
And documents can’t ‘drop and run scripts’, they are documents. And by the
way, try sending a password protected archive in the mail once. Most services
just throw them away.

~~~
FreakLegion
> downloaded and extracted executables are quarantined

The vast majority of companies won't implement a security policy that strict,
even if they can distinguish email attachment downloads from other sources,
which they generally can't (ADS doesn't capture it directly).

> And documents can’t ‘drop and run scripts’, they are documents

Yes they can, and do, without needing exploits, for both legitimate and
illegitimate reasons. The legitimate reasons are why, again, the vast majority
of companies won't implement blanket security policies here.

> And by the way, try sending a password protected archive in the mail once.
> Most services just throw them away.

Incorrect. You can do whatever you want with your personal email, but we're
talking about enterprise security. Few companies (but more than the above two
cases) will block password-protected anything as a matter of policy.

In practice, none of what you're saying will be done because of the downstream
problems it creates for IT and security teams.

~~~
codedokode
> The vast majority of companies won't implement a security policy that strict

Maybe such policy should be the default; by default the employee should be
able to run only applications installed (or approved) by their sysadmin, and
applications are sandboxed like Android's ones.

In 80s when DOS was developed, there were no easy access to the Internet, no
phishing letters and viruses, so there were no risk in running different
executables. But today this outdated security model simply doesn't work. You
allow employees to download and run executables and they open "yearly-
report.doc.exe".

Maybe desktop system developers should look at iPhones and Androids. It is
difficult to dowload and run a virus on an iPhone; and it doesn't require the
user to deal with configuration settings - it works out of the box. Something
similar could be done for desktop systems: a pre-approved catalog of known
"good" software and a simple UI (that doesn't require special skills) to
whitelist any other software.

Also, I think that applications and documents should look different; today you
can assign an icon of Word document to an executable; running an executable is
indistinguishable from opening a document; that's wrong. Maybe applications
should be located only in special application directory and run from there.

------
staticassertion
There's a lot of discussion of behavior based detections, but then it seems to
lean heavily on AMSI, which is just an in-memory signature system.

Even the syscall monitoring, I wonder if it's really "Given a known sequence
of suspicious syscalls" as opposed to "Given a known sequence of good
syscalls" eg: signatures vs baselining. Or "These syscalls semantically amount
to this behavior".

From what I have seen of AMSI it's not much harder than classic AV to bypass.

I appreciate the Fileless classifications - that seems like a larger value
add, but I'd love to see us also better define TTP and Behavior based
detections. It _implies_ that we are observing generalized behaviors as
suspicious when in reality it's almost always some sort of combination of
predefined signatures.

It is not a "behavior" (in a meaningful way) when an attacker uses specific
parameters on powershell or some LOLBAS executable, it's just a very specific
technique, which is subject to change. The higher level "Got a process to
execute and do a thing" is what the behavior is, to me, and what we should
detect.

To be fair LOLBAS and Fileless are still uncommon approaches for malware, so
it is not surprising that it's taking time to hammer out how we should be
building out our view of the issue.

Still, ATP is a great product, not trying to be overly negative. I think
Microsoft is in a really good position to start hammering out the definitions
for some of these concepts. I'll give this article another read I'm sure.

------
lisk1
As don't mind this type of articles informative and thorough, the excess use
of "Windows Defender ATP" makes me think they are trying to put suggestion in
the readers mind. Can we count how many times "Windows Defender ATP" is used?

~~~
jmartinpetersen
37\. That maybe seems a bit heavy.

Edit: 38 with the image link at the bottom.

~~~
basetop
I count 45 if we include variations like "Windows Defender AV", "Windows
Defender Security Center", etc.

Example from article : "Windows Defender ATP alert showing how detection of
the Sharpshooter technique by Windows Defender AV is surfaced in Windows
Defender Security Center"

And that's not including the text embedded in the images themselves - like the
image of the event log ( Event 1127 - Windows Defender ).

You can't scroll through the article without a mention of Windows Defender. I
don't know if they did it purposefully or not, but I'd say it was intentional.
Hard to believe it was accidental.

