Sunday, February 9, 2014

Quick and Dirty Windows Malware Analysis

Quick and Dirty Windows Malware Analysis

This is to accompany the slide deck that Chris Ziegler and I presented last week at University of Washington.  We presented it really within the context of doing quick and dirty malware analysis during a CTF / Red/Blue exercise...

Malware can be examined statically (at rest) or dynamically (when it's running). Let's start with static analysis...

Static Analysis

Finding malware in the first place:
  • Look for files with high entropy - there aren't that many legit heavily encrypted / obfuscated binaries
  • Look for files that have been timestomped (had their timestamp overwritten)
  • Look for alternate data streams 
    • Note: there is a legitimate use of ADS for IE where it uses ADS to provide the extra dialog prompts for internet-downloaded files. ADS have also been used in other applications for tagging files, etc. -- From a forensic standpoint, all of the files with ADS should stand out like a sore thumb
  • To look at entropy, there are a number of open-source python projects and it's not too involved. There are also EnCase features that will allow for you to check that out.
    • NOTE: there's now an even easier way to do this (thanks to @mattifestation) in powersploit called Get-Entropy which will take either a file or a byte array ( C:\PS>Get-Entropy -FilePath C:\Windows\System32\kernel32.dll )
  • Take a look through the PE Headers with a good PE Explorer:
    • Chris' favorite is NTCore Explorer Suite
  • Look for some of the following hinky stuff in the PE:
    • Empty executable sections (or sections filled with NOPs)
    • Uncommon section names - it turns out that most binaries have similar section names
STRINGS... yup running strings on a binary at rest and / or dumping a process and looking through the strings can be a super useful way to pull a lot of good and interesting data from the stuff that you're analyzing. It's funny how easy it is to store (and retrieve) C2, address, domain, function, config and versioning information with strings. 

Import Address Table info
  • The IAT is a section of the PE which is used as a lookup table for when an application is calling different functions
  • In Windows, functions are connected to the main executable through linking (static, dynamic, runtime). Runtime linking is pretty popular with malware and static linking isn't very popular on Windows (in general) - most other stuff will be dynamically linked.
    • If stuff is dynamically linked then you'll see lots of juicy imported functions in the PE Header
    • Linking at runtime means using GetProcAddress and LoadLibrary and probably not a lot of other inputs, which also probably looks a lot like that file could be / is malware
  • There are a few functions that are pretty stand-out ish such as:
    • URLDownloadToFile
    • SetWindowsHookEx
  • Import hashing is a pretty good technique for tracking pieces of malware across actors and campaigns
More Reading
Dynamic analysis is looking the behavior and characteristics of malware while it's not at rest. There are more or less two main ways to look at this, either to load up tools on a compromised machine/asset or to put the malware / a compromised system inside of a sandbox or other monitoring environment. 

Loading Up

The first way that we're going to cover to do dynamic analysis is to  load up tools on a compromised / affected host. This is good for live monitoring things like network traffic (with Wireshark / Tshark) and for monitoring how a piece of malware that you've got interacts with the underlying system. For more of a reference of how malware lives on a system - check out the "Malware is Alive" section of the Backdoor Primitives post that I wrote.

Opsec Tip:
Loading up tools onto a host is a fine technique once the host is completely quarantined.  however, it's super loud and if you have an attacker that knows what they're doing on the host, it will stand out like a sore thumb.

Evaluating processes with process explorer

  • Process Explorer is a very powerful tool that's part of the Sysinternals toolset , I would definitely encourage folks to look through the whole set of tools and their various capabilities. below are the quick and dirty capabilities that y'all should take a look at.
    • Verify Options
      • verify signature - this will show whether or not the signature of the process image is valid or not
      • verify packing - this will run a basic analysis to tell you if the process image is packed
    • Strings
      • all (at least 3 char) printable strings
      • either f rom process image on disk or in memory
Finding Threads
  • For this particular method of finding threads, you can use the volatility "threads" functionality
  • It's been a while since I gave volatility a whirl and poked around for threads, however, a cursory search found this MNIN Security Blog which is literally all about it. 

Sandbox'n it Up

So pretty much the Cadillac of free sandboxes these days is Cuckoo, the easiest way to get started with it / run it is probably in Malwr. I say this because I'm not an expert with VirtualBox and the last time that I tried to set up Cuckoo on my own it wasn't painless.  I would write more about the ins and outs of Malwr and Cuckoo, but I think that exercise is better left to the reader. You can look back through old submissions on the malwr homepage and some interesting submissions with analysis are linked on the @malwr twitter feed.

Anubis is another very handy online tool that you should check out and is also fairly self-explanatory. I submitted a toy sample to Anubis that can be checked out here. Features of Anubis include:
  • Mutexes created
  • Memory-mapped files
  • Device Control Communication
  • File System Control Communication
  • Files Modified
  • Files Read
  • Files Created
  • Files Deleted
  • Registry key operations ( Modified, Read, Monitored )

More Reading


Sunday, February 2, 2014

Backdoor Primitives

Backdoor Primitives

This is a super short post on backdoor primitives, meaning the building of the blocks of backdoors. When looking for backdoors in the network and doing things like remediating events, keep in mind that your attacker probably has these things pretty well covered. Please don't do things like assume that if there's not stuff laying all over disk that a machine isn't compromised. It's not 2005 and most *good* people have figured out and integrated reflective loading into most of their exploitation TTP's.

Backdoors always have:

  • Network transport(s)
    • Without a way to talk to other backdoors in the network and/or the outside world, there isn't much point of having a backdoor in a network. The unrelenting truth of network exploitation is measured in bytes in / bytes out. 
  • State storage
    • There has to be somewhere (in memory, on disk, reg keys, mutexs, etc.) where a backdoor keeps its state and configuration and does handy things like making sure that two copies of it aren't installed on the same host by accident (you'd be surprised how often attackers run into this scenario).

