Journey Into Incident Response

By failing to prepare, you are preparing to fail.

~ Benjamin Franklin

In many ways preparation is key to success. Look at any sporting event and the team who usually comes out on top are the ones who are better prepared. I'm not just referring to game day; I'm also talking about the coaching schemes and building a roster. Preparation is a significant factor to one's success in the Digital Forensic and Incident Response field. This applies to the entire field and not just malware forensics, which is the focus of this post. When you are confronted with a system potentially impacted with malware your ability to investigate the system successfully depends on your knowledge, experience, and toolset.  This is where there is a conundrum. There is a tendency for people not to do malware cases (either through being hired or within an organization) due to a lack of knowledge and experience but people are unable to gain knowledge and experience without working malware cases. The solution is through careful preparation one can acquire knowledge, experience, and toolset that can eventual lead to working malware cases. This post outlines the process I used and currently use to improve my malware forensics skills.

The process described in this post helped me to develop the skills I have today. I even use a similar process to create test systems to help develop malware forensic skills in others (if you read this blog then you have already seen the benefits of doing this). With that said, what I am describing is a very time consuming process. However, if you decide to replicate the path I took it will be worth it and along the way you'll improve your malware forensic skills. This post is specifically directed at those wanting to take this step using their own resources and time. Those wanting to lose themselves in the DFIR music.

Process, Process, Process

Malware forensics is the process of examining a system to: find malicious code, determine how it got there, and what changes it caused on system. The first place to start for improving one's skills is by exploring the process one should use. The purpose of starting with the process is twofold. First and foremost it is to understand the techniques, examination steps, and knowing what to look for. The second reason is to explore the various tools to use to carry out the process. There are only a few resources available specific to this craft such as: Malware Forensics Field Guide for Windows Systems and Windows Forensic Analysis Toolkit, Fourth Edition. In addition, this has been an area on my radar to add one more book to the discussion but in the meantime my jIIr methodology page outlines my process and links to various posts. My suggestion is to first review the methodology I put together which is further explained in the posts: Overall DF Investigation Process and End to End Digital Investigation. Afterwards, review one or two of the books I mentioned. As you work your way through this material pay attention to the malware forensic process the author uses or references.

When it is all said and done and you completed reviewing what you set out to then document a malware forensic process you want to use. If this sounds familiar then you either started reading jIIr from the beginning or you are one of my early followers. This is exactly what I described in my second and third posts Where to start? and Initial Examination Steps & First Challenge that I wrote almost four years ago. However, a lot of time has passed since I wrote those posts and I improved my process as outlined below:

     - Examine the master boot record
     - Obtain information about the operating system and its configuration
     - Examine the volatile data
     - Examine the files on the system that were identified in volatile data
     - Hash the files on the system
     - Examine the programs ran on the system
     - Examine the auto-start locations
     - Examine the host-based logs
     - Examine file system artifacts
     - Malware searches
     - Perform a timeline analysis
     - Examine web browsing history
     - Examine specific artifacts
     - Perform a keyword search
     - Examine suspected malicious files

Tools, Tools, Tools

After the process you want to use is documented then the next step is to identify the tools you will use in each examination step. There are numerous tools you can use; the tools mentioned by the authors in the reference material, tools talked about the bloggers in my blog roll, or tools you already have experience with. To be honest, what tools someone should use depends. It really depends on what you prefer and are comfortable with. The tools I started out with are not the same ones I use today; the important thing is each tool helped me learn and grow. Pick any tools you want as a starting point and over time you will start to see the pros and cons of various tools.

Testing Environment

With your process and tools selected, now it is finally time to stop the researching/documenting and to actually use the process you documented and tools you selected. To do this you first have to set up a testing environment. There is an inherit risk to using virtualization for the testing environment; the malware may be virtualization aware and behave differently than on real computer. However, despite this risk I highly recommend to use virtualization as your testing environment. It's a lot faster to create multiple test systems (by copying virtual machines) and the snapshot feature makes it easier to revert mistakes. There are various virtualization options available with great documentation such as VirtualBox and VMware. Pick a virtualization platform and install it using the provided instructions.

Creating your VMs

Another decision you'll need to make is what operating systems to perform your testing on. This not only includes the operating system versions (i.e. Windows 7 vs Windows 8) but what processor to use as well (32 bit vs 64 bit). I ended up selecting VMware for the virtualization software and Windows 7 32 bit as the testing platform. You will need to create your first VM by installing the operating system of your choice. After the installation try to make things easier for the system to be compromised.

