1
00:00:00,792 --> 00:00:06,792
>> I'm technical director, Matt
Hastings, one of our
consultants, both of us has done
2
00:00:09,542 --> 00:00:14,917
response investigation at
Mandiant, for myself upwards of
five years,for matt upwards of
3
00:00:14,917 --> 00:00:22,167
three years. Apologize if we
sound horse. I have been in
Vegas since Friday of last week
4
00:00:22,167 --> 00:00:28,333
teaching and presenting. This is
last of my voice that's left.
Hopefully it will carry through
5
00:00:28,333 --> 00:00:34,333
the hour. Thank you for coming.
We will talk about investigating
power shells attacks. Not blue
6
00:00:37,250 --> 00:00:43,583
shell. If that's what you are
looking for in the wrong
presentation. The reason we did
7
00:00:43,583 --> 00:00:49,292
this research ‑‑ we continuously
are seeing attackers adopt
interestingly novel approaches
8
00:00:49,292 --> 00:00:55,000
to compromise and persist an
environment. We had seen an
increasing power shell in some
9
00:00:55,000 --> 00:01:00,833
targeted attacks we investigate
starting about 18 months to two
years ago, very sporadic,
10
00:01:00,833 --> 00:01:06,708
nothing consistent, nothing I
would call a trend at the time.
Earlier this year matt and I
11
00:01:06,708 --> 00:01:12,958
worked the case, targeted
compromise of the fortunate 100
cases, spent four months
12
00:01:12,958 --> 00:01:18,000
investigating in this
environment. This victim VPN
space have been compromised for
13
00:01:18,000 --> 00:01:25,083
over three years. Attacking main
administrator during that time.
They had free access to the
14
00:01:25,083 --> 00:01:28,375
majority the environment, but
the way they have conducted the
majority of their of command and
15
00:01:28,375 --> 00:01:35,000
control when we were watching
was from their own originating
attacker system through the VPN,
16
00:01:35,000 --> 00:01:39,708
targeting the victims work
station and server using a
combination of stuff we see
17
00:01:39,708 --> 00:01:46,000
often, like schedule tasks and
stuff not seen quite so often,
power shell remoting and copying
18
00:01:46,000 --> 00:01:49,917
and executing power shell
scripts on the target systems.
This turned out to be
19
00:01:49,917 --> 00:01:54,583
forensically challenging. You
don't get to see what's on
attacker's system. When you
20
00:01:54,583 --> 00:02:00,042
conduct attacks like power shell
remoting over the network, it's
difficult to see what was done
21
00:02:00,042 --> 00:02:05,542
on the host on the end point
side if it's in memory. This
lead down the path of doing
22
00:02:05,542 --> 00:02:10,458
research and that's why we're
here today. Of. We're not going
to go into a power shell 101,
23
00:02:10,458 --> 00:02:16,167
way beyond the scope of this
talk. Suffice it to say power
shell is powerful. A command
24
00:02:16,167 --> 00:02:22,625
line and scripting environment
in Windows takes the
functionality see in batch
25
00:02:22,625 --> 00:02:28,625
scripts or other scripts Windows
supported and rachets it up
another level. You can interact
26
00:02:31,458 --> 00:02:37,917
with Windows API and registry
and you can do cool stuff access
the entire dot net frame
27
00:02:37,917 --> 00:02:44,083
workload and reflectively load
and execute DLL and memories.
This makes it useful for system
28
00:02:44,083 --> 00:02:50,000
administrators and developers
for using it legitimate
purposes. It also means
29
00:02:50,000 --> 00:02:56,000
attackers can use it and do neat
stuff witness. Developers have
built penetration testing and
30
00:02:58,583 --> 00:03:04,042
attack frame that use power
shell. PowerSploit is probably
the best known written by a
31
00:03:04,042 --> 00:03:10,042
number of guys, Bell, Joseph,
Mack who works with us at
Mandy FRI. PowerSploit does
32
00:03:12,625 --> 00:03:18,292
recognizance, remote code
execution,its got a module
called invoke Mimikatz that will
33
00:03:18,292 --> 00:03:24,542
take the mimikatz code and in
memory run it on a remote system
without ever touching disc and
34
00:03:24,542 --> 00:03:31,375
do what mimikatz does and other
modules. Other tools like
MetaSploit which has power shell
35
00:03:31,375 --> 00:03:37,708
based modules for over a year
now, veil power view, more and
more attack framework are
36
00:03:37,708 --> 00:03:43,125
integrating power shells are
integrating power shell into
their tool kit. Targeted
37
00:03:43,125 --> 00:03:47,833
attackers learning how to use
it, attack and testing tools
using it. Mass malware use power
38
00:03:47,833 --> 00:03:53,208
shell. The first power shell
mass malware was shortly after
the creation in 2006 called
39
00:03:53,208 --> 00:03:59,208
power worm. A proof of concept
didn't do much but now mass
malware use power shell. Trend
40
00:04:04,208 --> 00:04:11,500
lab has reported a couple
examples in the last 12 month. A
classic ransom where sample that
41
00:04:11,500 --> 00:04:15,917
encrypted all your file and
demanded payment. The bottom
line attackers of all
42
00:04:15,917 --> 00:04:21,708
disciplines are learning how to
use this stuff. Instead of
coming up with an investigation
43
00:04:21,708 --> 00:04:27,542
methodology specific to one
attack frame work or cool or
malware, we took the lowest
44
00:04:27,542 --> 00:04:33,667
common denominator. What is the
fundamental way to interact with
a system and forensic impact
45
00:04:33,667 --> 00:04:40,083
does that have? The three
scenario exercise executing a
power shell local host, using
46
00:04:40,083 --> 00:04:45,833
power shell remoting feature
which using a protocol WinRM,
Windows remote management
47
00:04:45,833 --> 00:04:52,083
interact with a remote host and
persistent power shell, taking
power shell code and configuring
48
00:04:52,083 --> 00:04:58,958
system to automatically execute
upon log in or boot time. Each
scenario you run test case what
49
00:04:58,958 --> 00:05:06,625
impact on registry on file
system event logs, memory and
monitoring the memory, network
50
00:05:06,625 --> 00:05:13,375
traffic. A few assumptions, the
fist that we make is that the
attacker has local or domain
51
00:05:13,375 --> 00:05:18,333
administrator access to the
target system. You may be
thinking, isn't that cheating,
52
00:05:18,333 --> 00:05:23,583
what we're dealing with, when we
look at this is post compromise
scenarios. I don't care about
53
00:05:23,583 --> 00:05:29,667
the initial exploit, I concern
has a foothold in the
environment and achieving
54
00:05:29,667 --> 00:05:36,417
mission, moving host to host,
doing recognizance, stealing
data and whatever else brought
55
00:05:36,417 --> 00:05:43,042
them to that environment in the
first place. Almost every
Windows environment the attacker
56
00:05:43,042 --> 00:05:49,042
gains administrative permission
quickly. You can find the other
stages without getting
57
00:05:51,458 --> 00:05:57,458
compromised and kicked out.
That's the context we will be
looking at all these
58
00:05:59,542 --> 00:06:03,625
environments. A quick version
reference, there's a lot of
different versions of power
59
00:06:03,625 --> 00:06:09,333
shell. I think 4.0 is current,
5.0 is in the work. in most
Enterprise environment, you will
60
00:06:09,333 --> 00:06:15,542
see 2.0 because thats whats been
installed by default in Windows
2007 and viSta late and Server
61
00:06:15,542 --> 00:06:22,208
2008R2. Windows 8 power shell 3
by default, Windows 8.1 includes
4, but we dont see corporate
62
00:06:22,208 --> 00:06:29,083
environments adopting either of
those platforms for quite some
time. The down side is cool
63
00:06:29,083 --> 00:06:35,375
things in power shell 3 that
myself and Matt will talk about
later, won't be available by
64
00:06:35,375 --> 00:06:40,000
default and therefore won't be
installed in most environments.
You have to apply an optional up
65
00:06:40,000 --> 00:06:44,333
date in the Windows management
frame work to gain access to
later versions of power shell
66
00:06:44,333 --> 00:06:50,958
and Windows version of Windows.
Let's begin by talking about
memory analysis. In some ways
67
00:06:50,958 --> 00:06:57,792
this is the worst case scenario.
An attacker interact with
targeted host, use power shell
68
00:06:57,792 --> 00:07:03,792
remoting. Worse case scenario
because it's volatile, the
session end, come back to system
69
00:07:06,375 --> 00:07:12,083
in minute, hours days, and based
on a lot of factors we want to
understand what would be left
70
00:07:12,083 --> 00:07:16,625
behind assuming the system had
not been shut down or rebooted
and how long could you find and
71
00:07:16,625 --> 00:07:21,250
recover that and how much could
you get out of memory. To
understand this, we need to
72
00:07:21,250 --> 00:07:26,917
understand the process hierarchy
that power remote using. What
happens myself as client
73
00:07:26,917 --> 00:07:33,750
initiates power shell remoting
on target systems memory? The
way it work lets say i use the
74
00:07:33,750 --> 00:07:39,542
power shell command like the
invoke command to run evil .exe
and presumably evil.exe is
75
00:07:39,542 --> 00:07:45,208
already on target system.
svchost.exe service hosting
process that is running the
76
00:07:45,208 --> 00:07:52,167
decom launch service an
instantiates an instance of
wsmprovhost.exe and then that
77
00:07:52,167 --> 00:07:58,333
instance of wsmprovhost in
turns, executes evil.exe so
evil.exe parent process will be
78
00:07:58,333 --> 00:08:03,667
wsmprovhost and svchost will be
that wsmprovhost's parent
process host. In contrast, If I
79
00:08:03,667 --> 00:08:10,625
use power shell remoting to
execute power shell native
command, in other words, just
80
00:08:10,625 --> 00:08:16,500
command or code that is solely
resonant within power shell
language based, what happens is
81
00:08:16,500 --> 00:08:22,917
wsmprovhost spins up again. You
don't see a child process power
shell dot exe spawned. The power
82
00:08:22,917 --> 00:08:28,250
shell code runs in context of
wsmprovhost. You don't see a
child process when you do
83
00:08:28,250 --> 00:08:34,250
remoting like this. So what's in
memory? If you go to memory and
you dump memory right when a
84
00:08:39,000 --> 00:08:43,667
power shell session, remoting
session occurring on victim
host, you can reconstruct almost
85
00:08:43,667 --> 00:08:50,083
complete command from the
wsmprovhost memory space. The
problem with that is it
86
00:08:50,083 --> 00:08:54,792
terminates at the end of the
session. Meaning if I do one
power shell remoting command,
87
00:08:54,792 --> 00:08:59,542
the moment the command complete,
that wsmprovhost terminates, all
the cool evidence is totally
88
00:08:59,542 --> 00:09:05,042
gone. From a practical
standpoint as an analyst or
investigator you will almost
89
00:09:05,042 --> 00:09:10,625
never get to the system in time
to recover that process memory.
That kind of brought us back to
90
00:09:10,625 --> 00:09:15,875
the drawing board to see where
else in memory does this stuff
hang out? What we found is that
91
00:09:15,875 --> 00:09:21,542
another instance of the service
hosting process running the
Windows remote managing service,
92
00:09:21,542 --> 00:09:29,125
broker power shell remoting,
contains remnants of the soap
objects that power shell input
93
00:09:29,125 --> 00:09:36,250
and output martial-led into when
you do remoting. This may
persist after the end of a
94
00:09:36,250 --> 00:09:42,667
remoting session maybe up to
reboot. We found bits and pieces
of the same data persist in the
95
00:09:42,667 --> 00:09:48,292
kernel and the page file. We
suspect that that is probably
artifacts of page, tools and
96
00:09:48,292 --> 00:09:53,167
memory and therefore not
something you can reliably
expect to always find. We will
97
00:09:53,167 --> 00:09:58,833
not read this in detail. We put
together a table here of source
of evidence in memory and how
98
00:09:58,833 --> 00:10:04,792
long you can find stuff after
the fact on the system. Your
best bet is the winRM instance
99
00:10:04,792 --> 00:10:10,083
of Svchost. If you dump memory,
assuming that the attacker is
the only one thats interacting
100
00:10:10,083 --> 00:10:15,792
the system through remoting, and
assuming that the system hasn't
rebooted, you can recover input
101
00:10:15,792 --> 00:10:21,333
and output from power shell
sessions. It look like this. I
apologize if the colors are hard
102
00:10:21,333 --> 00:10:27,583
to read. Here's an example of us
running through remoting of
power shell command that does
103
00:10:27,583 --> 00:10:33,583
echo test string PS session
through output file. Amidst this
giant blob of ugly xml, you can
104
00:10:35,833 --> 00:10:43,042
see an RSB command tag and the
full command we submitted in the
command line. We were able to
105
00:10:43,042 --> 00:10:49,750
recover that from memory many,
many hours after that already
had executed. A more interesting
106
00:10:49,750 --> 00:10:55,750
example used the power sploit
invoke mimikatz madule again for
remoting. We used the technique
107
00:10:55,750 --> 00:11:02,500
where you download through power
shell the script over the
Internet, and then dynamically
108
00:11:02,500 --> 00:11:08,625
execute it. So nothing touches
this memory on the victim
system. Again, we can see in the
109
00:11:08,625 --> 00:11:14,875
inset a complete command line of
everything executed to pull and
run the invoke mimikatz Power
110
00:11:14,875 --> 00:11:21,083
sploit module. It's possible to
use this. Yes, this is painful.
This is kind of like worst‑case
111
00:11:21,083 --> 00:11:25,625
scenario. You can recover
evidence. Will you have to work
for it. The biggest problem is
112
00:11:25,625 --> 00:11:33,292
since we're looking at fragments
of the soap and the power shell
remoting protocol, xml objects
113
00:11:33,292 --> 00:11:39,292
used when do remoting, not like
well structured objects retained
in memory because being actively
114
00:11:41,667 --> 00:11:49,042
used. It's portion of memory no
longer actively allocated. The
bottom line you can do string
115
00:11:49,042 --> 00:11:55,250
searches. You can find RSP
command,RSP command line the
strings and hone in on the
116
00:11:55,250 --> 00:12:01,000
commands. You will have to sift
through a lot of garbage. In
summary, timing is kind of
117
00:12:01,000 --> 00:12:06,500
anything, everything rather,
that's always the case with
memory analysis but especially
118
00:12:06,500 --> 00:12:12,333
with this because there is no
proper place at which in memory
all of power shell history is
119
00:12:12,333 --> 00:12:17,958
retained forever. It has to be
constructed from what's left
behind in the Windows R M memory
120
00:12:17,958 --> 00:12:24,167
space. Taken then things like
system up time and memory
utilization can impact how
121
00:12:24,167 --> 00:12:30,167
likely you are to recover these
types of art facts. I will turn
to Matt? >> You look at similar
122
00:12:32,875 --> 00:12:39,167
scenario Ryan talked about
attacker interacting with
system, and we also looked at
123
00:12:39,167 --> 00:12:46,792
logs in power shell locally.
Each scenario try to answer
three questions. Which event log
124
00:12:46,792 --> 00:12:52,167
specifically are activity? This
will be event log that are
directly writing power shell
125
00:12:52,167 --> 00:12:57,417
activity. What you will see in
the next slide is event logs
that power shell writes to
126
00:12:57,417 --> 00:13:03,000
directly. It doesn't necessarily
cover the event logs that may
contain data. For example in the
127
00:13:03,000 --> 00:13:08,792
remoting example, an attacker
logs in, you will expect to see
a log in. That wasn't covered in
128
00:13:08,792 --> 00:13:14,792
research. As looking for each
resource, logging detail,
ideally get full command history
129
00:13:20,083 --> 00:13:25,958
of everything executed on the
system. What will we see?
Specifically some of the
130
00:13:25,958 --> 00:13:32,042
distance between power shell 2
and 3. So we identify five
specific logs that may contain
131
00:13:32,042 --> 00:13:38,042
power shell commands or may
contain some relevant
information related to power
132
00:13:38,042 --> 00:13:45,000
shell execution. The next two
slides will walk through what
happens local versus remote
133
00:13:45,000 --> 00:13:50,250
scenario. Starting with the
power shell event log itself, we
identified two event ids for
134
00:13:50,250 --> 00:13:57,083
104, three contained some bit of
relevant information. Not ideal
if you are looking to fully find
135
00:13:57,083 --> 00:14:03,292
out what was executed. but in
the EID 400 seeing the engine
state changes from none to say
136
00:14:03,292 --> 00:14:08,292
available, indicating that power
shell started. Looking at
generated time of event, power
137
00:14:08,292 --> 00:14:15,292
shell was run on the system at
this time. then in EID 403, done
running. You can two times and
138
00:14:15,292 --> 00:14:22,792
command between X and Y. The
host name consult host indicates
a local session versus a remote.
139
00:14:22,792 --> 00:14:27,542
We will show you what a remote
session looks like in a
following slide. A power shell
140
00:14:27,542 --> 00:14:31,250
operational event log and power
shell 2.0 doesn't contain any
information. We did find one
141
00:14:31,250 --> 00:14:33,708
that contained the same
information that power shell
starting up. You can get that
142
00:14:33,708 --> 00:14:39,708
from the same event he spoke
about previously. Power shell
3.0 and greater, it write for
143
00:14:45,708 --> 00:14:51,708
error messages. A script failed
to run, we get the full path of
the script. In a remoting
144
00:14:54,417 --> 00:15:00,417
session session, if looking at
remote host, you can get the
host name and I T address of the
145
00:15:02,583 --> 00:15:08,625
system attempt together be
accessed. For power shell
analytic logging, those not
146
00:15:08,625 --> 00:15:14,625
familiar, analytic logging is
disabled by default. Debugging
purposes and not for long‑term
147
00:15:17,417 --> 00:15:24,500
retention. We did enable it and
find that power shell contain
relevant information. You can
148
00:15:24,500 --> 00:15:30,500
see here in the 79, 37, the test
dot PS 1 scrypt was run. We can
see a power shell script run.
149
00:15:32,792 --> 00:15:40,375
You can run a native within the
same event I D and finally, a
dropper I D. Run that from the
150
00:15:40,375 --> 00:15:45,417
power shell console, that will
be recorded here as well. What
you don't get from here is any
151
00:15:45,417 --> 00:15:51,708
command or argument, you kind of
get like half way there and then
you want to know how were these
152
00:15:51,708 --> 00:15:57,583
configured and there's better
ways to record this information.
An analytical logging in this
153
00:15:57,583 --> 00:16:03,625
case is probably not worth it.
Moving on to remoting section
here back to the power shell
154
00:16:03,625 --> 00:16:10,417
log, EID6 the accessing system,
we can see that the WS man
session is starting. Looking at
155
00:16:10,417 --> 00:16:16,792
this, you can say from the
system of remote session
starting connecting to another
156
00:16:16,792 --> 00:16:22,750
host. And those not familiar, W
Sman manager protocol used by
win R M which is what power
157
00:16:22,750 --> 00:16:28,750
shell uses for remoting. On the
access system, we have E I D 400
and 403, in this case we see the
158
00:16:31,375 --> 00:16:38,583
serve remote host as a host
name, which indicates that this
is a remote session versus a
159
00:16:38,583 --> 00:16:42,750
local session. In the remoting
situation you are using the
winRN service, specifically here
160
00:16:42,750 --> 00:16:46,958
in EID 169 you can identify who
the user that logged into the
system was, if you don't have
161
00:16:46,958 --> 00:16:52,458
logs going back that far. The
security protocol that was use
Ford authentication. Similar to
162
00:16:52,458 --> 00:16:58,375
the power shell log, the time
frame of remoting activity, the
client request for the shell and
163
00:16:58,375 --> 00:17:04,375
the delete shell. That appears
in multiple event logs. Now
going back to the power shell
164
00:17:14,708 --> 00:17:19,958
analytic log. As far as 2.0 is
concerned, which Brian
mentioned, it is probably
165
00:17:19,958 --> 00:17:25,958
prevalent. I got to pause.
Yesterday a mispronounced
prevalent Back on track. In the
166
00:17:28,417 --> 00:17:34,417
analytic, way of capturing
command execution and responses.
Now to problem is, and well will
167
00:17:42,042 --> 00:17:47,583
get to this. The actual content
written in hex encoded format.
Looking at the log itself
168
00:17:47,583 --> 00:17:53,458
doesn't give any information.
What you will find is that every
piece of information, and
169
00:17:53,458 --> 00:17:58,625
everything that is sent back and
forth between the two host will
record it. The initial protocol
170
00:17:58,625 --> 00:18:04,333
is recorded in the log hex
producing format. You have to
dig through it if you want to
171
00:18:04,333 --> 00:18:10,667
find what was run. Here is an
example of the event log. Here
an object was received on
172
00:18:10,667 --> 00:18:18,375
company man, again, it's in a
hexing encoding format. You
can't tell what happened. If we
173
00:18:18,375 --> 00:18:24,375
decode it, you can see here that
the lines here. You can see it.
The command get char item in the
174
00:18:28,458 --> 00:18:36,417
script, no, not, you can see the
argument pass. You can see ‑‑
Looking at the analytic log now
175
00:18:36,417 --> 00:18:41,958
with a response that is sent
back, a single response that's
sent back to the request in the
176
00:18:41,958 --> 00:18:46,792
system. In power shell we run a
built‑in command, everything
that comes back is in the form
177
00:18:46,792 --> 00:18:52,542
of an object. Each object
returned from this command is
written as a single event in the
178
00:18:52,542 --> 00:18:59,500
event log. If you run this get
trial, it will create enough in
the event log to mass the number
179
00:18:59,500 --> 00:19:04,917
of items within the C directory.
It generates a ton of events and
you have to parse through
180
00:19:04,917 --> 00:19:11,583
individually decode and map back
to what was run and what was
responded. In 2.0, it's not
181
00:19:11,583 --> 00:19:17,750
practical to do this. There are
some other options. The first
one is some of the profiles that
182
00:19:17,750 --> 00:19:24,292
power shell has. Power shell has
multiple profile options where
you can configure code to be run
183
00:19:24,292 --> 00:19:30,458
at any time that power shell
locally starts up. Here an
example of global profile. You
184
00:19:30,458 --> 00:19:38,333
can start record transcript
command input and output. You
can write out to an event log
185
00:19:38,333 --> 00:19:44,083
format if you prefer. We have
seen some companies put together
custom codes overrides the
186
00:19:44,083 --> 00:19:49,667
default prompt so anything typed
in spit out to a file. Some of
the limitations here are like I
187
00:19:49,667 --> 00:19:54,292
mention, this is on for power
shell execution. It doesn't do
anything over remoting. Also,
188
00:19:54,292 --> 00:20:01,125
you can launch power shell by
saying no profile flag, so none
of this codes are run. Again,
189
00:20:01,125 --> 00:20:06,833
it's a solution not the best
answer, but it is something that
can help you out. Also, if you
190
00:20:06,833 --> 00:20:13,333
are using app blocker, it has an
option for enforcing scripting
rules. You can see here, okay, a
191
00:20:13,333 --> 00:20:19,125
script was attempted to run at
this time. Here's the path to
it. Even if not enforcing, it's
192
00:20:19,125 --> 00:20:25,125
another option if you are
running app blocker. Moving out
of power shell 3.0, the best
193
00:20:27,250 --> 00:20:34,542
option we found is module
logging. What it allows is to
get that clear text specific
194
00:20:34,542 --> 00:20:40,625
command input and output in
clear text for anything being
run through the shell. Both
195
00:20:40,625 --> 00:20:47,250
locally and remotely. We will
show you in further slides. Here
we ran a more complex command in
196
00:20:47,250 --> 00:20:53,167
the past. We said get trial item
of C attempt directory
recursively only filter back
197
00:20:53,167 --> 00:21:01,667
files with the .text extension
and do a basically a select
screen in power shell for the
198
00:21:01,667 --> 00:21:10,000
same pass word. The top item
here, you see we captured the
command sent to the system and
199
00:21:10,000 --> 00:21:12,000
have all the arguments being
parsed out and available in a
clear format and at the bottom
200
00:21:12,000 --> 00:21:14,542
you see the response or see the
file that it hit on and the line
where it found the file, found
201
00:21:14,542 --> 00:21:20,542
the hit. Now, this can be
slightly problematic when you
run a script. Each line and
202
00:21:27,500 --> 00:21:33,667
script, each command in the
script will generate own power
shell script. We ran the invoke
203
00:21:33,667 --> 00:21:39,875
mimikatz module in power shell
and doing over 1200 events in
the event log. A large number.
204
00:21:39,875 --> 00:21:44,625
We can't parse through. When we
got to the actual response, we
found it written in clear text
205
00:21:44,625 --> 00:21:49,500
mimikatz output in the event
log. so you can see all the
password hashes here clearly
206
00:21:49,500 --> 00:21:55,500
written in the event log. >> For
this last bit were gonna focus
on, we wanted to talk about the
207
00:22:01,333 --> 00:22:07,333
ways in which power shell code
configured to automatically run
in the system. Attackers like
208
00:22:10,167 --> 00:22:15,375
persistence, if you are look
doing something like back door
or key stroke or car data track,
209
00:22:15,375 --> 00:22:21,375
or track recording, anything
continuously execute on a system
and survive reboot and shutdown,
210
00:22:24,583 --> 00:22:28,958
you need to find persistence
mechanism. This is understood.
There's numerous techniques that
211
00:22:28,958 --> 00:22:34,958
Windows provide well‑documented
from registry, auto start point,
window services, thing like
212
00:22:39,708 --> 00:22:44,917
recurring schedule tasks, use of
the start‑up folder, if you
think about it, persisting power
213
00:22:44,917 --> 00:22:51,167
source, making power dot exe run
with argument of the script. All
of these techniques very well
214
00:22:51,167 --> 00:22:56,958
understood. We will not spend a
lot of time talking about them
because folks have done plenty
215
00:22:56,958 --> 00:23:03,458
of research on that in the past.
What we will spend time on is
per these tense via window
216
00:23:03,458 --> 00:23:09,583
management. One of the reasons
nor that is the power sploit
tool kit includes this as one of
217
00:23:09,583 --> 00:23:15,708
the mechanism that you can use
to persist the code of your
choice. We thought that made it
218
00:23:15,708 --> 00:23:21,875
a target. We seen a packers use
W M I persist, not necessarily
power shell but other things
219
00:23:21,875 --> 00:23:27,083
like C script or J script, the
other built in scripting
component in Windows that
220
00:23:27,083 --> 00:23:34,458
similarly running native and
code. W M I is friendly for that
scenario. To understand that, we
221
00:23:34,458 --> 00:23:40,458
need to step back and explain
how W M I works. This is a big
mess. I will give you a high
222
00:23:44,083 --> 00:23:49,542
level. It's this inventing
infrastructure. It has this
notion of event filter,
223
00:23:49,542 --> 00:23:56,417
consumers and binding between
the two. An event filter is a
query continuously run against
224
00:23:56,417 --> 00:24:02,417
the state of the system. When
it's satisfied, it fires the
consumers that bounds ‑‑ and the
225
00:24:02,417 --> 00:24:09,042
consumer runs something. All of
these things can be set with
power shell using set wmi
226
00:24:09,042 --> 00:24:15,042
instance command. And also as
we'll show you later enumerated
power shell. Event filter, as I
227
00:24:17,333 --> 00:24:22,708
said is the thing that causes
the consumer to trigger. Written
in Wql. Has a simple example. We
228
00:24:27,417 --> 00:24:33,417
have an example of wql that will
fire when the system up time
between 240 and 325 seconds;
229
00:24:36,000 --> 00:24:40,083
basically, a roundabout way of
saying, fire upon startup. The
next one is an example where
230
00:24:40,083 --> 00:24:46,083
instead of relative time, it
says at 12:00 exactly fire. So
that will satisfy the filter.
231
00:24:50,250 --> 00:24:54,417
Two different ways to basically
achieve the same thing,
continuously run something on an
232
00:24:54,417 --> 00:25:00,458
agreed upon interval. The
consumer is what runs when the
filter is satisfied. In this
233
00:25:00,458 --> 00:25:05,125
example we're going to execute
power shell. The trick is
execute power shell to load
234
00:25:05,125 --> 00:25:10,583
what? Where does the evil code
come from? You have a few
options here. The thing that
235
00:25:10,583 --> 00:25:16,833
power sploit does by default is
it puts the code in system wide
or user profile. As Matt
236
00:25:16,833 --> 00:25:22,667
mentioned earlier, load
automatically when power shell
executes. If I create a system
237
00:25:22,667 --> 00:25:28,708
runs power shell without any
options, it loads the profile.
By virtue, it loads the
238
00:25:28,708 --> 00:25:35,042
malicious code. Simple technique
and works nicely. The other
thing is add your malicious
239
00:25:35,042 --> 00:25:41,833
power shell code to argument
supplying to power shell exe and
build into the consumer's
240
00:25:41,833 --> 00:25:47,542
command line. In that case only
limited by the command line
length limit Windows enforces
241
00:25:47,542 --> 00:25:54,042
something like 8,000 characters.
That isn't too bad of a
constraint. The example shows
242
00:25:54,042 --> 00:26:02,000
you can run compressed power
shell code and decompress and
execute on the fly. You can fit
243
00:26:02,000 --> 00:26:08,000
8,000 characters. The easy
solution to find malicious wmi
filter and consumers that run
244
00:26:15,750 --> 00:26:21,750
this is through the use of power
shell. The get wmi company man
lets you filter consumer and
245
00:26:23,958 --> 00:26:30,417
binding between the two. We do
investigation in a lot of large
environments. We pulled 50,000,
246
00:26:30,417 --> 00:26:36,417
100,000 environments to get an
idea of what is and what is not.
What we have seen is that it is
247
00:26:39,167 --> 00:26:44,333
not common to have event
consumers that execute power
shell. That doesn't mean in your
248
00:26:44,333 --> 00:26:48,375
environment it may not be
legitimately used for
administrative purposes. The
249
00:26:48,375 --> 00:26:54,292
bottom line is base line
environment easily and determine
what consumers and filters and
250
00:26:54,292 --> 00:27:00,917
legitimate and look for
anomalies. The other thing you
can do is look at the file
251
00:27:00,917 --> 00:27:07,875
system at the host which this
occurred. This is difficult
because wmi is stored in the
252
00:27:07,875 --> 00:27:15,208
wbem repository. This directory
C Windows system 32 wbem
repository. The files that keep
253
00:27:15,208 --> 00:27:22,042
all of the wmi objects in event
filters and consumers, mainly
objects.data is the key file. It
254
00:27:22,042 --> 00:27:28,792
is this undocumented proprietary
format no documents whatsoever.
Some engineers looked at
255
00:27:28,792 --> 00:27:34,792
briefly. A big ball of hurt.
They don't want to get into. The
bottom line is if you had a dead
256
00:27:37,333 --> 00:27:43,333
disc image from a host, there's
no good way to host it purchase.
You can do strings against it
257
00:27:45,625 --> 00:27:51,708
which can kind of good. Strings
will give you the event filter
and consumer names. If your
258
00:27:51,708 --> 00:27:59,125
attacker was foolish enough to
create my bad ass event filter,
you would be able to find in
259
00:27:59,125 --> 00:28:05,583
object data. You get the command
line. If you discover on a host
this technique is in use, the
260
00:28:05,583 --> 00:28:10,542
attacker is referencing power
shell with arguments, you can
see that in strings in
261
00:28:10,542 --> 00:28:15,750
objects.data. If you are looking
at things I'm examining a
system, did these files get
262
00:28:15,750 --> 00:28:21,667
modified in the time frame
attack activity? It will not
work. Windows is up dated
263
00:28:21,667 --> 00:28:27,667
constantly. They change all the
time. Finally, you should
definitely review all the
264
00:28:31,500 --> 00:28:36,875
profile .ps1 file on a system
that you suspect has been hit.
In most environment, you will
265
00:28:36,875 --> 00:28:42,625
have an empty file. So quick and
easy to check the profile. You
might as well look at it.
266
00:28:42,625 --> 00:28:48,583
Anything in the profile will
automatically execute unless you
supply the no profile argument
267
00:28:48,583 --> 00:28:54,750
to the power shell command line.
Why not check it for malicious
code? Finally, the registry,
268
00:28:54,750 --> 00:29:00,458
this was kind of disappointing,
like many thing in Windows
creating a wmi filter, a
269
00:29:00,458 --> 00:29:07,458
consumer lead to some sort of
change for registry forensically
examined. That was in this case.
270
00:29:07,458 --> 00:29:14,625
The only exception was depending
on the filter you used to create
the condition to fire consumer,
271
00:29:14,625 --> 00:29:20,833
registry team might be created
to a provider that satisfied
that query. The long and short
272
00:29:20,833 --> 00:29:28,125
is the example power sploit uses
run this on this exact hour and
minute, it was like 12:00, in
273
00:29:28,125 --> 00:29:34,125
the example. Creating that
filter registers this key for
win 32 clock provider, by
274
00:29:36,500 --> 00:29:42,250
default this does not exist in
Windows environment. You have to
create a wmi filter that uses
275
00:29:42,250 --> 00:29:47,292
that as its provider. From all
the enterprise scale
investigations done, I have not
276
00:29:47,292 --> 00:29:51,708
seen this key except when an
attacker is using this
technique. Of course there's a
277
00:29:51,708 --> 00:29:56,125
hundred million ways you can
create wmi filters that don't
use that specific provider. This
278
00:29:56,125 --> 00:30:00,792
isn't meant to be comprehensive.
It was an interesting part of
the fact of default behavior of
279
00:30:00,792 --> 00:30:08,750
PowerSploit itself. Other
sources of evidence, if you use
the system internal tools, which
280
00:30:08,750 --> 00:30:15,000
are fantastic, auto runs was
updated a month or two ago.
Version 1d will enumerate and
281
00:30:15,000 --> 00:30:22,583
displays all wmi filters and
consumers in an easy to read
format. I suggest checking that
282
00:30:22,583 --> 00:30:27,500
out. In memory, we didn't spend
a terrible amount of time
examining this. That was mainly
283
00:30:27,500 --> 00:30:33,500
because the memory space of the
wmi relevant processes are
noisy. We didn't find any
284
00:30:36,500 --> 00:30:44,083
reliable way to recover evidence
after the fact. Event logs do
have some wmi, so you can enable
285
00:30:44,083 --> 00:30:51,125
wmi trace logging. If an
attacking register a malicious
wmi, it would generate an event.
286
00:30:51,125 --> 00:30:57,167
Windows does this stuff behind
the scene. The one event will be
buried amongst thousand events
287
00:30:57,167 --> 00:31:03,167
during system up times and roll
off the log quickly. >> Just to
wrap up. We didn't cover every
288
00:31:08,625 --> 00:31:13,208
source available. We have
released a white paper now
public, in a draft format. The
289
00:31:13,208 --> 00:31:20,042
final version out next week. It
has more detail and some of our
research and findings. A few
290
00:31:20,042 --> 00:31:26,042
other places if you look, if all
the other ones we have gone
through turned up nothing,
291
00:31:29,167 --> 00:31:35,417
looking at Windows work station
and a power shell pretext file
created, that can contain
292
00:31:35,417 --> 00:31:40,625
information on either a power
shell scriptures line or power
shell certain files of interest
293
00:31:40,625 --> 00:31:48,125
to you. Now only caveat only for
local execution of power shell.
No remoting here. Also, there's
294
00:31:48,125 --> 00:31:54,000
a single registry that I
wouldn't say relevant, the
execution policy setting. By
295
00:31:54,000 --> 00:31:58,042
default power shell doesn't let
you execute unassigned scripts
this is just to prevent people
296
00:31:58,042 --> 00:32:03,917
from double clicking bad
scripts. Everything else in
power shell, you can bypass
297
00:32:03,917 --> 00:32:11,417
command line with the execution
bypass flag. One situation, the
attacker modified registry key
298
00:32:11,417 --> 00:32:16,750
to allow unsigned scripts rather
than bypassing on the command
line. I don't know if tired of
299
00:32:16,750 --> 00:32:24,250
doing it, they did modify this
key. Network traffic analysis,
since power shell using the win
300
00:32:24,250 --> 00:32:30,250
rm service, looking at the winrm
port so port 5985 and 5986 use
http and https respectively. The
301
00:32:33,125 --> 00:32:41,000
pay load for power shell is
encrypted regardless if its
http. If you are using http, you
302
00:32:41,000 --> 00:32:47,250
can pick up header information
power shell version. In that
case, mentioned previously, the
303
00:32:47,250 --> 00:32:51,083
attacker is using a different
version of power shell than what
they use natively in the
304
00:32:51,083 --> 00:32:57,083
environment. They actually wrote
some ‑‑ did some network
monitoring power shell based on
305
00:32:59,500 --> 00:33:06,375
the version in the headers. And
then looking for anomalies.
Really, lessons learned and
306
00:33:06,375 --> 00:33:12,375
recommend upgrade module logging
possible. Move to a power shell
a version 3 or later and
307
00:33:15,750 --> 00:33:20,542
implementing module is the best
solution. Beyond that and
looking at high level, base line
308
00:33:20,542 --> 00:33:27,167
legitimate powershell usage
usage can be key in identifying
anonymous and malicious
309
00:33:27,167 --> 00:33:34,375
powershell usage. What is
execution policy setting and
does it change? If so, why? How
310
00:33:34,375 --> 00:33:37,750
do you name the power shell
experiment and where do you put
them and looking for other
311
00:33:37,750 --> 00:33:43,750
directories that may not match?
Do you use remoting? Is remoting
enabled by default or only on
312
00:33:46,167 --> 00:33:53,625
certain system and base lining
that usage? What users use it
and from? Is it only admin or
313
00:33:53,625 --> 00:33:59,417
serve admins and work from
similar sub net and base lining
and saying this is what good
314
00:33:59,417 --> 00:34:03,500
power shell looks like in my
environment and looking for
anomalies through the method we
315
00:34:03,500 --> 00:34:09,500
described earlier. >> The bottom
line exception of module loggng,
no perfect solution. There's a
316
00:34:13,250 --> 00:34:18,542
lot of attackers continue to do
it. Taking that step in advance
before an incident understand
317
00:34:18,542 --> 00:34:24,167
how being used can save a lot of
leg work in the future when you
may have to respond. The thing
318
00:34:24,167 --> 00:34:27,958
we find is during your
investigative process, power
shell isn't the lead. It's some
319
00:34:27,958 --> 00:34:32,250
other artifact activity on the
system. As doing forensic and
time line analysis and see these
320
00:34:32,250 --> 00:34:36,542
thing we presented today, you
may get indication that attacker
was using power shell. If you
321
00:34:36,542 --> 00:34:40,875
didn't node to look in these
places and memory, you might
completely miss that's part of
322
00:34:40,875 --> 00:34:46,125
their tool kit and therefore
they might be able to
successfully use it without
323
00:34:46,125 --> 00:34:52,125
being detective in post
compromise. We want to
acknowledge Matt, co author of
324
00:35:00,458 --> 00:35:04,292
powersploit, done a lot of cool
work on attack research with
power shell. As has Joseph,
325
00:35:04,292 --> 00:35:10,250
Chris Campbell, Microsoft has
reached out. I want to thank Lee
Holmes. The folks at Microsoft
326
00:35:10,250 --> 00:35:17,708
are aware of folks using it.
It's under the context of
attacker who is already in the
327
00:35:17,708 --> 00:35:22,792
administrator on system. All
bets are off from security
standpoint. They are working to
328
00:35:22,792 --> 00:35:28,458
make it more audit friendly and
easy to monitor. There will be
some cool stuff coming down the
329
00:35:28,458 --> 00:35:34,042
pike make it easier for those
running in their environment. I
think good thing will come out.
330
00:35:34,042 --> 00:35:41,917
Thank you for your time and
attendance here. If you have any
questions, it looks like we have
331
00:35:41,917 --> 00:35:47,917
a couple of minutes. Step up to
the microphone. We will answer
them. You want to talk to us
332
00:35:50,333 --> 00:35:56,333
directly, catch us after the
talk or email us or hit us up on
Twitter. At this point I will
333
00:36:00,208 --> 00:36:06,625
stop for any questions. Sure.
Could you go up to the mic
please so it gets caught in the
334
00:36:06,625 --> 00:36:12,625
recording. We will repeat it. >>
AUDIENCE MEMBER: [Indistinct
speech] >> The question
335
00:36:21,542 --> 00:36:29,292
recommended powershell 3, not up
date to 4? Not that I know . You
can just as well update to 4.
336
00:36:29,292 --> 00:36:34,292
They don't make it automatic.
There were a couple of things
that were deprecated between 2
337
00:36:34,292 --> 00:36:39,292
and 3 ,they're exceptionally
minor, for the small pool of
people using power shell for
338
00:36:39,292 --> 00:36:46,417
exchange event management, you
may not want to break things. I
would check whether the thing
339
00:36:46,417 --> 00:36:53,750
you are using in 2.0 not broken.
2 to 3 was the major change.
Does that answer your question?
340
00:36:53,750 --> 00:36:59,750
ANNOUNCER: Yes. >> Any other
questions? Once again, if you
want to talk to us directly, we
341
00:37:05,208 --> 00:37:10,542
will be here. You can reach out
to us via email. You guys were
great. Appreciate you having us
342
00:37:10,542 --> 00:37:12,542
here. (Applause) [End of
session] "This text is being
provided in a rough draft
343
00:37:12,542 --> 00:37:14,542
format. Communication Access
Realtime Translation (CART) is
provided in order to facilitate
344
00:37:14,542 --> 00:37:16,542
communication accessibility and
may not be a totally verbatim
record of the class." PAGE PAGE
345
00:37:16,542 --> 00:37:18,542
20