Incident Response

Monitoring file system changes with PowerShell

3
2 years ago
by Derek Newton in , , ,

I recently returned from facilitating Lenny Zeltser‘s excellent Reverse Engineering Malware course at SANS Security West.  One of the utilities covered in the course is called CaptureBAT, which is a useful utility for monitoring a system for changes while performing malware analysis.  Of course, given my ongoing interest in PowerShell, I decided to see if I could emulate some of CaptureBAT’s file system monitoring functionality natively in a PS script.

There are several strategies that you can use to monitor the file system in PowerShell and I decided to use the .Net framework to help accomplish this task.  Here’s how I did it:

  1. Create a new System.IO.FileSystemWatcher object, and set appropriate settings: 
    $watcher = New-Object System.IO.FileSystemWatcher
$watcher.Path = $searchPath
$watcher.IncludeSubdirectories = $true
$watcher.EnableRaisingEvents = $true

    .Path is the path that will be monitored, .IncludeSubdirectories tells the FileSystemWatcher to monitor all subdirectories of .Path

  2. Now we need to define some events that will fire when $watcher detects a filesystem change, I’m going to define an event for Changed, Created, Deleted, and Renamed: 
    $changed = Register-ObjectEvent $watcher "Changed" -Action {
   write-host "Changed: $($eventArgs.FullPath)"
}
$created = Register-ObjectEvent $watcher "Created" -Action {
   write-host "Created: $($eventArgs.FullPath)"
}
$deleted = Register-ObjectEvent $watcher "Deleted" -Action {
   write-host "Deleted: $($eventArgs.FullPath)"
}
$renamed = Register-ObjectEvent $watcher "Renamed" -Action {
   write-host "Renamed: $($eventArgs.FullPath)"
}

    Within each event you can define code for what you want to happen when the event fires.  In this example I’m just directly outputting the type of action and the full path of the changed object on the filesystem.

  3. That’s pretty much it.  These events will hang around until you close your current PowerShell session or manually unregister the events.  You can unregister the events using the Unregister-Event command: 
    Unregister-Event $changed.Id
Unregister-Event $created.Id
Unregister-Event $deleted.Id
Unregister-Event $renamed.Id

As you can see – monitoring file system changes is actually quite easy with PowerShell.  You could easily take the output of this script and write it to a file (either using output redirection, or specifying output directly in the script) and with a little more code you could read in a CSV/structured file containing a list of exclusions (i.e. what CaptureBat does) and within each event filter out unwanted “noise.”

The great thing about this method is that it just *works* in Windows systems that have PowerShell.  No need to install any applications or run any third-party utilities – which the malware that you’re looking at may be looking for (i.e. anti-analysis measures built into some malware).  My goal is to build a complete replacement for CaptureBat within PowerShell in my spare time over the next few weeks.  Once done, I’ll post the complete script with explanations on my blog…

But for now, time to spend some quality time with the family.  Have a great weekend.

Forensic artifacts: Dropbox

2
2 years ago
by Derek Newton in , , ,

