Category Archives: Cyber-Ark

  • 0

Locking Down the Remote Vendor Attack Pathway Through Privileged Account Security

Category : Cyber-Ark

Remote vendors are everywhere, and they’re not limited to help desk services, storage and application service providers or other IT-focused MSP’s. Let’s not forget about the other vendors a company typically works with – law firms, public relations firms, HVAC, trucking companies, supply chain vendors, services companies – the list goes on. Organizations both large and small grant third-party vendors with access to their network and applications as a necessary means to do business. However, in doing this, they also introduce a potential new pathway for cyber attacks.  This pathway can be especially vulnerable given that the security controls for third-party vendors are not typically held to the same standards as those followed internally by an organization.

Locking down privileged credentials for remote vendors is a critically important step in minimizing the attack surface. A recent report showed that 67 percent of organizations had experienced a data breach that somehow tied back to a third-party vendor. This is a clear indication that attackers continue to look at third parties as an easy way to gain a foothold into a network, move laterally, escalate privileges and eventually gain access to their target assets. Before engaging with third-party vendors, organizations should fully vet each one and consider the potential risks the vendor might introduce to their business.

Mitigating Risks Associated with Remote Vendors

The first step in mitigating risks associated with remote vendor access is an obvious one – identify all third parties that have access into your internal systems. This can represent a complex ecosystem for some organizations. The number of vendors given access to systems and applications continues to increase year-over-year widening the threat landscape for attacks – and somehow remote vendor access management is still not considered to be of high priority for many organizations. CyberArk has a free tool that discovers privileged user accounts and credentials provisioned by your organization as well as those created by third parties (that perhaps you didn’t even know existed).

Organizations should be able to safely provide their remote vendors with access to the resources they need without exposing any user credentials, and at the same time, without introducing too many hoops for them to jump through. Storing passwords, SSH keys and other associated credentials with your third-party privileged accounts in a single, secured vault is how you can provide the required level of access without burdening the end user. Keeping a close eye on all privileged activity within your environment is accomplished through session isolation, monitoring and recording.  Doing this both secures and assigns all internal and external users with a baseline-level of accountability. More importantly, by adding this separation layer between the end user and target systems, you enable your users to successfully complete their tasks without directly accessing critical systems. To the end user, everything appears to be totally normal, but if an attacker were to get into the network, they wouldn’t be able to move laterally across the environment or spread harmful malware to an organization’s systems.

Putting the Right Tools in Place

What about those regular and mundane manual tasks that can be inadvertently damaging to the business? Remember that recent public cloud outage where a routine debugging exercise went haywire leading to a six hour meltdown caused by one simple little typo? Automated privileged task management (both in the cloud and on-premises) safeguards your remote vendors and internal users alike by automating manual, sometimes critically sensitive privileged tasks while simultaneously improving workflow productivity. How would you respond to high-risk commands and tasks that can lead to a mix up like above example? With the right analytics tools in place, you can pre-define default, high-risk commands that are unique to your organization and automatically notify the necessary security teams to take action when those commands have been executed. Furthermore, these tools can help you to detect and even disrupt in-progress attacks through both heuristic and advanced behavioral-based threat detection capabilities.

The CyberArk Privileged Account Security Solution can help minimize the threat associated with third party vendor management. Controlling and auditing each vendor’s access can be resource-intensive, causing meaningful activities to get lost in the shuffle. Therefore, it’s recommended to start with the areas that have the highest risk, such as access, privileged access and critical assets. CyberArk enables organizations to securely lock down remote vendor access and put the necessary security controls in place to enable third parties to safely complete tasks.



  • 0

Balance Speed & Agility With Security & Compliance

Category : Cyber-Ark

Developers are shifting to a DevOps delivery model to increase the speed of delivering new code and features to the market. But as a security and IT practitioner, you want security-first, enterprise-wide solutions that support your development teams without compromising on security.

