One of the most important things we can do when designing our attacks is understanding the victim's perspective. We should never fire off attacks without understanding what will happen when someone takes the bait. So, now that the attacking website is up, power on your Windows 7 VM and navigate over to the site. In my lab, I'm hosting the file on 192.168.108.117, so I'm sending IE on my Windows 7 box to http://192.168.108.117:8000/lottery.html:
Meanwhile, back at our attack box, we see the GET request pulling the attack:
Though I haven't told you to click the CLICK TO CLAIM button just yet, I already know that some of you did. Morbid curiosity, right? What happened? That's right, Internet Explorer crashed. As you can see from the code in lottery.html, we expected one of two possible results: either we click the button and nothing happens, or we click the button and IE crashes. We only put a bunch of z in the buffer, so if the string was shorter than the buffer's size, nothing happens. If the string is longer than the buffer, then we'll overwrite the instruction pointer with 0x7a7a7a7a (or at least partially with 0x7a), causing a fault. There are no surprises here, but we have no idea what the memory actually looks like. Enter Windows Debugger (WinDbg).
The way we'll be examining Internet Explorer's memory is by attaching to the process with WinDbg. The best way to do this is at the command line, but we can't begin without the Process ID (PID) of the target process. Fire up the command prompt with cmd and pull the list of PIDs with tasklist. In our example, iexplore.exe is near the bottom. Note that there are two processes for Internet Explorer; I picked the one that is using the most memory. Using a PID of 3796 in my example, we run this command from within the WinDbg folder:
> windbg -p 3796 /g
Once WinDbg is running, it's attached to the process and you can continue using the program normally. The key functionality is pausing execution so you can examine memory at a given moment. We won't be diving too deeply into this, so don't worry about breakpoints for now. We can pause execution if everything is running smoothly, but we won't need to, if the program crashes. If the program crashes, WinDbg dumps memory information so you can do a postmortem analysis:
