Skip to content

Instantly share code, notes, and snippets.

@baderj

baderj/gozi_rfc.txt

Last active April 5, 2016 19:47
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save baderj/9d15acea2613eed7717d to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save baderj/9d15acea2613eed7717d to your computer and use it in GitHub Desktop.
Download ZIP
Gozi "Mar 9 2016" DGA Wordlist, sample https://twitter.com/Techhelplistcom/status/708341104685371392. Wordlist is taken from www.ietf.org/rfc/rfc4343.txt
Raw
gozi_rfc.txt
network
working
group
eastlake
request
for
comments
motorola
laboratories
updates
january
category
standards
track
domain
name
system
dns
case
insensitivity
clarification
status
this
memo
this
document
specifies
internet
standards
track
protocol
for
the
internet
community
and
requests
discussion
and
suggestions
for
improvements
please
refer
the
current
edition
the
internet
official
protocol
standards
std
for
the
standardization
state
and
status
this
protocol
distribution
this
memo
unlimited
copyright
notice
copyright
the
internet
society
abstract
domain
name
system
dns
names
are
case
insensitive
this
document
explains
exactly
what
that
means
and
provides
clear
specification
the
rules
this
clarification
updates
rfcs
and
table
contents
introduction
case
insensitivity
dns
labels
escaping
unusual
dns
label
octets
example
labels
with
escapes
name
lookup
label
types
and
class
original
dns
label
types
extended
label
type
case
insensitivity
considerations
class
case
insensitivity
considerations
case
input
and
output
dns
output
case
preservation
dns
input
case
preservation
internationalized
domain
names
security
considerations
acknowledgements
normative
references
informative
references
eastlake
standards
track
page
rfc
dns
case
insensitivity
clarification
january
introduction
the
domain
name
system
dns
the
global
hierarchical
replicated
distributed
database
system
for
internet
addressing
mail
proxy
and
other
information
each
node
the
dns
tree
has
name
consisting
zero
more
labels
std
rfc
rfc
that
are
treated
case
insensitive
fashion
this
document
clarifies
the
meaning
case
insensitive
for
the
dns
this
clarification
updates
rfcs
std
and
rfc
the
key
words
must
must
not
required
shall
shall
not
should
should
not
recommended
may
and
optional
this
document
are
interpreted
described
rfc
case
insensitivity
dns
labels
dns
was
specified
the
era
ascii
dns
names
were
expected
look
like
most
host
names
internet
email
address
right
halves
the
part
after
the
sign
numeric
the
addr
arpa
part
the
dns
name
space
for
example
foo
example
net
aol
com
www
gnu
mit
edu
addr
arpa
case
varied
alternatives
the
above
rfc
would
dns
names
like
foo
example
net
aol
com
www
gnu
mit
edu
addr
arpa
however
the
individual
octets
which
dns
names
consist
are
not
limited
valid
ascii
character
codes
they
are
bit
bytes
and
all
values
are
allowed
many
applications
however
interpret
them
ascii
characters
escaping
unusual
dns
label
octets
master
files
std
and
other
human
readable
and
writable
ascii
contexts
escape
needed
for
the
byte
value
for
period
and
all
octet
values
outside
the
inclusive
range
from
that
say
and
all
octet
values
the
two
inclusive
ranges
from
and
from
xff
eastlake
standards
track
page
rfc
dns
case
insensitivity
clarification
january
one
typographic
convention
for
octets
that
not
correspond
ascii
printing
graphic
use
back
slash
followed
the
value
the
octet
unsigned
integer
represented
exactly
three
decimal
digits
the
same
convention
can
used
for
printing
ascii
characters
that
they
will
treated
normal
label
character
this
includes
the
back
slash
character
used
this
convention
itself
which
can
expressed
and
the
special
label
separator
period
which
can
expressed
and
advisable
avoid
using
backslash
quote
immediately
following
non
printing
ascii
character
code
avoid
implementation
difficulties
back
slash
followed
only
one
two
decimal
digits
undefined
back
slash
followed
four
decimal
digits
produces
two
octets
the
first
octet
having
the
value
the
first
three
digits
considered
decimal
number
and
the
second
octet
being
the
character
code
for
the
fourth
decimal
digit
example
labels
with
escapes
the
first
example
below
shows
embedded
spaces
and
period
within
label
the
second
one
shows
octet
label
where
the
second
octet
has
all
bits
zero
the
third
backslash
and
the
fourth
octet
has
all
bits
one
donald
eastlake
example
and
example
name
lookup
label
types
and
class
according
the
original
dns
design
decision
comparisons
name
lookup
for
dns
queries
should
case
insensitive
std
that
say
lookup
string
octet
with
value
the
inclusive
range
from
the
uppercase
ascii
letters
must
match
the
identical
value
and
also
match
the
corresponding
value
the
inclusive
range
from
the
lowercase
ascii
letters
lookup
string
octet
with
lowercase
ascii
letter
value
must
similarly
match
the
identical
value
and
also
match
the
corresponding
value
the
uppercase
ascii
letter
range
historical
note
the
terms
uppercase
and
lowercase
were
invented
after
movable
type
the
terms
originally
referred
the
two
font
trays
for
storing
partitioned
areas
the
different
physical
type
elements
before
movable
type
the
nearest
equivalent
terms
were
majuscule
and
minuscule
eastlake
standards
track
page
rfc
dns
case
insensitivity
clarification
january
one
way
implement
this
rule
would
subtract
from
all
octets
the
inclusive
range
from
before
comparing
octets
such
operation
commonly
known
case
folding
but
implementation
via
case
folding
not
required
note
that
the
dns
case
insensitivity
does
not
correspond
the
case
folding
specified
iso
iso
for
example
the
octets
xdd
and
xfd
not
match
although
other
contexts
where
they
are
interpreted
the
upper
and
lower
case
version
with
acute
accent
they
might
original
dns
label
types
dns
labels
wire
encoded
names
have
type
associated
with
them
the
original
dns
standard
std
had
only
two
types
ascii
labels
with
length
from
zero
octets
and
indirect
compression
labels
which
consist
offset
pointer
name
location
elsewhere
the
wire
encoding
dns
message
the
ascii
label
length
zero
reserved
for
use
the
name
the
root
node
the
name
tree
ascii
labels
follow
the
ascii
case
conventions
described
herein
and
stated
above
can
actually
contain
arbitrary
byte
values
indirect
labels
are
effect
replaced
the
name
which
they
point
which
then
treated
with
the
case
insensitivity
rules
this
document
extended
label
type
case
insensitivity
considerations
dns
was
extended
rfc
that
additional
label
type
numbers
would
available
the
only
such
type
defined
far
the
binary
type
rfc
which
now
experimental
rfc
the
ascii
case
insensitivity
conventions
only
apply
ascii
labels
that
say
label
type
whether
appearing
directly
invoked
indirect
labels
class
case
insensitivity
considerations
described
std
and
rfc
dns
has
additional
axis
for
data
location
called
class
the
only
class
global
use
this
time
the
internet
class
the
handling
dns
label
case
not
class
dependent
with
the
original
design
dns
was
intended
that
recursive
dns
resolver
able
handle
new
classes
that
were
unknown
the
time
its
implementation
this
requires
uniform
handling
label
case
insensitivity
should
become
desirable
for
example
allocate
class
with
case
sensitive
ascii
labels
would
necessary
allocate
new
label
type
for
these
labels
eastlake
standards
track
page
rfc
dns
case
insensitivity
clarification
january
case
input
and
output
while
ascii
label
comparisons
are
case
insensitive
std
says
case
must
preserved
output
and
preserved
when
convenient
input
however
this
means
less
than
would
appear
since
the
preservation
case
output
not
required
when
output
optimized
the
use
indirect
labels
explained
below
dns
output
case
preservation
std
views
the
dns
namespace
node
tree
ascii
output
name
were
marshaled
taking
the
label
the
node
whose
name
output
converting
typographically
encoded
ascii
string
walking
the
tree
outputting
each
label
encountered
and
preceding
all
labels
but
the
first
with
period
wire
output
follows
the
same
sequence
but
each
label
wire
encoded
and
periods
are
inserted
case
conversion
case
folding
done
during
such
output
operations
thus
preserving
case
however
optimize
output
indirect
labels
may
used
point
names
elsewhere
the
dns
answer
determining
whether
the
name
pointed
for
example
the
qname
the
same
the
remainder
the
name
being
optimized
the
case
insensitive
comparison
specified
above
done
thus
such
optimization
may
easily
destroy
the
output
preservation
case
this
type
optimization
commonly
called
name
compression
dns
input
case
preservation
originally
dns
data
came
from
ascii
master
file
defined
std
zone
transfer
dns
dynamic
update
and
incremental
zone
transfers
rfc
have
been
added
source
dns
data
rfc
rfc
when
node
the
dns
name
tree
created
any
such
inputs
case
conversion
done
thus
the
case
ascii
labels
preserved
they
are
for
nodes
being
created
however
when
name
label
input
for
node
that
already
exists
dns
data
being
held
the
situation
more
complex
implementations
are
free
retain
the
case
first
loaded
for
such
label
allow
new
input
override
the
old
case
even
maintain
separate
copies
preserving
the
input
case
for
example
data
with
owner
name
foo
bar
example
rfc
loaded
and
then
later
data
with
owner
name
xyz
bar
example
input
the
name
the
label
the
bar
example
node
bar
might
might
not
changed
bar
the
dns
stored
data
thus
later
retrieval
data
stored
under
xyz
bar
example
this
case
can
use
xyz
bar
example
all
returned
data
use
xyz
bar
example
all
returned
data
even
when
more
than
one
being
returned
use
mixture
these
two
capitalizations
this
last
case
eastlake
standards
track
page
rfc
dns
case
insensitivity
clarification
january
unlikely
optimization
answer
length
through
indirect
labels
tends
cause
only
one
copy
the
name
tail
bar
example
bar
example
used
for
all
returned
rrs
note
that
none
this
has
any
effect
the
number
completeness
the
set
returned
only
the
case
the
names
the
set
returned
the
same
considerations
apply
when
inputting
multiple
data
records
with
owner
names
differing
only
case
for
example
record
the
first
resource
record
stored
under
owner
name
xyz
bar
example
and
then
second
record
stored
under
xyz
bar
example
the
second
may
stored
with
the
first
lower
case
initial
label
name
the
second
may
override
the
first
that
only
uppercase
initial
label
retained
both
capitalizations
may
kept
the
dns
stored
data
any
case
retrieval
with
either
capitalization
will
retrieve
all
rrs
with
either
capitalization
note
that
the
order
insertion
into
server
database
the
dns
name
tree
nodes
that
appear
master
file
not
defined
that
the
results
inconsistent
capitalization
master
file
are
unpredictable
output
capitalization
internationalized
domain
names
scheme
has
been
adopted
for
internationalized
domain
names
and
internationalized
labels
described
rfc
rfc
rfc
and
rfc
makes
most
unicode
available
through
separate
application
level
transformation
from
internationalized
domain
name
dns
domain
name
and
from
dns
domain
name
internationalized
domain
name
any
case
insensitivity
that
internationalized
domain
names
and
labels
have
varies
depending
the
script
and
handled
entirely
part
the
transformation
described
rfc
and
rfc
which
should
seen
for
further
details
this
not
part
the
dns
standardized
std
security
considerations
the
equivalence
certain
dns
label
types
with
case
differences
clarified
this
document
can
lead
security
problems
for
example
user
could
confused
believing
that
two
domain
names
differing
only
case
were
actually
different
names
furthermore
domain
name
may
used
contexts
other
than
the
dns
could
used
case
sensitive
index
into
some
database
file
system
could
interpreted
binary
data
some
integrity
authentication
code
system
these
problems
can
usually
handled
using
standardized
canonical
form
the
dns
eastlake
standards
track
page
rfc
dns
case
insensitivity
clarification
january
ascii
type
labels
that
always
mapping
the
ascii
letter
value
octets
ascii
labels
some
specific
pre
chosen
case
either
uppercase
lower
case
example
canonical
form
for
domain
names
and
also
canonical
ordering
for
them
appears
section
rfc
see
also
rfc
finally
non
dns
name
may
stored
into
dns
with
the
false
expectation
that
case
will
always
preserved
for
example
although
this
would
quite
rare
system
with
case
sensitive
email
address
local
parts
attempt
store
two
responsible
person
rfc
records
that
differed
only
case
would
probably
produce
unexpected
results
that
might
have
security
implications
that
because
the
entire
email
address
including
the
possibly
case
sensitive
local
left
hand
part
encoded
into
dns
name
readable
fashion
where
the
case
some
letters
might
changed
output
described
above
acknowledgements
the
contributions
this
document
rob
austein
olafur
gudmundsson
daniel
anderson
alan
barrett
marc
blanchet
dana
andreas
gustafsson
andrew
main
thomas
narten
and
scott
seligman
are
gratefully
acknowledged
normative
references
ascii
ansi
usa
standard
code
for
information
interchange
american
national
standards
institute
new
york
rfc
ohta
incremental
zone
transfer
dns
rfc
august
rfc
bradner
key
words
for
use
rfcs
indicate
requirement
levels
bcp
rfc
march
rfc
vixie
thomson
rekhter
and
bound
dynamic
updates
the
domain
name
system
dns
update
rfc
april
rfc
elz
and
bush
clarifications
the
dns
specification
rfc
july
rfc
wellington
secure
domain
name
system
dns
dynamic
update
rfc
november
eastlake
standards
track
page
rfc
dns
case
insensitivity
clarification
january
rfc
gustafsson
handling
unknown
dns
resource
record
types
rfc
september
rfc
arends
austein
larson
massey
and
rose
resource
records
for
the
dns
security
extensions
rfc
march
std
mockapetris
domain
names
concepts
and
facilities
std
rfc
november
mockapetris
domain
names
implementation
and
specification
std
rfc
november
informative
references
iso
international
standards
organization
standard
for
character
encodings
latin
iso
international
standards
organization
standard
for
character
encodings
latin
rfc
everhart
mamakos
ullmann
and
mockapetris
new
dns
definitions
rfc
october
rfc
postel
domain
name
system
structure
and
delegation
rfc
march
rfc
eastlake
and
panitz
reserved
top
level
dns
names
bcp
rfc
june
rfc
eastlake
brunner
williams
and
manning
domain
name
system
dns
iana
considerations
bcp
rfc
september
rfc
vixie
extension
mechanisms
for
dns
edns
rfc
august
rfc
crawford
binary
labels
the
domain
name
system
rfc
august
rfc
eastlake
manros
and
raymond
etymology
foo
rfc
april
rfc
bush
durand
fink
gudmundsson
and
hain
representing
internet
protocol
version
ipv
addresses
the
domain
name
system
dns
rfc
august
eastlake
standards
track
page
rfc
dns
case
insensitivity
clarification
january
rfc
hoffman
and
blanchet
preparation
internationalized
strings
stringprep
rfc
december
rfc
faltstrom
hoffman
and
costello
internationalizing
domain
names
applications
idna
rfc
march
rfc
hoffman
and
blanchet
nameprep
stringprep
profile
for
internationalized
domain
names
idn
rfc
march
rfc
costello
punycode
bootstring
encoding
unicode
for
internationalized
domain
names
applications
idna
rfc
march
unicode
the
unicode
consortium
the
unicode
standard
http
www
unicode
org
unicode
standard
standard
html
author
address
donald
eastlake
motorola
laboratories
beaver
street
milford
usa
phone
email
donald
eastlake
motorola
com
eastlake
standards
track
page
rfc
dns
case
insensitivity
clarification
january
full
copyright
statement
copyright
the
internet
society
this
document
subject
the
rights
licenses
and
restrictions
contained
bcp
and
except
set
forth
therein
the
authors
retain
all
their
rights
this
document
and
the
information
contained
herein
are
provided
basis
and
the
contributor
the
organization
she
represents
sponsored
any
the
internet
society
and
the
internet
engineering
task
force
disclaim
all
warranties
express
implied
including
but
not
limited
any
warranty
that
the
use
the
information
herein
will
not
infringe
any
rights
any
implied
warranties
merchantability
fitness
for
particular
purpose
intellectual
property
the
ietf
takes
position
regarding
the
validity
scope
any
intellectual
property
rights
other
rights
that
might
claimed
pertain
the
implementation
use
the
technology
described
this
document
the
extent
which
any
license
under
such
rights
might
might
not
available
nor
does
represent
that
has
made
any
independent
effort
identify
any
such
rights
information
the
procedures
with
respect
rights
rfc
documents
can
found
bcp
and
bcp
copies
ipr
disclosures
made
the
ietf
secretariat
and
any
assurances
licenses
made
available
the
result
attempt
made
obtain
general
license
permission
for
the
use
such
proprietary
rights
implementers
users
this
specification
can
obtained
from
the
ietf
line
ipr
repository
http
www
ietf
org
ipr
the
ietf
invites
any
interested
party
bring
its
attention
any
copyrights
patents
patent
applications
other
proprietary
rights
that
may
cover
technology
that
may
required
implement
this
standard
please
address
the
information
the
ietf
ietf
ipr
ietf
org
acknowledgement
funding
for
the
rfc
editor
function
provided
the
ietf
administrative
support
activity
iasa
eastlake
standards
track
page
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment