Open IPC $ share

First, let's first understand what is IPC $

IPC $ (Internet Process Connection) is a resource that shares "named pipes". It is a named pipe open for inter-Process communication. By providing a trusted user name and password, both parties can establish a secure channel and exchange encrypted data through this channel to access remote computers. IPC $ is a new feature of NT/2000. It has a feature that only one connection can be established between two IP addresses at the same time. NT/2000 provides the ipc $ function and enables default sharing when installing the system for the first time, that is, all logical sharing (c $, d $, e $ ......) Shared with the system directory winnt or windows (admin $. All of these, Microsoft's original intention is to facilitate administrator management, but intentionally or unintentionally, leading to a reduction in system security.
We often hear people talking about the ipc $ vulnerability and ipc $ vulnerability. In fact, ipc $ is not a real vulnerability, it must be the 'webshell 'placed by Microsoft itself: Null session ). So what is an empty session?

Before introducing null sessions, we need to understand how a secure session is established.
In Windows NT 4.0, a challenge response protocol is used to establish a session with a remote machine. A successful session becomes a secure tunnel through which both parties can communicate information, the general sequence of this process is as follows:
1) The session requestor (customer) transmits a data packet to the session receiver (server) and requests the establishment of a security tunnel;
2) The server generates a random 64-digit number (implementing the Challenge) and transmits it back to the customer;
3) The customer obtains the 64-digit number generated by the server, disconnects it with the password of the account trying to establish a session, and returns the result to the server (for response );
4) The server receives the response and sends it to the local security authentication (LSA). LSA verifies the response by using the correct password of the user to confirm the identity of the requester. If the requester's account is the local account of the server, verify that the local account has occurred. If the requested account is a domain account, the response is sent to the domain controller for verification. When the response to the challenge is verified as correct, an access token is generated and then transmitted to the customer. The customer uses this access token to connect to the resources on the server until the suggested session is terminated.
The above is the general process of establishing a secure session. What about empty sessions?

