Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : Plugin Updates Mari has done some fascinating research into MS Office Trust Records and posted her findings here. Based on her sharing her findings and sample data, I was able to update the trustrecords.pl plugin. Further, Mari's description of what she had done was so clear and concise that I was able to replicate what she did and generate some of my own sample data. The last update to the trustrecords.pl plugin was from 16 July 2012 since then, no one's used it or apparently had any issues with it or questions about what it does. For this update, I added a check for the VBAWarnings value, and added parsing of the last 4 bytes of the TrustRecords value data, printing Enable Content button clicked if the data is is in accordance with Mari's findings. I also changed how the plugin determines which version of Office is installed. I also made sure to update the trustrecords_tln.pl plugin accordingly, as well. So, from the sample data that Mari provided, the output of the trustrecords.pl plugin looks like this Word ---------- Security key LastWrite Wed Feb 24 15 58 02 2016 Z VBAWarnings Enable all macros Wed Feb 24 15 08 55 2016 Z pourcentsUSERPROFILEpourcents Downloads test-document-domingo.doc Enable Content button clicked. ...and the output of the trustrecords_tln.pl plugin looks like this 1456326535REGTrustRecords - pourcentsUSERPROFILEpourcents Downloads test-document-domingo.doc Enable Content button clicked Also, I ran across a report of malware using a persistence mechanism I hadn't seen before, so I updated termserv.pl to address the new key. Process Creation Monitoring My recent look into and description of PECapture got me thinking about process creation monitoring again. Speaking of process creation monitoring, Dell SecureWorks recently made information publicly available regarding the AdWind RAT. If you read through the post, you'll see that the RAT infection process spawns a number of external commands, rather than using APIs to do the work. As such, if you're recording process creation events on your endpoints, filters can be created to watch for these commands in order to detect this and other activity. Malicious LNK Wait, what Since when did those two words go together Well, as of the morning of 24 Feb, the ISC handlers have made it a thing with this blog post. Pretty fascinating, and thanks to the handlers for walking through how they pulled things out of the LNK file it looks as if their primary tool was a hex editor. A couple of things... First, process creation monitoring of what this looks like when executing would be very interesting to see. If there's one thing that I've found interesting of late is how DFIR folks can nod their heads knowingly at something like that, but when it comes to actual detection, that's another matter entirely. Yes, the blog post lists the command line used but the question is, how would you detect this if you had process creation monitoring in place Second, in this case, the handlers report that the ACE file contains a .lnk file so, the ACE file doesn't contain code that creates the .lnk file, but instead contains the actual .lnk file itself. Great...so, let's grab Eric Zimmerman's LECmd tool, or my own code, and see what the NetBIOS name is of the system on which the LNK file was created. Or, just go here to get that I see the machine name listed, but not the volume serial number... . But I'd like to parse it myself, just to see what the shell items look like in the LNK file. As a side note, it's always kind of fascinating to me how some within the community will have data in front of them, and for whatever reason, just keep it. Just as an example and I'm not disparaging the work the handlers did, but commenting on an observation... , the handlers have the LNK file, but they're not sharing the vol SN, NetBIOS name, or shell items included in the LNK file, just the command line and the embedded payload. I'm sure that this is a case of this is what we feel is important, and the other stuff isn't... , but what happens when others find something similar How do we start correlating, mapping and linking similar incidents if some data that might reveal something useful about the author is deemed unnecessary by some Like I said, not disparaging the work that the handlers did, just thinking out loud a bit. 8Kb One-Liner There was a fascinating post over at Decalage recently regarding a single command line that was 8Kb long. They did a really good walk-through for determining what a macro was up to, even after the author took some pretty significant steps to make getting to a human-readable format tough. I think it would be fascinating to get a copy of this sample and run it on a system with SysMon running, to see what the process tree looks like for something like this. That way, anyone using process creation monitoring could write a filter rule or watchlist to monitor for this in their environment. From the Trenches The From the Trenches stuff I've been posting doesn't seem to have generated much interest, so I'm going to discontinue those posts and move on to other things.

Les mots clés de la revue de presse pour cet article : plugin
Les videos sur SecuObs pour les mots clés : plugin
Les éléments de la revue Twitter pour les mots clé : plugin





Les derniers articles du site "Windows Incident Response" :

- Training Philosophy
- Cool Stuff, re WMI Persistence
- Windows Registry Forensics, 2E
- Event Logs
- Links Plugin Updates and Other Things
- Tools, Links, From the Trenches, part deux
- From the Trenches
- Updated samparse.pl plugin
- The Need for Instrumentation
- Analysis

---

S'abonner au fil RSS global de la revue de presse

---