I got a bit waylaid with how Dropbox performs host-level authentication while I was researching and documenting forensic artifacts that Dropbox leaves lying around, but finally have gotten the chance to come back around to finish my research/documentation.  Here’s a summary of my observations:

  • Dropbox binaries are installed into %AppData%\Dropbox\bin instead of the standard %PROGRAMFILES%.  During the install, a number of registry keys were added (13), although they contained no forensically useful data.
  • The Dropbox configuration and state is stored in SQLite files found in %AppData%\Dropbox
    • config.db: contains baseline configuration settings that the Dropbox client references in order to run in a table named config.   Records of interest include:
      • host_id: the authentication hash used by the Dropbox client to authenticate into the Dropbox “cloud.”  This hash is assigned upon initial install/authentication and does not change unless revoked from the Dropbox web interface.
      • email: account holder’s email address.  Can be changed to any value without consequence – set at install/authentication.
      • dropbox_path: actual path to the user’s Dropbox on the local system.
      • recently_changed3: lists the path/filename for the five most recently changed files- this includes files removed/deleted from the Dropbox.  This is probably the only truly useful forensic artifact produced by Dropbox (other than the usual filesystem related artifacts).  The BLOB for this record is text-based and is consistently formatted:
        • text begins with “lp1″, ends with “a.”
        • entries are in order of most recent to least recent and each entry the filename/path is followed by “I00″ and “tp#” (replace # with the order that the file is in + 1, i.e. first entry is followed by “tp2″), separate by line breaks.
        • if the file has been removed/deleted from the Dropbox, the “I00″ text is removed and a “N” is placed in front of the “tp#”.  So, an example of a removed/deleted file is would be:(V41725479:/new file.txt
          Ntp2
      • root_ns: appears to be used throughout the Dropbox DBs to reference the base Dropbox path/location.
    • filecache.db: contains a number of tables, but the primary focus is to describe all files actively in the Dropbox (deleted/removed files are removed from this table upon deletion/removal).  Tables and records of interest:
      • file_journal: includes the filename, path, size (in Bytes), mtime (file modified time, in Unix/POSIX format), ctime (file created time, in Unix/POSIX format), local_dir (flag indicating whether the entry is a directory), and more (mainly unpopulated).
      • block_ref: maps file IDs (fj_id) to file hashes (hash_id) found in the block_cache table.
      • block_cache: hash id (id) and hash.  Hash is of an unknown format and did not match up with anything I could generate using standard tools.
      • mount_table: appears to list folders that are shared with other Dropbox users.
    • host.db: actually not a SQLite database but contains what looks to be a hash of some sort (possibly SHA-1?) and the dropbox path (dropbox_path in config.db) encoded in base-64.  The entire file may be encoded in base-64 (basing this on a few Dropbox forum postings I read), but the first part of the file does not decode into anything human readable or match any other fields that I observed in the other DBs.
    • sigstore.db: stores hash values which correspond to the values found in the block_cache table in filecache.db.
    • unlink.db: appears to be a binary file and is not a SQLite database.  Format and purpose is unknown.

Honestly, short of the recently_changed3 record in the config database, there really isn’t a significant number of useful forensic artifacts generated by Dropbox.  Given Dropbox writes to the local filesystem, your standard filesystem analysis steps will encompass files stored/synced into a subject’s Dropbox; but perhaps, under certain circumstances, the recently_changed3 record and/or the Dropbox ctime/mtime entries for files could come in handy…

Happy Forensicating.

Dropbox authentication: insecure by design

243
2 years ago
by Derek Newton in , , , , ,

For the past several days I have been focused on understanding the inner workings of several of the popular file synchronization tools with the purpose of finding useful forensics-related artifacts that may be left on a system as a result of using these tools.  Given the prevalence of Dropbox, I decided that it would be one of the first synchronization tools that I would analyze, and while working to better understand it I came across some interesting security related findings.  The basis for this finding has actually been briefly discussed in a number of forum posts in Dropbox’s official forum (here and here), but it doesn’t quite seem that people understand the significance of the way Dropbox is handling authentication.  So, I’m taking a brief break in my forensics-artifacts research, to try to shed some light about what appears to be going on from an authentication standpoint and the significant security implications that the present implementation of Dropbox brings to the table.

To fully understand the security implications, you need to understand how Dropbox works (for those of you that aren’t familiar with what Dropbox is – a brief feature primer can be found on their official website).  Dropbox’s primary feature is the ability to sync files across systems and devices that you own, automatically.  In order to support this syncing process, a client (the Dropbox client) is installed on a system that you wish to participate in this synchronization.  At the end of the installation process the user is prompted to enter their Dropbox credentials (or create a new account) and then the Dropbox folder on your local system syncs up with the Dropbox “cloud.”  The client runs constantly looking for new changes locally in your designated Dropbox folder and/or in the cloud and syncs as required; there are versions that support a number of operating systems (Windows, Mac, and Linux) as well as a number of portable devices (iOS, Android, etc).  However, given my research is focusing on the use of Dropbox on a Windows system, the information I’ll be providing is Windows specific (but should be applicable on any platform).

