This setup raised a question: could we leverage our access to pivot toward more valuable data? To explore this, we created the SHIR configuration on a Virtual Machine in our lab environment and used Azure’s Run Command to modify settings and gain full access to the host machine.
Observing SHIR Credentials with Procmon
Once inside the SHIR host, we ran Procmon to monitor activity as we created a new connection in Azure Data Factory that used the SHIR instance. During this process, we observed the creation of a file named LocalDateSourceCredentials in the following location:
C:\\Windows\\ProgramData\\Microsoft\\Data Transfer\\DataManagementGateway
This file appeared unreadable in a standard text editor. However, using Strings from Sysinternals, we extracted a ProtectedBuffer from within the file, which hinted that it might contain credential data.
Decrypting Protected Data with DPAPI
Based on our findings, we hypothesized that the ProtectedBuffer was encrypted using the Data Protection API (DPAPI), given the Windows environment. DPAPI is commonly used to secure sensitive information on Windows. For those unfamiliar with DPAPI abuses, SpecterOps offers a great blog post that covers it in detail.
With DPAPI in mind, we knew that tools like SharpDPAPI or Mimikatz could be used to decrypt this blob. For simplicity, we chose SharpDPAPI to retrieve the Machine Master Key. Once we had the necessary key, we fed the ProtectedBuffer blob into SharpDPAPI, which successfully decrypted it.
The result was a decrypted key for the integration configured in Azure Data Factory and associated with the SHIR:
Prevention
To mitigate this type of risk, configure connections to sensitive data sources to use Azure Key Vault. Although we haven’t explored in detail how the SHIR instance interacts with Key Vault, securing credentials in Key Vault instead of locally on the SHIR instance could help prevent unauthorized access.
Detection
To detect potential abuses of SHIR instances:
- Monitor for anomalous access patterns on the data sources that SHIR connects to, especially if those credentials appear to be used by unexpected sources.
- Review access logs for unusual activities on the SHIR host itself, which could indicate a compromise or misuse.
Summary
To summarize, the implications of this means entail that a server running SHIR should be protected and considered as a means to gain access to the data sources it has connections for.
If an adversary is able to access the SHIR, it may result in access to credentials that can be used directly to access data sources.