This webinar explains why it is important to:

  • Secure and manage secrets used by machines (e.g. micro-services, applications, scripts, CI/CD tools, hosts, etc.) and privileged users throughout the DevOps pipeline.
  • Integrate with DevOps Toolchain to secure and manage secrets used by CI/CD tools such as Jenkins, Docker, Puppet, Chef, etc. to balance speed and automation while still significantly reducing the threat surface.
  • Help security and compliance professionals to automatically secure and manage secrets throughout the DevOps pipeline by implementing built-in privileged account best practices across all environments (cloud, on-premises and hybrid environments).

Download now

  • 0

Privileged Access Management, A Matrix Approach for Account Ranking and Prioritization

Category : Cyber-Ark

Throughout the course of my six years in helping KPMG clients with their Privileged Access Management programs, there has rarely been a simple answer to the critical questions of exactly which privileged accounts in an environment should be integrated first (e.g., application/infrastructure/personal accounts), and exactly how we should control each type of privileged account. The ways an organization can control privileged accounts using a solution like CyberArk can vary greatly (e.g. vaulting, password rotation, brokering, etc.).

A common approach to password management includes treating all vaulted credentials with the same level control measures; this is typically a symptom that indicates a lack of a risk-based approach to assigning criticality to accounts. Alternatively, we also see cases of wild inconsistencies in the way passwords are managed, typically leaving it up to the individual platform owners to pick and choose the right security controls for them. This typically an indication of a lack of defined PAM standards that can be applied enterprise-wide. When developing strategies and roadmaps for KPMG clients, our teams apply an “Account Criticality Matrix” to help answer these questions. This matrix is designed to help standardize the way we rate and weigh the criticality of a given account.  It includes a set of predefined criteria that we tailor to meet the unique needs of each organization. Example criteria in the Account Criticality Matrix include:

*   Number of individuals that have access to a given privileged credential
*   Frequency of account usage
*   Potential to access sensitive data
*   Scope of privilege across single/multiple systems or platforms
*   Control level granted

Based on the numerical scoring derived from the Account Criticality Matrix, we then begin to build a profile of what an organization would consider a “high-risk” account versus a “low-risk” account.  This profile helps on numerous fronts.  First, it allows for consideration of account types that typically would not be considered as true “privileged” accounts.  For example, many application or service accounts are inadvertently excluded from management in organizations due to a lack of understanding of enterprise privileged account definitions by the application owner.  In the absence of pre-defined account prioritization criteria, those owners are left to decide what constitutes a “privileged” account or not.  Many will opt for the latter without prescribed guidance.  The matrix will allow an organization to take any account type and provide a standardized metric to determine whether it meets the criteria to be integrated into CyberArk.

The second benefit is the standardization of account controls across the organization based on the calculated account criticality.  Depending on licensing and hardware limitations, recording all privileged accounts may not be feasible.  Based on a pre-defined policy, an organization could mandate that only “high” rated accounts require dual control and PSM recording, but periodic password rotations of “medium” rated credentials are sufficient.

Thirdly, combining knowledge of “high” severity accounts and implementation effort can provide a window to prioritization of the path of integration.  When various stakeholders ask why the decision was made to start with default local accounts first and not their specialized application, you can point them not only to the fact that those accounts rated as high based on the user base, scope of privilege, and access granted, but also because the implementation effort was lowest for those accounts.



  • 0

The Art of the Ethical Hack: A Q&A with CyberArk’s Head of Red Team Services

Category : Cyber-Ark

Today’s highly motivated cyber attackers continually hone their skills. After all, their job is to know your network better than you do, exploiting even the smallest vulnerability to carry out a mission. In order to stay a step ahead of advanced maneuvers, it’s critical to adopt an attacker’s mindset. For many organizations, a Red Team plays an integral role in continuously improving security practices.

