Top 11 Reasons Why You Should NOT Miss the SANS DFIR Summit and Training this Year

The SANS DFIR Summit and Training 2018 is turning 11! The 2018 event marks 11 years since SANS started what is today the digital forensics and incident response event of the year, attended by forensicators time after time. Join us and enjoy the latest in-depth presentations from influential DFIR experts and the opportunity to take an array of hands-on SANS DFIR courses. You can also earn CPE credits and get the opportunity to win coveted DFIR course coins!

summit video pic

To commemorate the 11th annual DFIR Summit and Training 2018, here are 11 reasons why you should NOT miss the Summit this year:

1.     Save money! There are two ways to save on your DFIR Summit & Training registration (offers cannot be combined):

·       Register for a DFIR course by May 7 and get 50% off a Summit seat (discount automatically applied at registration), or

·       Pay by April 19 and save $400 on any 4-day or 6-day course, or up to $200 off of the Summit. Enter code “EarlyBird18” when registering.

2.     Check out our jam-packed DFIR Summit agenda!

·       The two-day Summit will kick off with a keynote presentation by Kim Zetter, an award-winning journalist who has provided the industry with the most in-depth and important investigative reporting on information security topics. Her research on such topical issues as Stuxnet and election security has brought critical technical issues to the public in a way that clearly shows why we must continue to push the security industry forward.

·       The Summit agenda will also include a presentation about the Shadow Brokers, the group that allegedly leaked National Security Agency cyber tools, leading to some of the most significant cybersecurity incidents of 2017. Jake Williams and Matt Suiche, who were among those targeted by the Shadow Brokers, will cover the history of the group and the implications of its actions.

·       All DFIR Summit speakers are industry experts who practice digital forensics, incident response, and threat hunting in their daily jobs. The Summit Advisory Board handpicked these professionals to provide you with highly technical presentations that will give you a brand-new perspective of how the industry is evolving to fight against even the toughest of adversaries. But don’t take our word for it, have a sneak peek, check out some of the past DFIR Summit talks.


Immerse yourself in six days of the best in SANS DFIR training. Here are the courses you can choose from:

·       FOR500 – Advanced Windows Forensics

·       FOR585 – Advanced Smartphone Forensics

·       FOR610 – Reverse-Engineering Malware

·       FOR508 – Digital Forensics, Incident Response & Threat Hunting

·       FOR572 – Advanced Network Forensics: Threat Hunting, Analysis, and Incident Response

·       FOR578 – Cyber Threat Intelligence

·       FOR526 – Memory Forensics In-Depth

·       FOR518 – Mac and iOS Forensic Analysis and Incident Response

·       MGT517 – Managing Security Operations: Detection, Response, and Intelligence

3.    All courses will be taught by SANS’s best DFIR instructors. Stay tuned for more information on the courses we’re offering at the conference in a future article post.

4.     Rub elbows and network with DFIR pros at evening events, including networking gatherings and receptions. On the first night of the Summit, we’re going to gather at one of Austin’s newest entertainment venues, SPiN, a ping pong restaurant and bar featuring 14 ping pong tables, lounges, great food, and drinks. Give your overloaded brain a break after class and join us at our SANS Community Night, Monday, June 9 at Speakeasy. We will have plenty of snacks and drinks to give you the opportunity to network with fellow students.

5.     Staying to take a DFIR course after the two-day Summit? Attend SANS@Night talks guaranteed to enrich your DFIR training experience with us. Want to know about threat detection on the cheap and other topics? As for cheap (and in this case, that doesn’t mean weak), there are actions you can take now to make threat detection more effective without breaking the bank. Attend this SANS@Night talk on Sunday evening to learn some baselines you should be measuring against and how to gain visibility into high-value actionable events that occur on your systems and networks.

6.     Celebrate this year’s Ken Johnson Scholarship Recipient, who will be announced at the Summit. This scholarship was created by the SANS Institute and KPMG LLP in honor of Ken Johnson, who passed away in 2016. Early in Ken’s digital forensics career, he submitted to a Call for Presentations and was accepted to present his findings at the 2012 SANS DFIR Summit. His networking at the Summit led to his job with KPMG.

7.     Prove you’ve mastered the DFIR arts by playing in the DFIR NetWars – Coin Slayer Tournament. Created by popular demand, this tournament will give you the chance to leave Austin with a motherlode of DFIR coinage! To win the new course coins, you must answer all questions correctly from all four levels of one or more of the six DFIR Domains: Windows Forensics & Incident Response, Smartphone Analysis, Mac Forensics, Memory Forensics, Advanced Network Forensics, and Malware Analysis. Take your pick or win them all!


8.     Enjoy updated DFIR NetWars levels with new challenges. See them first at the Summit! But not to worry, you will have the opportunity to train before the tournament. You’ll have access to a lot of updated posters that can serve as cheat sheets to help you conquer the new challenges, as well as the famous SIFT WorkStation that will arm you with the most powerful DFIR open-source tools available. You could also choose to do an hour of crash training on how to use some of our Summit sponsors’ tools prior to the tournament. That should help give you an edge, right? That new DFIR NetWars coin is as good as won!

9. The Forensic 4:cast Awards winners will be announced at the Summit. Help us text2985celebrate the achievements of digital forensic investigators around the world deemed worthy of the award by their peers. There is still time to cast your vote. (You may only submit one set of votes; any additional voting will be discounted). Voting will close at the end of the day on May 25, 2018.

10.  Come see the latest in tools offered by DFIR solution providers. Summit sponsors and exhibitors will showcase everything from managed services covering advanced threat detection, proactive threat hunting, and accredited incident response to tools that deliver rapid threat detection at scale, and reports that provide insights for identifying potential threats before they cause damage.

11.  Last but not least, who doesn’t want to go to Austin?!? When you think Austin, you think BBQ, right? This city isn’t just BBQ, Austin has amazing food everywhere and there’s no place like it when it comes to having a great time. The nightlife and music include the famous 6th Street – which, by the way, is just walking distance from the Summit venue. There are many other landmarks such as Red River, the Warehouse District, Downtown, and the Market District. You will find entertainment of all kinds no matter what you’re up for. Nothing wrong with some well-deserved play after days full of DFIR training, lectures, and networking!

As you can see, this is an event you do not want to miss! The SANS DFIR Summit and Training 2018 will be held at the Hilton Austin. The event features two days of in-depth digital forensics and incident response talks, nine SANS DFIR courses, two nights of DFIR NetWars, evening events, and SANS@Night talks.

The Summit will be held on June 7-8, and the training courses run from June 9-14.

We hope to see you there!

Coin Check: Win the challenge, join the elite list of lethal forensicators & take home a brand new DFIR challenge coin!

forensics_coin (1)Hundreds of SANS Institute digital forensics students have stepped up to the challenge and conquered. They’ve mastered the concepts and skills, beat out their classmates, and proven their prowess. These are the elite, the recipients of the SANS Lethal Forensicator Coin, an award given to a select portion of the thousands of students that have taken any of the SANS Institute Digital Forensics or Incident Response (DFIR) courses. Now, the institute is expanding the opportunity for students to earn these highly coveted tokens in each of the SANS DFIR courses.

Thanks to an effort led by curriculum lead Rob Lee & the SANS DFIR faculty, students can now win specific SANS Lethal Forensicator Coins designed to go with each of the DFIR course themes. These coins are tailored to be icons and the precious prizes to be won by students as a proof and symbol of their mastery in a specific digital forensics specialty.

New DFIR course challenge coins available now:

500FOR500: Windows Forensic Analysis

“Ex Umbra in Solem”: From the Shadows into the Light
In today’s digital world, forensics plays a critical role in uncovering the truth. Forensic examiners shine light on the facts of the case, making good decisions possible. And the forces of evil unceasingly develop new ways to hide their activities, forcing us to continually improve our skills to counter them.

508FOR508: Advanced Digital Forensics, Incident Response & Threat Hunting