First disabled security features. This includes the built-in firewall and the user account control. Next make sure the account you are using has administrative privileges. Next you will want to make your test system a very juicy target. To do this you'll need to install vulnerable client-side applications including: Adobe flash, Adobe Reader, Java, Silverlight, Microsoft Office, Internet Explorer, and a non-patched operating system. One place to grab these applications is Old Apps and to determine what versions to install pick the ones targeted by exploit kits. At a minimum, make sure you don't patch the OS and install Java, Silverlight, Adobe reader, and Adobe flash. This will make your VM a very juicy target.

After the VM is created and configured then you'll want to make multiple copies of it. Using copies makes things easier during analysis without having to deal with snapshots.

Manually Infecting Systems

The first approach to improving your skills is a manual method to help show the basics. The purpose is to familiarize yourself with the artifacts associated with malware executing in the operating system you picked. These artifacts are key to be successful in performing malware forensics on a compromise system. The manual method involves you infecting your test VM and then analyzing it to identify the artifacts. The manual method consists of two parts: using known and unknown samples.

However, before proceeding there is very important configuration change. The virtual machine's network configuration needs to be isolated to prevent the malware from calling home or attacking other systems.

Using Known (to you) Samples

Starting out it is better to practice with a sample that is known. By known I mean documented so that you can reference the documentation in order to help determine what the malware did. Again, we are trying to improve our ability to investigate a system potentially impacted with malware and not trying to reverse the malware. The documentation is just to help you account for what the malware did to make it easier to spot the other artifacts associated with the malware running in the operating system.

The way to find known samples really depends. You could find them using information on antivirus websites since they list reports using their malware naming convention. For example, Symantec's Threat Listing, Symantec's Response blog, Microsoft's Threat Reports, or Microsoft's Malware Encyclopedia to name a few. These are only a few but there are a lot more out there; just look at antivirus websites. The key is to find malware with a specific name that you can search on such as Microsoft's Backdoor:Win32/Bergat.B. Once you find one you like then review the technical information to see the changes the malware makes.

I suggested finding known malware by names first because there are more options to do this. A better route if you can find it is to use a hash of a known malware sample. Some websites share the hash of the sample they are discussing but this doesn't occur frequently. A few examples are: Contagio Malware Dump, KernelMode.info, or MxLab blog. Another option is to look at the public sandboxes for samples that people submitted such as Joe Sandbox or one listed on Lenny Zelster's automated malware analysis services list.

After you pick a malware name or hash to use then the next step is to actually find the malware. Lenny Zelster has another great list outlining different malware sample sources for researchers. Anyone one of these could be used; it just needs the ability to search by detection name or hash. I had great success using: VirusShare, Open Malware, Contagio Malware Dump, and KernelMode.info.

Remember the purpose of going through all of this is to improve your malware forensic skills and not your malware analysis skills. We are trying to find malware and determine how the infection happened; not reversing malware to determine its functionality. Now that you have your sample just infect your virtual machine (VM) with it and then power it down. If the VM  has any snapshots then delete them to make it easier.

Now that you have an infected image (i.e. the vmdk file) you can analyze it using the process you outlined and the tools you selected. At this point you are making sure the process and tools work for you. You are also looking to explore the artifacts created during the infection. You know the behavior of the known malware so don't focus on this. Malware is different and so will be their artifacts. Focus on the artifacts created by a program executing in the operating system you selected. Artifacts such as program execution, logs, and file system.

Using Unknown (to you) Samples

Using a known sample is helpful to get your feet wet but it gets old pretty quick. After you used a few different known samples it is not as challenging to find the artifacts. This is where you take the next step by using an unknown (to you) sample. Just download a random sample from one of the sources listed at malware sample sources for researchers.  Infect your virtual machine (VM) with it and then power it down. If the VM  has any snapshots then delete them to make it easier.

Now you can start your examination using the same process and tools you used with a known malware sample. This method makes it a little more challenging because you don't know what the malware did to the operating system.

Automatically Infecting Systems