Backdoors sometimes have:

  • Built-in persistence mechanisms
    • making it so that you don't have to do more than type a line in a command prompt to get persistence
  • Built-in lateral movement mechanisms
    • making it so that you don't have to manually do service executable replacement (or other nifty tricks) by hand to execute code remotely
  • "on-host kit"
    • This is pretty much everything and the kitchen sink, this is all the stuff that is broken apart into a plethora of different tools that a quality backdoor has baked in, including mimikatz-like functionality to dump creds and passwords, keyloggers, etc.

Packers exist

I'm not talking about the cheesheads from Green Bay, I'm talking about the fact that there are F as in Free tools that will make an attacker binary / code not look like anything malicious to A/V and other hash-centric tools. There is a whole range from "doesn't flag A/V" to "um this is obfuscated by I can use Olly to deal with it" to "Zoinks, this is commercially packed / encrypted and I don't know what to do about it". I write this because I've seen multiple lazy and skilled defenders do stuff like "hashes" and "fuzzy hashes" as a foundational part of doing forensics, IR and threat intel. Please stop doing that (or at least please stop pretending it's a complete approach) . Modifying a PE and / or encrypting binaries is not a hard thing to do and well below HD Moore's law of skiddies.

Attackers can have more than one set of tools:

There are different tools for different purposes, I don't use a wrench and a screwdriver interchangeably, mostly because they are fairly purpose-built tools. Attackers are much the same way in that there are predominantly two types of implants (backdoors) that a semi-skilled attacker will use:
  • Stage I Implants
    • Lightweight
    • Main purpose is download and execute
    • May essentially be little more than shellcode and have no footprint on the target machine
    • Will only communicate with initial (burnable / short term) C2
    • "burnable" and low-cost
  • Stage II Implants
    • Meant for persistence / long-term deployment
    • "not as burnable", higher cost implant
    • May use multiple C2 methods and will use multiple C2 endpoints if it is well designed for long-term deployment
    • Swiss-army knife type full of kit for...
      • hash / cached cred / password dumping
      • domain / network enumeration tools
      • purpose-built functions 
      • etc.

Malware is alive

Malware running on a system has to be executing at some level. This means that it can exist as one of the following:
  • Process
    • On disk 
    • In memory (runs process and then deletes presence on disk)
  • Thread
    • DLL attachment
    • CreateRemoteThread
    • Detour patching
  • Rootkit
    • Kernel-mode/User-mode
    • DKOM
    • Hooking

For more information about how attackers use tools:

Check out the 3-part blog post on an intro to attacker methodology:

Learn more:

Here are 3 blogs that are all by very well versed and qualified penetration tester / red team folks that develop, reverse engineer and generally know a lot of stuff about backdoors. I suggest that you check out what they have to say and if you're participating in CCDC you'll definitely want to go through the ins and outs of what they're talking about.

Intro to Attacker Methodology Part III - Persistence and Entrenchment

Part III - Persistence and Entrenchment

Background / Assumptions

Well you made it to part 3 of this series which either means that you're in the wrong place or you're really just interested in how attackers make their beds in a network and then proceed to camp out indefinitely. It's always very interesting to participate in remediation discussions because of how incredibly hard it is to actually cut an attacker off from a network once they've stolen the credentials and been hanging around for a while. I know that my goals were always to achieve a sort of network-zen where my actions were one with the network and overall I was in a better position to administer the network than the people who were getting paid to (by the target org).