“Non Potestis Celare”: You  cannot hide
The most successful incident response teams are evolving rapidly due to near-daily interaction with adversaries. New tools and techniques are being developed, providing better visibility and making the network more defensible. Adversaries can no longer hide.

610FOR610: Reverse-Engineering Malware

“R.E.M”: Reverse-Engineering Master

Today,  attackers are modifying their malware with increasing frequency to bypass antivirus and other endpoint controls. Through reverse-engineering Malware (R.E.M) Analysis Masters can isolate the most appropriate Indicators of Compromise (IOCs) to stop & identify malware.

585FOR585: Advanced Smartphone Forensics

“Omnis Tactus Vestigium Relinquit”:  Every contact leaves a trace
Knowing how to recover all of the data residing on the smartphone is now an expectation in the digital forensics field, and examiners must understand the fundamentals of smartphone handling, data recovery, accessing locked devices, and manually recovering data hiding in the background on the device. There are traces of evidence hiding on the device, and you know how to uncover them.

572FOR572: Advanced Network Forensics Analysis

“Malum Loquitur, Bonum Auscultat”: Evil must talk, so good must listen

Network Forensic professionals are hunters with great visibility, who can find a target among a mass of camouflaging data. Wisdom, experience, and stealth are all embodied by the owl’s watchful, unwavering eye, seeking its prey under the cover of darkness. No matter how crafty an adversary may be, their communications will allow the hunter to find, identify, and ultimately eliminate their presence.

518FOR518: Mac Forensics

“Impera magis. Aliter cogita”: Command more and think differently.

Apple users have always thought differently and that goes for Apple forensicators too. The analysts who hold this coin take command of their forensic analysis and appreciate looking at the raw data and interpreting it correctly without the necessity of superfluous tools. Knowing where you came from can help you move forward, this is where the hat tip to the original colored Apple logo comes in. New artifacts are presented to analysts in every OS update, the knowledge of historic elements may provide insight.

FOR578_coinFOR578: Cyber Threat Intelligence

“Hominem unius libri timeo”: I fear the man of one book.

FOR578 is all about developing analytical skills. To think critically and expand our views which is a skill that applies to any security profession. The quote is attributed to Thomas Aquinas and despite the common use of the phrase (which is meant to deride the person who is not well studied across multiple subjects) the original meaning was to state that a person who understood one good book well could defeat their opponent. Thus, this phrase can be interpreted two entirely different ways. Both are about self-education and broadening our views on the world.

FOR526_coinFOR526: Memory Forensics In-Depth

“Cur mihi oculi dolent?” Why do my eyes hurt?

Memory forensics reveals deeper insights into the state of a compromised system and stands as the best source for detection of malware and OS/process manipulation/subversion. These analysis methods reveal key evidence which may not be uncovered through querying the operating system or digging through network packets. This quote comes from the original Matrix movie, a question Neo asks of Morpheus when he first wakes from his life in the artificial reality created by sentient machines. It is this awakening and raw view of reality that we as forensic examiners/incident responders strive to achieve through deeper analysis of system memory.


Netwars DFIR Netwars

Staying up-to-date with the latest challenges in the digital forensics field demand analytical skills that cannot be gained by just reading a textbook. Just like firemen could never learn the skills of how to fight a fire by just studying theory, incident responders, threat hunters, and digital forensic investigators can test their skills with DFIR Netwars.

New DFIR Challenge coin back design:

BackThe challenges for each course are held on the last day. Students must successfully overcome a number of obstacles, directly compete against fellow students, and prove their proficiency during timed, hands-on incidents. The obstacles, competitions and hands-on scenarios have been created by SANS’ top instructors – digital forensics practitioners, subject matter experts, experienced teachers and professional leaders in their own right. At the end of the challenge, the instructor announces the winner(s) who are awarded the coins at the end of the 6th day of class and winners are later on listed on the SANS Institute’s virtual wall of Lethal Forensicator Coin Holders.


History of the SANS Challenge coins:

The coin – more precisely, Round Metal Object (RMO) – was initially created to recognize students who demonstrate exceptional talent, contributions, or who serve as leaders in the digital forensics profession and community. The coin is meant to be an honor; it is also intended to be rare. SANS Institute uses the coins to identify and honor those who excel at detecting and eradicating threats, understand the critical importance of cybersecurity and continually strive to further not only their knowledge but also the knowledge of the entire digital forensics field. They actively share their experience and encourage learning through participation in the community and are typically leaders in the digital forensics and incident response community.

Those who are awarded the Lethal Forensicator are also bestowed special privileges and recognition, including participation in the so-called and well-regarded “coin check” challenge and response.

“Coin check” Challenge:

Initiated by one coin holder to another, a coin check typically begins by a challenger holding his or her coin in the air or slamming it on a table and yelling “coin check!” All who are challenged must respond by showing their coins to the challenger within 10 seconds, and whoever fails to do so must buy everyone a round of drinks. If all the challenged coin holders do produce their coin, the challenger must by the round of drinks. (By the way, if you accidentally drop your coin and it makes an audible sound on impact, then you’ve “accidentally” initiated a coin check. And, there are no exceptions to the rules!)

Coin checks aside, there are other ways to win the DFIR Challenge coins besides being an exceptional DFIR student and winning the classroom challenges. Each GOLD GCFA, GREM, GCFE member that has written a published white paper that has furthered the field of research in the Digital Forensics field receives a coin, as do SANS Digital Forensics Blog authors who have written six published entries over a one-year span. In addition, speakers and panelists who participate at a SANS Digital Forensic Summit are awarded coins (vendors and vendor-related speakers are not eligible). Finally, any coin holder can nominate an individual in the digital forensics field who has contributed knowledge, tools or service.

For more information on our SANS DFIR courses, please visit our Forensics Courses list. And to read more about the coin and the history of the term “Forensicator,” check out our Community – Lethal Forensicator Coin page.

Using ProcDOT Plugins to Examine PCAP Files When Analyzing Malware

ProcDOT is a free tool for  analyzing the actions taken by malware when  infecting a laboratory system. ProcDOT  supports plugins, which could extend the tool’s built-in capabilities.  This article looks at  two plugins that help examine contents of the  network capture file loaded into ProcDOT.  If you’re not already familiar with ProcDOT,  review its documentation before proceeding.

As of this writing, the tool comes with the Servers List plugin. In addition, you can install the Extract Files Form PCAP plugin, mentioned below, from its Github repository.  If you’re using the REMnux distribution, you will find ProcDOT and these plugins already installed and configured (run the “update-remnux” command to get the latest versions).

The directory structure of ProcDOT files includes the “plugins” subdirectory. This is where you should  copy the files that implement the plugins. Once the plugins have been installed, they will be visible in the Plugins menu of ProcDOT.  However, you won’t be able to actually use the plugins until after you’ve loaded the data files that you want to analyze.


The Servers List plugin, written by ProcDOT’s author Christian Wojner,  generates a listing of hostnames and IP addresses from the loaded PCAP file, as shown below. It’s not an earth-shattering feature, but this can be handy if the network capture includes a lot of systems.


The plugin Extract Files Form PCAP  was  created by  Brian Maloney. It allows you to extract files transferred during the network session that was captured in the PCAP file. After asking you to specify the output directory, this plugin saves the carved files there.


Though standalone PCAP carving and mining tools exist, it’s convenient to perform    such tasks within ProcDOT if you’re already using the tool for examining other aspects of the infected system in your  malware analysis lab.

—  Lenny Zeltser

Lenny Zeltser teaches  malware analysis at SANS Institute and focuses on safeguarding customers’ IT operations at NCR Corp. He  is active on Twitter  and writes a security blog.

Threat Hunting and Incident Response Summit – CFP – Closing 12 Oct


dfir (1)

The inaugural Threat Hunting and Incident Response Summit will be held in New Orleans, LA on April 12- 13, 2016.