The manual method is an excellent way to explore the malware forensic process. It allows you to get familiar with an examination process, tools, and artifacts associated with an infection. One important aspect about performing malware forensics is to identify the initial infection vector which was used to compromise the system in the first place. The manual method infections always trace back to you executing malware samples so you need to use a different method. This method is automatically infecting systems to simulate how real infections appear.

Before proceeding there is a very important configuration change. The virtual machine's network configuration needs to be connected to the Internet. This can be done through the NAT or bridged configuration but you will want to be in a controlled environment (aka not your company's production network). There are some risks with doing this so you will need to take that into consideration. Personally, I accept this risk since improving my skills to help protect organizations is worth the trade off.

Using Known Websites Serving Malware

In the automatically infecting systems approach the first method is to use a known website serving malware. There are different ways to identify these websites. I typically start by referring to Scumware.org (FYI, site hates Internet Explorer), Malc0de database, and the Malware Domain List. In both instances I look for URLs that point to a malicious binary. Other sources you can use are the ones listed by Lenny Zelster on his Blocklists of Suspected Malicious IPs and URLs page. Again, you are trying to find a URL to a site hosting a malicious binary. Another, source you shouldn't overlook is your email SPAM/Junk folder. I have found some nice emails with either malicious attachments or malicious links. Lastly, if you pay attention to the current trends being used to spread malware then you can found malicious sites leveraging what you read and Google. This is a bit harder to pull off but it's worth it since you see a technique currently being used in attacks.

Inside your VM open a web browser, enter in the URL you identified, and if necessary click any required buttons to execute the binary. Wait a minute or two for the malware to run and then power it down. If the VM  has any snapshots then delete them to make it easier.

Now you can start your examination using the same process and tools you used with the manual approach. The purpose is to find the malware, artifacts associated with the infection, and the initial infection vector. Infecting a VM in this manner simulates a social engineering attack where a user is tricked into infecting themselves. If a SPAM email was used then it simulates a email based attack.

To see how beneficial this method is for creating test images to analyze you can check out my posts Examining IRS Notification Letter SPAM and Coming To A System Near You. The first post simulates a phishing email while the later simulates social engineering through Google image search.

Using Potentially Malicious Websites

The second method in the automatically infecting systems approach is to use potentially malicious websites. This method tries to infect the VM through software vulnerabilities present in either the operating system or installed client-side applications. This is the most time consuming out of all of the methods I described in this post. It's pretty hard to infect a VM on purpose so you will end up going through numerous URLs before hitting one that works. This is where you may need to use the VM snapshot feature.

To find potentially malicious URLs you can look at the Malware Domain List. Look for any URLs from the current or previous day that are described as exploit or exploit kit as shown below. You can ignore the older URLs since they are most likely no longer active.

Another option I recently discovered but haven't tried yet is using information posted at Malware-Traffic-Analysis.net. The site doesn't obfuscate websites used so you may be able to use it to find active websites serving up exploits. The last option I'm sharing is the one I use the most; the URLs others are submitting to URLQuery.net. Just keep in mind, there are certain things that can't be unseen and there are some really screwed up people submitting stuff to URLQuery. When reviewing the submitted URLs you want to pay attention to those that have detections as shown below:


After you see a URL with detections then you'll need to examine it closer by reviewing the URLQuery report. To save yourself time, focus on any URLs whose reports mention: malicious iframes, exploits, exploit kits, or names of exploit kits. These are the better candidates to infect your VM. The pictures below show what I am referring to.






Before proceeding make sure your VM is powered on and you created a snapshot. The snapshot comes in handy when you want to start with a clean slate after visiting numerous URLs with no infection. An easy way to determine if an infection occurred is to monitor the program execution artifacts. One way I do this is by opening the C:\Windows\Prefetch folder with the items sorted by last modification time. If an infection occurs then prefetch files are modified which lets me know. Now you can open a web browser inside your VM, enter in the URL you identified, and monitor the program execution artifacts (i.e. prefetch files). If nothing happens then move on to the next URL. Continue going through URLs until one successfully exploits your VM. Upon infection wait a minute or two for the malware to run and then power it down. Make sure you delete any snapshots to make it easier.

Now you can start your examination using the same process and tools you have been using. The purpose is to find the malware, artifacts associated with the infection, and the initial infection vector. The initial infection vector will be a bit of a challenge since your VM has various vulnerable programs. Infecting a VM in this manner simulates a drive-by which is a common attack vector used to load malware onto a system. To see how beneficial this method is for creating test images you can check out my post Mr Silverlight Drive-by Meet Volatility Timelines (FYI, I suspended the VM to capture the vmem file in addition instead to powering it down to get the disk image).