Under Windows, Dropbox stores configuration data, file/directory listings, hashes, etc in a number of SQLite database files located in %APPDATA%\Dropbox.  We’re going to focus on the primary database relating to the client configuration: config.db.  Opening config.db with your favorite SQLite DB tool will show you that there is only one table contained in the database (config) with a number of rows, which the Dropbox client references to get its settings.  I’m going to focus on the following rows of interest:

  • email: this is the account holder’s email address.  Surprisingly, this does not appear to be used as part of the authentication process and can be changed to any value (formatted like an email address) without any ill-effects.
  • dropbox_path: defines where the root of Dropbox’s synchronized folder is on the system that the client is running on.
  • host_id: assigned to the system after initial authentication is performed, post-install.  Does not appear to change over time.

After some testing (modification of data within the config table, etc) it became clear that the Dropbox client uses only the host_id to authenticate.  Here’s the problem: the config.db file is completely portable and is *not* tied to the system in any way. This means that if you gain access to a person’s config.db file (or just the host_id), you gain complete access to the person’s Dropbox until such time that the person removes the host from the list of linked devices via the Dropbox web interface.  Taking the config.db file, copying it onto another system (you may need to modify the dropbox_path, to a valid path), and then starting the Dropbox client immediately joins that system into the synchronization group without notifying the authorized user, prompting for credentials, or even getting added to the list of linked devices within your Dropbox account (even though the new system has a completely different name) – this appears to be by design.  Additionally, the host_id is still valid even after the user changes their Dropbox password (thus a standard remediation step of changing credentials does not resolve this issue).

Of course, if an attacker has access to the config.db file (assuming that it wasn’t sent by the user as part of social engineering attack), the assumption is that the attacker most likely also has access to all of the files stored in your Dropbox, so what’s the big deal?  Well, there are a few significant security implications that come to mind:

  • Relatively simple targeted malware could be designed with the specific purpose of exfiltrating the Dropbox config.db files to “interested” parties who then could use the host_id to retrieve files, infect files, etc.
  • If the attacker/malware is detected in the system post-compromise, normal remediation steps (malware removal, system re-image, credential rotation, etc) will not prevent continued access to the user’s Dropbox.  The user would have to remember to purposefully remove the system from the list of authorized devices on the Dropbox website.  This means that access could be maintained without continued access/compromise of a system.
  • Transmitting the host_id/config.db file  is most likely much smaller than exfiltrating all data found within a Dropbox folder and thus most likely not set off any detective alarms.  Review/theft/etc of the data contained within the Dropbox could be done at the attackers leisure from an external attacker-owned system.

So, given that Dropbox appears to utilize only the host_id for authentication by design, what can you do to protect yourself and/or your organization?

  1. Don’t use Dropbox and/or allow your users to use Dropbox.  This is the obvious remediating step, but is not always practical – I do think that Dropbox can be useful, if you take steps to protect your data…
  2. Protect your data: use strong encryption to protect sensitive data stored in your Dropbox and protect your passphrase (do not store your passphrase in your Dropbox or on the same system/device).
  3. Be diligent about removing old systems from your list of authorized systems within Dropbox.  Also, monitor the “Last Activity” time listed on the My Computers list within Dropbox.  If you see a system checking in that shouldn’t be, unlink it immediately.

Hopefully, Dropbox will recognize the need for additional security and add in protection mechanisms that will make it less trivial to gain long-term unauthorized access to a user’s Dropbox as well as provide better means to mitigate and detect an exposure.  Until such time, I’m hoping that this write-up helps brings to light how the authentication method used by Dropbox may not be as secure as previously assumed and that, as always, it is important to take steps to protect your data from compromise.