Up to this point I've covered how to get into a network and how to move around, but unless you're on a 3-day pentest or you're just here for the smash-n-grab, persistence is something that every attacker is going to care deeply about. 

Here are the links to the first couple posts in case you want to read them first or go back for a refresher...


This is a super TL/DR summary of persistence, for a much more in-depth treatment of the subject matter, y'all should check out the presentation that @passingthehash and I did at DerbyCon 2013...

Starting access level: Temporary access to an asset in the target network
End Goal: Persistent access to the target asset / network
Attacker Steps: Leverage access to gain persistence

So when I look at it there are really a few types of persistence:
  • Persistent during but not across power cycles
  • Across power cycles (for a single user)
  • Across power cycles (for all users of the system)
The first two do not require administrative privileges on the target asset and can be achieved simply and reliably through registry modification. Running in memory is an excellent way of staying persistent during a power cycle with almost no footprint on the asset (unless the defenders do a full memory dump during / before turning the machine off). After our DerbyCon talk a few people argued that this isn't persistence, I would ask those people how often their company's domain shuts down all of their domain controllers (and workstations) at the same time?

Common persistence methods include: 
  • Services (on Windows)
    • Services are great for attackers because they are both naturally robust as well as programmed to run as default NTAUTHORITY\SYSTEM, on boot and are remotely query-able (read - troubleshoot-able) remotely with tools such as SC.
  • Run Levels (on Linux)
    • not many people validate everything in their runtime configs all of the time
  • Registry Keys
  • Autoruns (huge category)
  • Startup scripts
  • DLL path hijacking
    • exploiting unquoted paths in loading service and other executables
  • Unquoted pathname problems
    • check using sc and sc qc <servicename>
  • Re-exploitation
    • just when you think you've kicked your attacker out, make sure that you have a full understanding of the original hole that they came in through and that you've patched that all up