Summary

Benjamin Franklin said "by failing to prepare, you are preparing to fail." To be successful when confronted with a system potentially impacted with malware we should be preparing for this moment now. Taking the time to improve our malware forensic skills including our process, tools, and knowledge of artifacts. Making the right preparations so when game day approaches we will come out on top. The process I use to improve my malware forensic skills and the one I described in this post is not for everyone. It takes time and a lot of work; I've spent countless days working through it. However, working your way through this process you will attain something that can't be bought with money. There is no book, training, college course, or workshop that can replicate or replace the skills, knowledge, and experience you gain through careful preparation by training yourself.

A few weeks ago my family and I were eating dinner at our dining room table. A car alarm started going off outside so I went to the window to see what was going on. I first checked to make sure our cars weren't the ones making the noise and then I saw it was my neighbor’s car across the street. I went back to the dining table when my three year old said "the car is saying there is a fire drill". Laughing aside his statement made a lot of sense. Before that moment the only time he has heard loud sirens have been during fire drills. Naturally, his first thought when he heard something similar was a fire drill was happening. Fire drills are one simulation people have practiced (most of the time forced) over and over again to help them know how to proceed when the real thing occurs. Simulations in DFIR work the same way in helping educate ourselves how to proceed in certain types of scenarios.

Most trainings I attended reinforced learning by having the attendees practice on test images or data. The attendees just don't stumble around in the data since their objective is dictated by working through a simulation based on some case scenario. The simulation training approach even carries over to when people want to improve their skills on their own. Similar to the fire drill, different DFIR scenarios can expose people to different types of cases so they are more aware about their options and what to do when a real case comes up. The choices one has available for scenarios are to either use a test case put together by someone else or create your own. I found the latter option to be extremely effective at better preparing me since I can focus on areas I want to improve on. Simulations are how I developed my skills to investigative malware infected systems.

Forensicator Readiness is the thought process I use to develop and implement different scenarios. The process focuses my efforts on the exact skills or knowledge I want to learn more about. One simulation I’ve been working on for some time is answering these two questions about infected systems: is the system infected and how did the system get infected. All the different scenarios I developed overtime and some research I conducted was a direct result of trying to answer those two questions.

My scenarios started out by manually infecting systems with different malware to develop my skills in finding malware both in memory and on disk. Once I was effective at quickly locating the malware - without scanning - then the next step was to purposely attack systems. Some attacks I conducted such as running Metasploit against systems with malware as the payload while other attacks involved finding malicious SPAM emails or active drive-by attacks. In all the scenarios I simulated infections with different initial infection vectors on systems to provide myself with test cases. I improved my skills by examining the infected systems so I could answer were the systems infected and how did it occurred.

My neighbor’s car alarm put my three year old in fire drill mode. He didn’t get up and start walking towards the door because it was my neighbor’s car. The drill was for my neighbor and not us; otherwise our cars would have told us. :) Putting ourselves through our own simulations in advance increases our ability to be in the right mode when we need it. I was better prepared when I took on my first infected system. Not only did I locate the malware (without av scanning) but I was successful in tracing the infection back to a drive-by against an Adobe Reader vulnerability. It wasn’t luck I was able to do this right out of the gates. Nor was it luck I have continued to do this on system after system. This ability is a direct result of honing my skills in advanced by putting together my own simulations focused on areas I want to improve on.

People and children are not able to just able magically figure out how to exit a building in chaos. It takes practice and when chaos occurs the training kicks him to help people know how to proceed. DFIR is the same way; we won’t magically know how to process certain cases or answer certain questions. It takes practice and overtime we develop the knowledge on how to proceed with certain cases. Practicing can take the form of trainings or self simulations. Trainings are a one size fits all where the content is the same across the board. An advantage that self simulations have over trainings is one’s ability to focus on whatever area one wants. Time can be better spent focusing on the areas one doesn’t have knowledge about while trainings can be used to supplement other areas (this approach is a better way to use training dollars as well). The next time one wants to develop their DFIR skills then self simulations shouldn’t be overlooked as a viable option.

