Memory has plenty of useful information for incident handlers such as open files, network connections and encryption keys. With pulling the plug forensics methodology you are losing all this information and you’re putting your skills into question if the case go to the court.
While analyzing memory require a set of skills, acquiring memory isn’t that difficult with the new tools available. On a previous diary[i] Mark Baggett wrote about using winpmem to acquire memory.
This diary will be about using similar tools which is Dumpit. Dumpit is a free tool written by Matthieu Suiche from MoonSols . Dumpit support both 64-bit and 32-bit Windows operating systems .
Dumpit can be downloaded from MoonSols website[ii] . After downloading and extracting the zip file it wil be a single executable file ‘dumpit.exe’.
One of the major benefits of Dumpit that it is very easy to use and any user with an admin privileges can use it. I would suggest that you provide your helpdesk team with some USB sticks with a copy of Dumpit, there are some issues that have to be considered: first the size of USB stick should be higher than the RAM size and if you have memory larger than 2 GB the USB sticks should be NTFS formatted.
When you have a suspicious event in a remote office or on a time that no body from the incident response team is available, a ready USB stick with Dumpit might be the ‘smoking gun’ for this incident.
The memory accusation can be performed with these three simple steps:
1. Insert the USB stick.
2. Double click on Dumpit icon (Figure 1)
3. Type “y” (figure 2)
Figure 1 (Dumpit executable)
Figure 2 (Dumpit)
After few minutes the image will be ready on the USB stick as the computer name-date-time.raw (figure 3)
Since Dumpit is a simple tool, it doesn’t have any analysis capabilities .Tools such as Mandiant Redline can be used for the analysis purpose.
Encrypted traffic has long been a challenge for network monitoring. But even if traffic is encrypted, there is still plenty of information that can be extracted. In this little example, we are looking at "SSL Hello" messages. These messages are sent by the client to initiate the SSL connection. They include a number of parameters that may vary depending on the SSL library used or the SSL clients preference.
The SSL Hello message contains a couple of major parts 
This gives us quite a bit of data to fingerprint clients. The timestamp can be used to check if the clients time is in sync. The supported cipher suites and extensions may tell us what browser version the host is running and could for example be used to block out of date browsers at a gateway that is not able to decrypt traffic.
Ivan Ristic has published similar data in the past focusing on SSL ciphers , and p0f considered including some of that data.
My tool of choice to extract this information from packet captures is tshark. To run this test, I collected a couple minutes of traffic. I also extracted the IP addresses and user agents from the web server log to be able to link the "SSL Fingerprint" to the user agent. I ignored all IP addresses for which I saw multiple user agents (looks like mostly mobile devices that accessed the podcast via a podcast client as well as the web site via a browser).
In tshark, to extract the "fingerprint" I used:
tshark -r test.pcap -T fields -e ip.src -e ssl.handshake.ciphersuite -e ssl.handshake.version -e ssl.handshake.extension.type -R "ssl.handshake.type=-1"
Here is a partial result:
Firefox 25 on Windows 7 ( Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 )
Cipher Suites: 0x00ff,0xc00a,0xc014,0x0088,0x0087,0x0039,0x0038,0xc00f,0xc005,0x0084,0x0035,0xc007,0xc009,0xc011,0xc013,0x0045,0x0044,0x0033,0x0032,0xc00c,0xc00e,0xc002,0xc004,0x0096,0x0041,0x0005,0x0004,0x002f,0xc008,0xc012,0x0016,0x0013,0xc00d,0xc003,0xfeff,0x000a
SSL Version: 0x0301 (TLS 1.0)
Extensions: 0x0301 0x0000,0x000a,0x000b,0x0023,0x3374
Chrome 31 on Windows 7 (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36)
SSL Version: 0x0303 (TLS 1.2)
Internet Explorer 7 on Windows 7 (Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.2; .NET4.0E; Microsoft Outlook 14.0.7109; ms-office; MSOffice 14)
SSL Version: 0x0303 (TLS 1.2)
These three examples, all from Windows 7, show how different browser result in very different fingerprints. The order of ciphers and extensions appears to vary as well allowing for more detailed distinctions, and something that needs a bit more data to work with.
Timestamp fingerprinting was kind of interesting as well. Turns out that out of the times are actually very accurate. Out of a total of 3814 Client Hello messages, 3109 where within 5 seconds. A couple of time stamps where "far outliers" with timestamps in 1970, likely indicating a "time since reboot" instead of the absolute time.
Figure 1: Time difference frequency up to 10 seconds
Adobe also has published updates today for Flash Player, resolving CVE-2013-5331 and CVE-2013-5332.
This is a remote execution vulnerability, by way of a malicious SWF (Flash) content in an MS Word document.
The versions will vary from platform to platform, but if you are running Flash Player you should update soon (today if possible).
Shockwave Player also sees an update today, addressing CVE-2013-5333 and CVE-2013-5334 on the Windows and Mac platforms. With this update applied, both platforms should be at version 188.8.131.52
These exploits also result in remote execution, so if you have Shockwave Player installed today is a good day to update, either right before or right after the Microsoft reboot.
You'd think by now most major products would have an auto update or a "click here to update" feature. From this note, perhaps you'd think that Adobe might be unique in not having this, but you'd be surprised what other major system components don't update themselves!
Overview of the December 2013 Microsoft patches and their status.# Affected Contra Indications - KB Known Exploits Microsoft rating(**) ISC rating(*) clients servers MS13-096 Code Execution Vulnerability in GDI+
(**): The exploitability rating we show is the worst of them all due to the too large number of ratings Microsoft assigns to some of the patches.
I had a chat with another one of the ISC Incident Handlers the other day about inventorying large networks, which is covered in the first two Controls in the SANS "Critical Security Controls" (http://www.sans.org/critical-security-controls). Paraphrased, these controls boil down to "know what's on your network" and "know what software and services are running on those stations".
This seems like a couple of pretty obvious statements, but it started me thinking about my client base. For instance, about just how many are still running old print servers that top out at 10Mbps and advertise IPX printer SAPs. Similarly, I started implementing a standard to isolate ATMs in a banking environment (without changing any IPs), and found a number of switches sol old that they didn't support port based ACLs, or Private VLANs or source port filtering.
In short, it's really easy to let sleeping dogs lie (or prevaricate) - it's easy to let that 10 year old (plus) hardware that's been working forever stay on the network until you need a feature that doesn't exist on them. And if it's easy to let this happen with IT owned gear that you know about, how about stuff that's NOT owned by IT? Stuff like cameras, projectors and video conferencing units? Or how about even more removed from IT - gear like elevator controls and HVAC systems? Time clocks or PLCs? Or, just to up the ante, medical devices that are network attached in a hospital or other health-care setting?
And that's just the hardware. If you are inventorying your corporate stations' software, you're most likely using the OS's "list applications" commands or API calls to do this, whether in your own scripts or wrapped into a commercial product.
For windows, you might use commands like:
wmic product list /format:csv > applist_for_database_import.csv
wmic product list brief /format:htable > %COMPUTERNAME%_applist.html
In Linux, depending on the distro you might use one of these:
yum list installed
However, these commands and other active scanning methods won't help you in a lot of cases - situations like:
So, what should you do to find these incognito stations and camoflaged applications? For many of my clients, we look for evidence of these situations in the network traffic that they create, just the same way we often find Indicators of Compromise in malware or attack situations.
Several tools will help you in finding, fingerprinting and identifying versions of apps like this. The "granddaddy" of these "passive scanner" applications is p0f. Downloadable from http://lcamtuf.coredump.cx/p0f3/, it's been around for over 10 years, is still actively developed and is still free. If you have a budget and are looking for a commercial alternative, PVS from Tenable might also fit the bill - either instead of or in conjunction with p0f. Info on PVS can be found here: http://www.tenable.com/products/passive-vulnerability-scanner, it's available for free for up to 16 nodes, or you can get an "eval-ware" version for larger networks.
So, with good tools in hand and pure intentions in your heart, how to proceed? You'll need to find a spot on your network to capture traffic of interest - the obvious place is to put your sensor station would be on a SPAN port, sniffing the traffic on the inside interface of our firewall. However, this won't find traffic to identify internal-only stations like internal-use database servers, print servers and the like. For these, you'll want a SPAN port capturing an entire internal VLAN, or perhaps capturing traffic from internal router ports. It's best to take some time and apply some business process knowledge to place your station well, or in many cases several stations.
There are lots of other pointers on using "fingerprint" applications - the SANS Reading Room at http://www.sans.org/reading-room is a great place to start, or the SANS Security Resources pages here http://www.sans.org/security-resources/idfaq/p0f.php.
In my most recent deployment of p0f, we found unpatched Win95 stations running a pharmaceutical assembly line. Stations that were put in by the industrical controls vendor back in the mid-90's, buried inside the cabinets with the PLCs and so on, then just plugged into the network so the plant engineers could get to them. Nobody left in the organizations had any idea these stations were there, the plant engineers who used them knew the interfaces, but not what was behind them. And of course these stations were just about as business critical as you could find - SCADA systems in all but name.
What tools have you used for passive discovery? Use our comment form and let us know where you've placed passive sensors in your network and most importantly, what's the most interesting things that you've found?
Microsoft released its pre-announcement for the upcoming patch Tuesday. The summary indicates 11 bulletins total, 5 are critical all with remote code execution and 6 Important with a mix of remote code execution, security feature bypass and elevation of privileges. The announcement is available here.
Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.