Update (10/31/2011): Dropbox has release version 1.2.48 that utilizes an encrypted local database and reportedly puts in place security enhancements to prevent theft of the machine credentials.  I have not personally re-tested this release – feel free to comment if you’ve validated that the new protection mechanisms operate as described.

Volume Shadow Copies

0
2 years ago
by Derek Newton in , ,

Harlan Carvey recently wrote a post on his blog called Accessing Volume Shadow Copies, which provided some excellent instruction on how you can go about accessing Volume Shadow Copies (VSCs) from an existing image without having to use expensive tools (in fact, his solution uses completely free tools).  In Windows 7 and Vista, VSS is turned on by default and thus additional artifacts are possibly just waiting to be discovered.  Accessing a system’s VSC(s) can be highly useful in an investigation and can possibly help you get your hands on older copies of registry hives (i.e. being able to get historical UserAssist data, etc) as well as other older file snapshots (pictures, etc), which can come in very handy.  So, needless to say, if you’re not presently looking for VSCs as part of your forensics workflow, you probably should be…

In the process of testing Harlan’s procedure, I started to wonder how Windows, by default, decides to generate these VSCs (and what is included).  I came up with some data and I thought that I’d go ahead and post my findings (feel free to comment if I’ve gotten anything wrong here):

  • Windows 7/Vista automatically (out of the box) create restore points at pseudo-random intervals:
    • A scheduled task (named SR in Win7) controls when a snapshot occurs.  By default, the task is set to run at 12:00AM every day and 30 minutes after every system startup, but will only execute when the system is plugged in and has been idle for 10 minutes.  If the system is not idle, the task will continue to wait for idle for 23 hours.
    • If a restore point/snapshot has not been successfully created in the last seven days, system protection will create one automatically.
    • And finally, a restore point may be created “automagically” as part of certain software installation/driver installation processes.
    • The bottom line: it is basically impossible to predict with any degree of certainty when a snapshot will occur.
  • All files/folders are covered in a volume snapshot, except for those defined under the HKLM\System\CurrentControlSet\Control\Backup Restore\FilesNotToSnapshot registry key.
  • If a file is modified several times between snapshots, only the version that was current when the restore point/VSC was made will be available to you for analysis.  Mind you, there may be multiple VSCs available, so that can be helpful with getting further historical revisions.

Additional resources:

Wikipedia – System Restore
Wikipedia – Shadow Copy
QCCIS – Reliably recovering evidential data from Volume Shadow Copies Whitepaper

Searching the Registry using PowerShell

1
2 years ago
by Derek Newton in , , ,

On a cold and rainy Thursday morning, I thought that it would be a good time to write a post on searching the Windows registry using PowerShell.  In an Incident Response scenario you may want or need to do some live analysis on a compromised system, and part of this analysis may be to search the registry for some sort of artifact that is appropriate.  Using PowerShell can help you do this in a relatively efficient manner and is, of course, built in on new version of Windows (i.e. Windows 7, 2008, etc).