I attended a lot of trainings as a communications technician in the Marines. There were formal trainings by outside parties, organized trainings by my unit, and formal education on my own to hone my troubleshooting skills. The goal of all of those trainings was to prepare me to perform my job regardless of the situation I might face. Even though I left the Marines, I carried over the same mentality to my career in information security especially for digital forensics. Using a mixture of formal education, paid training, and a lot of self training to ensure I'm capable of performing my job regardless of the situation I might encounter. However, outside of forensic challenges or forensic datasets I never had an organized way to approach self training until I wanted to learn about incident response investigations. This post will explain the approach I've been using but haven't documented until now.

Forensicator readiness is the method I've been using to help prepare myself to be able to investigate any situation regardless of the circumstances. If someone said "I need you to help figure out what caused this incident” I wanted to be able to hit the ground running. This is better than having to reply with "I'd like to help out but first I have to attend a training which by the way costs a few thousand dollars". I'm sharing my approach because I think it might be useful to others. Experienced analysts/examiners can use it to learn how to investigate new types of cases or students can use it to help prepare them for the common cases they might face. Forensicator readiness consists of the following six steps:

          * Pick a Scenario
          * Establish the Scenario’s Scope
          * Collect Digital Information
          * Examine Digital Information
          * Scenario Simulation
          * Identify Areas for Improvement

Ever since I read the Alexiou Principle (as described by Chris Pogue here and here) I've been using it in my cases. The principle has been helpful in planning out the investigation and keeping the investigation on track. I thought if it works for actual cases then it should work for simulations. Well, the principle does work in simulations so I use it in the forensicator readiness steps.

Pick a Scenario

There is always something to learn in digital forensics whether it’s a student studying the field in school or a forensicator who has been in the field for a number of years. It could be trying to understand how to investigate different types of cases, how to examine new data, or how to extract data from certain devices. The first step is to pick a scenario containing the item or situation of what is to be learned. The scenario could be based on the common types of cases processed in your organization or on a potential situation someone might need to investigate. A few scenario examples are: data leakage through USB device, sexual harassment involving company email, or a malware infected server.

Next a determination needs to be made to see if it’s possible to set up test systems to simulate the scenario. Research is completed in the collection, examination, and simulation steps and systems will be needed to run a few tests on. For example, I’d like to learn how to investigate a hacked database server. Unfortunately, I can’t use this scenario since I can’t simulate a SQL injection attack against a test database server. As a result, my focus is on the scenarios I can simulate in a test environment such as a malware infected system.

Having a scenario by itself isn’t enough because an end goal hasn’t been established; what is trying to be accomplished. This is where the first question of the Alexiou principle comes into play which is “what question are you trying to answer”. Identify a few potential questions to help guide the goal of the investigation. For example, the two potential questions of a suspected malware infected system I've been using are: is the system infected and how did the system become infected. The two questions identify what I’m trying to accomplish and helped guide my research in investigating a malware infected system.

Establish the Scenario’s Scope

The selected scenario has an end goal and can be replicated in a test environment. The next step is to determine the scope of the testing environment. Is the test environment going to be one computer or multiple computers? What operating systems are going to be on the computers? Are there going to be any networking devices such as routers, switches, or firewalls? Another consideration when determining the scope of the testing environment is what resources are available. Is there the necessary hardware and software to build the test environment? I'd like to be able to simulate a test environment of over 20 machines for my malware scenario but I can’t pull it off due to the lack of resources. I had to settle on just a few test systems and I’m still able to simulate my scenario. The above questions are only some of the things that have to be considered when scoping the test environment.

Setting up of the test environment during the next few steps may take some time. Despite the time required, one of the benefits of setting up your own environment is learning about the technology as you install and configure it. For example, if your scenario requires a web server running IIS (Windows Internet Information Service) then setting up IIS will provide a better understanding of what the default settings are and how it can be configured.

Collect Digital Information

At this point, the scenario has been identified, goals have been established, and the testing environment has been identified. The next step is to collect the digital information. The second question in the Alexiou principle states “what data do you need to answer that question”. The data sources in the test environment need to be evaluated to determine which ones can help you answer your question(s). The data sources could include hard drives, memory, logs, or captured network traffic.

