My next class:
Reverse-Engineering Malware: Advanced Code AnalysisOnline | Greenwich Mean TimeOct 28th - Nov 1st 2024

The Risk of Authenticated Vulnerability Scans

Published: 2019-05-16. Last Updated: 2019-05-16 07:46:51 UTC
by Xavier Mertens (Version: 1)
2 comment(s)

NTLM relay attacks have been a well-known opportunity to perform attacks against Microsoft Windows environments for a while and they remain usually successful. The magic with NTLM relay attacks? You don’t need to lose time to crack the hashes, just relay them to the victim machine. To achieve this, we need a “responder” that will capture the authentication session on a system and relay it to the victim. A lab is easy to setup: Install the Responder framework[1]. The framework contains a tool called MultiRelay.py which helps to relay the captured NTLM authentication to a specific target and, if the attack is successful, execute some code! (There are plenty of blog posts that explain in details how to (ab)use of this attack scenario).
 
Once you deployed all tools, you need to wait for an “interesting” user to connect on the infected system. How to find such kind of juicy users credentials? Most vulnerability scanners propose different scanning modes. The classic one is a non-authenticated scan based on available ports (compare this to a penetration test in "black box" mode). In many organizations, scans are performed in "authenticated mode". This time, the scanner has credentials to connect to targets and is, therefore, able to access more information like the list of installed applications (compare this to a penetration test in "grey box" mode). See the example below with the free scanner OpenVAS[2]:


You can configure OpenVAS to collect information via SSH, SMB, SNMP or even connect to a VMware hypervisor. To achieve this, you need to provide valid credentials that have enough access rights to perform basic tasks on the scanned hosts.  

I was aware of a case where attackers implemented an NTLM relay on a first victim's host and waited for some SMB authentication. The vulnerability scanner used credentials to perform an authenticated scan and its connection details were automatically reused to pivot internally and infect more hosts. Seen that such users have more rights to do their job, it's always an interesting candidate for attackers.

So keep in mind that using security tools could also introduce some new risks! By the way, how to protect yourself against this type of attack? Use SMBv3 and enable SMB signing[2]!
 
[1] https://github.com/lgandx/Responder
[2] http://www.openvas.org/
[3] https://blogs.msdn.microsoft.com/openspecification/2017/05/26/smb-2-and-smb-3-security-in-windows-10-the-anatomy-of-signing-and-cryptographic-keys/
 
 
https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

2 comment(s)
My next class:
Reverse-Engineering Malware: Advanced Code AnalysisOnline | Greenwich Mean TimeOct 28th - Nov 1st 2024

Comments

One way to detect this is to look for logins by the vulnerability scanner service account that are NOT from (source IP) the vulnerability scanner(s).

Craig Bowser
SEC555 Mentor
If we instead use certificate based authentication, this should not be an issue?

Diary Archives