For example, let’s say that you know (or have guessed) that you’re dealing with some sort of malware that is probably going to be calling home at some time and you are wanting to look through the registry to see if the malware author decided to store any IPs/URLs in the clear.  In PowerShell you are able to easily browse and search through the registry, just like you were dealing with a filesystem.  There are a number of ways to accomplish this (for example, using -match rather than select-string), so feel free to use whatever method you’re comfortable with.  But, let me show you how I mangled my way through it this morning…

  1. Open up a PowerShell window.
  2. Let’s look for things that appear to be IP addresses under HKEY_CURRENT_USER, so first I need to recursively iterate through everything under that hive.  I do this by using the Get-ChildItem method: 
    Get-ChildItem HKCU:\ -rec -ea SilentlyContinue

    This method returns a complete list of all keys (as objects of course) under the HKCU hive.

  3. From there, we’re going to need to dig into each of these returned objects and do our search.  So I’m going to pipe the output of the previous command into a foreach loop and then retrieve the data for each key: 
    Get-ChildItem HKCU:\ -rec -ea SilentlyContinue | foreach {
   $CurrentKey = Get-ItemProperty -Path $_.PsPath
  4. Now that we have the contents that we want to search, let’s search for something that looks like an IP address and then print out any matches: 
       select-string "\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b" -input $CurrentKey -AllMatches | foreach {($_.matches)|select-object Value}

    You’ll notice the use of a simple regular expression that will match on things that “look” like IP addresses.  If, for example, you’d prefer to look for URLs, a simple regex that you can use that’ll match most URLs would be: “\b(ht|f)tp(s?)[^ ]*\.[^ ]*(\/[^ ]*)*\b”.

  5. So putting it all together, to perform a simple string search of the registry for possible IP addresses and URLs using a regular expression you can use the following script: 
    write-host "Possible IP addresses:`n"
Get-ChildItem HKCU:\ -rec -ea SilentlyContinue | foreach {
   $CurrentKey = (Get-ItemProperty -Path $_.PsPath)
   select-string "\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b" -input $CurrentKey -AllMatches | foreach {($_.matches)|select-object Value}
}
write-host "`nPossible URLs:`n"
Get-ChildItem HKCU:\ -rec -ea SilentlyContinue | foreach {
   $CurrentKey = (Get-ItemProperty -Path $_.PsPath)
   select-string "\b(ht|f)tp(s?)[^ ]*\.[^ ]*(\/[^ ]*)*\b" -input $CurrentKey -AllMatches | foreach {($_.matches)|select-object Value}
}

This code will return any hits on the specified regular expressions, but doesn’t actually give you context as to where it was found within the registry.  If you’re just looking for odd URLs/IP addresses, it may be useful for you to just see a simple list of both to run through; but, if you want more context you may want to use a conditional with -match rather than select-string and then just output $CurrentKey:

write-host "Possible IP addresses:`n"
Get-ChildItem HKCU:\ -rec -ea SilentlyContinue | foreach {
   $CurrentKey = (Get-ItemProperty -Path $_.PsPath)
   if ($CurrentKey -match "\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b") {
      $CurrentKey
   }
}
write-host "Possible URLs:`n"
Get-ChildItem HKCU:\ -rec -ea SilentlyContinue | foreach {
   $CurrentKey = (Get-ItemProperty -Path $_.PsPath)
   if ($CurrentKey -match "\b(ht|f)tp(s?)[^ ]*\.[^ ]*(\/[^ ]*)*\b") {
      $CurrentKey
   }
}

PowerShell can be a really powerful tool for easily searching the registry and is a good, albeit slightly slower, alternative to using another method that would require an interpreter, etc (i.e. Perl).  Have fun!

Your company is a target – targeted phishing attacks

0
2 years ago
by Derek Newton in ,

Whether you choose to believe it or not, your company (given it is of a reasonable size or deals with sensitive data) is, or will be, the target of a specific technology oriented attack of some kind.  And I’m not talking a basic port scan here, I’m talking an attack tailored to your environment in some way where an attacker is specifically trying to access your infrastructure.  If you look hard enough within your environment, you’ll most likely find something of value (be it your secret sauce recipe, credit card numbers, SSNs/PII, etc) and there will always be people interested in getting their hands on that data.

This is the first of a series of posts that will discuss specific attack vectors that are commonly used in targeted attacks along with how I recommend you respond to and proactively protect against the attack.  We’ll begin with targeted phishing attacks…

Targeted Phishing Attacks

Overview

Wikipedia defines phishing as “the criminally fraudulent process of attempting to acquire sensitive information such as usernames, passwords and credit card details by masquerading as a trustworthy entity in an electronic communication.” (source)

Common phishing attacks can be written in either a general (for a large, non-related audience) or in a targeted fashion.  General phishing attempts are rather easy to recognize and many computer users have become savvy enough to not respond to those attempts (in addition, many SPAM filters catch a large number of these attempts before they even reach an inbox).  However, a targeted Phishing attack is more sophisticated and is written with a specific audience (your company’s users) in mind; it’ll ask for company specific information using company specific terminology, which lends a more authentic and authoritative feel to the communication.  This request for specific information may appear to be sent from a commonly known or believable email address within your organization, albeit if you dig into the email header and/or reply to address you’ll clearly notice that the email did not originate within your organization and the reply-to address is outside of your organization.

The goal of a targeted phishing attack on an organization is most likely to gain access to credentials or to some other set of information that will allow attackers to impersonate a user (to gain access to credentials, etc).

Response

A targeted phishing attack on an organization should be considered a direct threat to the security of your environment and you should respond swiftly.  Some debate may exist as to whether an actual “incident” has occurred, but I generally lean towards treating a targeted phishing attempt as a live incident and treating it as such – hopefully you already have an incident response policy in place that will provide some guidance as well as empower the incident responder (I’ll write more on this in a future post).  At a minimum, given you have been notified that a targeted phishing email has made its way to end-users, you should assume that users have already responded or are at risk of responding to the attempt.

If you are the recipient of a targeted phishing attack (via email), I recommend that while following your existing incident response procedures, that you take the following incident-specific reactive steps:

  1. Notify end users immediately that the email that they received is not legitimate and if they responded to it, they should contact your helpdesk immediately (or some other team/individual that is available to assist) so that corrective actions can be taken; the specific corrective action that is taken by your helpdesk is dependant on the information being phished for.  If the email is requesting credentials, then you should change them, if possible.  If the email is requesting PII that can be used by an attacker to impersonate a user, then the account should be flagged in some way so that the helpdesk/administration team takes extra care when contacted.  If you cannot quickly determine who actually received the phishing email, send this alert to your entire user population.
  2. Inspect the phishing email’s message header and record all pertinent information.
  3. If possible, put a block in place that will be prevent any outbound email being sent to the reply-to address of the phishing email.  Additionally, if possible, put a block in place preventing any further attempts with the reply-to address or subject line, etc from being delivered.
  4. If possible, run a search of your email logs to determine whether anyone responded to (i.e. sent email to) the reply-to address of the phishing email.  If you do find responses, you should contact these users immediately and take corrective action on their account – corrective action should be taken whether or not you can get in touch with the user.  Since the attackers generally realize that they have a limited window to “exploit” the information that they receive, it might be wise to check any remote access systems (or other systems in the organization) for activity using the userid that was provided to the attacker to ensure that they have not already made their way into your environment.

Proactive Mitigation

There are a number of strategies that you can implement to help lower the effectiveness of a targeted phishing attack.  The number one strategy to combat phishing is user education – I cannot stress this enough.  An informed and educated user population is much less likely to respond to phishing attempts.  Regular communications should be sent out to users reminding them of information that will never be asked of them via email and that any emails received asking for this information should not be responded to and reported to your security clearinghouse (be that an incident response team, helpdesk, local security contact, etc).  Additionally, your user onboarding process should include education new users of this threat and IS/IT personnel should also be regularly reminded as what information they’re allowed to ask a user for and what method of communication is appropriate for these questions.

Other mitigation strategies include:

  • Putting in place a filter on your email gateways and/or filtering solutions to drop any email coming from outside your organization that has your organization’s domain in the From line.  Well-designed email environments should never receive email with internal From addresses from external sources – I do recognize, however, that many environments may have external providers sending in these types of emails, so exceptions may need to be put in place.
  • External (and Internal, if feasible) authentication should be two-factor where the second authentication mechanism uses a rotating code (i.e. RSA SecurID) or is something the user has (i.e. smartcard).
  • Externally accessible web pages, including system access pages (i.e. VPN, work from home, etc) should not contain company specific terminology or information that can be mined by an attacker to better craft their phishing message.

A good phishing attack is no longer easily identifiable and is written in such a way that even the most savvy of users may consider the request legitimate.  Attackers are increasingly using more sophisticated phishing techniques to allow them to gather information to gain access to your environment and you should be taking steps now to help mitigate the impact that a well-crafted attack could make and plan for this eventuality.

Go to Top