CyberArk Red Team services provide a safe way for security operations teams to test their ability to effectively defend against cyber attacks. The CyberArk Red Team uses a variety of tactics, techniques and procedures (TTPs) that are used in real world attacks to help clients uncover vulnerabilities, test security procedures and identify areas of improvement.

We recently spoke with Shay Nahari, our Head of Red Team Services, to learn more about the process and goals of simulated attacks. Here are some highlights from our discussion. Additional information about the Red Team is available here.

Q: Why do organizations request adversary simulation?

A: Organizations hire us to test their teams’ ability to detect and respond to targeted attacks against their infrastructure. By thinking and acting like real attackers, we give our customers a way to face a real attack and learn from it.

Q: How do you prepare for a simulation?

A: Before any simulation, we focus on reconnaissance, trying to learn as much as we can about the target organization, its employees and the security measures in place. To do so, we employ a number of methods, such as collecting information from public sources like LinkedIn, Shodan and other lesser-known sources. Armed with this information, we typically utilize custom malware to evade their security measures, then either exploit a vulnerability, an external server or use social engineering to gain an initial foothold in the network.

Q: How easy is it to breach a typical network? And what do you do once you get inside?

First, there are always ways to get inside a network. That’s why it’s important for organizations to change their mindsets around cyber attacks. It’s not a matter of “if” but a matter of “when.” Organizations have to adopt an “assumed breach” mindset – assume that one (or more) of their resources is already compromised. 

Once we’re inside, we always try to exploit built-in trust as a first step. Trust usually translates to some type of credential – passwords, hashes, SSH keys, tickets.  We can abuse this trust to impersonate real users and typical user behavior, which makes it very hard for the defenders to detect the intrusion.

Q: What happens after you breach a network? 

A: Once we have a foothold in the network, we take time to familiarize ourselves with our surroundings. At this point, most of the information we need can be gathered by abusing inherent trusts in the target environment, without necessarily requiring admin rights. For example, with standard user privileges, we can query the Active Directory and learn the network topology, map out users and group membership, and also see what privileges users have within the network. We can see their last login time, where they logged in to, and with what privileges.

At this point, we can build a map of the network and create an attack path. During these simulations, we ideally only target internal resources that can either help us escalate privileges or that have the access to the “crown jewel” we’re after – whether it’s financial, intellectual property or something else.

In Windows environments, AD contains a lot of useful information. Even if my “crown jewels” aren’t in the Windows environment, user group and system information can be extremely helpful in mapping out the most direct attack path.

Q: What happens after you establish an attack path?

AOnce we have an attack path, we need to start pivoting in the network. Before we can do this, we need to escalate privileges or abuse some sort of inherit trust on the local target. Once we do that, we can start looking for passwords, hashes, SSH keys, tokens, Kerberos tickets, or anything else that we can leverage for pivoting. Credentials are everywhere. Unless you maintain very strict operational security, one remote login can allow me to take over your entire AD forest.

Next, we try to “live off the land” – which means we try to abuse native tools in order to reuse the credentials we’ve found. With every new system we compromise, we repeat the process, which in turn, allows us to gain access to another set of machines, until we’re able to gain domain admin. Once we achieve domain admin, the main goal is to persist and stay hidden in the network until we can reach the “crown jewels.”

Q: How do you stay hidden?

We try to make sure our actions generate the fewest and smallest footprints possible. For example, WMI or PowerShell remoting are much better options during lateral movement because they leave much less forensic evidence than, let’s say, PSexec.

We leverage native tools to avoid defensive tactics. For example, PowerShell gives you access to the entire .NET language, and other built in tools allow you to compile code natively on Windows without introducing external binaries on the system. By avoiding touching disk and injecting into memory, you can make hunting and IR much harder for the defender.

Q: So how can organizations stop this?

A: It’s important for organizations is to have an “assume breach” mindset regarding their security posture. Assume your internal network is as hostile as your external network.  One major way organizations can reduce risk is by limiting internal users’ abilities to gather information from AD. In most cases, you can limit what types of information regular users are able to gather. If you can limit what attackers can learn, it’s much harder for them (and us!) to build an attack path.

