Typical autumn day, through the window you can only see a gray sky. It is the typical day in which you believe that nothing strange is going to happen. Suddenly, our surveillance system alerts anomalous connections: a user has tried to connect against IP addresses of unknown origin. These IP addresses are public and, according to the configuration established in the organization, any HTTP connection to the outside must pass through a proxy.
The connections are searched in the proxy logs and are not found, so this user has tried to connect directly, ignoring the configuration of the system.
Connections take place from 06:52 am to 07:09 am.
In addition, it can be seen that not only have they tried to communicate through port 80, but they have also tried through other ports such as 139, 445 and 97.
Many doubts arise. Has an email with an attachment capable of evading all organizational barriers arrived in their mailbox? Have they visited a website with a watering hole? Have they connected an infected pendrive?
The local antivirus on their computer has not detected anything strange.
In the investigations on these IP addresses, there is not much to be found except that they belong to either Akamai, or an alleged Chinese telecommunications company:
Analyzing the traffic capture shows that there has not been an effective connection:
Now it’s time to find out why those connection attempts have occurred. To do this, an image of the computer’s RAM memory and a triage with the CyLR tool are prepared.
It begins by analyzing the memory capture. Normally I usually consult a Volatility cheat sheet, but I have automated the basic commands for future occasions:
There is no trace of the connections or evidence linking these connection attempts in the memory image.
We proceed to analyze the MFT with mftdump, exporting the information to CSV format for a better reading.
Dimensioning by the day and time of the connections you see the modification of a file that draws attention:
\Windows\System32\winevt\Logs\Microsoft-Windows-WPD-MTPClassDriver%4Operational.evtx
This log refers to an MTP (Media Transfer Protocol) driver. With the Windows Event Viewer, we proceed to analyze said Event Log:
This is when a new IP address comes into play that has nothing to do with the range assigned by DHCP in the organization. The network range is investigated again in the memory dump.
When looking at the strings generated with Volatility the previous network range:
You can see an identifier. It seems that the user has connected a USB device.
In a quick Google search, on the first Microsoft Web link, it specifies that it is a network device by usb:
Information to contrast with in the DLP (Data Loss Prevention) log of the endpoint and see what kind of device they have connected:
It is a mobile device from the Xiaomi brand, specifically the Mi 5 model.
In addition, if the Usb Tethering option is enabled, the device is automatically installed on the computer and acts as an access point to connect to the Internet:
As a test I try to connect this same model on a computer with Windows and looking at the network configuration I can see that the range assigned by the terminal is familiar:
This practice is quite common when the user wants to bypass the restrictions of a proxy in an organization, doing Tethering and using for example a portable browser.
A quick measure to avoid this type of behavior would be to disable the possibility of automatically installing the drivers each time a new device is connected:
But in a very large corporate environment it can cause problems (inability to connect and use printers, pen drives, etc.)
Therefore there is a much better option which is to disable the use of network devices by usb. For this you have to modify the registry entry:
And change the “start” value to 4.
There is a problem, because if a USB network device has never been connected to the computer, this registry entry will not exist. The solution is to manually create the log entry:
File.reg is created that contains:
And execute file.reg
Note: The driver C:\Windows\system32\DRIVERS\usb8023x.sys does not exist, but in the tests that I have done, it is not necessary to copy such file since manually entering the single registry is enough.