The Threat Hunting & Incident Response Summit 2016 focuses on specific hunting and incident response techniques and capabilities that can be used to identify, contain, and eliminate adversaries targeting your networks. Attend this summit to learn these skills directly from incident response and detection experts who are uncovering and stopping the most recent, sophisticated, and dangerous attacks against organizations.

Call for Speakers Now Open

The Call for Speakers is now open. If you are interested in delivering a presentations or participating in a panel, we’d be delighted to consider your practitioner-based case studies with communicable lessons.  We have had many service and tool vendors submit talks which is great, but we are especially interested in organizations or businesses doing threat hunting internally to give a talk at this event.

The THIR Summit offers speakers the opportunity for exposure and recognition as industry leaders. If you have something substantive, challenging, and original to offer, you are encouraged to submit a proposal.

Topics of interest include, but are not limited to:

  • Adversary hunting
  • Threat containment
  • Effective remediation and threat elimination planning
  • Proactive digital forensics
  • Enterprise network and host monitoring
  • Threat intelligence utilization and usefulness
  • Incident response team operations and management

Proposed presentations should be relevant to: Incident Response Team Members, Security Operations Center Personnel and Information Security Practitioners, Digital Forensic Analysts, System Administrators, Federal Agents and Law Enforcement Officials

Benefits of Speaking

  • Promotion of your speaking session and company recognition via the THIR Summit website and all printed materials
  • Full conference badge to attend all Summit sessions
  • Speakers can bring 1 additional attendee for free to attend the summit
  • Private speakers-only networking lunches
  • *Presentations may also be recorded and made available via the Internet to a wider audience (at the discretion of SANS).

Submission Requirements

  • Title of Proposed Talk
  • Abstract: The presentation abstract should outline your presentation and what attendees will All content must be strictly educational. The presentation should be relevant to: Incident Response Team Members, Security Operations Center Personnel and Information Security Practitioners, Digital Forensic Analysts, System Administrators, Federal Agents and Law Enforcement Officials
  • Author Name(s)
  • Author Title
  • Company
  • Speaker Contact Information: Address, phone number, email address
  • Biography

o  Your biography should be approximately 150 words. You may include your current position, titles, areas of professional expertise, experience, awards, degrees, personal information, etc.

  • Twitter Handle:
  • Google+:
  • Facebook:
  • Blog:
  • YouTube videos featuring you speaking:

Session/panel length: 35-40 minutes Question & Answer: 5-10 minutes

Submit your submissions to by 5 pm Central time on Monday, October 12th, 2015 with the subject “SANS THIR Summit CFP 2016.”

Timeline analysis with Apache Spark and Python

This blog post introduces a technique for timeline analysis that mixes a bit of data science and domain-specific knowledge (file-systems, DFIR).

Analyzing CSV formatted timelines by loading them with Excel or any other spreadsheet application can be inefficient, even impossible at times. It all depends on the size of the timelines and how many different timelines or systems we are analyzing.

Looking at timelines that are gigabytes in size or trying to correlate data between 10 different system’s timelines does not scale well with traditional tools.

One way to approach this problem is to leverage some of the open source data analysis tools that are available today. Apache Spark is a fast and general engine for big data processing. PySpark is its Python API, which in combination with Matplotlib, Pandas and NumPY, will allow you to drill down and analyze large amounts of data using SQL-syntax statements. This can come in handy for things like filtering, combining timelines and visualizing some useful statistics.

These tools can be easily installed on your SANS DFIR Workstation, although if you plan on analyzing a few TBs of data i would recommend setting up a Spark cluster separately.

The reader is assumed to have a basic understanding of Python programming.

Quick intro to Spark

This section is a quick introduction to PySpark and basic Spark concepts. For further details please check the Spark documentation, it is well written and fairly up to date. This section of the blog post does not intend to be a Spark tutorial, I’ll barely scratch the surface of what’s possible with Spark.

From Apache Spark is a fast and general-purpose cluster computing system. It provides high-level APIs in Java, Scala, Python and R, and an optimized engine that supports general execution graphs. It also supports a rich set of higher-level tools including Spark SQL for SQL and structured data processing, MLlib for machine learning, GraphX for graph processing, and Spark Streaming.

Spark’s documentation site covers the basics and can get you up and running with minimal effort. Best way to get started is to spin up an Amazon EMR cluster, although that’s not free. You can always spin up a few VMs in your basement lab :)

In the context of this DFIR exercise, we’ll leverage Spark SQL and  Spark’s DataFrame API. The DataFrame API is similar Python’s Pandas. Essentially, it allows you to access any kind of data in a structured, columnar format. This is easy to do when you are handling CSV files.

Folks over at Databricks have been kind enough to publish a Spark package that can convert CSV files (with headers) into Spark DataFrames with one simple Python line of code. Isn’t that nice? Although, if you are brave enough, you can do this yourself with Spark and some RDD transformations.

To summarize, you’ll need the following apps/libraries on your DFIR workstation:

  • Access to a Spark (1.3+) cluster
  • Spark-CSV package from Databricks
  • Python 2.6+
  • Pandas
  • NumPy

It should be noted that the Spark-CSV package needs to be built from source (Scala) and for that there are a few other requirements that are out of the scope of this blog post, as is setting up a Spark cluster.

Analysis (IPython notebook)

Now, let’s get on with the fun stuff!

The following is an example of how these tools can be used to analyze a Windows 7 system’s timeline generated with log2timeline.

You can find the IPython Notebook over on one of my github repos

How to Install SIFT Workstation and REMnux on the Same Forensics System

Having the  right  tools at your fingertips can save hours and even days when examining digital evidence or analyzing malicious artifacts. You can now  install two  popular Linux  distros, SIFT Workstation and REMnux, on the same system to create a powerful  toolkit for digital forensics and incident response. To quote @ma77bennett,  this combo  is reminiscent of “Transformers combining together to form a super robot.”

You can start with SIFT and then add REMnux, or begin  with REMnux and add SIFT to it.  If you prefer the look and feel of SIFT Workstation, use SIFT as the starting point. If you like the look of REMnux, start with that one.

Option 1: Add REMnux to SIFT Workstation

If you wish to start with SIFT Workstation, make sure you have the latest version of SIFT running on Ubuntu 14.04 64-bit. Follow instructions to download SIFT as a pre-built virtual appliance or use the SIFT bootstrap script to install it.

After booting into SIFT Workstation and making sure that it has Internet access, run the following command to install REMnux on it:

wget --quiet -O - | sudo bash

You’ll need to enter the SIFT user’s password when promoted. By default, the password  on the SIFT Workstation’s virtual appliance is “forensics”.


The REMnux installer will run for a while, depending on the speed of your Internet connection and the strength of your system. Once it completes,  reboot the system.  In this configuration, REMnux will not replace the SIFT skin, and your system will look like a standard SIFT Workstation with the exception of a few REMnux documentation shortcuts that the installer will add to the desktop.

Option 2: Add SIFT Workstation to REMnux

If you wish to start with a REMnux system,  make sure you have REMnux installed according to its installation instructions  to get a REMnux virtual appliance or use the REMnux installer script to bootstrap its installation.

Note that the REMnux virtual appliance is configured to use little RAM by default; if planning to install SIFT into the same virtual machine, increase the RAM to at least 4GB. Also, if using the  REMnux installation machine to install REMnux on a compatible system of your own, be sure to allocate  enough RAM and disk space to accommodate your SIFT plans.

After booting into REMnux  and making sure that it has Internet access, run the following command to install SIFT  on it:

wget --quiet -O - | sudo bash -s -- -i -s -y

The SIFT installation script will run for a while, depending on the speed of your Internet connection and the strength of your system. Once  it completes, reboot the system.


In this configuration, SIFT will not replace the REMnux branding   and your system will look like a standard REMnux system, with the exception of a few SIFT documentation shortcuts that the installer will add to the desktop.


Updating the SIFT+REMnux System

To keep your system up to date with the upgraded and newly-added software,  periodically run the following update scripts for SIFT and REMnux,  preferably in the order in which you’ve installed the two distros, such as:


There you have it, two powerful forensics-focused distros combined in one super-toolkit. Be sure to read  REMnux and SIFT  documentation sites for each distribution  to learn how to use the powerful utilities now available at your fingertips.

—  Lenny Zeltser

Lenny Zeltser teaches  malware analysis at SANS Institute and focuses on safeguarding customers’ IT operations at NCR Corp. He  is active on Twitter  and writes a security blog.

How Miscreants Hide From Browser Forensics

Scammers, intruders and other miscreants often aim to conceal their actions from forensic investigators.  When analyzing  an IT support scam, I interacted with the person posing as the help desk technician. He  brought up a web page on my lab system to present  payment  form, so I’d supply my contact and credit card details. He did this  in a surprising manner, designed to conceal  the destination URL.

You can see the scammer  bringing up the web page by watching this 17-second video of his actions.  Rather than bringing up the web browser, the person  launched  the HTML Help application, which is built into Windows, by typing:

hh h

According to Microsoft, HTML help is “the standard help system for the Windows platform. Authors can use HTML Help to create online help for a software application or to create content for a multimedia title or Web site.” To bring up the interface captured in the above video, it’s sufficient to launch the application using the “hh” command and supply any string as a parameter.

Why would the miscreant launch this application? The goal is to use the “Jump to URL…” feature, which is available by clicking in the top left corner of the application:

HTML Help: Jump to URL


The  “tech support” rep then pasted the desired URL from the clipboard into the Windows that popped up. Since the input field of the Window was relatively small, I (posing as the victim) could not see the full URL.

The web page rendered within the HTML Help window, the way it would show up within a browser, though  there was no URL bar to display the address of the page:

ClickBank Payment Form

Examining the system after this incident, I could not find a reference to the ClickBank URL in the Internet Explorer history. I used  ESEDatabaseView  to examine the system’s  WebCache file; the tool found a cookie set by ClickBank, but showed no relevant URLs.  I also used Redline to pull out browser artifacts from this system using memory forensics; this tool showed some URLs belonging to the domain, but not the address of the initial web page:

Redline Clickbank URLs

I was able to locate the URL by extracting all strings from the system’s memory image that included “clickbank” in them. The same URL was also left by the adversary on the system’s clipboard.

Based on this analysis, it appears the adversary used an unusual method of visiting the website from the victim’s system to conceal the URL from the person’s view and to make it hard  for  an  investigator to locate the URL in the browser history. This is the first time I’ve seen such an approach, and wanted to share it with the community. If you’ve encountered  similar techniques or would like to share your perspective on this situation, please leave a comment.

To learn more about this incident, take a look at  my  Conversation With a Tech Support Scammer article.

—  Lenny Zeltser

Lenny Zeltser teaches  malware analysis at SANS Institute and focuses on safeguarding customers’ IT operations at NCR Corp. He  is active on Twitter  and writes a security blog.

Running Malware Analysis Apps as Docker Containers

A new REMnux project initiative provides Docker images of Linux applications useful for malware analysis, with the goal of making it easier for investigators start using malware forensics tools that otherwise might be awkward to set up.  Docker is a platform for packaging, running and managing applications as “containers,” offering a lightweight alternative to full-fledged virtualization. The following application images are available as of this writing, as a starting point for the effort:

  • V8 JavaScript engine for JavaScript deobfuscation: remnux/v8
  • Thug low-interaction honeyclient: remnux/thug
  • Viper binary analysis and management framework: remnux/viper
  • Rekall memory forensic framework: remnux/rekall
  • JSDetox JavaScript analysis tool for deobfuscation: remnux/jsdetox
  • Radare2 reverse-engineering framework: remnux/radare2

Docker takes advantage of a Linux kernel’s ability to run applications in containers, which are sometimes described as “chroot on steroids.” This approach provides each app an independent runtime environment, while avoiding the overhead of a full virtual machine.  An application distributed as a Docker image incorporates all the dependencies and configuration necessary for it to run, eliminating the need for end-users to install packages and troubleshoot dependencies

To run an application distributed as a Docker image, first you need to install Docker. After that, you can use the “docker run” command to launch the desired application. Docker will automatically find the app in its public registry and download it if you don’t already have it cached locally. There are some nuances to launching such apps to ensure that you can share files and network connections with the container; if you’re new to Docker, the best way to get started is to read the article on  Running REMnux-Provided Images.

If you’ve been looking for an excuse to experiment with Docker, here’s your chance. You can not only run the malware analysis apps that have already been Dockerized, you can also build your images of your favorite applications and suggest them for inclusion in the REMnux project. For more details on how to contribute, see  Creating Docker Images for REMnux.

Note that when running malware analysis applications in containers, I am not placing a lot of trust in the isolation that Docker implements for the apps. Instead, I am using Docker primarily as a tool for conveniently packaging, distributing and running tools that otherwise might be difficult or awkward to set up. To better understand information security implications of this technology in a production environment, see  Security Risks and Benefits of Docker Application Containers.

To learn more about this topic, tune into the webcast  How to Run Linux Malware Analysis Apps as Docker Containers.

—  Lenny Zeltser

Lenny Zeltser teaches  malware analysis at SANS Institute and focuses on safeguarding customers’ IT operations at NCR Corp. He  is active on Twitter  and writes a security blog.

Kerberos in the Crosshairs: Golden Tickets, Silver Tickets, MITM, and More

It’s been a rough year for Microsoft’s Kerberos implementation.  The culmination was last week when Microsoft announced critical vulnerability MS14-068.  In short, this vulnerability allows any authenticated user to elevate their privileges to domain admin rights.  The issues discussed in this article are not directly related this bug.  Instead we’ll focus on design and implementation weaknesses that can be exploited under certain conditions.  MS14-068 is an outright bug which should be patched immediately.  If you haven’t patched it yet, I suggest you skip this article for now and work that issue right away.  Then come back later for some more Kerberos fun!

Our red-team friends have been quite busy recently dissecting Kerberos and have uncovered some pretty concerning issues along the way.  Issues, or attacks, such as the “Golden Ticket”, the “Silver Ticket”, man-in-the-middle (MITM) password cracking, and user passwords being reset without user knowledge have all been discovered, disclosed, or advanced over the past few months.  These techniques can allow for credential theft, privilege escalation, and impersonation—goals in just about any advanced attack.  As incident responders, these are issues we should definitely understand in order to “Know thy enemy”.  So let’s get to it.  We’ll start with a discussion of the Kerberos architecture and see how the placement of a compromised host impacts the security of the design.

Kerberos Architecture

In my previous article on network authentication, I presented the following diagram to show how Kerberos addresses the man-in-the-middle design weakness we face with NTLM:

This architecture addresses the man-in-the-middle issue for our privileged accounts that are connecting to compromised hosts.  It allows the user authentication to take place between the trusted client and the DC.  The DC then provides a non-forwardable, target-specific “ticket” to use for connecting to the remote compromised host.  That works great for our IR account scenario, as well as many other scenarios where privileged accounts are reaching out to untrusted hosts.

However, several Kerberos weaknesses come to light when the situation gets flipped around.  If we make the compromised host the client, rather than the target, then we see several issues arise. Here’s that same diagram with the scenario flipped, along with a fuller description of the Kerberos steps and a summary of the issues/attacks raised recently:



Seeing all these issues in one diagram looks pretty ominous.  Fortunately these issues are not deal-breakers for Kerberos, but they should get your attention and hopefully are getting Microsoft’s attention as well.

I’m going to describe each of these issues while stepping through the Kerberos authentication process.   I’ll then provide a few thoughts on mitigations.  First though, let’s start with a high level description of Kerberos.

Kerberos Overview

Microsoft’s implementation of Kerberos allows users (UPN: user principal names) to authenticate to services (SPN: service principal names)—such as CIFS, Terminal Services, LDAP, WS-Management, and even the local host itself (the local host is treated as a service when you perform an interactive logon with a domain account).