Once the data sources of interest are identified then it’s time to research how these sources should be collected and what tools can be used. The amount of research required for this step will depend on the experience of the person conducting this exercise. In some instances, a person will already have a procedure in place for collecting the data sources and will have knowledge of the tools to use so additional research may not be necessary. On the other hand, the person may be facing a new data source(s) so there won’t be a procedure for the collection and the person won’t have knowledge about the tools to use. For example, in one of my scenarios I wanted to collect a hard drive and volatile data. I had experience with hard drives but collecting volatile data was new. I conducted research with the intention of modifying my collection procedures to include volatile data. The research involved reviewing RFC 3227, forensic books, blogs, and forums to determine what procedural steps were required to collect volatile data and what tools could be used to acquire volatile data from a system.

The new procedural steps and tools will need to be evaluated to determine if they work as intended. This evaluation will require a small test environment. Continuing with my volatile data example, I tested the procedural steps I researched and my list of tools to see which one best met my needs. I ran a few tests against Windows XP virtual machines by acquiring the volatile data from them. This not only allowed me to see if the steps were correct and what tool worked best but it also showed me what changes I had to make to the collection steps.

Examine Digital Information

At this point it's time to identify and extract the data required to answer the scenario questions. Continuing on with the Alexiou principle's second question “what data do you need to answer that question”; this question can further identify the data needed to answer the questions. The data sources have already been identified so the next part is to identify what information in those data sources can answer the questions. For example, in my scenario one of my data sources was volatile data so I had to figure out what information I needed from it. Some of the information was the running processes, established network connections, and loaded drivers. Once the exact information in the data sources is identified, the third Alexiou principle comes into play which is "how do you extract the data". Using the volatile data example, this would be determining how to extract the established network connections, loaded drivers, and running processes from the data.

As might be expected, research has to be conducted to decide what information in the data sources is needed to answer the questions and how that information can be extracted. The same types of references used in the collection step can be used such as blogs, forums, and forensic books.

Similar to the collection step, the new examination steps and tools need to be evaluated to see if they work as intended. The evaluation can use available forensic datasets or a small test environment. Forensic datasets can be used for testing different types of data sources and this is a faster option then setting up a test environment. The datasets available for testing the examination steps and tools for the volatile data example include: NIST CFReDS Project, Forensic Educational Datasets, Honeynet Challenges, or the memory images on the Forensic Incident Response blog. If there isn't an available dataset then a small test environment has to be set up. The fourth question of the Alexiou principle is "what does the data tell you". This question should be kept in mind during the evaluation because the purpose of the examination steps and tools are to extract information needed to answer the scenario questions. If the information doesn't help answer the question then additional research may have to be performed so the examination steps and tools can be adjusted.

Scenario Simulation

This step is where all of the hard work of researching and evaluating pays off. The scenario simulation is when the test environment is created and the scenario is simulated in that environment. The first scenario I've been working with is a computer infected with malware, and one of the ways I simulated this scenario was by visiting known malicious websites with a computer running vulnerable software. After the scenario is simulated then the next step is to treat the test environment like a real investigation. The data sources of interest get collected, and information is extracted from those sources to answer the scenario's questions.

Identify Areas for Improvement

Now that the dust has settled from investigating the scenario in a test environment; it's time to reflect back on what was done. The purpose of this step is to see if there is anything to improve upon. A few things for consideration are: did the tools perform as expected, were the procedures correct, what didn't work, and what can be done better. Something else to keep in mind during this reflection is to decide if any additional research has to be performed on any artifacts in order to get a better understanding about them. During my simulation, I didn't have a good understanding about the attack vector artifacts such as those left by exploits. I spent some time researching a few of these artifacts so I'd have a better understanding the next time I come across a similar artifact.

Summary

There isn’t a set time table to complete the forensicator readiness steps. It could take days, weeks, or months to complete. The time all depends on the scenario and how much of an understanding someone wants. People prepare for things differently and forensicator readiness is no different. If the steps can accomplish the end goal of preparing someone to investigate an incident regardless of the circumstances - like it did for me- then the process has served its purpose.

So when someone said to me "I need your help to figure out what caused this infection"; I was ready to rock and roll. I’ve been successful numerous times locating malware on systems and identifying the attack vector that put the malware on the systems. A few of the vectors were: a malicious email attachment, a drive-by download using a malicious PDF, and third party content pointing to a website hosting Windows help center and Java exploits. I don't think my success is a string of luck. It's due to my preparation for a situation I thought I would face sooner or later. It just so happened to be sooner than I was expecting.