How Nmap detect MAC address?

Question

Here I find an interesting phenomenon, that I get different MAC address using different Nmap options.

With my Kali OS, I type nmap -sS 192.168.1.4 to start a "half-open" scan.

    Starting Nmap 7.70( https://nmap.org ) at 2018-07-04 12:38 UTC
    Nmap scan report for 192.168.1.4
    Host shown: 999 closed ports
    PORT    STATE unknown
    49159/tcp open unknown
    MAC Address: 94:XX:XX:XX:XX:XX (Tp-link Technologies)

then I type nmap -O 192.168.1.4 to detect target's OS.

   Starting Nmap 7.70( https://nmap.org ) at 2018-07-04 12:39 UTC
    Nmap scan report for 192.168.1.4
    Host shown: 999 closed ports
    PORT    STATE SERVICE
    49159/tcp open unknown
    MAC Address: 18:XX:XX:XX:XX:XX( Apple )

As you see, I got two different MAC address!

I wonder why this happens, and what technology Nmap uses to detect OS?

Answer 1

Perhaps the remote computer 192.168.1.4 has multiple NICs. This would cause a problem since each NIC has a different MAC address and the response may be sent from different NICs. Or, since each network adapter, like Wi-Fi and ethernet, has a different MAC address, maybe the remote device was using a Wi-Fi connection and then changed to an Ethernet connection (or vice versa).

As for the OS detection, nmap sends TCP and UDP packets to the remote host and analyzes each part of the response packet, and based on fields in the packet, it matches it against known values. More information about this can be found at the nmap OS detection page

Answer 2

Nmap uses packet sniffing to detect responses to its probes for host discovery, port scanning, and OS discovery. Any time a valid response (i.e. one that is likely to have come from the target) is received and has a MAC address in it, the address is recorded. This means that if different probes receive different responses, a different MAC address might be reported. This is a very unusual circumstance, though, since the target MAC would be the same in each instance. Since the OS detection phase runs later than the port scan phase, it would seem that those probes (sent mostly to open ports) are getting different responses than the last probes sent in the port scan phase.

You may be able to force one or the other result by using the --send-eth option. Some platforms are capable of sending both raw Ethernet and raw IP packets, and forcing Ethernet frame building with --send-eth may lock in one MAC address and ensure that responses from the other one are not registered. This is a bit speculative, though, as I haven't traced this particular interaction through the source code.