Authentication is first done between the user and a trusted 3rd-party called the Key Distribution Center (KDC), which is the domain controller in Microsoft domains.  This initial authentication is done via the user’s long-term key, which is derived from the user’s password in most environments.

When users are ready to authenticate to services, they request a new service ticket from the KDC.  That service ticket is unique to the target service and it includes identity information about the user, such as group membership, inside a structure called the Privilege Attribute Certificate (PAC).  The new service ticket and a new set of temporary encryption keys, called session keys, are passed to the client and then to the service.  The client and the service use the session keys to authenticate each other, as well as encrypt data between them as necessary.  Once the target service receives the service ticket, it will read the included identity information about the user and make a decision as to whether the user is authorized to use the service as requested.

That’s Kerberos in a nutshell.  Of course there are plenty of additional details, some of which we’ll get into shortly.  However, my goal is to strike a balance between providing enough information to fully describe the problems, yet not overwhelm you with unnecessary details.  For example, short-lived session keys are very important to the inner workings of Kerberos, but since they are not directly pertinent to the problems being discussed, I’m going to mostly avoid mentioning them here.  If you find yourself needing more details though, two general resources I recommend are Microsoft’s article “How the Kerberos Version 5 Authentication Protocol Works” and Mark Minasi’s recorded TechEd presentation, “Cracking Open Kerberos: Understanding How Active Directory Knows Who You Are”.

Microsoft Kerberos Step-by-Step

Now that we’ve covered the basics, let’s dig deeper and look at each step of a typical Microsoft Kerberos transaction.  Along the way, we’ll also discuss the weaknesses that provide avenues for attack.


Step 1–Authentication Service Request (AS-REQ):  The user initially authenticates to the KDC’s authentication service (AS) for a special service ticket called a ticket-granting ticket (TGT).  This most commonly occurs when the user initiates an interactive logon, though it can happen in other situations too.  This initial request encrypts the current UTC timestamp of the format YYYYMMDDHHMMSSZ with a long-term key.  In password-based environments, the long-term key is derived from the user’s password.

Multiple encryption types are normally available.  The client should choose the strongest mutually-supported encryption type, but of course an attacker can produce a downgrade attack to choose weaker encryption.  Here’s a brief summary of possible encryption types:

  • DES-CBC-CRC (disabled by default in Vista/2008)
  • DES-CBC-MD5 (disabled by default in Vista/2008)
  • RC4-HMAC (XP & 2003 default, as well as the strongest encryption they support)
  • AES128-CTS-HMAC-SHA1-96 (introduced with Vista/2008)
  • AES256-CTS-HMAC-SHA1-96 (default in Vista/2008 and higher)

When a user logs in, Windows will create a long-term key for each encryption method supported by the client OS.  Let’s take a look at the long-term keys for user ‘mike’ on a Windows 7 host that supports both the newer AES and older RC4 algorithms:



In last week’s article, we calculated user mike’s NT hash, which is simply the MD4 hash of the user’s Unicode password.  Here it is again—and notice that the hash value is the same as the RC4 long-term key:

$ echo -n Use4Passphrase,K? | iconv -t UTF-16LE | openssl md4
(stdin)= e456d67ce26e0f174ba2c92f4b677cac

As you can see, Microsoft uses the NT (NTLM) hash for Kerberos RC4 encryption.  Crazy, huh?  Why is this the case?  Apparently it was to support a more seamless upgrade from NT4 (NTLM/LM only) to Windows 2000 (the first version to support Kerberos).


The fact that an NT hash can be used to create Kerberos tickets leads to the ability to do something Benjamin Delpy, the creator of mimikatz, has termed “overpass-the-hash”.  The idea being, you can do more in Kerberos with the NT hash than you can from a standard pass-the-hash attack that utilizes NTLM.  The ability to use the NT hash to create Kerberos tickets opens up a few additional possibilities that can only be done via Kerberos, such as changing a user’s password and joining a machine to a domain.  In fact, the ability to change a password without the user’s knowledge using the NT hash caused a stir this summer following this disclosure by Aorato.  Once an attacker has changed the password, they have at least a small window of opportunity to use services like Remote Desktop and Outlook Web Access that require the password.


Step 2–Authentication Service Response (AS-REP):  Assuming the client encrypted the timestamp correctly in Step 1, and the time is within the accepted skew (5 minutes by default), then the user will have passed authentication.  The KDC then constructs a special service ticket, called the ticket-granting ticket (TGT), to be used when requesting other service tickets from the KDC’s Ticket-Granting Service (TGS).  Like all service tickets, the TGT includes identity information about the user, including username and group memberships.

Also like all service tickets, the TGT is encrypted with the target service’s long-term key.  By encrypting service tickets with the destination service’s long-term key, this protects the information in the ticket from being read or modified since only the KDC and target service know the long-term key.  In the case of the special TGT service ticket, the target service account is the built-in ‘krbtgt’ account.

An interesting feature of Kerberos is that authentication is effectively stateless.  In subsequent communications with the user, the KDC only knows that it previously authenticated this user because the TGT that the client will send in Step 3 has been encrypted with its ‘krbtgt’ account.  Once the KDC receives that encrypted TGT again, it trusts that the user must have previously authenticated and that all the included user and group information in the encrypted ticket is accurate.  This is by design so that any DC in the domain can process subsequent requests without the need to synchronize authentications across all DCs.  To a certain extent, it also does not have to spend additional cycles to look up the account information again as long as the ticket is valid (10 hours by default).  There is a caveat to this though.  Since it would be dangerous to assume for 10 hours that a user has not been deleted, disabled, or modified, the KDC will re-verify the account information if the TGT is more than 20 minutes old.

Let’s take a look at the user’s identity information embedded inside an encrypted ticket.  The following screenshot is from a Powershell Remoting (WS-MAN) session that was captured and parsed with Wireshark:


What’s being parsed here is the Privilege Attribute Certificate (PAC) information.  This has all the necessary information that allows the target service to determine if the user has the proper privileges to perform the requested action.  In this example, user ‘mike’ is just a member of Domain Users, well-known group RID 513.

It’s worth noting again that the information in the ticket, including this PAC data, was created by the KDC and encrypted with the target service’s long-term key—a key that only the KDC and the target service account know.  In order to parse these details in Wireshark, it’s necessary to provide Wireshark with the target accounts long-term Kerberos key, as shown here:


In case anyone wants to try this, what worked for me was using the Linux version of Wireshark (I could not get the PAC to parse in Windows Wireshark) and create the necessary keytab file with the Linux tool ktutil.  More details on parsing Kerberos encrypted data can be found on Wireshark’s Kerberos page and this SAMBA presentation by Ronnie Sahlberg.  (Thanks to Tim Medin for some guidance here!)


Step 3–Ticket-Granting Service Request (TGS-REQ):  Now the client would like access to a service and it needs a new service ticket to do so. The client double-checks that its TGT is still valid (not expired) and if so, it sends a request to the ticket-granting service on the KDC.  The request includes the user’s TGT and the specific service principal name that it would like to access.  Assuming the TGT is properly encrypted with the ‘krbtgt’ account’s long-term key, and the TGT is less than 20 minutes old as previously mentioned, then the KDC’s ticket-granting service will assume this is an authentic request for an authentic user whose identity details are specified in the PAC inside the ticket.  It will then continue to Step 4 to create the service ticket.

Golden Tickets

Now consider this:  What if an attacker has the long-term key for the ‘krbtgt’ account?  Well, in that case the attacker can create a TGT, put anything they want in it, and pass it to the KDC.  If it’s less than 20 minutes old, then the TGT is treated as fact—the KDC believes it describes an authenticated user with the attributes described in the PAC details.  This describes the “Golden Ticket” attack.  It’s a ticket created by an attacker with the ‘krbtgt’ key that can give any user any rights (via group membership).  In fact, it doesn’t even have to be a real user.  It can be a fictitious username with domain admin membership, or any other membership the attacker chooses to give it.  As long as the ‘krbtgt’ key is valid and the crafted TGT is less than 20 minutes old (and if it’s not, the attacker can simply create a new one), then the KDC will issue a service tickets for that user with the specified group membership.  Here’s an example of creating a Golden Ticket for non-existent user ‘bevo’ with domain admin membership via well-known group RID 512:


Assuming I supplied a valid key for the ‘krbtgt’ account, I can get a service ticket to connect to any service in the domain as a domain admin.  Furthermore, the fictitious user named ‘bevo’ is the name that would show up in the remote event logs!

The thing that makes this attack particularly devastating is that the password, and resulting keys, for the ‘krbtgt’ account almost never change.  In fact, research has shown that there is “only one circumstance where this password automatically changes.  The password for the KRBTGT account only changes when the domain functional level is upgraded from a NT5 version (2000/2003) to a NT6 version (2008/2012).  If you move from 2008 -> 2012R2 domain functional level, this hash won’t change.”

This opens up a can of worms for organizations that have previously had their domain compromised and credentials dumped from a domain controller.  Or perhaps had the Active Directory data get out of their control via an old backup, or DC VM archive, or even an attack they are unaware of.

The takeaway is that if you are responding to a potential domain compromise and see unusual activity, perhaps even from non-existent users, then the Golden Ticket could possibly be in play.  Furthermore, if you’re in a situation where you need to reset the ‘krbtgt’ account for recovery, be sure to change it twice, as described here and here.   Probably the better course of action is to leave the old domain for dead and move to a new pristine domain/forest, but unfortunately that’s not always feasible.


Step 4–Ticket-Granting Service Response (TGS-REP):  Once the TGS examines and verifies the TGT, it creates the requested service ticket. The client’s identity from the TGT is copied into a PAC in the new service ticket.  Then the new service ticket is sent to the client, who will then pass it on to the target service.

The new service ticket is encrypted with the target service account’s long-term key and the embedded PAC is signed by the ‘krbtgt’ account for verification in optional Step 6.  In most cases, the target service account is the computer account for the remote service.  This is true for common services such as CIFS, RPC, Scheduler, WS-MAN, and many more.  However, the target service account could be a dedicated domain user account used to run the service.

It’s interesting to note that the KDC cannot determine if the user will be able to get access to the target service.  It simply returns a valid ticket.  Authentication does not imply authorization.  Authorization is determined by the target service based on the user and group information in the PAC.


There is no obstacle to requesting service tickets other than having a valid TGT.  A user can request service tickets to any service in the domain.  Again, the KDC doesn’t know if the user is authorized for the service—that’s up to the service to decide—so it happily issues tickets for any valid request it receives.  For a large domain, there could be thousands, perhaps even millions of services, as each host typically has a few SPNs.  Check for yourself with the command “setspn –l <account-name>”.  The <account name> should be either a computer name or dedicated user account for hosting services.

Why would this be of interest?  Since the service ticket is encrypted with the service account’s long-term key, an attacker can gather service tickets and attempt a brute-force attack on the long-term key that was used to encrypt the ticket.  If the key can be derived, then there’s potential to elevate privileges via the “Silver Ticket” attack (more on Silver Tickets in Step 5).  The attacker could also take the cracked key and connect to other hosts on the network if the service account has sufficient rights.

By the way, when discussing Kerberos cracking via MITM, I use the terms password and key almost interchangeable.  This is because the most efficient way to crack the key that created the Kerberos ticket is to start with a dictionary attack against the password that created the Kerberos encryption key.  So yes, the MITM attack is cracking the key, but it typically involves first guessing the password that created that key.

For most service accounts, brute-force cracking the password and resulting key is very difficult because they belong to the built-in computer account.  The password for computer accounts is very complex and highly unlikely to be cracked, regardless of RC4 or AES encryption.  However for some services, the service does not use the built-in computer account to run the service, but instead uses a dedicated domain user account.  Tim Medin has done a lot of research in this area and has found that MS-SQL services are particularly vulnerable to attack because they are typically configured with a domain account rather than a computer account.  Furthermore, many blogs suggest that the quick way to get the job done is to give the MS-SQL service account domain admin rights.  Yikes!

Whether given domain admin rights or not, what is the chance that this dedicated MS-SQL account, or any other domain service account, was given a strong password?  Probably a good chance in some environments and a poor chance in others.  If the password is poor, then the password and resulting Kerberos key can be cracked–period.  It can be cracked faster if the encryption type is RC4 rather than AES since the Kerberos AES function requires much more computational efffort to generate a guess than RC4.  Therefore, along with the “overpass-the-hash” issue described in Step 1, MITM vulnerabilities provide another incentive to decommission RC4 encryption in favor of AES.

Definitely check out the work by Tim Medin on this issue.  He did a great presentation at DerbyCon where he goes through this in great detail.  He also debuts his toolset called Kerberoast, which among other things, provides a tool to crack the Kerberos TGS-REP responses.  He also shows how the discovered password/long-term key can be used to create a Silver Ticket, which I’ll describe in the next step.


Step 5–Application Server Request (AP-REQ):  Once the user receives the service ticket, it’s ready to forward on to the target service. The service will decrypt the ticket with the service account’s long-term key.  After it decrypts the ticket, it will check the user’s information within the PAC.  Based on the account information, the service decides whether or not to authorize the user to perform the requested action.

At this point, the service could proceed to optional Step 6 to validate the PAC information with the KDC.  Only the KDC can validate the PAC because the validation occurs via a signature with the ‘krbtgt’ account.  Ideally this validation would happen to verify that user information is accurate, but it rarely does due to the performance impact.  The validation exceptions are discussed in a number of places, such as the Technet article “Understanding Microsoft Kerberos PAC Validation” and the previously mentioned 20-minute rule article.  In a nutshell, as Tim put it in his DerbyCon presentation, “Basically, if it runs as a service, it will not verify”.  My own testing backs this up.  I’ve yet to find a way to get services that “Act as part of the operating system” (of which most do) to validate, even with the ValidateKdcPacSignature value is set to 1 in the registry as described in the above Technet article.

Silver Tickets

So is it problem if the service doesn’t verify the PAC information?  Yes, it is a problem if the service account’s long-term key can be discovered (for example, via the MITM attack discussed with Step 4).  If an attacker discovers the long-term key, a service ticket can be crafted that the service will decrypt and trust as long as it doesn’t verify the PAC with the KDC.  What if an attacker creates a service ticket that says the connecting client is a member of the domain admins group?  If the ticket is encrypted with the service’s long-term key, and the service doesn’t verify the PAC data, then it assumes it to be true and will grant access to the connecting user as though they were a domain admin.  This is the “Silver Ticket”.

Why doesn’t Microsoft always verify?  For performance reasons.  From the Technet article referenced above, “Performing PAC validation implies a cost in terms of response time and bandwidth usage. It requires bandwidth usage to transmit requests and responses between an application server and the DC. This may cause some performance issues in high volume application servers (KB906736). In such environments, user authentication may induce additional network delay and traffic for carrying PAC validation messages between the server and the DC.”


Step 6—Verify Service Ticket PAC (Optional) (VERIFY-PAC):  As just discussed, the service has the option to send the PAC information to the KDC to verify the ‘krbtgt’ account’s signature.  This ensures the KDC created the service ticket.  This can be enforced, but it rarely is for performance reasons.


Step 7–Application Server Response (Optional) (AP-REP):  Optionally, the user might have requested in Step 5 that the target service verify its identity for mutual authentication. If so, the service encrypts a timestamp with the session key that only the user and service should know and sends it back to the user for verification.


I’m going to mention just a few things here, and also refer you to a great resource with many more suggestions for hardening your Windows environment.  The paper “Mitigating Service Account Credential Theft on Windows” by HD Moore, Joe Bialek, and Ashwath Murthy provides a very good discussion of the problems we face with privileged accounts, along with a significant list of recommendations beginning on page 8 of the 13 page paper.

