►
From YouTube: AMA with the Red Team (external & public livestream)
Description
Live Ask Me Anything session with the GitLab Red Team
A
B
A
B
Team
that
we
have
on
the
call
today
and
we're
going
to
jump
right
into
the
questions.
We
don't
have
a
lot
of
time,
so
we
may
not
get
to
all
of
the
questions
that
are
on
here,
but
our
intent
is
to
answer
them
all.
So
we
will
answer
anything
we
don't
get
to
verbally
or
in
the
stream.
Here
we
will
answer
in
the
document
and
we're
also
going
to
turn
the
document
into
a
blog
post
as
well,
so
we'll
be
able
to
get
information
out
there.
B
We
also
have
an
email,
alias
that
if
you
have
a
question
that
you
didn't
get
a
chance
to
ask-
or
you
want
to
follow
up
on
something
I
read
team
gitlab.com
is
a-
is
a
good
way
to
reach
the
entire
team.
So
real,
quick
introductions,
my
name
is
steve
madzik,
I'm
the
manager
of
the
red
team
here
at
gitlab
and
turn
it
over
to
my
team.
I
will
start
with
you
greg
to
go
ahead
and
introduce
yourselves.
C
B
D
A
Okay,
so
voice
over
number,
one
which
is
considering
you're
a
full
remote
company.
Persistence
on
endpoints
is
still
relevant
in
your
activity,
or
hunting
tokens
or
credentials
make
more
sense.
Some
cloud
services
do
not
require
you
to
reach
them
with
vpn,
so
sso
tokens
or
credentials
could
be
enough
in
some
cases
to
reach
sensitive
information.
B
Yeah,
that's
that's
actually
a
really
good
question,
so
the
the
the
simple
answer
there,
of
course,
is
both
right.
I
mean.
Obviously
both
of
those
things
are
are
definitely
important
to
us,
but
but
we
have
focused
a
lot
over
the
last
little
while
on
going
after
things
like
credentials
and
tokens
and
things
of
that
nature,
in
fact
I'll
let
greg
here
take
over
because
he
he
worked
on
releasing
a
couple
of
tools
that
we
actually
use
internally
as
well.
To
do
this.
C
So
we
we
wrote
some
some
extra
bits
in
there
to
make
it
to
make
it
support
gitlab
and
we
wrote
some
custom
tooling
that
started
off
pretty
simply
as
just
a
recon
tool
and
then
we
sort
of
expanded
on
that
to
basically
do
the
same
thing.
That
tools
like
git,
rob
and
and
other
tools
like
it
do
find
credentials
in
in
different
parts
of
the
of
the
gitlab.
C
B
E
That
we
ask
questions
to
every
day.
I
know
I
often
pop
into
like
development
slack
rooms,
for
instance,
and
ask
how
something
works
and
when,
when
people
see
my
name-
and
they
see
me
asking
a
question-
and
I
see
red
team
next
to
it-
I
want
them
to
trust
me.
I
want
them
to
feel
like
they
can
help
and
and
answer
my
question
and
you
know
feel
safe
that
they're
not
putting
themselves
in
danger
in
danger.
E
Doing
that.
I
don't
want
anyone
to
think
that
we're
out
there
trying
to
exploit
their
laptops,
especially
at
a
company
like
git
lab,
where
we're
fully
remote.
So
those
laptops
are
sitting
inside
our
homes,
they're
they're
on
our
home
network
and
they're
sort
of
the
gateway
into
our
personal
life.
They're
used
for
personal
think.
So,
when
we're
talking
about
persistence
on
endpoints,
it's
just
not
something
that
we
want
everyone
to,
think
that
we're
going
after
their
endpoints
and.
E
We
really
like
to
focus
on
something
that
we
call
an
assumed
breach,
so
we
need
to
fully
understand
the
threat
model
of
these
endpoints.
We
need
to
understand
the
type
of
data
that's
accessible
on
that
endpoint
and
then,
essentially,
what
we'll
do
is
we'll
assume
that
an
endpoint
can
be
breached
and
we'll
start
with
that
level
of
access
that
we've
identified
in
a
threat
model.
So.
E
A
Great,
thank
you.
We'll
move
on
to
number
two
next
question
is
to
evaluate
an
insider
threat.
Do
you
consider
to
run
exercises
from
authorized
users?
I
mean
run
an
exercise
to
simulate
a
legit
change
in
your
system,
but
with
some
malicious
effects,
for
example,
set
up
a
new
web
service
or
whatever,
with
some
back
doors,
in
order
to
be
able
to
keep
access,
steve.
B
Yeah
yeah,
so
so,
and
this
kind
of
overlaps
a
little
bit
with
with
the
answer
to
the
previous
question.
So
so
we
definitely
consider
that
in
in
some
of
the
exercises
that
that
we
do
so,
we
will
do
things.
You
know
like
chris
said
in
his
last
answer,
where
we
assume
the
attacker
is
either
someone
that
already
has
some
sort
of
access
to
something,
or
he
is
an
internal.
You
know,
employee
or
or
in
insider
threat.
B
And
again,
though,
you
know
when,
when
focusing
on
things
like
like
endpoints,
we
have
our
own
test
ones
that
will
build
to
look
identical
to
what
an
end
user
is
using
and
and
then
test
things
out
that
way
versus
actually
trying
to
exploit
some
of
our.
You
know,
co-workers
and
things
of
that
nature.
Fred,
you
wanted
to
expand
on
that.
One.
D
Yeah
just
a
little
example
like,
for
instance,
we
will.
We
will
really
start
with
the
linux
shell
from
either
vm
or
container,
because
we
would
assume
I
mean
the
user,
since
it's
an
authorized
user
who
is
trying
to
breach
anything,
he
would
eventually
be
able
to
have
such
a
shell,
and
we
will
start
the
operation
from
there
and
then
we
will
see
how
far
we
can
expand
and
how
we
can
detect
that.
C
Yeah
and
just
to
expand
on
that
a
tad
bit,
but
in
the
interest
of
time
it
won't
go
too
deep,
but
it
as
chris
mentioned
you
know,
we
we
spend
some
time
mimicking
how
an
attacker
might
try
to
gain
persistence
on
those
those
vms
or
containers
as
well.
So
so
we
know
what
that
traffic
looks
like
and
we
we
know
better
how
to
defend
it.
A
A
B
E
E
So
we
leverage
our
own
self-hosted
gitlab
instance.
We
use
gitlab.com
for
some
things
as
well,
but
we
also
do
a
lot
of
self-hosted
and
one
of
the
things
that
we
do
that
I
really
like
is
to
try
to
make
our
techniques
for
red
team
operation
automated
and
repeatable,
and
we
do
that
by
building
custom
attack
tooling,
like
let's
say
we're
I'll,
just
keep
it
very
simple.
Let's
say
we're
doing
a
password
brute
force
tool
or
something
we
could
write
our
own
custom
password
brute
force
tool.
B
E
We
can
use
the
git
lab
ui,
either
manually
or
via
schedule,
to
repeat
those
techniques.
So,
let's
say
in
an
operation
we,
you
know,
we
do
a
brute
force
attack
and
it
gets
in
the
record,
and
it
shows
what
time
we
did
it
and
everything
if
the
blue
team
makes
some
modifications
to
their
capabilities
and
they
want
to
run
that
technique
again,
we
can
go
back
to
that
project
and
we
can
look
at
you
know
an
exact
commit
of
that
custom,
tooling,
that
we
wrote
and
re-run
it
with
with
the
source
code.
E
A
gitlab
ci
job,
then
we'll
get
the
full
console
output,
which
is
logged,
and
it
has
time
stamps
and
everything
that
we
need
to
go
back
and
review
and
see
what
work
and
what
didn't
is
sort
of
right
there
inside
the
gitlab
project
we
can
iterate
on
it.
If
we
make
changes
to
the
source
code,
we
can
then
rerun
it.
You
know,
pin
to
a
different
different
version
of
our
source
code
and
so
on.
E
We
we
even
have
another
tool,
actually
that's
pretty
interesting.
That
uses
multiple
pieces
of
the
git
lab
project,
so
it
uses
some
some
off-the-shelf
pen
test
tools
combined
with
some
custom
bash
scripts
that
we
wrote
and
it
uses
gitlab
ci
to
run
this
tool
and
then
the
output
of
the
tool
fortunately,
is
html
and
we
use
that
tool.
Output
combined
with
something
called
git
lab
pages,
which
is
a
way
to
host
static
websites
to
host
the
output
of
that
attack.
E
Tooling
and
gitlab
pages-
has
authentication
built
in
so
we
can
even
do
you
know,
role-based
access
control
on
the
output
of
this.
You
know
off-the-shelf
pen
test
tool
where
only
get
lot
of
people
can
access
that
output
and
it
has
two-factor
authentication
built
in
and
all
that
stuff.
So
that's
just
sort
of
one
cool
way
we
can
use
our
own
in-house
product,
and
then
I
did
just
want
to
echo
steve's
comment
by
using
vector
vector
is
awesome.
E
E
After
the
fact
you
get
these
really
cool
reports
about
how
effective
all
your
blue
team
tools
are,
and
things
that
you
can
show
upstream
to
management,
so
vector
is
a
very
cool
tool.
It's
unfortunately,
it's
not
open
source.
It
is
free,
you
can
find
they
do,
have
a
github
project
and
you
can
download
some
docker
containers.
E
A
B
Yeah,
that's
a
that's
a
good
question,
so
we're
a
little
bit
different
in
this
regard.
When
it
comes
to
you
know
what
I
would
call
your
traditional
red
team
right,
so
most
rec
teams-
you
know
at
least
traditionally
would
excuse
excuse
me-
would
be
performing
exercises
and
trying
different
things
in
a
rather
stealthy
manner,
without
necessarily
telling
anybody
else.
We
try
to
do
the
opposite
right.
So
so
we
do.
B
When
we're
planning
our
operations,
we
usually
pull
people
in
from
different
teams,
especially
teams
that
will
be
impacted,
and
somebody
always
knows
what
we're
up
to
right.
So
a
good
example
I
have
here
is:
if,
if
we
were
working
on
something
that
you
know
potentially
could
set
off
fire
alarms
for
our
incident
responders
in
our
incident
response
team.
B
Typically,
the
manager
of
that
team
or
somebody
on
that
team
knows
what
we're
doing
knows
what
we're
up
to
and
then
when
we
are,
if
we
are
detected,
we
then
jointly
make
the
call
of
okay.
Well,
do
we
want
to
say
fine
you've
been
caught?
Let's
stop,
you
know
work
now
or
do
we
want
to
actually
test
what
the
incident
response
would
be
and
let
everyone
proceed
through
like
this
is
a
real.
D
Okay,
I'm
seeing
this
now,
I'm
gonna
try
to
elevate
privileges
here
and
there
and
and
it's
actually,
they
usually
take
it
very
well,
and
sometimes
they
even
give
us
some
cool
ideas,
actually
that
we
didn't
think
about,
and-
and
they
don't
see
this,
as
I
mean
because
they
are
part
of
it-
really-
they
don't
see
this
as
us
trying
to
like
point
fingers
at
them,
but
really
collaborating
with
them
to
to
make
things
better.
At
the
end,.
B
And
I
think
to
quickly
add
to
that
too.
There's
always
going
to
be
a
scenario
where
we
don't
want
to
tell
anybody,
but
even
I
mean,
but
even
in
those
scenarios
typically,
you
know
my
boss
and
my
boss's
boss
know
you
know
what
I
mean
like
so
somebody
there
is
always
somebody
that
knows
what
we're
doing
it.
Just
we
just
may
not
share
it
as
broadly
or
as
wide
across.
You
know
the
the
different
security
teams
or
infrastructure
teams,
as
normally.
A
B
You
know
we're
calling
somebody's
baby
ugly
right,
so
we
we
are
very
careful
to
not
have
any
ego
with
that
right.
We're
very
careful
to
you
know
present
the
facts,
the
data,
the
men.
You
know
the
message
and
make
sure
that
people
understand
that.
Look.
We're
not
here
to
point
fingers
we're
not
here
to
tell
you
that
you
messed
up
we're
just
here
to
make
sure
that
you
know:
we've
we've
done
our
due
diligence
and
that
we've
raised
you
know
the
bar
from
a
security
perspective.
B
You
know
as
much
as
we
can
and
I
mean
a
lot
of
that
comes
with
experience
right.
I
mean
I've.
I've
seen
red
teams
and
other
organizations
and
other
places
where
they
maybe
forget
that
you
know,
and
they
you
know,
get
on
that
call
to
explain
something
to
another
team
where
they're
laughing
about
a
bug
or
something
that
they
found
and
that's
usually
not
a
helpful
approach
right.
D
Oh
sorry,
yeah
when
I
joined
gitlab,
I
saw
like
this
transparency
value
is
really
nice,
because
every
team
is
kind
of
used
to
to
show
what
they
do
and
have
like
feedback
from
other
teams.
So
they
are
kind
of
used
of
being
pointed
at
mistakes
and
also
gig
club
is
promoting
like
yeah.
You
can
do
mistakes
and
just
learn
from
them.
So
there
is
some
kind
of
culture
of
like
yeah.
Nobody
tries
to
hide
really
anything
and
they
are
used
to
to
have
some
yeah
different
inputs
from
different
teams.
D
C
C
You
know
early
in
the
process
and
and
making
sure
that
you
that
you,
that
you
meet
that
trust
in
the
end
and
the
points
that
both
steve
and
fred
brought
up
about
working
with
other
teams,
closely
is
extremely
important,
because
git
lab
is,
is
a
huge
ecosystem
of
different
systems
and
technologies,
and
no
one
person
can
can
possibly
understand
all
of
it.
So
getting
input
from
from
other
people
and
say
hey.
This
is
something
that
I
that
I
thought
about
you
know.
Maybe
we
could
attack
this.
A
C
Thank
you,
spacebar
just
stopped
working
all
of
a
sudden.
In
the
end
you
know
we
we
try
not
to
limit
our
creativity.
You
know,
I
think
you
know
being
participating
at
gitlab
and
being
part
of
the
team
as
a
whole.
We
we
learn
a
lot
about
how
the
systems
work
and
and
where
the
weaknesses
might
be,
that
a
generic
framework
like
mitre
might
not
cover.
So
you
know
we
tried,
try
not
to
limit
things,
but
there's
an
extreme
amount
of
value
in
the
things
that
we
find
in
mitre.
A
B
Attack
yeah
yeah.
I
can
finish
it
yeah
that
aren't
track
and
minor
attack
published
outside
of
vector
or
where
the
public
can
access
them.
So
that's
actually
a
national
question,
because
that's
something
and
chris
I
know
you're
probably
smiling
to
see
that
question.
That's
something
we've
actually
talked
about
doing
and
we
need
to
follow
through
on
is.
We
have
talked
about
that
as
we're.
Creating
these
two
start,
releasing
them
ourselves
and
essentially
just
posting
them.
E
Yeah
next
so
just
to
add
to
that-
and
I
know
we're
right
at
the
end
here
so
attack
matter-
attack
is
organized
by
tactics
which
is
sort
of
the
high
level
thing
like
initial
access
and
persistence
and
then
below
that
those
techniques
and
techniques
are
where
it
gets
very
specific
like
like
create
a
system
d
service
or
use
as
a
sued
binary.
So
we
use
the.
A
E
Everywhere,
because
they're
they're
very
generic
and
we
can
sort
of
fit
everything,
we
do
in
pretty
much
any
operation
into
mitre's
definition
of
tactics
when
it
comes
to
techniques,
though
what
mitre
prefers
is
to
only
include
techniques
in
their
framework
that
are
publicly
known
and
have
attribution
to
some
known
threat
group
and
for
mitre.
I
think
that
makes
a
lot
of
sense,
but
at
gitlab
we're
in
a
much
more
modern
environment.
E
We
have
no
physical
networks,
we
have
no
active
directory
and
it
could
be
years
until
there's
attribution
to
techniques
that
we
know
work
because
we've
done
the
research
and
we've
tested
them.
So
again,
yeah
we've
created
sort
of
a
lot
of
our
techniques
we
reached
out
to
mitre
and
had
the
discussion,
but
again,
as
we've
learned,
they're
more
interested
in
techniques
that
already
have
attribution,
so
ours
are
probably
not
going
to
be
included
until
a
threat
group
uses
them
and
gets
caught.
We
do
have
some
of
them
published
publicly.
E
If
you
look
at
our
red
team
tech
notes,
we
did
a
very,
very
thorough
blog
on
techniques
inside
google
cloud,
for
example,
in
terms
of
having
them
broken
down.
Like
in
the
mitre
format,
exactly
how
you'd
see
them
in
attack
we
sort
of
started
on
on
those,
but
because
once
we
learned
that
mitre
would
prefer
not
not
to
include
them
until
they
have
attribution.
E
It
was
just
sort
of
a
lot
of
work
that
might
not
go
anywhere,
but
if
people
are
interested
in
that-
and
they
let
us
know-
then
yeah
possibly
we
could
work
on
that
as
well.
We
have
some
things
in
the
pipeline
as
well.
Some
upcoming
vlogs
that
may
be
a
bit
more
focused
on
providing
things
sort
of
in
that
attack
framework
as
well.
A
B
B
I
know
for
for
me
something
I
look
for
you
know
for
people
when
we're
when
we're
growing
the
team
is,
is
not
necessarily
the
skills
that
that
people
already
have,
but
but
how
easily
and
how
quickly
they're
able
to
learn
new
things
and
how
much
they
enjoy
being
kind
of
thrown
into
that
fire
right.
So
things
change
so
fast
and
there's
just
so
much
so
many
different
moving
pieces.
B
When
we
look
at
gitlab's
entire
ecosystem
that
that
we
are
constantly
put
into
positions
where
you
know,
we
have
to
very
quickly
learn
something
and
then
very
quickly,
figure
out.
Okay,
how
do
I
attack
this?
You
know
new
thing
that
I
just
learned
about
right.
Yeah
greg
did
you
did
you
want
to
add
to
that?
One.
C
D
Yeah,
I
wanted
to
add
a
small
one.
There
are
actually
some
skills
that
are
absolutely
you
use
less
at
gitlab
that
maybe,
if
you
confirm
a
traditional
office
environment
like
I
knew
I
was
doing
a
lot
of
microsoft,
active
directory
stuff-
and
you
can
forget
about
that
at
gitlab-
anything
wireless
or
related
to
entering
into
buildings
that
no
no
no
need
at
all.