Additionally, use two-factor authentication everywhere you can. Rotate and randomize passwords on a regular basis to make cracking them time-consuming for the attacker.

Avoid giving standard users local admin rights, make local admin accounts unique, and keep privileged accounts to a bare minimum. By doing that, you’re significantly raising the bar and making lateral movement much harder for the attacker.

It’s also important to understand what is normally running on your network – and create baseline of internal traffic. Without a baseline, you don’t know if what you are seeing is suspicious or not. Lastly block machine-to machine-communication, to the greatest extent possible.



  • 0

Cloud Security Use Cases – A Panel Discussion

Category : Cyber-Ark

July 25 / 2PM EST

Insights via use cases and lessons learned: Chris Smith
This session offers the unique opportunity to learn first-hand about deployments related to privileged account security in cloud environments. Our panelist of CyberArk system engineers will provide insight related to the use case/business need, technical solution and lessons learned. Use case examples include securing:

  • Cloud infrastructure (e.g., AWS Management Console)
  • Applications and other infrastructure (databases, OS, etc.) on public and private clouds
  • Commercial SaaS applications

Register here!

  • 0

Secured Credential Scans: When Vulnerability Management is Powered by Privilege

Category : Cyber-Ark

In order to attain comprehensive, enhanced results, vulnerability scanners require credentials every time they need to perform a trusted scan. But hard coding/storing credentials within a vulnerability solution configuration file or code can introduce risk into the process – leaving the credentials exposed to possible compromise. As such, organizations need to enable intelligent vulnerability-driven access control enforcement. To eliminate the need to store a copy of privileged credentials in the™ solution, Tenable and CyberArk have joined forces to secure, manage and rotate these credentials.

In this session, we’ll introduce the how the integration automatically:

  • Synchronizes credentials within the Tenable scanners and the target systems, and secures these powerful credentials according to your security policies.
  • Authenticates vulnerability scanners before granting credentials and privileged user access to a specific machine to help maintain the IT environment integrity.
  • Blocks user access to specific resources that shows high-risk vulnerability scores until the vulnerability is resolved (or allows privileged user access via a secured channel).
  • Securely tracks resources and vulnerabilities while accommodating dynamic assets like cloud and containers.

July 18 / 2PM EST

Register now!

  • 0

Employees Behaving Badly: The Everyday Insider Threat

Category : Cyber-Ark

If you’ve ever worked in an office, you know that you can’t access any data you want. Some files are locked away from the everyday employee: out of sight and out of mind. Whether it’s your boss’ bonus, private emails between colleagues, company financials, performance reviews or information about yet-to-be-launched products and services, access to information is limited.

A lot of people are quite comfortable with this. However, a new survey we carried out found that over half (52%) of UK office workers would access sensitive company data if they knew they wouldn’t get caught. In fact, far from being a moral issue, one in five (21%) cited a lack of technical skills as holding them back from attacking their employer.

So, what could tempt employees into accessing company information?

The survey revealed a mix of motives, from wanting to make sure they were being rewarded fairly, to having suspicions the company was unethical or corrupt, to straightforward curiosity and office gossip. What was clear, though, is that very unhappy employees are twice as likely to want to spy on company information than their happier peers.

While disgruntled or angry employees only account for 26% of insider attacks, according to Forrester[i], they are the source of some of the most costly and difficult attacks to detect. The 2016 Sage Group data breach is just one example of an employee using an internal login to steal company data, temporarily rocking the reputation of the company and, indeed, its share price.

How should employers stop malicious insiders in their tracks?

First, we should recognise that most respondents weren’t out to deliberately cause the company harm. The majority simply wanted to get their hands on information about themselves and engage in idle gossip; just 2% said they would be prepared to sell information to competitors for financial gain or to blackmail their boss.