Of the Kerberos issues discussed here, the Golden Ticket issue is the most concerning.  Of course it’s concerning if you know your domain controller was compromised and AD credentials were dumped.  Unless the ‘krbtgt’ account was reset twice, then consider that domain to still be compromised.  Furthermore, it’s also concerning if you don’t know if your domain controller was compromised.  What if there are indications of compromise, but no solid proof?  What if there aren’t even any indications?  Does that mean it hasn’t happened and that it’s okay to keep this almighty ‘krbtgt’ password unchanged for years and years?  That goes against one of our primary security principles—the idea that we should refresh passwords regularly in order to avoid exposure from stolen credentials.  I hope Microsoft addresses this by forcing a password rotation scheme for the ‘krbtgt’ account.  In theory it should not be a problem.  The reason you have to change this account’s password twice to invalidate the current password is because there is a built-in fault tolerance to allow for the previous password to still work.  So it should be possible to frequently rotate in new passwords/keys.  At least that way a compromise (known or unknown) does not last effectively for years.

Regarding the Silver Ticket issue, always enforcing PAC validation doesn’t currently appear to be a feasible solution.  Therefore, the best bet here is to do something you’d want to do anyway—enforce very strong passwords for your service accounts to mitigate the MITM attack.  Probably the best ways to do that is to use Microsoft’s Managed Service Account feature, which among other things rotates strong passwords every 30 days for designated service accounts.

Lastly, to help address both the MITM and “overpass-the-hash” issue, disable the older RC4 encryption method if possible.  This makes brute-force MITM attacks more time consuming and prevents the NT hash from being used to create Kerberos tickets.  From a Windows perspective, this can be done via Group Policy after all XP and 2003 systems have been decommissioned.


Mike Pilkington is a Sr. Information Security Consultant and Incident Responder for a Fortune 500 company in Houston, TX, as well as a SANS instructor teaching  FOR408  and  FOR508.  Find Mike on Twitter @mikepilkington.

Protecting Privileged Domain Accounts: Restricted Admin and Protected Users

It’s been a while since I’ve written about this topic, and in that time, there have been some useful security updates provided by Microsoft, as well as some troubling developments with Microsoft’s Kerberos implementation.  In order to fully cover these topics, I’m going to split the discussion into two articles.  This article will cover specific updates Microsoft has provided to help protect user credentials.  I’ll follow up next week to discuss the Kerberos issues in depth.

As a quick reminder, the major takeaway from my previous articles on this subject are that we can successfully protect our privileged domain accounts by taking these 3 steps:

  1. Avoid interactive logons to untrusted hosts
  2. Disable delegation for privileged accounts
  3. Enforce Kerberos network authentication

Let’s take a look at the changes in the newest Microsoft operating systems, as well as recent patches for older operating systems, that have helped with each of these 3 areas.

Avoiding Interactive Logons

Of the 3 steps we should take to protect our privileged domain accounts, avoiding interactive logons is the most important because traditional interactive logons store the keys to a user’s kingdom—including  password hashes, Kerberos keys and tickets, and even the password itself.  I used the word “traditional” because we now have a new type of interactive logon that mitigates this credential exposure, called Restricted Admin Remote Desktop.  More on that in a moment.

The previous password hashes article in this series includes a detailed look at what constitutes an interactive logon, but to quickly summarize, it includes the following:  local desktop logons at the console, remote desktop logons via RDP/VNC/Citrix and the like, and even RunAs logons.  Although less common, an interactive logon can also be generated programmatically with tools such as PsExec when the “-u” option is invoked.

So rather than logging on interactively, exposing all of those credentials, you should instead connect with network logons remotely using tools such as PowerShell Remoting, WMI/WMIC, as well as most SMB/CIFS connections such as mapping drives, using Computer Management, etc.

That said, a feature in Windows 8.1 and Server 2012R2 provides a modified version of an interactive logon which has the same beneficial effect of a network logon—it does not store the user’s credentials on the remote system.

Here’s a look at the description of this feature from the new Remote Desktop client’s help dialog box (run “mstsc /?” from a command prompt):


Normal RDP vs. Restricted Admin RDP

Let’s take a look at the differences between a normal Remote Desktop logon and the new Restricted Admin Remote Desktop logon.

First we’ll look at a regular RDP logon session for user ‘mike’ to a Windows 8.1 host.  The following screenshot shows event ID 4624 as a result of a normal RDP session.  Logon Type 10 indicates a Remote Desktop interactive logon.  For a list of logon types, see the Ultimate Windows Security description of Event ID 4624.


Next, let’s assess the available credentials for ‘mike’ with this normal RDP logon.  I’ve used mimikatz to dump the hashes and passwords from memory.  At this point it’s worth noting that not only does Windows 8.1/2012R2 provide the new Restricted Admin mode for avoiding credential exposure, but it also implements some changes to limit credential exposure even with a normal interactive logon.  In this first test, we are examining a normal Remote Desktop session which results in a normal interactive logon.  Because it is Windows 8.1, we do not have passwords available in memory any longer.  That’s good, but we do have the user’s NTLM (aka NT) hash available, which can be used in pass-the-hash attacks to impersonate user ‘mike’ on remote systems.  This is still a significant exposure since, for the most part, the user’s hash is every bit as useful as the password itself in a Windows domain.

To verify we see the correct NT hash above for ‘mike’, let’s calculate the hash.  An NT hash is simply an MD4 hash of the user’s Unicode password.  So here we echo the password with “-n” to prevent the new-line character being added to the string, then pipe that ASCII string through iconv to convert it to Unicode, and finally pipe it into openssl specifying the MD4 hashing algorithm.  The result is the same hash as the NT hash shown by mimikatz (this command was run via Cygwin):

$ echo -n Use4Passphrase,K? | iconv -t UTF-16LE | openssl md4
(stdin)= e456d67ce26e0f174ba2c92f4b677cac

Now let’s use mimikatz to list the Kerberos tickets available with this logon session (the built-in Microsoft tool klist can also provide this Kerberos ticket information):


We have several Kerberos tickets available, including the TGT ticket (the first one—krbtgt).  This is the ticket needed to request service tickets to remote services.  It can be used in a pass-the-ticket attack to impersonate ‘mike’ for remote authentication.

Ok, so thanks to the default settings in Windows 8.1, the clear-text password for ‘mike’ is no longer available, but the NT hash and Kerberos tickets are.  So even with 8.1/2012R2, an interactive logon creates sensitive account credentials that can be stolen by an attacker and used for lateral movement.

Now let’s turn our attention to the new Restricted Admin RDP logon.  Here I have the event ID 4624 for the session I started with “mstsc /restrictedAdmin”:


This 4624 event looks identical to the previous RDP logon event, except the Logon GUID is all zeroes.  Unfortunately that’s not a definitive marker for a Restricted Admin logon because a normal RDP logon can create this as well (as does Type 11 Cached Logon and Type 7 Unlock Workstation logon).  In fact, I could not find a way to definitively identify a Restricted Admin RDP session in the event logs (and this Technet article on Restricted Admin RDP suggests the same).  Let me know if you find a way to distinguish a Restricted Admin session in the event logs and I’ll update this section with the details.

Now that we have a Restricted Admin session, let’s use mimikatz to identify any associated credentials:

In this case we see ‘mike’ is the user associated with the remote interactive logon, but the credentials are those of the remote workstation named SEATTLE rather than the user’s credentials.

Now take a look at the Kerberos tickets available.  Notice they are also associated with the workstation credentials rather than the user’s credentials:

As advertised, the “Restricted Admin” remote desktop logon allows the user to have interactive access to the workstation, but without exposing the user’s credentials.  This is a nice development and will certainly be useful for systems administrators needing the full desktop experience.  Well…nearly the full experience.  Since the user’s credentials are not stored on the remote system, the user cannot access remote services or shares as their account.  The only resources they can seamlessly access are those which the computer account is authorized to access (in this case, the SEATTLE computer account).  For example, I setup a share and allowed the built-in group “Everyone” read-only access and I could access files on that share just fine, since “Everyone” includes computer accounts.  However, other shares that required ‘mike’ credentials were inaccessible.

