Hi Ramon, >straight forward ;) Will certainly have a look at using this lib >though as it >will make life a whole lot simpler. Not sure how licenses would go >but thats >something to worry about later.
Yeah, it's pretty much fully implemented, using this approach. I'm not sure about licenses either, but it could at least give an idea on how to implement an "open-source" equivalent; not sure if Detours is licensed differently, though. >Onto the bad stuff. The current process monitor imo sucks. Have you >ever tried >to create processes really fast? It dies horribly. Internally the >monitor keeps >track of its parent processes but I'm pretty sure this is >implemented wrong and >would be causing the BSOD and incorrect process names. I will try >getting >Capture working with this in the weekend so hopefully I can send you >a patched >process monitor by then if you like? Thanks; no problem -- take your time on the patch. I think you're right on the fast process creation. Currently, when spawning a single IE process every 20s, the process monitor doesn't seem to have any issues. But yeah, I can see how if we're suddenly creating a 4+ deep process tree every 20s, then the monitor might have issues. Incidentally, I think there might be another approach that I'm looking at (may not solve the issue -- dunno yet). Anyway, if I can just spawn IE (as before), but then call INJLIB to inject the DLL prior to having IE navigate to a URL, then I should be able to do exactly what we're looking for -- but without any additional processes spawned (i.e., no CMD.EXE, RUNELEVATE.EXE, WITHDLL.EXE)... that should help. For the actual Capture code, one thought would be to figure out what the programmatic API equivalent to INJLIB.EXE in order to accomplish the same thing. Btw, it looks like the latest version of the VIX API appears to offer some interesting functionality: http://pubs.vmware.com/vix-api/ReferenceGuide/ Namely: - VMOpenUrlInGuest - VMLoginInGuest - VMRunProgramInGuest - VMListProcessesInGuest - VMKillProcessInGuest I'm curious if you've tested this functionality (or have already implemented it). It's almost as if VMware is trying to implement enough of a communications mechanism in its API so you'd (eventually) no longer need a separate TCP/XML connection altogether. Though, they still don't seem to have any nice way of getting data out of the VM onto the host (other than through file copies -- weird). Anyway, I still can't get a straight answer from VMware as to when VIX will be ported to ESX (sigh). >Thanks for the link, Welcome, -- Darien >Ramon. > >Kindlund, Darien F. wrote: >> Hi Christian & Ramon, >> >> I've tried incorporating the proxy/DNS suggestions you've >mentioned, >> regarding how to preserve the original pages that served malware >for as >> long as possible. However, the solution isn't perfect. Here's an >> example: >> >> If the VM visits a page where the malware is contained within a >banner >> ad that rotates, it's possible that when you try to view the >original >> page, javascript within the page might (try) to load a different >ad -- >> making it difficult to replicate initial compromises. >> >> Of course, one solution to this, would be to capture PCAP data, >and try >> to serve this PCAP data back to the browser/application. This >sounds >> hard. >> >> THE GOOD NEWS: >> -------------- >> >> Fortunately, it looks like the folks at Microsoft have made life a >> little easier; check out this URL about STRACE/HTTPREPLAY: >> http://blogs.msdn.com/emmanubo/archive/2007/06/04/introduction-to- >strac >> e-httpreplay-support-tools.aspx >> http://tinyurl.com/4llhar >> >> Essentially, STRACE is a (DLL) wrapper that you can inject into >_ANY_ >> windows application, that logs all TCP/UDP traffic to/from the >> application -- one of the biggest benefits, is that it's able to >log >> raw HTTP data -- even data that's been wrapped in an SSL stream >(before >> encryption/after decryption!). >> >> Here's the best part: HTTPREPLAY is a tool that allows you to >"replay" >> strace logs within IE (or any browser), in order to serve up the >exact >> content that was logged. >> >> This solves a whole slew of issues that I'm sure we've all been >dealing >> with. What's really cool about this approach, is that you could >inject >> the STRACE DLL even into live, running processes (via INJLIB.EXE) >-- >> and it even works with Mozilla Firefox! >> >> Anyway, it's based off the "Detours" library, which appears to be >used >> extensively by sysinternals utilities. >> >> Okay, so what's the catch? >> >> THE BAD NEWS: >> ------------- >> >> I've done some initial testing with STRACE/HTTPREPLAY and Capture, >and >> it looks like the code doesn't (exactly) play nice. Specifically, >it >> seems CaptureProcessMonitor.sys sometimes causes BSODs and some >(weird) >> false positives -- for example, if you have a process tree like: >> >> PROCESS (PID) >> 1) CMD.EXE (389) >> 2) +- RUNELEVATE.EXE (783) >> 3) +- WITHDLL.EXE (762) >> 4) +- IEXPLORE.EXE (3726) >> >> And the processes terminate in the order of: #2, #3, #1, #4, then >(for >> example) Capture will report WITHDLL.EXE terminated with an parent >> process of (783) -- but no parent process EXE name listed (i.e., >> RUNELEVATE.EXE), because that parent process has already >terminated. >> So Capture seems to list the parent process PID when it can't >determine >> the parent process name. In other words, when process trees >terminate >> in any other order than bottom to top, we start getting PIDs >listed as >> parent process names -- which makes it difficult to filter within >the >> corresponding .EXL >> >> Anyway, you can see some of the initial testing I've tried in this >> changelog (example code): >> http://www.honeyclient.org/trac/changeset/1599 >> >> >> First off, check out the STRACE/HTTPREPLAY libraries and let me >know >> what you guys think; specifically, I'm curious if you manage to >get >> Capture working with the libraries, or if you also run into any >BSODs. >> If they get more consistent, I can try to get a minidump for you >in >> order to debug further. >> >> Second, you're interested in using this library, I'm curious what >your >> thoughts were on how it could be (easily) incorporated into the >Capture >> code. >> >> Hope this helps, >> -- Darien >> _______________________________________________ >> Capture-HPC mailing list >> Capture-HPC@public.honeynet.org >> https://public.honeynet.org/mailman/listinfo/capture-hpc >_______________________________________________ >Capture-HPC mailing list >Capture-HPC@public.honeynet.org >https://public.honeynet.org/mailman/listinfo/capture-hpc _______________________________________________ Capture-HPC mailing list Capture-HPC@public.honeynet.org https://public.honeynet.org/mailman/listinfo/capture-hpc
