This is explained in the Virtualbox manual. Since your VM is a Virtual Machine, it runs on hardware that does not actually exist, and sees a network containing equally virtual other nodes. The manual above contains the following:
In NAT mode, the guest network interface is assigned to the IPv4 range 10.0.x.0/24 by default where x corresponds to the instance of the NAT interface +2. So x is 2 when there is only one NAT instance active. In that case the guest is assigned to the address 10.0.2.15, the gateway is set to 10.0.2.2 and the name server can be found at 10.0.2.3.
And a few lines later:
For network booting in NAT mode, by default VirtualBox uses a built-in TFTP server at the IP address 10.0.2.4.
So the IP addresses that the guest VM sees as 10.0.2.2, 10.0.2.3 and 10.0.2.4 are addresses for virtual nodes that Virtualbox maintains on the virtual network to which the guest VM believe that it is connected; the guest VM itself is awarded IP address 10.0.2.15 on that network.
All of this happens within the entrails of Virtualbox; the host operating system (Windows 7) is completely unaware of it. When the guest VM sends an IP packet with target address (for instance) 10.0.2.3, the packet is sent on the virtual network interface: the guest VM sends an I/O request on that "hardware" (with an
out opcode); the opcode triggers a CPU exception trapped with Virtualbox, which then sees the packet contents (they are in RAM) and acts as if a network interface really existed. From the packet contents, Virtualbox notices that it is meant for one of its virtual nodes, and computes a response packet, puts it in the RAM buffer that corresponds to the buffer for the virtual network interface of the guest, and triggers an interrupt request for the guest, there again as if there really was a network card able to warn the guest CPU about incoming data. Everything about virtual machines and emulation is smoke and mirrors, and this includes the whole virtual network that the guest VM is part of.
From the point of view of that Windows, there is only a process (Virtualbox) which possibly issues network-related system calls; the 10.0.2.x addresses are invisible to it.