The basic rule in defending against malicious insiders is to address the threat, not the individual. Privileged access – not people – is the true insider threat. The process of securing privileged accounts should be on-going with continuous evaluation and adjustments to improve security as the business and threat landscape changes.

To effectively protect against insider threats, organisations should minimise user privileges to reduce the attack surface, lock down privileged credentials, and control and monitor privileged accounts, which are consistently targeted by insider attackers.

The threat from outside…..

While this survey highlights the potential mischief that employees can get up to without proper access controls, it’s also an important reminder of the threat that cyber attackers posing as insiders could pose.

If more than half of everyday workers would be prepared to access sensitive data, it’s not hard to imagine the damage a cybercriminal with advanced skills and malicious intentions could cause. They have no loyalty to the company and are more likely to be driven by financial or political motives over innocent curiosity.

Security teams have long known that one of the most effective ways for attackers to access sensitive data is to masquerade as a legitimate insider – using existing privileged credentials to achieve broad, unfettered access to a company’s most valuable assets. With cyber skills advancing all the time, and cybercriminals hiding behind valid credentials to avoid being caught, companies must be more alert than ever to stop unwanted insiders in their tracks and protect their most valuable information.

[i] “Understand The State Of Data Security And Privacy: 2015 To 2016”, Forrester Research, Inc., January 8, 2016


Author: Matt Middleton-Leal VP for the UK, Ireland and Northern Europe at CyberArk

  • 0

CyberArk Labs: Ransomware

Category : Cyber-Ark

Ransomware is a type of malware designed to infect machines, encrypt files and hold the needed decryption key for ransom until the victim submits the required payment. In 2015, this attack method was used to successfully extort over $400 million from victims. This paper documents research conducted by CyberArk Labs to better understand ransomware and evaluate what mitigation strategies could be most effective. One of the key findings was that when local administrator rights were removed and application control policies were in place, 100 percent of ransomware samples were prevented from encrypting files.

Download this report to learn about the research methodology, ransomware behaviors and mitigation strategies that were considered.


  • 0

5 Ways to Address the General Data Protection Regulation (GDPR) With CyberArk

Category : Cyber-Ark

On May 25, 2018, the General Data Protection Regulation (GDPR) will be enforced across the European Union (EU). This regulation aims to extend the rights of individuals residing within the EU to better control and protect the use of their personal data in the evolving digital landscape.  It’s also an attempt to strengthen, simplify and harmonize the data protection and privacy laws across Europe. GDPR requires any organization whose business involves either collecting or processing any EU citizen’s personal data – not just those that are located within the member states of the EU – to maintain compliance. Non-compliance risks both steep financial penalties and reputational damages. The CyberArk Privileged Account SecuritySolution protects the privileged credentials that enable access to the systems and applications that contain and process highly sensitive personal data.

Here are five ways CyberArk solutions can help organizations address GDPR:

  1. Protect and Monitor Access to Sensitive Personal Data

Attackers and non-authorized users target privileged accounts as a means to gain access to critical systems and applications that hold sensitive personal data. CyberArk enables organizations to perform live monitoring and session recording to quickly identify unauthorized, suspicious and high-risk activity. With CyberArk, organizations can control privileged access to systems and applications that hold and process personal data, which is essential for your GDPR data protection program.

  1. Secure Processing through Least Privilege Enforcement

Organizations are required to limit the risk of unlawful destruction, loss, alteration, unauthorized disclosure of, and most importantly – access – to personal data. CyberArk provides a unified access control solution to regulate and monitor the commands super-users can run based on their roles and the specific tasks they manage. The solution limits the use of privileged rights within the organization, enables them to segregate administrator duties and enforces least privilege policies for their super-users.

  1. Detect and Respond to Breaches Early in the Attack Lifecycle

