Registry Settings
Microsoft TechNet had a blog post recently regarding malware setting the IE proxy settings by modifying the "AutoConfigURL" value. That value sounded pretty familiar, so I did a quick search of my local repository of plugins:
C:\Perl\rr\plugins>findstr /C:"autoconfigurl" /i *.pl
I came up with one plugin, ie_settings.pl, that contained the value name, and specifically contained this line:
ie_settings.pl:# 20130328 - added "AutoConfigURL" value info
Pretty fascinating to have an entry added to a plugin 3 1/2 years ago still be of value today.
Speaking of the Registry, I saw a tweet recently indicating that the folks at Volatility had updated the svcscan module to retrieve the service setting for what happens when the services fails to start. This is pretty interesting...I haven't seen this value having been set or used during an engagement. However, I am curious...what Windows Event Log record is generated when a service fails to start? Is there more than one? According to Microsoft, there are a number of event IDs related to service failures of various types. The question is, is there one (or two) in particular that I should look for, with respect to this Registry value? For example, if I were creating a timeline of system activity and included the contents of the System Event Log, which event IDs (likely from source "Service Control Manager") would I be most interested in, in this case?
Outlook Rulez
Jamie (@gleeda) recently RT'd an interesting tweet from MWR Labs regarding a tool that they'd created to set malicious Outlook rules for persistence.
I was going to say, "hey, this is pretty fascinating...", but I can't. Here's why...SilentBreak Security talked about malicious Outlook rules, as have others. In fact, if you read the MWRLabs blog post, you'll see that this is something that's been talked about and demonstrated going back as far as 2008...and that's just the publicly available stuff.
Imagine compromising an infrastructure and leaving something in place that you could control via a text message or email. Well, many admins would look at this and think, "well, yeah, but you need this level of access, and you then have to have this..."...well, now it's just in a single .exe file, and can be achieved with command line access.
I know, this isn't the only way to do this...and apparently, it's not the only tool available to do it, either. However, it does represent a means for retaining access to a high-value infrastructure, even following eviction/eradication. Imagine working very hard (and very long hours) to scope, contain, and clean up after a breach, only to have the adversary return, seemingly at will. And to make matters even more difficult, the command used could easily include a sleep() function, so it's even harder to tie back the return to the infrastructure to a specific event without knowing that the rule exists.
Webshells
Doing threat hunting and threat response, I see web shells being used now and again. I've seen web shells as part of a legacy breach that predated the one we were investigating, and I've seen infrastructures rife with web shells. I've seen a web shell used internally within an infrastructure to move laterally (yeah, no idea about that one, as to "why"...), and I've seen where an employee would regularly find and remove the web shell but not do an RCA and remediate the method used to get the web shell on the system; as long as the vulnerability persists, so does the adversary.
I caught this pretty fascinating description of a new variant of the China Chopper web shell, called "CKnife", recently. I have to wonder, has anyone else seen this, and if so, do you know what it "looks like" if you're monitoring process creation events (via Carbon Black, Sysmon, etc.) on the system?
Tool Testing
Eric Zimmerman recently shared the results of some pretty extensive tool testing via his blog, and appeared on the Forensic Lunch with David and Matt, to discuss his testing. I applaud and greatly appreciate Eric's efforts in putting this together...it was clearly a great deal of work to set the tests up, run them, and then document them.
I am, however, one of those folks who won't find a great deal of value in all of that work. I can't say that I've done, or needed to do, a keyword search in a long time. When I have had to perform a keyword search, or file carving, I tend to leave long running tasks such as these for after-hours work, so if it finishes in 6 1/2 hrs, or 8 hrs, really isn't too big a deal for me.
A great deal of the work that I do involves creating timelines of all sizes (Mari recently gave a talk on creating mini-timelines at HTCIA). I've created timelines from just the contents of the Security Event Log, to using metadata from multiple sources (file system, Windows Event Logs, Registry, etc.) from within an image. If I need to illustrate how and when a user account was used to log into a system, then download and view image files, I don't need a full commercial suite to do this...and a keyword search isn't going to give me any thing of value.
That's not to say that I haven't looked for specific strings. However, when I do, I tend to take a targeted approach, extracting the data source (pagefile, unallocated space, etc.) from the image, running strings, and then searching for specific items (strings, substrings, etc.) in the output.
Again...and don't misunderstand...I think that what Eric did was some really great work. He would not have done it if it wasn't of significant value to him, and I have no doubt in my mind that he shared it because it will have significant value to others.
On the subject of Outlook rules, something you didn't mention (and which the original Silent Break post was highlighting) is the usefulness of Outlook rules in lateral movement and initial access to a network. If attackers can obtain ANY user's credentials, they can now access a network remotely and/or move laterally on the internal network (assuming that the account of the compromised credentials uses Outlook, anyways).
ReplyDeleteFor lateral movement, Outlook rules remove the requirement of an attacker needing local admin (or an exploit) to execute remote commands. Also, Outlook rules can be extremely useful for pivoting in environments that are well segmented. For example, the attacker might have found creds to an admin machine, but the current host the attacker is on cannot access the admin's machine directly due to the firewalls/network segmentation. With Outlook rules, an attacker could put an EXE/bat file on a their own external server(SMB/WebDAV) or on a shared internal file server, and create an Outlook rule using the admin's credentials to execute the payload (essentially causing the admin's machine to execute the payload without need to send any packets directly to the admin's machine).
For initial access, the attacker could obtain brute force passwords through OWA or get passwords via leaked databases. Then, the attacker could use Outlook rules to download and execute a exe/bat/vbs hosted on the attacker's own internet-facing SMB/WebDAV server.
- Lee Christensen (@tifkin_)