Artifacts Created by Nmap/Zenmap

The scenario is that I knew a particular system had run an Nmap scan against another particular system, using the Zenmap GUI (and was manually terminated before completion). I know, I know, why wasn't CLI used? Well, it just wasn't, and that's not really part of the problem. The problem was that after the fact, there was a need to correlate the scan against certain event log entries on the target, as it appeared that perhaps the scan had not shut down properly, and continued running in the background.

So how to do it? Does Nmap/Zenmap create any logs or other artifacts on the source system, which remain afterwards? So I put on my forensicator hat, gloved up (technical term for putting your protective gloves on), then announced, "I'm goin' in!" For testing, I ran Zenmap versions 4.6 (because I had it) and 5.1 (which was the current version in question) on XP Pro and Win7 Pro, both 32-bit, both fully patched. I ran scans both from the GUI and CLI (yes, I went ahead and tested that too, as I thought it would be good to know, although not pertinent to the current scenario). The ultimate prize was to be able to show what scan ran when, for how long, against what target (specifically the scan that was terminated early).

I'll also state that I wasn't trying to prove that Nmap/Zenmap was run, so I didn't look to prefetch, user assist, or other similar artifacts. I was trying to prove what was done when the application did run, more so than if it had been run or by whom. Think of a scenario where it might be legitimate for a user to use the application as part of their normal duties, and the question is whether they did something with it they should not have done. "What" and "When" became more important questions than "Who," "How" or "Why."

I'd love to be able to say that I reached the goal, but I'm afraid that's not the case. I found good stuff, but nothing directly showing the terminated scan. Ultimately I did find evidence of that scan in pagefile, but nothing that gave specific time frames, or the options used. What was useful was that I saw the NSE (Nmap Scripting Engine) info, which showed some details about the scan; some of these were particulars that were useful to me (some of this was similar to some of the data from temp files that you'll read about later). So in a round-about way I accomplished the mission, just not in the neat, clear-cut way I had hoped for. But even in that respect, all was not lost...

Results of testing were inconsistent. But wait, I thought you said all was not lost?! Right, it's not. Results were inconsistent, but there is stuff to look for, and I can provide some direction on that, so in case you need to know about Nmap/Zenmap artifacts, you'll have something to work with ahead of time. So, inconsistent results, what does that mean? It means that on either OS, with either version of Zenmap, some things were logged, some artifacts were created, and sometimes they weren't. That's what I mean by inconsistent. Seems like it meets the definition of the word to me. Anyhow, artifacts are created, and I will expand on that, so you'll know the kinds of things to look for.

Basically, there were three areas containing artifacts; two under the user profile, and one in the program directory. Keep in mind that sometimes some of these were present, and sometimes they were not; sometimes they had data and sometimes they did not. I'm just going to explain what I saw, when it was there to see, YMMV. Note: I did not see any of these artifacts when running Nmap from CLI; only when using the Zenmap GUI front-end. Due to the otherwise inconsistent results, I don't know that CLI doesn't create some of these artifacts as well (such as the temp files you'll read about), just that in my testing, I did not see it occur.

In c:\program files\nmap\zenmap\ a file was created when a scan was saved. This had the same user-selected name as the saved scan, with the extension USR. So if the scan saved was "test" then the subsequent file would be "test.usr." If you find one of these, you can bet the user saved a scan; this file should be identical to that. It is an XML file that has all the information about the scan, it starts out looking something like this:


nmaprun profile="nmap -v %s" scanner="nmap" hint="" scan_name="" args="nmap -v xxx.xxx.xxx.2" profile_name="Regular Scan" startstr="October 1, 2011 - 16:54" options="Verbose" start="1317506087" nmap_output=" Starting Nmap 4.60 ( http://insecure.org ) at 2011-10-01 16:54 Central Daylight Time Initiating ARP Ping Scan at 16:54 Scanning xxx.xxx.xxx.2 [1 port] Completed ARP Ping Scan at 16:54, 0.48s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 16:54 Completed Parallel DNS resolution of 1 host. at 16:54, 0.00s elapsed Initiating SYN Stealth Scan at 16:54 Scanning System (xxx.xxx.xxx.2) [1715 ports] Completed SYN Stealth Scan at 16:55, 39.01s elapsed (1715 total ports) Host System (xxx.xxx.xxx.2) appears to be up ... good. All 1715 scanned ports on System (xxx.xxx.xxx.xxx) are filtered MAC Address: xx:xx:xx:xx:xx:xx (make) Read data files from: C:\Program Files\Nmap Nmap done: 1 IP address (1 host up) scanned in 39.847 seconds Raw packets sent: 3431 (150.962KB) | Rcvd: 1 (42B) " version="4.60" target="xxx.xxx.xxx.2" annotation="" description=""


There was also a "zenmap.exe.log" file under Program Files, but it was not helpful for this purpose. It appears to be an error entry related to the application itself, not relating to activity. This might be helpful to show that Zenmap was run at some point, if that was a goal, but not for showing what scan was run or when.

In %User%\.zenmap (hidden folder) there are primarily three files of interest: recent_scans.txt, target_list.txt and zenmap.db. Recent_scans.txt is a list of saved scans (or perhaps the .USR instance, it's inconclusive at this point); all it has is a list of files with their paths. Target_list.txt is a list of all target IP addresses, separated by semicolons; it has no other information, not even an associated date. Zenmap.db is the fun one; it's a SQLite database that contains a history of what scans were run - type of scan, target IP, XML output (ie, basic scan detail) and time. In my case, the killed scan was not in there, but others were.

In %User%\%Local%\Temp has another potential treasure trove of evidence. I found temporary files (with no extension) located at this level. Some of contained no data, some contained only a small amount, and others looked like this (at the start):


Winpcap present, dynamic linked to: WinPcap version 4.0.2 (packet.dll version 4.0.0.1040), based on libpcap version 0.9.5

Starting Nmap 4.60 ( http://insecure.org ) at 2011-10-01 16:34 Central Daylight Time
--------------- Timing report ---------------
hostgroups: min 1, max 100000
rtt-timeouts: init 500, min 100, max 1250
max-scan-delay: TCP 10, UDP 1000
parallelism: min 0, max 0
max-retries: 6, host-timeout: 0
---------------------------------------------
Initiating ARP Ping Scan at 16:34
Scanning xxx.xxx.xxx.1 [1 port]
Packet capture filter (device eth1): arp and ether dst host 00:11:25:D1:04:E0
SENT (1.3820s) ARP who-has xxx.xxx.xxx.1 tell xxx.xxx.xxx.2
RCVD (1.3820s) ARP reply xxx.xxx.xxx.1 is-at xx:xx:xx:xx:xx:xx
Completed ARP Ping Scan at 16:34, 0.80s elapsed (1 total hosts)
Initiating SYN Stealth Scan at 16:34
Scanning xxx.xxx.xxx.1 [1715 ports]
Packet capture filter (device eth1): dst host xxx.xxx.xxx.2 and (icmp or (tcp and (src host xxx.xxx.xxx.1)))
SENT (1.3920s) TCP xxx.xxx.xxx.2:49151 > xxx.xxx.xxx.1:25 S ttl=40 id=15841 iplen=44 seq=237510861 win.14
SENT (1.3920s) TCP xxx.xxx.xxx.2:49151 > xxx.xxx.xxx.1:554 S ttl=55 id=24142 iplen=44 seq=237510861 win=4096
SENT (1.3920s) TCP xxx.xxx.xxx.2:49151 > xxx.xxx.xxx.1:3389 S ttl=47 id=2030 iplen=44 seq=237510861 win=4096
SENT (1.3920s) TCP xxx.xxx.xxx.2:49151 > xxx.xxx.xxx.1:389 S ttl=51 id=32698 iplen=44 seq=237510861 win=4096
SENT (1.3920s) TCP xxx.xxx.xxx.2:49151 > xxx.xxx.xxx.1:256 S ttl=46 id=12578 iplen=44 seq=237510861 win=3072
SENT (1.3920s) TCP xxx.xxx.xxx.2:49151 > xxx.xxx.xxx.1:113 S ttl=54 id=21527 iplen=44 seq=237510861 win=3072


Basically this is a detailed breakdown of the scan, really the veritable motherlode, as it shows the time of the scan, each target port, protocol, scan times, and so on. Very good stuff, when present. The temporary files that had only a little content basically mirrored the type of content in the USR files, so if you don't have one, you might have the other and still have some insight into the scan. Note: All these temp filenames were 9 characters in length, and started with "tmp."

And a slightly tangential question posed on twitter was how to identify a scan with packets. That's probably already documented, but since I was in testing mode, I looked into that myself as well. Fairly simple, right - just start Wireshark, run an Nmap scan, and review the results. Turns out across multiple types of scans run, that there are 60-byte packets, and all have the following content: 00 0d 60 da b4 e7 00 11 25 d1 04 e0 08 00 45 00. Obviously, that's not all the content, but that is what I saw as consistent across all packets captured. So there you go.

I think that's about it for this post. Hopefully if you're doing an investigation wherein the use of Nmap/Zenmap is key, this will help get you started. As always, happy forensicating!