GDPR requires unauthorized access to personal data to be reported within 72 hours of detection. CyberArk provides threat detection solutions that will not only detect malicious activity in real-time, but can contain the threat at the earliest stage of the attack lifecycle – before the attacker is able to gain access to personal data. The solution features an analytics engine that leverages statistical modeling, machine learning, user behavior analytics, and deterministic algorithms to detect attackers and malicious insiders navigating the network. As a result, incident response teams now have the additional time they need to stop the attacker before they get to their end target.

  1. Security Controls and Procedures Risk Assessment

CyberArk has a dedicated Red Team that provides a safe way for security operations teams to test their ability to effectively defend against cyber attacks. This team uses a variety of tactics, techniques and procedures used in real world attacks to help clients measure the risk to critical assets, uncover vulnerabilities, test security procedures and identify areas of improvement.  This wide-ranging assessment will help demonstrate if the security measures and mechanisms in place can help guarantee the protection of personal data and demonstrate GDPR.

  1. Minimize Risk Against Non-Compliance

In the event of a breach, each organization and its business partners need to be able to prove that they’ve met their obligations – and in some cases – determine which party is at fault. So the question then becomes: who has access and to what systems and applications do they have access? CyberArk’s free Discovery and Audit (DNA) tool helps organizations discover privileged user and application accounts in their environments, including those used by third-party users. The tool produces a full report including a list of accounts and associated credentials as well as current account status with regard to your security policies. Furthermore, CyberArk solutions provide detailed logs and audit trails that capture privileged account activity for both internal users and third-party vendors alike. The log files are stored securely in order to prevent manipulation. Audit trails are searchable to aid in the event of forensic investigation or litigation from data subjects.

The core of GDPR is all about data protection by design and by default – CyberArk is all about security by design and by default. By locking down access to sensitive systems and applications, you secure control of who and what has access to personal data. Research shows that most organizations will not be compliant when GDPR officially goes into effect. Given the potential fines upwards of €20 million, impact on customer loyalty, future loss of revenue, brand damage, etc., it makes good business sense to address GDPR requirements urgently. For organizations that have a strong privileged access management strategy in place today, this conversation is already top of mind for CISOs, compliance officers, legal and IT professionals.



Author: Corey OConnor

  • 0

GhostHook – Bypassing PatchGuard with Processor Trace Based Hooking

Category : Cyber-Ark

In this article, we’ll present a new hooking technique that we have found during our research work.

Hooking techniques give you the control over the way an operating system or a piece of software behaves. Some of the software that utilizes hooks include: application security solutions, system utilities, tools for programming (e.g. interception, debugging, extending software, etc.), malicious software (e.g. rootkits) and many others.

Please note, this is neither an elevation nor an exploitation technique. This technique is intended for post-exploitation scenario where the attacker has control over the asset. Since malicious kernel code (rootkits) often seeks to establish persistence in unfriendly territory, stealth technology plays a fundamental role.

Technical Description

The GhostHook technique we discovered can provide malicious actors or information security products with the ability to hook almost any piece of code running on the machine.

Let’s start by explaining the primary technology involved in this technique, Intel® PT:

Intel® Processor Trace (Intel PT) is an extension of Intel® Architecture that captures information about software execution using dedicated hardware facilities that cause only minimal performance perturbation to the software being traced.

This information is collected in data packets. The initial implementations of Intel PT offer control flow tracing, which generates a variety of packets to be processed by a software decoder.

The packets include timing, program flow information (e.g. branch targets, branch taken/not taken indications) and program-induced mode related information (e.g. Intel TSX state transitions, CR3 changes). These packets may be buffered internally before being sent to the memory subsystem or another output mechanism that is available in the platform.

Debug software can process the trace data and reconstruct the program flow. Here’s a list of a change-of-flow instructions which Intel PT traces:


Type Instructions
Unconditional Direct Branch JMP (E9 xx, EB xx), CALL (E8 xx)
Indirect Branch JMP (FF /4), CALL (FF /2)
Near Ret RET (C3, C2 xx)