Keep in mind that Restricted Admin only works when the remote system is Windows 8.1 or Server 2012R2.  The connecting client can be an older OS such as Windows 7 or Server 2008R2 if KB2871997 update has been applied.

One last thought on Restricted Admin.  There is a somewhat peculiar side-effect to this new feature.  It turns out that Restricted Admin provides attackers the ability to perform pass-the-hash or pass-the-ticket attacks against the remote host.  While this may seem counter-intuitive (in other words, why would Microsoft allow this?), it actually makes sense when you think about it.  In a nutshell, Restricted Admin Remote Desktop no longer sends your username and password to the remote system to perform the interactive logon.  This is to protect your credentials on the remote host, by never having them sent to the remote host in the first place.  Instead, your client authenticates to the remote host via a network logon using either Kerberos or NTLM.  Therefore, an attacker with your NT hash or Kerberos TGT can authenticate as you to connect to the remote system.  Aorato has a very informative article on this trade-off titled “Remote Desktop’s Restricted Admin: Is the Cure Worse Than the Disease?

So, is the cure really worse than the disease?  Not in my opinion.  I think the positives definitely outweigh the negatives.  Giving administrators a way to safely interact at the desktop is still a critical need in many organizations.  And after all, attackers can do plenty of damage using pass-the-hash without interactive access—as they’ve been doing for many years in many organizations.  Furthermore, if this feature provides incentive for the attacker to move laterally using remote desktop, then that gets me excited from an investigative standpoint because I’ll have many more artifacts to sift through as a result of their interactive activity.

New ‘Protected Users’ Group

The new Protected Users Active Directory group was introduced last year as a native feature to Windows 2012R2 domains.  Most of its protections have recently been added to legacy domains (2008R2/2012) via update KB2871997.

This group automatically provides protection to its members for the other 2 mitigation steps discussed in this blog series–disabling delegation and enforcing Kerberos.  It does this and more.  Here’s a rundown:

  • Users in this group will have delegation disabled.  The issues around token theft of delegate-level impersonation tokens were discussed in the Safeguarding Access Tokens article.  The simple fix is to disable delegation for privileged accounts, which happens automatically for members of this group.
  • Users in this group will be forced to use Kerberos authentication, meaning NTLM authentication is disabled, as well as the WDigest and CredSSP security service providers.  Refer to the Network Authentication In-Depth article for a close look at the reasons we should enforce Kerberos wherever possible.
  • Not only does it enforce Kerberos authentication, it enforces Kerberos with AES encryption (versus DES or RC4).  As I’ll discuss in a follow-up article next week, enforcing AES encryption is an important step in hardening your Kerberos implementation.
  • Kerberos long-term keys are not maintained in memory.  The long-term keys are used to generate the ticket-granting ticket (TGT), which in turn is used to request service tickets to logon to network services.  Because the long-term keys are not maintained in memory,  the user must manually re-authenticate when the TGT expires.
  • The Kerberos TGT expires after just 4 hours rather than the normal 10 hour default setting.
  • Users in this group will not have their cached domain credentials stored.

Let’s take a look the Protected Users group in action.  For this testing, we’ll run through some tests with a Windows 7 host with update KB2871997 applied.  First let’s look at standard user ‘mike’ logged into this machine.  This user is not in the Protected Users group.

It’s worth noting here that KB2871997 did more than just implement the Protected Users group.  It also partially addressed the issue of passwords in memory.  However it’s only partial (as we can see in the above screenshot), because it did not remove the password from the WDigest SSP.  Microsoft decided there would be too many customers negatively impacted to make the removal of WDigest a default part of the change.  At the end of the KB2871997 article there are some useful suggestions for monitoring your event logs to determine if WDigest authentication is being used in your environment and therefore decide whether or not it’s safe to disable.

Now let’s look at a user named ‘responder’ who is in the Protected Users group.  This user has logged on to the same Windows 7 host after ‘mike’ logged out.  As you can see in the middle of the next screenshot, there are no hashes or passwords available for this Protected User—however, we can also see a flaw:

Regarding the flaw, we see credentials lingering in memory from the previous logon for user ‘mike’.  Credentials lingering in memory has been a known issue for some time and was supposed to have been resolved in KB2871997 (see 3a in the KB article), but apparently it’s not completely effective.

In any case, the ‘responder’ account in the Protected Users group is looking pretty good.  The NT hash is no longer maintained.  The password is also not stored for the WDigest provider since Protected Users cannot authenticate with WDigest–only with Kerberos.  That’s all good–but don’t get the wrong idea—this is not a substitute for avoiding interactive logons on untrusted hosts!  It simply cleans up unnecessary credential exposure since only Kerberos authentication is allowed with these users.  As you can see here, Kerberos tickets are still available, including the TGT for ‘responder’:

Another interesting feature of Protected Users is that the Kerberos TGT is only valid for 4 hours and the Kerberos keys are not stored for automatic TGT renewal (the mimikatz command “sekurlsa::ekeys” lists the stored encryption keys for Kerberos, and there are none for members of Protected Users).  So after 4 hours, the user must re-authenticate.  For example, I let the logon above persist for several hours and when I came back to list the Kerberos tickets, it had only these remaining—without the TGT (krbtgt) ticket:

In order to log into a remote resource such as a file share, I had to re-authenticate:

The Protected Users testing above was done on a Windows 7 host with KB2871997 applied.   A Windows 8.1 host works the same.  It still avoids storing the password (which Windows 8.1 does anyway), the NT hash, and the Kerberos keys.  For example, here’s a screenshot of ‘responder’ logged on to a Windows 8.1 host and the output of mimikatz skecurlsa::logonpasswords, which would show the NT (NTLM) hash and password if available—and neither are:

Last but not least, members of Protected Users will not have their domain credentials cached for use when a domain controller is unavailable.  This useful protection is not well-advertised by Microsoft.  One place I happened to notice it mentioned was in the very useful and thorough Microsoft article How to Configure Protected Accounts.  It includes just this one line about it, stating Protected Users can no longer “Sign-on offline — the cached logon verifier is not created”.  I decided I should double-check that this meant what I expected, and it does, even on a Windows 7 host.  Here’s the output from Quarks PwDump that lists the cached domain credentials from my Windows 7 test host.  This was after several interactive logons with the ‘responder’ Protected User account, yet no cached credentials were available for this account according to the dump:

I also double-checked by attempting to logon when the domain controller was powered down.  I was able to logon with ‘mike’ and ‘johnd’ using cached account credentials, but a logon attempt with ‘responder’ gave me the following error:

Wrapping Up

To summarize the changes built into Windows 8.1/2012R2, as well as the corresponding updates added to Windows 7 and higher via KB2871997, the main takeaways are:

  • We have a new form of interactive logon called Restricted Admin RDP which authenticates the user with a network logon and avoids storing the user credentials on the remote host.  This is the ONLY safe form of an interactive logon to an untrusted host.  This is particularly appropriate for systems administrators who need a desktop environment.  Unfortunately the target system must be running Windows 8.1 or Server 2012R2, though the client can be Windows 7 or higher with  KB2871997 applied.
  • The Protected Users group provides a number of beneficial changes to protect its members, including disabling delegation, enforcing Kerberos with only AES encryption, and preventing the storage of cached domain credentials.  It is highly recommended to take advantage of the protections provided by this new group.  Keep in mind though that interactive logons with Protected User accounts still result in sensitive credential information being created in memory–in particular the user’s Kerberos TGT–so Protected Users must still avoid interactive logons to untrusted hosts.


Mike Pilkington is a Sr. Information Security Consultant and Incident Responder for a Fortune 500 company in Houston, TX, as well as a SANS instructor teaching FOR408 and FOR508.  Find Mike on Twitter @mikepilkington.