Alright, let's take a look at Module 6 where we're going to be dealing with Steps 3

through
5 of the hacking cycle in system hacking.
So system hacking covers gaining access, maintaining access, and covering tracks.
Everything we've collected in the previous modules is now going to be leveraged to
find
a vulnerability in a way to gain access to the system, potentially escalate
privileges,
maintain access, and then cover up any evidence of compromise, oftentimes through
the clearing
of log files.
Alright, so there's two basic ways to gain access to a system and a bunch of
subcategories
within.
One is to crack user passwords, and the other is to exploit system vulnerabilities,
which
lots of possibilities around that.
When you log into a system using Type 1 authentication, which is by the way the
weakest type of authentication
we have, Type 1 something I know, Type 2 something I have, Type 3 something I am,
which
we should use at least two factor authentication because passwords in the grand
scheme of things
are horrendously insecure, usually due to user error.
So we'll talk more about that here in a bit.
But if I'm going to verify that the password a user has just typed in is correct,
that
means the password to verify the match against has to be stored somewhere on the
box, which
then starts the whole thought process of why wouldn't attackers just go after the
password
storage, compromise the stored password, and then use that to gain access to the
system.
The answer to that is they would.
So we make passwords on the system difficult to retrieve through a protected
location in
the fact they're encrypted with non-reversible encryption, they're password hashes.
So the password hash can't be immediately reused.
You have to crack the hash, which can't be directly reversed, it has to be
recreated
over and over and over again until you get a match by running password candidates
or
attempts through the known algorithm resultant output is matched against the hash,
if it
matches up, ding ding ding ding, I'm in, if it doesn't, I'm on to the next attempt.
So that can be incredibly time consuming, but definitely possible.
So the password storage locations on Windows systems for non-domain controllers is
the
SAM database found in the system 32 config directory.
There's also the NTDS DIT file, which is the storage location on an active
directory domain
controller.
In Linux systems, it's typically a file called shadow.
Now there's a password, P-A-S-S-W-D, and a shadow file.
The password file contains user accounts, the shadow file contains the hashes.
Within the NT family of operating systems authentication options, you have NTLM,
which
consists of NTLM and LM, which is outdated and insecure, we'll talk about that, and
then
Kerberos authentication, which has been around since Windows 2000 came out, which
is a much
more secure way to authenticate users, we'll talk about why that is, but there is a
possibility
of falling back to NTLM if Kerberos won't work for whatever reason.
So when we crack passwords, we're trying to guess at the correct password until we
happen
to match the result in hash output.
All right, so that's what users and user relative identifiers and password hashes
look like
in the SAM file, which is again in the System32 configure records, one of the
registry files.
So I don't know what this is, I have to figure out what I run through the hash
algorithm
to actually produce that.
LM hashes have been disabled in Windows, Vista, and later operating systems because
it's a
really, really weak form of encryption.
I'll talk about that when we show examples of work factor for performing rule-based
brute
force attacks.
All right, so I retrieve this file, I retrieve the hashed passwords in the file,
and then
I go through a trial and error process until I can produce the same hash.
So the NTLM authentication process and Kerberos, let's talk through those, and then
I'm going
to show you a password crack against a locally captured password from the SAM file,
and I'll
show you one through an NTLM authentication.
Actually, before we do that, let's go and set the stage for it.
All right, on my server 2019 machine, I'm going to fire up a oldie but a goodie,
the
Kane password cracking utility.
It's actually a multifaceted security tool, but in this capacity, we're going to be
looking
at password cracking.
I'm going to go to the cracker tab, and I'm going to dump password hashes from the
local
system.
Using a dump from the live registry option, I'm not going to worry about password
history
hashes right now.
I can import from local system, from a text file, or from a captured SAM database,
which
the captured SAM database is encrypted using RC4 128-bit, so you'd have to have the
decryption
key for it as well.
I'm going to click next, and since I've got system admin privileges, I can dump
those
Now, a little bit later on, we're going to talk about privilege escalation.
So if I compromise a box using an average user account without admin privileges, I
will
not be able to dump password hashes, I'll have to escalate my privilege, but we'll
get
to that here in a bit.
All right, so this is my password hash for JSON, this is my password hash for the
administrator
accounts.
Now, we're typically going to know what the algorithms used to store the passwords
are,
that adheres to something called Kirchhoff's Principle.
We know how it's done mathematically, we just don't know what the actual password
is.
So we can run our password candidates or attempts through that process over and
over and over
again until ding, ding, ding, ding, we just happen to match that same 32 character
hexadecimal
hash.
All right, so the ways we go about doing that are dictionaries, hybrid brute force
attacks.
We're going to hold off on that or rainbow tables, we'll hold off on that for a
second
until we get to the corresponding slides.
So that's a locally dumped password file, which I can then directly crack the
captured
hashes.
There's also capturing online authentications or communication dialogues across the
network.
The NTLM authentication process prevents password hashes from being immediately
replayed
and reused by incorporating a challenge response mechanism into the process.
So in a nutshell, when Sheila goes to log in to the domain controller, she sends
her
name, the domain controller sends back a challenge that is going to be matched
against her submitted
username and password.
That challenge string is 64 bits of data, which is unique every time.
You're not going to see the same challenge twice.
All right, the attacker eavesdropping on all this, they can definitely sniff the
exchange,
but they can't immediately replay it as if it was just a transmitted password hash.
Since the challenge string is unique to every authentication attempt, Sheila's
challenge
response back is actually a combination of her password hash plus the challenge
equals
the challenge response.
It's actually hashed as well.
So the attacker can't just replay that in a subsequent login attempt because
they'll
give it a different challenge string every time.
So challenge handshake prevents replay attacks by incorporating a unique challenge
string
every time.
So it protects the user's password and the replaying of the password since each
dialogue
will be unique.
But I can still capture that and I can still attack it.
So let's see that in action.
All right.
If I turn on my sniffer and I log in from another machine.
Now we're going to fill in some blanks on this here when we get to the sniffer's
module.
But for now, let's just say I'm on a hub network and I can sniff an authentication
dialogue.
I'm going to log into the victim C dollar sign account, put in my username and
password
and I just authenticated to the admin share.
On my cane box 2019, I've captured a server message block protocol login with a
successful
result.
I can send that to the cracker to be cracked alongside my dumped password hashes.
So if I was to select NTLMv2 hashes, I can crack that just like a locally dumped
password
hash.
But we haven't done that yet, so we're going to come back to it.
Okay.
Kerberos on the other hand is much more secure in the fact that your password never
crosses
the network, just things encrypted with the password, which you don't know what
they are
to begin with.
So you have an unknown encrypted with an unknown.
You would never even know that you've decrypted intelligently.
Now there's definitely more to this.
I'm going to simplify it.
When you log in to a Kerberos key distribution center, i.e. domain controller, it
runs to
services, authentication server and ticket granting server.
When I log in for the first time, that business day, for example, typically eight
to 10 hour
timeframes, I'm going to need to get a ticket granting ticket, which is my master
authenticated
ticket for an eight to 10 hour duration.
So I request from the authentication server a ticket granting ticket.
My name is actually sent with a request.
So the server looks me up in the database, sends back a TGT that's encrypted with
my
password.
All right.
That TGT's symmetric key information is unknown to a eavesdropper, like an
attacker, and then
it's encrypted with my password, which is held in memory.
So Eric and password are held in memory.
They never leave the machine.
They can't be captured.
The TGT is decrypted with my password stored in memory, and then it's replayed
against
a ticket granting server to request access to other resources.
Each subsequent session ticket or TGS, ticket grant, session ticket ST or service
ticket
has a unique symmetric key that's encrypted with my password, and then the trust
account
password to serve, for example, and I'm gaining access to both unknown factors.
So an attacker is not going to like that because even if it intercepts any of these
tickets,
these encrypted symmetric keys, it doesn't know what they are to begin with.
It's never going to know that it decrypt them correctly.
So you have an unknown encrypted with an unknown.
There's nothing to go on here.
So that's the strength and curb us.
There's more to it than that, but that's the basics.
I'm going to match handshake.
I capture the challenge and the response, and I can guess at that password piece
until
I happen to match the response, and I'm going to do that here in just a second.
So Kerberos.
We've had that since Windows 2000.
It's been around for decades, but you still see fallback to NTLM or even weaker
forms
of authentication if the Kerberos fails potentially now that can be reconfigured in
the domain
policies.
But by default, there's still a huge tendency to lean towards functionality, which
is away
from security.
So if there's a problem, you got to get those systems talking.
Let's fall back to something less secure and you can negotiate down to a weaker
form of
encryption.
All right.
So now that we've discussed local password storage, NTLM and Kerberos, let's go and
crack
a couple of passwords.
Password cracking techniques are used to recover passwords from computer systems,
got it?
Passwords can be guessed, lent, stolen, cracked, et cetera, they're the weakest
form of authentication
we have.
They're an example of type one, something I know authentication.
Type two is something I have in my possession, like a smart card, RSA security
token, and
then type three is something I am biometrics.
So passwords, if I present a password, does that actually prove I am who I say I'm?
Not really.
It's possible you're not Eric, you still want Eric's password and you're
authenticating
as Eric, but you're not really Eric.
So the weakest form of authentication we have, but the most widely used.
So most of your password cracking techniques are successful because of weak or
easily guessed
passwords.
When people use something that's easy to remember, generally it has some sort of
personal meaning
to them, pets names, birth dates, anniversary dates, and so forth.
That kind of stuff can be recovered from social media sites and through footprint
reconnaissance
and social engineering.
So password cracking is going to fall into non-electronic and electronic varieties,
shoulder
surfing, social engineering, and dumpster diving.
We actually talked about these in our second module, footprint reconnaissance.
Active online attacks.
Remember that active means I engage the target system actively, dictionary brute
forcing,
rule-based hash injection, a bunch of different examples of that.
Passive online means that I'm sniffing the password exchange and I just did that.
I didn't do anything active, but I sat back and took in the password challenge
handshake.
I used wire sniffing for that.
Later on, we're going to talk about how hard that is on a switch network and why we
need
man in the middle and replay attacks to make that happen.
And then an offline attack is where I take what I've captured online and I take it
offline.
I go out in the shed, the garage, the shop, whatever, I close the door and I go to
work
on that thing.
There's nothing to stop me from trying, trying, trying, trying in an offline
attack.
You don't get locked out after three and a half attempts.
You can keep on trucking until you're successful.
It just may take a gazillion years.
So the strength in a password and its security is how resilient it is to brute
forcing attacks
and that goes to length and complexity.
I'm going to illustrate that here in a second.
All right.
So those are our basic categories.
All right.
Social engineering, convincing people to go out passwords, it is frightening how
easy
it is with the right pretext to get somebody talked into giving up their password
over
the phone.
Doing pen tests all the time, social engineering, phishing attacks, mods to a
flame, my friends.
All right.
Shoulder surfing.
Somebody types in a password at the Starbucks, local coffee shop.
You set up video recording equipment or with your two eyes.
And then dumpster diving again, jot things down on a, on a scrap of paper, throw it
in the trash, sticky notes, things like that may contain passwords.
All right.
The dictionary, the brute force and the rule-based attack.
Okay.
These are different ways you're going to feed the password cracker with the next
password
attempt.
So in a nutshell, I need to figure out, say that the password hash I'm trying to
crack
is H99.
Now that's a big long 32 character hexadecimal string, but I'm not going to torture
you
with me drawing out 32 characters of hexadecimal hash every time we talk about
hashing.
So imagine H99 as a unique hash value.
I need to figure out what will equal H99 when run through the hashing algorithm
that is
used by the target operating system.
So for example, in a windows operating system, we know the exact process, the
password is
run through to produce the hash.
And we just repeat that process over and over again with different candidate
passwords from
a source that's either automated or manual.
Now manual is going to go really, really slow.
I'm going to tell you, is it Apple?
Is it banana?
A word list or a dictionary file takes a word list, Apple, banana, cat, dog,
elephant,
ferret, and so forth, and just takes each word one at a time.
So Apple, you run it through, produces hash 18 or 81 or whatever, doesn't match.
Banana, hash 44, no match.
Cat, hash 99, ding, ding, ding, ding, ding, we got a match.
Now usually you're not going to get it in the first three attempts, but that's how
it works.
You will try on error until you produce the right hash.
Now here's the scary thing.
If you happen to produce a collision, which means a different password just happens
to
produce the same hash, that will authenticate you to the system like the real
password.
The system doesn't know what the password is.
It just knows what the hash should be.
So if you get a collision, you're in, even with the wrong password.
Yep.
It's called a birthday attack.
Frightening.
Yeah.
So we're supposed to use hash collision algorithms like SHA-2, SHA-3.
What happens though if my password is not in the word list?
Well, thanks for playing.
Game over.
What if the password was actually cat 07?
Well cat 07 is probably not in a dictionary list, but if I was to use a
hybridization
attack where I add random characters to each dictionary word, like apple 00, apple
01,
02, 03, 04, et cetera, and if I added two-number randomization, I would increase
the number
of attempts, but I would catch variations on those dictionary-based passwords.
So eventually I do cat 01, 02, 03, 04, 05, 06, 07, ding, ding, ding, ding, I got a
match.
I would catch variations.
So hybrids add random data to the dictionary root words for the dictionary file.
The dictionary attack will always be the quickest to run, shortest time frame, but
also not
guaranteed success, since if the password is not in the dictionary list, you're not
going to guess right.
Brute force attacks on the other end of the spectrum will try every possible
combination
of characters in a methodical manner.
Is it A?
Is it B?
Is it D?
Is it AA?
Is it AB?
Is it AC?
Is it AAA?
Is it AAA?
Is it AAB?
And try every combination like rolling up an odometer in a car.
You go through all the possible combinations.
It's an exhaustive brute force attack, but guaranteed to be successful eventually.
It may be thousands of years from now, but eventually I'm going to guess right and
I'm
going to crack the password.
So word list, pretty straightforward, hybrid, add characters to the word list,
brute force
every possible combination of characters one at a time, and then there's rainbow
tables
where you generate your hash tables ahead of time, which can save you time after
the
fact because once you've created the table, you've got the password and the hash in
a
table, then you can instantly decrypt any passwords for which you've generated
hashes.
So let's say later on I save my work on this brute force or dictionary attack and
later
on I need to attack or crack hash 44.
Well, ding, ding, ding, ding, that's banana.
I've got it in my rainbow table.
That's a little bit more involved than that.
Rainbow tables take as long to generate as it would be to crack the password in the
real
time.
They also take up tremendous amounts of space potentially.
They're also completely neutralized if you use second variables like salts or
peppers.
All right, so let's take a look at the password crack, the dictionary attack
against Jason's
account.
I'm going to right click dictionary attack and TLM hash.
The dictionary file I'm going to add to the list and Kane is good enough to include
a
word list for us in the installation directory.
This has 306,706 passwords in it and I will make short work of that dictionary
file.
I'll select it.
I'll also choose different permutations of the password as is, reverse it, double
it
up, lowercase to uppercase conversion, et cetera, et cetera, two number hybrid
brute
force attack.
All right, let's let it rip.
I'm going to hit start and my new I9 box is way faster than my old boat anchor
system
that finally failed on me.
I got the password QWERTY in a relatively short time and I was rolling along at,
let
me go after Martin real fast, I got the talking here and I didn't point out the key
rate.
I'm rolling along at about 3.8 million, 4.0 million passwords per second.
It didn't take me long to exhaust that word list.
All right, Martin's password was apple.
Got it pretty quickly.
So depending on where the password exists in the word list, if it's in the A's,
it's
probably get picked pretty quickly.
What happens if we don't get the password in the word list attack?
Then you move on to a brute force.
So the administrator account, for example, is more complex.
I'm going to brute force that with an NTLM hash.
This is where rule-based configuration comes in.
So I need to define a character set and a minimum and maximum length.
This means I know something about the password requirements and I program the
cracker to
only attempt passwords that match rules.
So minimum and maximum length of one, that's just 94 characters.
I'm going to crack that instantaneously, but it's not one character long, so I need
to
move on.
Two characters, 8,930 instance.
Three characters, 839,420 instance.
Four characters, 78,905,480.
About five seconds.
Six characters, 7,365,508,562.
That's going to take me about six minutes.
Rocking 18 million password attempts per second.
Password attempts per second.
Up at six characters, now it's going to take me about 10 hours.
Up at seven characters, now it's going to take me about 41 days.
Up at eight characters, now it's going to take me about 10 years.
So there's usually a substantial jump between seven and eight characters, but
that's completely
dependent on the processor power of the system during the cracking.
If you get multiple graphics cards going, multiple CPUs, you're going to reduce
that
work factor by increasing the key rate.
So many hands make light work, my dad always said.
If you can distribute that across multiple systems, you're going to expedite the
cracking
process.
All right, so that's a dictionary.
That's a brute force and a hybrid type of attack.
So eventually it's going to guess right, ding, ding, ding, ding, you're going to
get a match.
All right, back to my NTLM hashes, which I can also crack even though it was
challenge
response.
I'll do a dictionary attack, reset the dictionary file position and click start.
And notice this runs at about 20% of the key rate that I saw with a non-challenge
handshake.
There's just more math involved.
So more math to do, the key rate, but it will eventually get to password, which is
what
the password is.
The P's in the word list and eventually be successful.
So let that cook for a second.
And that describes dictionary brute force and rule based attacks.
All right, other types of attacks, a password spraying attack is retarget multiple
user
accounts simultaneously and crack the passwords using a small set of commonly used
passwords.
So instead of using the same user accounts for multiple password iterations, which
gets
you locked out in a live situation, you're going to rotate those user accounts and
use
password lists and try not to lock anyone out and try to get a match.
So password spraying is where you're again blasting away multiple user accounts
with
commonly used passwords.
Crack map exec is one example.
And then the mask attack.
And then you might hear credential stuffing used alongside the password spraying
discussion.
Credential stuffing is where I've captured a username and password from a website,
a
known set of authentication credentials, which we all do it, come on.
We all use the same username and password for at least two accounts, come on, we do
it.
Then you blast those credential pairs against random websites hoping to get a
match.
That's called credential stuffing.
All right, mask attack, attackers recover passwords from hashes with a specific set
of characters based on some information or the attacker.
So hashcat is a well-known password cracking utility does have a mask attack mask
attack
option.
All right, password guessing, right?
So is it this?
Is it this?
Is it this?
That sounds painfully slow.
Your failure rate is high because typically after one, two, three and about
attempts,
you get locked out.
Count lockouts, great mechanism for preventing online authentication attacks.
Offline, however, nobody watch it.
So I was able to run through millions of possibilities and not get locked out.
That's because I'm not logged into a live system.
Default passwords.
We mentioned this before.
If you do a Google search for default passwords, there are websites dedicated to
the cataloging
of default passwords, cert.net, datarecovery.com by vendor and by products.
So again, default configurations, definitely a vulnerability.
Our active online attacks, Trojans, spyware and keyloggers, which we're going to
have
the full Trojans, spyware and keylogger discussion in malware threats.
We're going to introduce the concepts in this module and we're going to talk a lot
more
about it in our next module, module seven, which is a great extension of our
initial
discussion in system hacking.
Keyloggers, log keystrokes, plain and simple.
It's a certainty that sooner or later you're going to type in something sensitive
through
the keyboard and a keylogger is there to capture your keystrokes.
They're often implemented as a component of spyware or a Trojan, which will have
the formal
introduction and definition of tomorrow morning.
So you get infected.
That malware collects your keystrokes, hands it back to the attacker, looky, here
are some
passwords.
All right.
They also typically collect local password files, stored credentials for websites
and
a bunch of other stuff.
Okay, a pass the hash attack is you don't have to crack the hash, you replay the
hash.
There's actually two ways to do this.
One of them is to rewrite your authentication token after you've logged into a
windows machine.
If I am logged on to a local box and another account with privilege is also logged
on and
I have system level privilege, I can actually access utilities like the windows
credential
editor.
I can look at my authentication token and I can clone the username and password
hash
of another logged in account.
I can then use that to present myself to other resources and move laterally through
the network.
The most classic utility for doing that has got to be Mimicats, which we'll see
referenced
in later slides.
But original credit goes to Hernan Ochoa with core security who wrote the original
pass
the hash toolkit to executables.
One was called who's there and the other was called I am.
What do you think those do?
Who's there?
Who's logged in?
Domain admin.
I am domain admin.
Rewrite your own session token.
So Mimicats pass the hash toolkit.
The other option is where you compromise a password hash and then you just append
it
to a challenge and hash it in an NTLM authentication.
You don't have to crack the password, you just have to replay the hash and that's
definitely
a weakness in NTLM where you can just concatenate it and hash it and send it back
as a response.
The other issues with capturing passwords typically revolve around the fact we use
switch
networks.
In a switch network, I don't see anybody else's traffic.
We'll have that full discussion in the sniffing module, but for now suffice it to
say everybody's
on their own dedicated port on a switch and we don't see anybody else's traffic.
If I want to capture your password handshake, how am I going to do that if I can't
see the
exchange?
So the answer to that often is man in the middle, replay and forwarding attacks,
which
again we'll talk about that in module eight.
LLMNR, NBTNS poisoning is a way to spoof your identity to impersonate a server.
So in a nutshell, when a broadcast is made for a host name resolution, NetBIOS name
or
host name LLMNR, then a broadcast says, hey, who's file server one?
And then file server one goes, oh, that's me.
Here's my IP address.
Connect to me.
What's to stop an attacker from impersonating the response from file server one?
So hey, who's file server one, I am.
Attacker jumps in, beats the legitimate response back, says this is my IP address
and now they're
masquerading as or impersonating that file server.
Now you send them a challenge, they send the challenge response and you're now
privy
to the challenge handshake response or otherwise you're not going to see it.
So link local multicast name resolution is used as a replacement for broadcast in
IPv6
networks.
NetBIOS over TCPIP uses old school broadcasts.
So any way you slice it, the responder tool will respond to requests for name
server,
for name resolution and falsify or impersonate the response and then collect the
challenge.
You'll be doing a lab on LLMNR, MBT poisoning using responder.
Good stuff.
All right, Kerberos passwords.
We just got done talking about the fact that Kerberos exchanges are much more
secure because
there's really nothing to crack like the challenge handshake.
So instead you try to compromise tickets, session tickets from the KDC.
So AS rep-roasting or Kerberosting is trying to crack the tickets themselves if
they've
been captured and turning those into an intelligible form.
So the TGT should be, again, should be issued at the beginning of the workday for
example
and then that sits in your ticket cache for 8 to 10 hours.
If I could compromise the victim system and I could compromise that TGT, I could
brute
force it and try to turn certain fields into intelligible fields.
Kerberosting is going after a ticket granting service ticket, try to get service
account,
trying to crack the ticket to obtain the user's password.
So both of these require access to the ticket, which oftentimes is done by
compromising the
system where the tickets reside.
Mimicats, the pass the hash toolkit utility also has a pass the ticket attack.
So on that one, again, if I'm on the same system with another login account, I can
take
their Kerberos tickets, TGTs, I can then replay those as my own and impersonate
just like
a pass the hash.
So Mimicats does both pass the hash and pass the ticket.
Wire sniffing.
We're going to have the full wire sniffing discussion in module 8, but we've
already
shown an example that a wire sniffing is meant to retrieve useful information off
the wire.
It typically involves something active in nature to accomplish sniffing in a switch
network.
So we will talk more about wire sniffing in module 8.
We'll come back to it.
Sometimes though, wire sniffing is performed by implementing a man in the middle
attack.
So the attacker fools the victim into thinking it's the server and vice versa and
sets up
a man in the middle or replay attack where the victim sends to the intermediary and
it's
forwarded on and that gives the attacker the opportunity to intercept and then
crack what's
not directly readable, right?
So clear text obviously would be immediately reusable.
Anything that's sent as an encrypted form would have to be cracked.
So there's plenty of examples of man in the middle attacks, different layers of the
OSI
model.
So we're going to talk about layer 2, layer 3, layer 7, impersonating access
points, there's
bunches of ways to do that.
The rainbow table.
So the rainbow table, remember my password crack using Kane, it was going to take,
you
know, 20 years to complete.
But once I completed it, if I created that table and I held on to it, I could
immediately
decrypt anything created in that table and I was thinking I actually left that
open,
but I didn't.
So the rainbow table takes time and effort to generate and lots of storage space,
but
once you're done, instantly decrypts anything within the range that was used to
generate
the table.
So time-space trade-off, lots of storage space, rainbow tables that you download
from the
internet that are smaller footprints, 50 gig, things like that are much more
limited character
sensor key spaces and they're not ever comprehensive.
You'll never find a rainbow table for all 127 characters of Windows password, it
would
be monstrous and take eons to generate.
Rainbow tables are also easily defeated by using salts or peppers, which are second
values
added to the password before it's run through the algorithm.
So we mentioned rainbow tables and then we kind of walk away from it for a while
and
come on back.
But rainbow tables can be effective for application password crackers and again,
anything where
you're not using the salts or peppers, otherwise you'd have to know the salts to
actually create
the table ahead of time and salts have a tendency to be variable, for every
password change
they get changed.
All right, so rainbow tables we're going to come back to when they talk about
salts.
Offline attacks, distributed network attacks, this is just getting multiple systems
working
on the same job.
So a DNA attack involves multiple agents running in a coordinated fashion by a
manager
and you just divvy up pieces of the key space to different agents and they go to
work on
breaking it apart into smaller tasks and then running through their particular
portion of
the key space.
The DNA manager manages the whole thing when an agent has finished its piece of the
pie,
it trades it in for another and the whole thing is coordinated centrally and
distributed
across multiple nodes.
So that could be grid computing, parallel processing, cloud environments, etc.
Graphics cards again are multiple cores, you know, working in concert.
All right, PW dump, tools to extract password hashes, typically are going to use
one of
two methods.
There's the LSAS vulnerability method and then there's dumping from the library
registry.
If you've seen one password dumping tool, you've seen them all, PW dump, FG dump,
cane,
loft crack, rainbow crack, etc., etc., mini-cats, all dump using these exploits or
these techniques.
Once they're dumped, the password hashes are cracked using a cracker and we've seen
how
that works already.
These tools must be run with administrative privileges, important note at the
bottom of
the slide.
Rainbow crack, pretty famous.
Rainbow crack was one of the first tools to generate rainbow tables and use them to
crack
passwords.
Time memory trade-off algorithm to crack hashes.
There are other rainbow table generation utilities without a doubt.
Other notable password cracking tools, which again, if you've seen one, you've kind
of
seen them all.
They all have dictionary brute force hybrid types of attacks and potentially, and
you
can figure them pretty similarly, GUI or command libraries.
John the Ripper, definitely famous.
Hashcat, really good stuff.
CHC Hydra and Medusa, Hydra is more for online password cracking, Hashcat and John
the Ripper
more for offline or cracking captured hashes, Secure Shell Brute Forcer, can't
actually
say I've ever used that one, plenty of Hydra, plenty of John the Ripper, plenty of
Hashcat
and Cain every time I teach a CH class and then still love Cain, which I'm going to
clarify
something here.
Sometimes Cain gets bashed as being an old dated tool.
Well a 66 Mustang is still a classic and still does the job.
Cain is still monstrously effective.
It's been around ever since I've been in IT or longer, so 20 years plus, and it
still
does a great job.
So it's also one of the most inclusive tools in functionality in one toolkit and
you don't
have an equivalent on Linux.
So that's like one of the few scenarios where Windows has an advantage over Linux
systems
as far as available tools.
So Cain, no matter what you've heard, it is still going strong, really powerful
utility.
You've already seen it in action.
It's been established for quite some time.
Alright, salting is an extra value.
Whenever you change anything about the password and you run it through the
algorithm, you're
going to completely change the hash.
So salt makes it more difficult to reverse the hashes, defeats pre-computed hash
attacks
since it's an unknown variable and unknown to the rainbow table creator at the time
of
generation.
Salting is a variable, peppering is a fixed value within the algorithm.
So the same password would have different hashes due to the different salts.
Now you can definitely still crack that by incorporating the salt into the
algorithm
if you were to capture the password file.
Alright, then we get to vulnerability exploitation, which we've already had this
discussion to
a degree.
We did vulnerability analysis in the previous module, looked at discovered
vulnerabilities
and then we determined what exploits were available and then we actually used the
exploit
to exploit the box.
So with vulnerability exploitation, we've already had most of this discussion,
identify
vulnerability, risk, capability, develop the exploit.
A lot of times exploits are already developed.
Select the method for delivering local remotes, generate, deliver, payload, get in-
road access
and we already did it.
Also this local or remote, we didn't really spend a lot of time on that, but an
exploit
may require you have access to the box.
It may be something that can be run due to an insecure listener.
What we looked at in vulnerability analysis was network-based exploitation of
vulnerabilities.
We had an insecure RPC endpoint listener.
We also mentioned that as time goes on, Windows OSes become more hardened against
those types
of attacks.
It may not be possible at all, so I may need to perform a client-side exploit, get
on the
box, and then elevate privileges by executing the exploit locally.
So your exploit sites, as we looked at in the last module, exploit database, CVE,
VolDV,
vulnerability database, VolDV.com, the exploit DV is probably the most established.
That's maintained by offensive security.
Again, the CVE is the most established index or catalog of known vulnerabilities.
All right, the buffer overflow.
So this is one of the most classic types of vulnerabilities.
It deals with a lack of validation of the length of user-supplied input.
In a nutshell, address spaces and restrictions are logically enforced by the
security kernel
You don't get access to areas of memory that are off-limits or restricted, but you
may
have access to physical memory spaces in close proximity.
You may be able to flood that physical memory space with unexpected over-the-long
input.
Now this can get really involved, and your lab on this is very detailed.
So pay close attention to what you're typing in the lab.
There's a possibility you're going to have to start all over again.
Again, it's like 170 steps, but it'll walk you through the identification and the
exploitation
of a buffer overflow.
So in a nutshell, you have stack and heat-based buffer overflows, format stringers,
and a
couple other flavors, but the stack-based overflow is you're overriding the stack
of
running process.
In a nutshell, you're going to overwrite a return address pointer that points to
malicious
code that you've dropped onto the stack by exploiting another physical memory
location
that happens to be close to the stack location and floods into the stack location.
It hijacks the stack of the workspace, running under a more privileged security
context,
and you execute your malicious code by pushing the code into the stack or onto the
stack
and then overriding a return address pointer.
Now again, you're going to walk through this step-by-step in the lab, but I'm going
to
walk you through the basics of buffer overflow exploitation.
And this is not something that you're going to be doing day in and day out.
So actually finding buffer overflows and constructing an exploit is some pretty
manual stuff.
Not a daily driver type of activity, but we definitely want to cover it.
Heat-based overflows, a little bit different memory space.
We're not going to spend a lot of time on the heap.
We're going to be looking at a stack-based overflow in the lab, and the
exploitation
involves multiple steps.
We actually have an eight-step process, which involves first performing spiking.
In spiking, you're sending crafted packets to the server to make it crash.
That helps to identify buffer overflow vulnerabilities in the target application.
So if the thing crashes, it may be vulnerable.
Then, and this is actually an examination of the code debugger, then fuzzing is
sending
unexpected input to the application, large amounts of data, so that it experiences
the
buffer overflow and overrides the EIP register.
It helps to identify the number of bytes required to crash the server.
In a nutshell, you've got to figure out exactly how far you need to push to flood
the buffer
and overwrite the return address pointer.
It helps us to locate the extended instruction pointer register, which tells us
where to
inject malicious code.
Then you identify the offset, which is, again, exactly where the EIP register is.
Again, you're going to be doing all this in the lab.
Then you will overwrite the EIP register with malicious shellcode.
Identify whether it can be controlled or overwritten with malicious shellcode.
You're going to send, and again, you're walking through all these screenshots
they're going
to walk you through in the lab.
Again, identify bad characters before injecting the shellcode.
Identify bad characters that may cause issues with the shellcode.
Identify the right module.
The attackers identify the module of the vulnerable server that lacks memory
protection.
A debugger can be used to analyze the memory space, and you're going to be using
the debugger
throughout the process.
You're going to attach the process to the debugger.
That allows you to dump the memory space and allows you to see exactly what's
happening
in memory.
Generate shellcode and gain access.
The shellcode will be the payload.
You're going to use the Metasploit Framework Venom command to generate shellcode
and inject
it into the register.
All ADBG is a debugger, and that will actually exploit the box.
I feel like we had an extra step there.
Again, you're going to walk through this step-by-step.
There's by far and away the longest lab in the course, and it weighs in at 170
steps,
so grab some coffee before that one for sure, and plan on restarting it at least
once.
The first time I ran through that lab, not a developer of my background, certainly
don't
do manual memory analysis.
I had to do it twice before it, actually the third time was a charm.
So pays close attention, read every line, type in everything as advertised, double
check,
and I'll mention this in the lab videos as well, but double check your input before
you
hit enter.
Buffer overflow detection tools, the two primary tools that we use for code
analysis are debuggers
and disassemblers.
Disassemblers will turn compiled code into assembly instructions.
Debuggers actually show you the memory space that's being occupied by the process.
All right, then we get into privilege escalation.
Privilege escalation is where you either go up or you go sideways.
Horizontal means you get the privileges of another user at the same level.
Why would I ever care to have the privileges of another average user?
Typically permissions-oriented.
Oh, got it.
So Bob has access to some files I want access to, administrators can dump password
hashes
and things like that, that's vertical privilege escalation.
So typically when I think of escalation, I think up, but there's also going
sideways
compromised another user account.
So one is typically ability-based, vertical, and one is access or permissions-
based, horizontal.
All right, DLL hijacking, and there's several different privilege escalation
options in
your courseware.
We're going to touch on a few.
DLL hijacking is since most Windows applications don't use the fully qualified path
when loading
an external DLL library, instead they search the directory from which they've been
loaded.
So if you can inject a malicious DLL in the application directory, you can actually
subvert
the application when it calls the DLL.
So Robber and PowerSploit can both be used to detect hijackable DLLs and perform
hijacking
on the target system.
No labs for that one, but it definitely warranted an explanation.
All right, we've already seen privilege escalation by exploiting vulnerabilities.
If you remember this right here, those are both running under system security
context.
It's a little bit garbled here, but if I have a interpreter and interact with the
interpreter
shell and I get user ID, I'm on as system.
All right, it doesn't get any better than that.
All right, so I may have escalation at the time of exploitation, and I may have to
actually
run a privilege escalation after the fact by running an additional metasploit
payload
or post-exploitation model.
All right, Dylib hijacking, same concept, but Mac OS versus Windows, same concept,
Dylibs, DLLs.
And then pivoting and relaying to hack external machines.
Pivoting and relaying are both moving through a intermediary initially compromised
host.
So in a nutshell, one is routing, one is port forwarding, you can look at it that
way, but
pivoting is, let's say I can't get to client two here directly, shut down, but I
can get
to client one and then I can advance to client two, and then I establish a reverse
connection
back to the attacker, that's pivoting, same thing with relaying, but in relaying,
you're
using port forwarding rules to access the system, and again, you're kind of
relaying
the attack through it.
Any way you slice it, it's like playing hacker frogger moving from turtle shell to
turtle
shell advancing under target.
All right, misconfigured network file system, you actually have a lab on this,
you're going
to use a misconfigured NFS share to gain root access to the target system, a
misconfigured
network file system can be used to deliver an exploit, paves the way for attackers
to
gain root level access through a rigor user account or a low-privilege user, and
you can
use it to sniff sensitive data and files passing through the internet and launch
further attacks.
You'll be running through a lab on that one.
All right, bypassing user account control, okay, one way to perform privilege
escalation
is to remove that UAC pop-up, are you sure you want to run this, it requires
administrator
privileges.
There are a couple different ways to disable UAC, but in a Windows environment,
even if
it's set to any option, attackers can abuse a few Windows applications to create
privileges
without triggering a UAC notification.
All right, and then executing applications.
So once you've got the privilege on the system you require, now it's time to
execute applications
and that may be to preserve access, which is a backdoor, it may be to log
keystrokes,
gather additional information, spyware, gather additional information, or install
crackers
to crack other sets of credentials on the hacked box.
So it really depends what you want to do at this stage, but once you've gained
access,
escalated privileges, first thing you want to do is maintain access, but if you
don't
care to revisit the system and you just want to grab some information, again, it's
completely
dependent on what you're setting out to do.
But it would be a good idea to ensure you can continue to revisit the system.
Our remote code execution techniques, there are various ways to execute code
remotely,
through exploitation, service execution, through WMI controls, Windows remote
management,
you can use PS tools for that, but they're just ways to launch executables on the
target
system.
A little bit later in some demos, we'll be using remote code execution, I'll do it
through
web applications, I'll also do it through command line and through SQL injection,
and
we'll actually use symbolic links to execute codes as well, so we'll see several
examples
of that throughout the course, actually in this module and in a couple later
modules.
Gameware remote support, that's a gooey, yeah, but it's still remote code execution
applications.
So remote administration tools in the hands of an attacker are hacking tools, hands
of
administration, hands of an attacker, it's a hacking tool, same tool, different
purpose,
different degrees of ethics or permissions.
All right, the concept of the keylogger.
The keylogger comes in two basic flavors, you have physical or hardware-based
keyloggers
and you have software, and in the software variety, you've got kernel mode or
application
mode and a couple of other different sub variants, but the whole purpose of a
keylogger is to
capture keystrokes, so invariably, you're going to type in something that's
sensitive
on the keyboard and the keylogger is going to be there to capture it and get that
either
through a network connection or through local retrieval to the attacker through a
keylog
file.
Now, we're going to be looking at keyloggers in the form of spyware and as
components installed
in Trojans and backdoors, and as I mentioned earlier, we're going to have a more
detailed
discussion of that in our next module, which deals with malware threats.
So we're going to inject the keylogger into the target system, which can be in the
form
of a driver or an application, it's going to intercept keystrokes, they also have a
tendency to capture things like stored credential files, web browser password
files, things
like that, chat histories and so forth, which put them more into the spyware
category, incorporating
keylogger a little bit more multifaceted.
All right, Metasploit, amongst other cool functionality, definitely has a keylogger
component.
You use the keyscan start command and the keyscan dump command to perform post
exploitation
keysniffing after your meturper session has been established, and we'll be taking a
look
at that in some of our lab exercises.
Our hardware keyloggers, you can pick them up for 15, 20 bucks online, the higher
storage
capacity tend to be a little bit more pricey, they come in USB and they used to
have PS2
flavors back in the day where we had PS2 mice and keyboards, but lots of examples
of hardware
keyloggers and those are generally more stealthy because they get installed as a
physical device
and there's really not much to detect, you'd have to physically inspect the system
to identify
the keylogger.
I don't know about you, but I'm going to go crawling around under my desk looking
at the
back of my PC on a regular basis, especially in public locations, kiosk machines
and hotel
kiosk machines ripe for the plucking as far as embedding keyloggers, not that I've
ever
done that, but I've stayed in lots of hotels over the years and there's plenty of
opportunity
to snip networks, impersonate keylogger machines, install spyware, etc. etc.
I've thought about it, of course I didn't do it.
Alright, so spyware in general, spies on your activities. The most basic flavor of
spyware
is a cookie, a tracking cookie. It records details about what you do when visiting
certain
websites and if you ever notice that you could be looking at something on Amazon
and then
five minutes later on another website and you see the pop-up ad for the same thing
you're
just looking at, that's going to be a tracking cookie. Browser add-ons, piggyback
software
installation, drive-by download, mask rating as anti-spyware which is usually more
of a
Trojan type of characteristic and web browser vulnerability exploits are all ways
for spyware
to propagate. In general, it's going to record your activities and we have a very
cool lab
you'll be running through with the spy tech spy agent. So it'll show you all sorts
of
different aspects and it's actually a little disconcerting that this stuff gets
marketed
out in the open as legitimate software. You can most definitely monitor your kids
online.
You can monitor your employees if you tell them to. So this stuff gets marketed for
legitimate
purposes but invariably it's used for purposes other than prescribed. So lots of
examples
of spyware, power spies, spy tech spy agent, tons of other ones over the years.
The root kit. The root kit is the term means kit to provide root access. It's
originally
indigenous to Linux operating systems allowing you to maintain root access from
remote location
or backdoor access and then as they evolved they became more stealthy. They
concealed
themselves on the system and the whole idea is the root kit tries to make itself
undetectable
while preserving access to the target system. So it may provide backdoor
functionality.
It may just hide or cloak other system processes, registry keys, software objects,
etc. So I'll
show you an example of one that hides processes here in just a second. But the root
kit gets
actually the system gets infected or propagated pretty much the same way any other
flavor
of malware does. You can scan for and detect root kits prior to it being dropped on
the
system. Once it's been dropped it takes measures to hide itself in view and if it's
running
as a kernel mode driver which most root kits are it's actually patching the
operating system.
So just to show you an example I'm going to walk you through a direct kernel object
manipulation
using a 2003 root kit called foo. So DCOM actually directly manipulates kernel
objects. In this
case the process table or task manager view can be directly edited and remove a
suspicious
process from view. So here's an example of that. It's my Unicode directory
traversal
demonstration. I'm going to start run calc. Calculator is now running on my desktop
and I
know that if I view task manager it shows me calc.exe. So I can see it in the
process table.
The root kit open a command prompt process hide 1008 and enter and now the process
disappears.
All right so no longer resident, nowhere to be found, any process explorer, task
list,
any process table enumeration utility will come up blank on that. That's pretty
powerful mojo.
The only way to really determine that it's running is to do a memory dump and start
parsing the
process memory. That guy actually is not participating in network communications.
We're
going to revisit this in our malware threats module. I'm going to walk through some
dynamic
behavioral based analysis and I'll use a remote access trojan. I'll rootkit it.
Will they be able
to identify it based on the fact that it's listening port? But if I view my
software
environment I can actually see that it's running as a system driver. It's this
msdirectx.sys file
Oh there it is msdirectx.sys kernel driver running from a path other than the
system 32 drivers
folder which is typically where they run. So that looks a little bit weird running
off the desktop.
Another one running here. Not sure what that is pssdk. You've never noticed that
one before.
I might have to revisit that in our malware threats discussion.
All right so that's what a rootkit is going to look like
and especially nasty because it can hide processes from being detected.
All right there's also ntfs alternate data streams. So we're getting into the
covering tracks phase
gaining access, maintaining access, covering tracks, the three hacking phases and
the hacking
cycle, the recovering in module six. So hiding data with a rootkit is possible.
Hiding data with
an ntfs alternate data stream is possible. Hiding data using steganography is
possible and then
hiding malicious executables in another executable we're going to call that
wrapping.
We'll take a look at that in the next module. It'll look an awful lot like
steganography
but the difference is an executable carrier file. So the alternate data stream
everything in ntfs
is an attribute. This is a feature not a flaw in the ntfs file system. Alternate
data streams
allow me to create a secondary data attribute for the primary file and that allows
me to
hide it from view casual detection. If you're looking for it you're going to find
it.
So I've got an example here. Oh there's my password crack by the way on my password
exchange.
So I've got a folder created.
I'm going to get rid of all this here.
Alternate data streams and I'm going to get a shell
and do a notepad eric.txt. Create a new file.
This is visible period. Save the file. Save. All right if I do a dir here I see
that eric.txt is
16 bytes in size. All right if I do a sha hash of that file I'm going to see that
it is in fact
16 bytes in size. There's my original sha hash ending in 800. Now I'm going to do a
notepad
eric.txt colon hidden text and enter and that's going to create the forked
secondary data attribute.
So that colon operator is the magic file fork indicator. Create a new file called
hidden text.
This is hidden and replicate and create some bulk. All right so we've added plenty
of data to the
file. I'll go ahead and close it and save it and then rehash the file. All right
it's still 16
bytes in size. It still produces the same hash side by side. Okay that doesn't
appear to be right
but it only calculates the discharge and the hash for the primary data stream. If I
do a dir I see
that it's still just 16 bytes in size. So where did that data go? It counted
against the free space
but it didn't impact the file's discharge. If I do a notepad eric.txt colon hidden
text again
I'll call the file but if I look at it in the directory view and I open it I just
see the payload.
If I open this in a hex editor oops let's not do that yet.
Come back to that I want to put an executable in there as well.
If I do a dir slash r that'll actually show me the alternate data streams.
All right so there it is and if I'm looking for it I'm going to find it.
I can also put an executable but I've got to manipulate it a bit to actually launch
it. So I
could do a type
windows system32 calc.exe into
eric.txt calc.exe and I just put an executable in a hidden location.
All right now to call it I have to do a symbolic link creation
do backdoor.exe
make sure my syntax is right there symbolic link created. All right so now if I run
backdoor
it launches Calculate. So I can launch it from the hidden location. Now again if I
do a dir
slash r I'm going to see both of those alternate data streams
and it shows me the system link it also shows me the path to the alternate data
stream.
If I look at it in a hex editor
I'll see the child objects because the hex editor is going to show me child
objects.
All right so go to ads there's eric.txt the dot dot dot says it has child objects
and if I double click it's going to ask me to explore there's my calc.exe there's
my hidden.txt
and it still does some wacky stuff.
It's not tracking the file again something funky is going on here it's actually
going to the root
the partition versus the file. That should show me
something's wacky
I'm going to open that one more time second time to churn
open the partition
we're having errors as well all right ads eric.exe explore there's hidden
still not displaying it interesting well this is hidden this is hidden this is
hidden it's
supposed to be showing up there but it's not advancing
weird some of the google drive file streaming thing that causes issues with that as
well that
doesn't make any sense on this one so regardless I see the alternate data stream
and if I'm looking
for it I'm going to find it all right so that is a little bit different than what
we're going to see
in steganography we're hiding data inside the file system how to create ntfs
streams I actually
just ran through everything so everything I just showed you the demo actually maps
these slides
and the stream manipulation and we did the back door after making the symbolic link
all right
steganography is putting a message inside of an obvious cover media so I'm going to
put a message
or a file inside of another file and I'm not going to impact that file's
functionality or
viewability so hiding something in a picture file for example is a classic is a
classic scenario
for steganography I can then send a picture file out as an email attachment or an
embedded object
and then the recipient can extract it and it's typically encrypted as well which
means even if
it's detected it can't be extracted so steganography is used for all sorts of
things
hiding illegal content contraband covert messaging data exfiltration steganography
tools
snow a whitespace steganography tool has been around forever at least two decades
it allows you
to put a message in the whitespace of a text file that actually shows up as extra
space if
you were to highlight the whole thing you'd see the blue lines over the whitespace
but you don't
see any actual data there and then you could extract it using the password in the
receiving
system I'm going to show you an example of image steganography using a tool called
invisible secrets
and then we'll extract it and detect it using a tool called xsteg which is a
graphical front end
for a command line utility called steg detect all right so steg analysis is
reversing the process
of steganography it's detecting a malicious payload or suspicious payload in an
image file
and I'll show you an example of that here in just a second one other steganography
detection tool
is zsteg all right so now that I have covered the slides let's do the demonstration
and I'm
going to use a picture of my my oldest Dudley my oldest dog Dudley
and we're going to embed a malicious script inside a picture of my puppy Dudley
all right so I'm going to bring the Dudley puppy out
the xsteg utility out invisible secrets in a malicious dns poisoning script
dnspoison.bat
now if we look at this we're going to use this in our sniffers discussion
to perform dns poisoning of the internet variety we're going to misconfigure our
victim with a static dns ip address that is a impostor server all right so I'm
going to
install invisible secrets and utilize the evaluation version
I'm going to give it a try I'm going to hide a file I'm going to add a file for my
desktop
we're going to select the dnspoison.bat file I'm going to select a carrier file
which
will be my image file Dudley puppy.jpg next specify a password for the encryption
select the encryption algorithm and enter a name for the file we'll call this stego
and hide the
file all right so stego if I right click and look at the shaw hash
and Dudley puppy if I right click and look at the shaw hash they're definitely
going to be
different all right so I've got a payload size difference
071 versus 263 and the hashes are definitely different so there is a difference
between the
two files all right if I view both files in a hex editor I'll also see a difference
so stego has all this going on Dudley puppy does not so that's the encrypted
payload and I don't
see it so when I compare and contrast there is definitely differences when I look
at the files
side by side there is no difference all right so this is Dudley when he was seven
weeks old my
first got him he's my oldest he's going to be 14 here in a week and he's still got
the same look on
his face but there's no difference between the two files right no discernible
difference the file
view is just fine when I open the file it does not run the executable which your
brain wants to jump
to oh wow did it run the exploit as well it doesn't because the jpeg is not an
executable file
did it run the exploit as well it doesn't because the jpeg is not an executable
file wrapping
however which we're going to look at in the malware threats module will execute so
they
look almost identical but one is encapsulation in an executable file one is the
encapsulation
in a non-executable like a jpeg all right so that's the embedding that's the
analysis and
then I can also run a utility like xsteg which is a graphical interface for steg
detect which
is command line and I can open my newly created stego file and register a detected
signature for
invisible secrets all right so ding ding ding ding ding we detected an embedded
signature looks
like invisible secrets all right but it won't extract it for me so it identifies
that it's there
but we still have to break the encryption and use the original tool to extract it
so steganography even if it's detected if it's secured with strong encryption
you're probably
not getting to it so that's another great way to hide information from being
detected use
steganography so we've got alternate data streams we've got root kits we have
steganography
all right there's also maintaining persistence by abusing boot or log on autostart
executions
so if I want to continue to revisit the system and I install a backdoor I need that
to restart
every time the system boots we'll talk more about autoruns in the malware threats
module
but we have a lab you're going to complete on maintaining persistence
by abusing boot or log on autostart executions and typically those are embedded as
registry keys
or in the startup folder so startup folder is kind of the classic location for
autostarts
and then registry keys there's dozens of those in the registry which we'll take
a closer look at in our malware threats module all right and then all of a sudden
kind of back
to the kerberos discussion the golden tick ticket attack and the silver ticket
attack
refer to golden is forging tgt's by compromising a key distribution service account
and then
silver ticket is for the ticket granting service tickets or the session tickets
so both of those can actually be forged with mimecats so those are revisiting our
kerberos
attacks from earlier in the modern
and then finally covering tracks step five of the hacking cycle is cleaning up any
evidence
of compromise so there are a few ways to go about doing this you can disable
auditing which turns
off auditing disables actual logging the log file there's clearing logs nice clean
empty log file
which might raise some suspicion and then manipulating log files selectively
removing
entries which would be the most meticulous way to go about doing it in the malware
threats module
talk about covering tracks in the network os deleting files hiding artifacts and
disabling
windows functionality are also options all right so imagine that i want to rob a
bank and not get
caught on tape doing it what are my options turn off the cameras rob the bank or
rob the bank go
back and wipe the tapes or rob the bank go back and wipe just the time sequences
where i'm in
there at the ski mass and stick them up so disabling auditing audit paul is a
native windows system
administration utility that allows you to administer the audit policy all right
when you
change the audit policy that itself leaves an audit entry say that the audit policy
has been
changed so you can turn off auditing or you can clear the log files completely
which looks a
little bit suspicious but better than having evidence left behind there's a ton of
log clearing
utilities dump el el save ps log list batch files like clear event viewer logs dot
bat
and then there's also the clear ev command in meterpreter that's real handy since
it's
already built in a meta split so for example let's hit my 2003 box here actually
let's go
after my 2008 box
an event viewer with the windows logs application all right so i've got application
i've got setup i've got system i've got security now i've got that 2008 box
compromised i'm going
to right click get myself a meterpreter shell and i'll do a clear ev to clear the
event logs
all right wiping wiping wiping now i go back and visit and if i do a refresh
oh it confirmed but let's do this back up back up
well that's interesting i refresh no confirmed but it didn't run that is
interesting
all right well let's go ahead
it was 2008 box huh it got didn't get confirmed all right let's blast the 2003 then
you've never seen that fail when it confirms before that's interesting
our meterpreter clear ev bam bam bam
i'm going to run that against the
get user ID the wrong box maybe
i think i've misdirected
all right let's hop over to 2003
all right empty empty empty all right one more time just so we see it in real time
okay
all right there's my application
let's go ahead and compromise this guy
all right i'm a tripper shell
all right now refresh empty empty empty 2008's got me intrigued though let me go
back and revisit
that one all right so it can be that simple or you can of course like anything else
use
powershell for it so whenever anybody asks you can you do this in powershell just
go ahead and
say yes because you can do it somehow some way powershell monstrously powerful
command line
interface you can definitely clear event logs using powershell a lot of emphasis on
the use
of powershell since it's a living off the land type of tool allows you to use a
very powerful
native system utility to perform nefarious activities so we'll talk more about that
when
we talk about fileless malware and our malware threats discussion i could also
manually clear
the event logs and right click say clear log files in lytics the var log folder
contains
most of the log files in a text file format so all you really need is a text editor
and the ability
to manipulate the log files there's also going in and removing and we get into this
way more
in forensics but windows tracks all sorts of stuff about what you do on that box
command
histories most recently used url histories it's all there it's just a matter of
digging in and
extracting it so clearing online tracks most recently used cookies cash and so
forth that's
just the tip of the iceberg using a multifaceted tracks clearing utility is
recommended like a cc
cleaner window washer bleach bit that sort of thing all right then your bash shell
tracks
the command history in a linux bash shell is ongoing the command history in a
windows terminal
window command prompt window goes away the second she closed the window so the dos
key history
command in windows is pretty useless if the terminal window has been closed in
linux the
history file is ongoing and keeps getting appended to session after session there's
my history
and i could clear that or i could set it to not record x number you know history
sizes zero not
record anything but when you delete or clear those history files the actual data is
still there
waiting to be forensically retrieved so instead you can use shred or cat null
commands
to go through and purposely overwrite that information so this is more of a
discussion
for the ch5 forensics class but something that's deleted is not deleted it's just
marked as you
may overwrite if you like and we wait around until it's actually overwritten so
lots of opportunity
for forensically retrieving deleted data but you got to come back for chf fire for
that
all right covering tracks on the network we're going to address covert channels
in our malware threats discussion but the idea here is to obscure your
communications across the
network if you're remotely interacting with a compromised host reverse http shells
icmp tunnels
these are great ways to get a connection back out of the network but i'm going to
diagram it
whiteboard it talk about it in our trojan discussion tomorrow dns tunneling tcp
parameters
are both options as well and then covering tracks in the os the alternate data
streams we talked
about unix and linux you can append dots to files which just hides the files export
history size to
zero modifies the history file and then cipher.exe is actually for managing
encrypted file system
under the windows ntfs file system i did not know until ch version 11 came out that
it has a function
for overwriting deleted files it does it through a multi-pass zeroization and
random overwrite so
cipher tack or slash w drive letter goes through identifies deleted files removes
them otherwise
deleted files are far from deleted are other options for hiding artifacts most of
this is
standard making the hidden hidden file hidden an attribute adding the dot so hiding
files and
folders and windows set the attribute command you can hide user accounts using
registry keys
and then hiding files and folders in linux again you add a dot to the beginning of
the file and
then it has to be told directly to show hidden files so those are all ways for
evading casual
detection all right track covering tools cc cleaner had some malware in it not too
long ago
but these types of utilities will very targeted and very focused purposefully
delete most recently
used command histories things like that privacy eraser white bleach bit clear prog
all examples
of track covering tools all right now we've got more on that topic in the malware
threats module
which is coming up next but that completes our discussion of system hacking at
least for the
time being we talked about gaining access escalating privileges maintaining access
executing applications and finally covering tracks so we got lots of cool labs for
you
for this module and some of these topics that we introduced today we're going to
continue in the next module we did table some other items for later discussion
specifically
around sniffing which we'll talk about in the sniffing module so that concludes our
lecture for module six enjoy the labs