Credential scanning

preethi_r · June 25, 2020, 5:04pm

Hi Team,

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?

I gave my PC credential when setting up the site.

holly_wilsey · June 25, 2020, 6:11pm

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/

preethi_r · June 26, 2020, 10:02am

thank you so much for the suggestion @holly_wilsey . I raised case with them now.

ramreddy_tangella · September 23, 2020, 9:52am

@preethi_r, I’m also facing the similar issues with the authentication on port 135, may I know if you have got any solution from Rapid7.

Thanks,
Ram

aaron_cook · September 25, 2020, 8:44pm

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.

holly_wilsey · September 29, 2020, 2:39pm

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.

anthony_onorati · October 9, 2020, 6:10pm

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).

vanessa_villalpando · October 29, 2020, 4:56pm

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?

holly_wilsey · October 30, 2020, 3:30pm

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.

michael_galhouse · November 4, 2020, 8:44pm

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:

michael_galhouse · November 4, 2020, 8:46pm

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.

david_randolph · November 6, 2020, 9:46pm

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.

david_randolph · November 6, 2020, 10:59pm

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.

syed_sajjad_jaffer_rizvi · December 17, 2020, 7:42am

Hi David,

I am facing same issue, have you got any response from support on this or any workaround

regards

david_randolph · December 17, 2020, 2:05pm

I’m working on getting a session with support where they get on my machine & I show them.

michael_galhouse · January 5, 2021, 11:20pm

Any update on this?

khant_khant · January 12, 2021, 7:54pm

Did it Work?

david_randolph · January 25, 2021, 8:37pm

at one point they mentioned that this was a known bug in the test.

adrian_borlea · February 3, 2021, 5:39am

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.

robert_guglielmo · March 10, 2021, 2:31pm

@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.