Empty sessions are Sessions established with the server without trust (that is, no user name or password is provided), but according to the WIN2000 access control model, A token is also required to establish a null session. However, a null session is not authenticated by user information during creation. Therefore, this token does not contain user information, this session cannot send encrypted information between systems, but it does not indicate that the token of the empty session does not contain the Security Identifier SID (which identifies the user and the group). For an empty session, the SID of the token provided by LSA is the S-1-5-7, which is the SID of the empty Session, the username is: anonymous logon (This username is visible in the user list, but it cannot be found in the SAM Database and belongs to the system's built-in account). This access token contains the following disguised group:
Everyone
Network
Under Security policy restrictions, this empty session will be authorized to access all the information authorized to access the above two groups. So what can an empty session be created?

For NT, with the default security settings, you can use a null connection to list users and shares on the target host, share the everyone permission, and access a small portion of the Registry, there is no significant value for use; it is less useful for 2000, because in Windows 2000 and later versions, Only Administrators and Backup Operators have the right to access the registry from the network by default, and it is not convenient to implement it, tools are required.
From this we can see that this untrusted session is not very useful, but from a complete ipc $ intrusion, empty sessions are an indispensable stepping stone, because we can get the user list from it, and most weak password scanning tools use this user list to guess the password, successfully exported user lists greatly increase the guess success rate. This alone is sufficient to indicate the security risks caused by empty sessions, therefore, null sessions are useless. The following are some specific commands that can be used in an empty session:

1 first, create an empty connection (of course, this requires the objective to open ipc $)
Command: net use \ ip \ ipc $ ""/user :""
Note: The preceding command contains four spaces. There is a space between net and use, one after use, and one between the left and right sides of the password.

2. view the shared resources of the remote host
Command: net view \ ip
Explanation: The premise is that after an empty connection is established, you can use this command to view the shared resources of the remote host. If shared resources are enabled, you can obtain the following results, however, this command cannot display the default share.

Share resources in \ *. *
Resource Sharing name type usage comment

-----------------------------------------------------------
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
The command is successfully completed.

3. view the current time of the remote host
Command: net time \ ip
Explanation: You can use this command to obtain the current time of a remote host.

4. Obtain the NetBIOS username list of the remote host (you need to enable your NBT)
Command: nbtstat-A ip
Run the following command to obtain the NetBIOS username list of the remote host:

Node IpAddress: [*. *] Scope Id: []

NetBIOS Remote Machine Name Table

Name Type Status
---------------------------------------------
SERVER <00> UNIQUE Registered
OYAMANISHI-H <00> GROUP Registered
OYAMANISHI-H <1C> GROUP Registered
SERVER <20> UNIQUE Registered
OYAMANISHI-H <1B> UNIQUE Registered
OYAMANISHI-H <1E> GROUP Registered
SERVER <03> UNIQUE Registered
OYAMANISHI-H <1D> UNIQUE Registered
. _ MSBROWSE _. <01> GROUP Registered
INet ~ Services <1C> GROUP Registered
IS ~ SERVER... <00> UNIQUE Registered

MAC Address = 00-50-8B-9A-2D-37

The above is what we often use empty sessions to do. It seems that we can also get a lot of things, but note that the operations for establishing an IPC $ connection will leave a record in the Event Log, whether or not you have successfully logged on. Well, let's take a look at the port used by ipc $?

First, let's take a look at some basic knowledge:
1 SMB: (Server Message Block) Windows protocol family, used for file printing and sharing services;
2 NBT: (NETBios Over TCP/IP) use the 137 (UDP) 138 (UDP) 139 (TCP) port to implement NETBIOS network interconnection based on the TCP/IP protocol.
3. In WindowsNT, SMB is implemented based on NBT, that is, port 139 (TCP) is used. In Windows2000, SMB is implemented based on NBT and port 445.

With these basic knowledge, we can further discuss the port selection for access network sharing:

For the win2000 client (initiator:
1. If NBT is allowed to connect to the server, the client tries to access ports 139 and 445 at the same time. If port 445 has a response, the client sends an RST packet to port 139 to disconnect, when port 455 is used for a session, port 445 is used only when port 139 does not respond. If neither port responds, the session fails;
2. If NBT is prohibited from connecting to the server, the client only attempts to access port 445. If port 445 does not respond, the session fails.

For the win2000 Server:
1 If NBT is allowed, UDP port 137,138 and TCP port 139,445 will be open (LISTENING );
2. If NBT is disabled, only port 445 is enabled.

Our ipc $ session port selection also complies with the above principles. Obviously, if the remote server does not listen to port 139 or port 445, the ipc $ session cannot be established.

The ipc pipeline was originally designed by Microsoft to facilitate remote management by administrators, but it seems easier for intruders to open the ipc pipeline to hosts. Through the ipc pipeline, We can remotely call some system functions (mostly implemented through tools, but corresponding permissions are required), which is often the key to the success or failure of intrusion. Without such considerations, the ipc pipeline has provided great support to intruders and even become the most important means of transmission, therefore, you can always see some friends on major forums who cannot open the ipc pipeline of the target machine, but cannot help. Of course, we cannot ignore the important role that permissions play in the ipc pipeline. You must have tasted the embarrassment of empty sessions. If you do not have the permissions, you cannot start the pipeline. However, once an intruder has the administrator privilege, the ipc pipeline will display the side of the vulnerability.

The fastest IPC $ intrusion method
20171100000000xec.exe \ IP-u Administrator Account-p password cmd
\ With this tool, we can get the shell in one step

OpenTelnet.exe \ server administrator account password NTLM Authentication Mode port
\ You can use it to conveniently change the authentication method and port for telnet, so that we can log on

[2]
There is no second step. After you get the shell in one step, you can do everything. You can use winshell to install backdoors, use ca to clone the shell, use 3389.vbeto open the terminal, and use win2kpass to record the password, in short, there are a lot of good tools. If you choose one, I won't say much about it.

What are you waiting?

Next, we will introduce some methods to prevent IPC $ intrusion.

1. prevent the establishment of an IPC $ null connection

Modify the Registry HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ LSA \

Value Name: RestrictAnonymous type: dword Value: 1

Click to View Details. Click to download the NoIPC. REG file.

Ii. Disable default share of C $ AND OTHER SYSTEMS

Modify the Registry HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \
LanmanServer \ Parameters

Value: AutoShareServer type: dword Value: 0

Click to View Details and click to download the NOShare. REG file.

3. Stop server Service (disable IPC $ Service)
Net stop server/y (the server service will be restarted after the restart)

4. Shielding port 139,445
Without the support of the above two ports, you cannot establish ipc $. Therefore, blocking port 139,445 can also prevent ipc $ intrusion.

1. Port 139 can be blocked by disabling NBT
Local Connection-TCP/IT properties-advanced-WINS-select 'Disable NETBIOS on TCP/IT'

2. port 445 can be blocked by modifying the Registry
Add a key value
Hive: HKEY_LOCAL_MACHINE
Key: System \ Controlset \ Services \ NetBT \ Parameters
Name: SMBDeviceEnabled
Type: REG_DWORD
Value: 0

5. Install a firewall to filter ports

6. Set a complex password to prevent the password from being poorly cited through ipc $. I think this is the best way to enhance security awareness, which is much safer than Constantly patching.