Intel PT was initially released as part of “Broadwell” (5th-generation) CPU and was expanded on “Skylake” (6th-generation) CPU.

So basically, Intel PT provides low overhead hardware that executes tracing on each hardware thread using dedicated hardware (implemented entirely in hardware) in the CPU’s Performance Monitoring Unit (PMU). Intel PT can trace any software the CPU runs including hypervisors (except for SGX secure containers).

This technology is primarily used for performance monitoring, diagnostic code coverage, debugging, fuzzing, malware analysis and exploit detection.

There are three types of tracing:

  1. Tracing of the entire user-mode/kernel-mode (current privilege level).
  2. Tracing a single process (Page Map Level 4).
  3. Instruction Pointer tracing, and this is what we will take advantage of.

To enable tracing, all you have to do is set the proper values inside the IA32_RTIT MSRs according to the tracing type.

Although this technology can be used for legitimate, valuable purposes, one can also take advantage of the buffer-is-going-full notification mechanism to try to take control of a thread’s execution.

The basis of this proposed technique is to make the CPU branch to our piece of code. How can we achieve that with Intel PT?

  1. Allocate an extremely small buffer for the CPU’s PT packets.

This way, the CPU will quickly run out of buffer space and will jump the PMI handler.

The PMI handler is a piece of code controlled by us and will perform the “hook”.

The PMI handler is invoked when the buffer is full or about to be full and can be registered via:


HalSetSystemInformation(HalProfileSourceInterruptHandler, sizeof(PMIHANDLER), (LPVOID)&amp;hookroutine);


  1. Start the Intel PT to trace a critical range of code in the kernel. For example, the LSTAR MSR, which is the system-call entry point of the kernel. It’s address can be obtained as follows:


ULONG64 LSTAR = ((ULONG64(*)())"\xB9\x82\x00\x00\xC0\x0F\x32\x48\xC1\xE2\x20\x48\x09\xD0\xC3")();


This will produce a naked function with the following instructions:

As mentioned, LSTAR is the kernel’s RIP SYSCALL entry (MSR entry 0xc0000082) for 64-bit software.

So basically, we will intercept the nt!KiSystemCall64 function, which is the entry point for service functions on Windows, until the end of the nt!KiSystemServiceUser.

Once a user-mode (SYSCALL) or a kernel-mode (ZW functions) thread will branch inside this code region, the CPU will trace its execution.

  1. As mentioned before, we are allocating a tiny buffer for the CPU to get it filled almost immediately. We can also use the PTWRITE instruction to make it more precise. PTWRITE will allow us to write data to a processor trace packet, and once the buffer is full, the CPU will interrupt the execution and will call the PMI handler (controlled by us) in the context of the running thread. It is possible to completely alter the execution context at this point, which is exactly the same as what one could do via traditional opcode-replacement-based patching for a given location. Proof of Concept:

The technique described above, in the current implementation, will result in a race-condition manner. This stack trace demonstrates hooking the service function nt!NtClose, called by a user-mode application.

The same thing can be done for example to an IDT routine:

Registering to PMI is transparent to the current PatchGuard implementation. Because this technique uses hardware to gain control of a thread’s execution and kernel code/critical kernel structures aren’t being patched, it would be extremely difficult for Microsoft to detect and defeat this technique. Thus, the proposed method should be preferable (despite adding significant complexity to the implementation). Moreover, the suggested technique should be future proof and reliable across kernel versions.

Microsoft’s response:

The engineering team has finished their analysis of this report and determined that it requires the attacker already be running kernel code on the system. As such, this doesn’t meet the bar for servicing in a security update however it may be addressed in a future version of Windows. As such I’ve closed this case.”

Microsoft does not seem to realize that PatchGuard is a kernel component that should not be bypassed, since PatchGuard blocks rootkits from activities such as SSDT hooking, not from executing code in kernel-mode.


Author: Kasif Dekel