Beyond these common methods, I would strongly suggest that readers refer to the PPT and Derbycon Presentation.

    Looking for persistence / backdoors

    • Look for high-entropy binaries
    • Look in prefetch
    • Audit services
    • Look for unsigned drivers and dll's (especially in relation to services)

    More Reading

    Starting access level: Temporary access to an asset in the target network
    End Goal: Persistent access to the target asset / network
    Attacker Steps: Leverage access to gain persistence

    Entrenchment is really where an attacker sets up shop in the network. It starts with expanding upon the initial foothold gained during the persistence phase of the attack by spreading that level of persistent access to the point where it is robust to defender actions.

    Steps to gaining an entrenched presence in a target network:
    • fully understand the administration structure of the network including enumerating who admins what and when - mimic that in your actions
    • gain access to and exfiltrate all credentials, authentication material (hash dump of the domain) 
    • gain multiple methods of persistence in the target network
    Secondary methods of access:
    • VPN's
    • Multiple types of backdoors in the network
    • Multiple transports in the network, e.g., HTTP & DNS command and control communications (C2)
    • Webshells
    • Infrastructure backdoors

    Attacker Methodology Intro Part Deux (PrivEsc and Propagation)

    Background and Assumptions

    This is not an in-depth treatment of the subject matter, this is meant as a quick and dirty intro to attacker methodology. The goal is that folks that read or review this will have a basic understanding of how attackers think, and/or some of the challenges that they will face trying to defend a network. There are some notes in here for CTF/CCDC style competitions as well.

    Local Privilege Escalation

    Starting access level: non-privileged access to a single host in the network
    End goal: privileged access to the host
    Attacker Steps: Gain information about the local machine and exploit a misconfiguration or software vulnerability to elevate privileges


    So... when you compromise a target you gain code execution within the context of the software or user you just exploited. That means that if you just pwnd a web server you're running with the privs of that web server process on the remote server. On the client side that means that you're running code within the privs of the user you just popped. In the days prior to Windows XP, it was pretty routine that one would compromise a target just to find that they were running as an administrator on the local machine and well they didn't need/use anything in this section. 

    There's a big difference as an attacker to running in (especially) the different Windows integrity levels - specifically stuff that you can't do:
    Low Integrity
    • Pretty much the only thing you can do here is write to a virtual filesystem / registry
    • No cross-boot persistence (can't write to any fun reg. keys etc.)
    Medium Integrity
    • You get cross-boot persistence, but only for when one user logs in
    • You can keylog (only the user that your originally popped)
    • No cached password dumping, no dumping hashes from the local host
    • No computer-wide keylogging
    • No computer-wide persistence
    • No packet crafting or MITM attacks
    • I *would* like to point out that you can still PTH by generating the token on your (remote) attack machine and then just port-forwarding the authentication traffic (135-139,445)
    High Integrity
    • Pretty much everything since you're a local administrator on the box, still some files and reg. keys that are "untouchable"
    • Prior to Windows Vista this is god-mode
    • WinVista + you can't touch anything that's owned by the TrustedInstaller group
    • TrustedInstaller is a service that runs to install patches / updates to the OS that was introduced in Windows Vista
    • welcome to god-mode

    Step 1 - Situational Awareness:

    Good attackers don't do anything until they know what's going on with the host that they're executing code on, which at a minimum includes enumerating ( I like these because none require admin privs to run ) :
    • What user they are running as
      • whoami
      • set
      • net user <NAMEOFUSER> /domain
    • Who uses the system
      • net localgroup users
      • net localgroup adminsitrators 
    • What the system is for
      • net statistics /workstation
      • net statistics /server
    • What else is hanging around
      • ipconfig /all
      • ipconfig /displaydns
      • arp -a

    Step 2 - Misconfigurations:

    A whole lot of the time you don't need a software vulnerability as an attacker to privesc on Windows or Linux due to the high difficulty of hardening and monitoring changes off of a baseline for every system in a network. Most of the time the misconfigurations are either:
    • Permission issues
    • 3rd party software and insecure directory permissions
    • service configuration issues
    • Domain-specifc configs (startup scripts, 
    • passwords stored improperly on the system ( in registry keys, 3rd party software, config scripts 
    Ways to check for these...

    Step 3 - Software Vulnerabilities:

    OH: " patches ? we don't need no stinking patches "
    Umm... turns out that patches are kind of important to not getting easily pwnd. Using Windows Update is a good way to make sure that you get / have patches. Other ways include looking at add/remove programs, wmic and other administration tools

    Read More




    Encylopedia of Windows PrivEsc
    AT is the new Black *

    Lateral Movement

    Starting access level: Access to a single host in the network
    End goal: Access to other hosts in the network
    Attacker Steps: Gain information about the network, leverage password re-use, network permissions or network misconfiguration to traverse the network

    Situational Awareness (it's back):

    Local Credentials only go so far ... unless everyone's got the same local credentials
    • If the network will allow you - local admin password re-use is a great way to bounce from machine to machine
    • If all of the local passwords are different ... then you should look at Group Policy Preferences (GPP)... there's this thing called the CPassword attribute which, when certain policies are active will store most-all of the local passwords for machines in the domain in a plaintext-equivalent fashion
    • Look at network shares and do what you can with read or write access (.LNK files

    Methods for executing code remotely

    Running code remotely... there really aren't that many ways to do it
    • PSExec
    • MOF (managed object format)
    • Remote task scheduling
    • PowerShell Remoting
    • Remote Registry Modification
    • Service executable replacement (remote)
    • RDP ( which isn't turned on by default and is really only on servers )
    • Malicious update server
    • WPAD
    • Network Ninja Time / MITM

    Network PrivEsc

    Starting access level: Access to multiple system on the network 
    End goal: Access to other hosts in the network
    Attacker Steps: Gain information about the network, leverage password re-use, network permissions or network misconfiguration to traverse the network

    Elevating privs on the network may not be necessary depending on how an attack gained access to the target network. On the one hand if the initial compromise is a server, it's usually just a matter of dumping cached credentials and bouncing around around the different servers until a set of creds show up for the DC and then it's game over. 

    Moving from a workstation to more privileged access in the domain can be quite a bit more challenging, especially in networks that have good separation (don't have flat domain / enterprise structures), restrictive OU's, and responsible admins (that use low-priv accounts to manage the workstations / do support tasks).

    Situational Awareness

    • Using LDAP / DSQuery to pull all of the relevant domain information
      • All admins for the workstation that you're on
      • OU's, Groups and separations in the network
      • All admins in the network - enumerating built-in and other groups in the network
    • Use nltest (from the ntreskit) to determine trust relationships
    • note: these tools can be a pain in the arse to get running in a customer networks (they're not installed by default) and all of this can be better accomplished through PowerShell and the net commands will get it done in a pinch

    Pulling yourself up by your bootstraps

    Once you have some level of access to other assets in the network, a lot of the work comes down to figuring out which assets in the network belong to network admins, targeting their workstations is usually the most effective way of elevating privs in the network. Misconfiguration of network deployment and scanning tools is a another quick method of escalating privs as they often do not securely manage authentication remotely (the credentials can be stolen) or securely store credentials. Some examples of this include:
    • C:\unattend.txt
    • C:\sysprep.inf
    • C:\sysprep\sysprep.xml
    • VNC
    • SNMP parameters
    Service Accounts...
    • Service accounts are *traditionally* accounts used for non-interactive tasks that need to be run in a network 
    • The easiest way to set this up is making a domain user account not associated with an actual user which is good for attackers and problematic for admins because:
      • the password has to be managed by the network administrators
      • it's really hard to change the password because usually these accounts are critical for the operation of the domain
      • more times than I'd like to count, these passwords end up being variations on p@$$w0rd1 or QAZWSXEDCRFV (keyboard walks)
    • MSA's aren't really good news for attackers, the accounts have privs for one computer, but aren't really useful for moving around the network. 

    More Reading

    * this is an aggregate source which may not credit all sources

    Saturday, February 1, 2014

    Intro to Attacker Methodology

    Attacker Methodology

    A co-worker and I recently had the opportunity to go work with some of the aspiring infosec gurus at UW this week and so I'm putting all 3 parts of the lecture that we gave here online... so ... let's get started with some basic adversary methodology...

    Background / assumptions: 

    This is probably useful if you've never defended or broken into a network on your own before. The goal is that this is a primer to understanding malware, understanding what attackers are after and what they need to do with malware should help towards that overall level of understanding.

    Attack Phases

    Here are the basic phases of an attack, all of which are important in the real world:

    Facebook recent RCE
    • OSINT
    • Initial Access
    • PrivEsc (Local)
    • Lateral Movement
    • PrivEsc (Network)
    • Persistence
    • Entrenchment

    Competition networks

    For working in a "game" network you'll only really need to worry about the following attacker phases (but I'd advise reading this whole thing - you can skip the rest of it if you're more TL/DR):

    • Lateral Movement
    • Persistence
    • Entrenchment
    I wouldn't really worry beyond that scope in a game because there are almost always rules which allow for the Red Team to pre-compromise the network or you'll have to deal with a network that's riddled with semi-rediculous vulns like MS08-067, RPC-DCOM, or stuff that fits into the category of "easily remotely exploited with default Metasploit".


    Starting access level: No internal access to the network
    End Goal: Targeting / Attack strategy and outline of network resources, identities, etc.
    Attacker Steps: Use open and public resources to build out a picture of the target
    • Open Source Intelligence (OSINT)
    • Focus on identities (people), technology and the context and connections between them 
    • Connections
      • Connections are what ties the individuals and technologies together
        • Ex: The organization is hiring for a DBA position so the posting can be analyzed to find out more about the IT support group structure (other individuals) and the technology (type(s) of databases and web servers that are in the network
      • Groups, networks, organizations
    • Context
      • Context refers to the roles and responsibilities of the identities/people that are targets are
    • Technology
      • OSINT will should provide a background of what's in a target network and a start at how it's all connected together.

    OSINT - in context - Phishing

    • A commonly used tactic is for attackers to try to get their hands on screenshots or snapshots of internal email or websites to build higher quality phishing or other social engineering content.

    For more information on OSINT see:

    Initial Access

    Starting access level: No internal access
    End Goal: Initial access in the network (running arbitrary code in the network)
    Attacker Steps: Leverage OSINT information to target and gain access to the network
    • Social Engineering
      • TL/DR this is where you get people to do things that they probably shouldn't to get easy access to the network. This spans everything from getting users to give personal information to login information to just directly downloading and executing binaries
    • Targeted Attacks
      • While completely overused in industry, "targeted" means that the content of the attack is crafted for the target, this means a phishing, spearphishing, whaling, etc, piece of content mean to appear especially enticing or valid to the target
      • Really this is just about all attacks except for broadly used Exploit Kits (EK's) when used by bot herders
    • Remote Code Execution
      • Remote Code Execution vulnerabilities come in two main flavors:
        • Server-Side RCE
          • The old-school flavor (MS08-067, RPC-DCOM, etc) are mostly short-lived software vulnerabilities that crop up in environments that don't have good compliance / patch management and/or 3rd parties running remotely accessible services for a company
          • The slightly less old-school flavor are web-based vulnerabilities 
          • The newer vulnerabilities are those that result in code execution directly on the server through the service endpoint / exposed API surface. This would 
        • Client-Side RCE
          • These are vulnerabilities accessible either through a document format (usually delivered via email) or through a user agent
          • Attacks right now seem pretty fixated on 3rd party browser plugins, especially Oracle Java

    For more information see:

    Social Engineering

    Web Vulnerabilities (RCE)

    Server-Side Code Execution Bugs (new-school)

    Client-Side RCE Bugs