I am trying to scan my asset and could see only partial credential success. port 135 is failing and port 445 is success. I just tried to create new site just with my IP and tried to test credentials for port 135, It is throwing the error "java.util.concurrent.ExecutionException: com.hierynomus.smbj.common.SMBRuntimeException: com.hierynomus.protocol.transport.TransportException: java.io.EOFException: EOF while reading packet " . When i tried to test the credentials for port 445, it is showing authentication success. Can you guys help me in this?
Hi @preethi_r! This case would be best handled by our Support team. They’ll be able to better answer questions regarding credential testing. You can open up a case here: https://r7support.force.com/
Port 135 authentication has been giving us issues for a while.and so far support hasn’t been able to help. It is still doing this for some machines but others work fine even though they are configured the same.
We have some info here on requirements for Windows authentication, and this is the best place to start/double check that everything’s configured as specified. This is generally tough to troubleshoot though, because it often comes down to some type of local configuration that’s impacting auth.
I had a very similar issue which Rapid7 support helped me troubleshoot. We were relying on port 135 for Windows OS fingerprinting because CIFS (Port 445) stopped detecting Windows OS versions after we disabled SMBv1 on our Domain, even though authentication on 445 was successful.
Our solution was to get 445 working again by enabling the Remote Registry service on our Windows endpoints (This was disabled by default).
Question is there a difference between Results in full credential success vs. Partial. I did a comparison and can’t seem to find any more vulnerabilities from partial to full; and enabling WMI is just creating risk in my mind. Please let me know if I’m wrong? Is there documentation anywhere that states partial is okay as long there some success?
It’s possible for sufficient data collection and vulnerability analysis to occur with partial credential success. One thing you can do to help further confirm this is review the fingerprint certainty. This is a value between 0 and 1 that gives you an idea of the degree of confidence in the info a scan can obtain from an asset. In general though, full credential success is going to be most likely to give the most accurate picture of an asset and its vulnerabilities.
I’ve had the same issue. Multiple interactions with support did not resolve, including their suggestion of enabling Windows services in the scan template. At some point they suggested that Defender ATP could be blocking, but I’m not so sure. On the plus side, during my interactions with support, I learned of this feature, which is a useful workaround if you’re running the agent and having trouble with partial credential status on Windows:
In my experience, the partial credential success only results in an external scan (mostly protocol misconfigurations). I get no missing patches or related software vulns when partial credential success occurs.
I opened a case yesterday about the port 135 failure. I did a wireshark & the scanned machine is returning an RPC bind_nak with “protocol version not supported”. I can’t tell much else about the problem.
Unfortunately the complimentary scanning doesn’t seem to work with the policy module which is what I’m trying to get working right now.
I think there may be an inconsistency in the testing of port 135. I did some more digging & it looks like something that isn’t an RPC bind packet is being sent from IVM to the scanned host. That’s then being rejected, the connection gets closed, and we get that weird EOF message.
I would be curious to see the results of a test of port 135 that succeeds somewhere & what the wireshark of that looks like.
There have been a lot of issues with user locking out because of some ports. Unfortunately, we were not able to capture the port, but seems that recreating the user with other name fixed it for some domains not for all.
@support_rapid7 Any update on this? I have customers that are failing on 135 and we can not seem to figure the issue out. FW rules are allowed. What is the key factors to getting this to work? 445 is working just fine. 135 is not.
