Category Archives: Cyber-Ark

  • 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

  • 1

Privileged Account Security Inside Industrial Control Systems(ICS)

Category : Cyber-Ark

Date and time: Tuesday, June 20, 2017 1:00 pm
Eastern Daylight Time (New York, GMT-04:00)
On The Front Lines – A CyberArk Weekly Webcast Series
Panelist(s) Info:
Chris Maroun
Duration: 30 minutes
Learn how to stop a takeover of the world’s most important environments.

CyberArk ICS specialists will discuss how the Privileged Account Security solution can be utilized to help stop advanced privileged attacks within environments such as NERC, CIP, SCADA, and other ICS regulated network configurations.







  • 0

Shadow Admins – The Stealthy Accounts That You Should Fear The Mos

Category : Cyber-Ark

Shadow Admin accounts are accounts in your network that have sensitive privileges and are typically overlooked because they are not members of a privileged Active Directory (AD) group. Instead, Shadow Admin accounts were granted their privileges through the direct assignment of permissions (using ACLs on AD objects).

From the attacker’s perspective, these accounts are highly desired because they provide the administrative privileges necessary to advance an attack, and they have a lower profile compared to accounts under the well-known admin groups (ex: Domain Admins).

To maintain a strong security posture, CyberArk Labs highly recommends that organizations get to know all of the privileged accounts in the network, including those Shadow Admins. For that reason, we developed a special tool that scans and discovers privileged accounts based on account permissions. The tool, ACLight, is available for free on GitHub and can be used to discover these Shadow Admin accounts on your network today. You can find ACLight here.

Once you discover these Shadow Admin accounts, we recommend that you take steps to fully protect them.

Background: Defining Privileged Accounts

Most security professionals are well aware of the importance of protecting privileged accounts in networks and the potential damage an attacker can cause with access to a privileged account.

So, what are the privileged accounts?

There are four main categories of privileged accounts:

  1. Domain privileged accounts, such as Domain admin users, DHCP admin users
  2. Local privileged accounts, such as Local Administrator accounts on endpoints and servers, and “root” on *nix boxes
  3. Application/services privileged accounts, such as DB admins or SharePoint admins
  4. Business privileged accounts, such as Finance users or the corporate Twitter account

In this blog post, we focus on the first category: domain privileged accounts. We prioritized this category because these accounts are the most powerful accounts in a network. If these accounts are compromised, an attacker can easily compromise all other accounts in the domain.

Identifying Domain Privileged Accounts

The basic and naïve way to identify privileged accounts is to review the built-in privileged groups in Active Directory. To do this, one can query and list all the accounts in the groups “Enterprise Admins,” “Domain Admins,” “Account Operators,” “Schema Admins” and so on.

However, what if the organization created their own additional admin groups, such as a new domain admins group named “DA_accounts”? If we stop searching after the first step described above, we will miss all the other unique administrative groups the organization created – and therefore miss those additional highly privileged accounts.

Moreover, what if your organization mismanaged Active Directory permissions and did not have the time (or did not take the time) to take care of the details and update the necessary Access Control Lists (ACL)? There may be legacy sensitive ACL assignments that have been forgotten. Or perhaps a specific account needed a specific permission, but the administrator who made the change did not fully understand the implications of directly assigning the privileged permission.

Figure 1 shows the difference between using group assignments and direct assignments in an ACL.


Figure 1: Delegated ACL permissions in Active Directory

To know and keep track of all our privileged accounts in the domain, we must have a better method of identifying privileged accounts. Let’s consider a new approach, one that looks directly at the ACL permissions.

Understanding ACLs

At the heart of every network there are the Domain Controllers and the Active Directory instances that run on them.

Active Directory is composed of a tree of objects that define the network and all its accounts, assets, groups, system, GPOs and more. Each object in the Active Directory has its own list of permissions (ACEs – Access Control Entries) that make up the ACL. Each object’s ACL defines who has permissions on that specific object and what actions can be performed on it. There are several kinds of permissions, from “Full Control” permission to more specific permissions like “Write,” ”Delete,” “Read” and even some “Extended Rights” such as “User-Force-Change-Password,” which allows the reset of the targeted account password.

Figure 2 shows an example of the ACL of the Active Directory “Domain Admins” group object:

Figure 2: Active Directory tree of objects, each with its own ACL

Figure 3: Advanced look at the ACL of the Domain Admins group object, the specific entry for administrators and the defined permissions

Figure 3 provides a more detailed look at the ACL of the Domain Admins group. Note that the Domain Admins group is granted full access to all objects in the directory by default, but an account does not need to be a member of the Domain Admins group to have those same permissions. An individual account can be granted the same ACEs as a domain admin, yet remain outside of the Domain Admins Active Directory group. Such an individual account would be classified as a “Shadow Admin” account.

Exploiting the Shadow Admin

Once an attacker gets inside the network, he or she will most likely target domain admin privileges to gain flexibility to access desired accounts and assets. However, creating a new account in the Domain Admins group will likely set off alarms, as the account can easily be detected. To stay under the radar, it is in the attacker’s best interest to compromise an existing account and add domain admin permissions directly to the account without changing group membership.

Discovering Shadows Admins through ACL Analysis

As demonstrated above, group analysis is not sufficient when attempting to discover all privileged accounts in the domain. Instead, searching and analyzing the ACL permissions granted to each account is a more comprehensive method.

Permission analysis of Active Directory will identify all the accounts that have sensitive permissions. In a good scenario, those accounts are meant to be privileged. But what if there are new, unknown accounts with administrative privileges? Or perhaps there are known, non-privileged accounts that, for an unclear reason, now have administrative privileges? These accounts could pose a significant risk, as they may have remained unnoticed and unsecured for months or years. Worse, the existence of these Shadow Admin accounts could indicate that a cyber attack is currently in-progress, as these accounts may have been created or exploited by an attacker who later “enhanced” them with extra permissions needed to execute malicious actions.

Let’s see few real examples of Shadow Admins:

Example 1: Account with “Full control” over the Domain Admins group objects.

Figure 4: Shadow Admin example #1

The account “James” shown in Figure 4 is a Shadow Admin. James may not be in a privileged group, but his account is considered privileged because of his permission to register himself to the Domain Admins group at any time.

Example 2: Account with “Reset Password” permission over another known Domain Admin account.

Figure 5: Shadow Admin example #2

“Emily” is a Shadow Admin because of her “Reset password” permission. Even though this is her one and only permission in our domain, it is a very powerful one. Based on this permission, she is just as privileged as the sysadmin account.

Example 3: Account with “Replicating Directory Changes All” permissions.

Figure 6: Shadow Admin example #3

Example 3 carries the highest risk, as any user with this permission has the ability to replicate any object on the directory – including passwords. By default, Domain Controllers and Domain Admins are granted this permission for the purpose of keeping the Master Domain Controller and all other Domain Controllers synchronized. From the attacker’s perspective, any account with a Replicating Directory Changes permission can be used to retrieve the passwords of other accounts on the domain, and thus advance the attacker’s position in the network.

In this scenario, any account with these permissions has the privileges needed to perform a “DCSync” attack and steal the password of every other account. DCSync can be done easily using MimiKatz and other similar tools.

Of the three examples explained above, Example 3 is by far the most dangerous. It’s critical that only Domain Controller and Domain Admin group have these ACEs; no other account or group on the domain should have such an ACL configuration. From the attacker’s perspective, access to this type of Shadow Admin account could be highly valuable in maintaining persistence.

Takeaways and Recommendations

Our research indicates that Shadow Admin accounts are likely prevalent in any organization using Active Directory. When overlooked and left unsecured, these privileged accounts can create unnecessary risk and increase and attacker’s likelihood of success. As such, it’s critical that you know exactly which accounts in your network have sensitive, directly delegated permissions, so that you can take action.

We encourage you to use our Shadow Admins scanning tool, ACLight, to start uncovering these accounts today. You can run the scan using any standard, non-privileged account, as the tool only reads ACLs from AD; it does not modify anything. The output of the scan will be a list of privileged accounts that were discovered from all connected domains.

Next, we highly recommend that you investigate the discovered accounts and take action as appropriate:

  • First, check that the newly privileged accounts are not part of an on-going attack
  • Be sure that the remaining legitimate accounts truly need the permissions they were assigned
  • Follow best practices to protect and secure these privileged accounts including:
    • Dividing personal user accounts from their administrative accounts
    • Using complex and long passwords, storing them in a secure location and rotating them often
    • Monitoring and recording the use of these accounts, and searching for anomalies

For questions and comments, please contact CyberArk Labs.

Additional References

View our research presentation on Shadow Admins at InfoSecurity Europe.

For additional reading on ACLs and how exactly attackers and penetration testers use them, refer to this blog post, “BloodHound 1.3 – The ACL Attack Path Update.”



Author: Asaf Hecht

  • 0

The Case for Comprehensive Access Management

Category : Cyber-Ark

  • 0

A Balanced Approach to Securing Unix Environments

Category : Cyber-Ark

Unix environments present unique challenges to IT security teams because of their inherently privileged nature. Any security steps taken within these environments must offer proactive protection and detection, but they must do so without interfering with the day-to-day responsibilities of authorized administrators.

Privileged account security solutions offer a balanced approach to help organization better secure, manage and control Unix environments while keeping users productive. This document outlines common challenges within Unix environments, offers recommendations on how to address those challenges, and describes how CyberArk Privileged Account Security solutions can work together to help organizations better secure and manage privileged access within these environments.

  • 0

CyberArk Discovery & Audit

Category : Cyber-Ark

In this 30 second video, learn why you should scan your network with CyberArk Discover and Audit™. This free assessment tool will help you to discover privileged accounts, privileged passwords, SSH keys and Pass-the-Hash vulnerabilities on your network.

  • 0

Securing Assets and Applications in the Cloud

Category : Cyber-Ark

In our recent blog, Cloud Security: Who is Responsible for What?, we focused on the idea of shared responsibility in cloud environments; with IaaS/PaaS, the customer is responsible for everything above the hypervisor, while the cloud vendor takes responsibility for the infrastructure itself.

We also addressed how the public cloud vendors’ management consoles are a key weak point and consequently an attractive target for an attacker, often via a phishing attempt. As such, it’s important to lock down and secure privileged credentials in a digital vault to secure the management console. Now, I’d like to further address the enterprise’s responsibilities, specifically the functions above the hypervisor, including securing the privileged credentials used by applications and scripts accessing other applications and assets, such the enterprise’s customer database. Unfortunately these credentials are all too often hardcoded. This is a particularly troubling vulnerability as there can be a large number of hardcoded credentials used throughout cloud and hybrid environments.

Hard-coding and embedding credentials in the code or a script can initially make them easy to use – but this represents a significant vulnerability because attackers or malicious insiders can also easily access them, especially if the credentials are in clear text. But, even worse, when credentials are hard-coded or locally stored, they are nearly impossible to rotate, further making them a static and easy target for attackers.

The risk is real. As part of the DevOps process developers often share source code they’ve developed on code repositories such GitHub. While it’s part of the DevOps process, it’s an all too common example of how embedded passwords and credentials can become public if they’re hardcoded. Even if the code is only saved in the enterprise’s internal code repositories – those passwords and credentials can easily be accessed by other developers and used either inadvertently or maliciously. It also becomes difficult, if not impossible, to fully identify which applications or scripts are interacting with other applications and other enterprise assets.

In the past, these mistakes might not have been so risky, exploitable and damaging within an on-premises environment. However, in a cloud environment, because of the rapid pace of change, the ability to quickly scale, and the tools being used, these vulnerabilities are amplified and can pose unacceptable levels of risk.

To minimize risk and follow best practices, enterprises should avoid hardcoding passwords and credentials used by applications and scripts, and instead, secure credentials in a secure digital vault and rotate them according to policy. With this approach, just like with human users, enterprises can assign unique credentials to each application, code image or script, and then track, monitor and control access via a secure digital vault. Taking this approach, IT administrators will know which applications access resources such as a customer database. Also, when an application or script is retired, the administrator or script can simply turn off the credentials.

secure app to app credentials - best practiceA core business benefit of cloud is elasticity – the ability to easily and instantaneously scale up and scale down the number of compute instances, or virtual servers, to meet the needs of the business at a specific point in time. With on-demand cloud computing, the business only pays for the compute, storage and other resources they use. No human intervention is required. The cloud automation tools are either built-in as a capability of the public cloud vendor’s offerings, such as AWS Auto Scale, or as part of the orchestration and automation tools used with DevOps, such as Puppet, Chef, Ansible, etc.

On-demand computing in the cloud, enabled by the automation tools, is a huge business benefit, but it also presents challenges and new potential risks – when these new application instances are created and launched, they need privileges and credentials to access resources. The automation tools can provide the credentials, but these credentials also need to be secured. Consequently, when a new application instance is created, as the compute environment dynamically scales, a best practice is to immediately secure the permissions and credentials assigned to the new instance in the secure digital vault. This ensures that the credentials can immediately be monitored, managed, secured and rotated according to policy. When the compute instances are retired, the associated credentials can also be removed. This is achieved with integrations between the various automation tools and the secure digital vault.

Whether the enterprise is fully in the cloud with IaaS or PaaS or is migrating to the cloud, it is critical to ensure applications, scripts and other assets use secure passwords and privileged credentials to access other applications and assets in the cloud.

Increasingly, businesses leverage the CyberArk Application Identity Manager to store, monitor, track and rotate credentials and passwords according to policy in the secure digital vault for their cloud and elastic compute environments. Learn more here.

  • 0

CyberArk acquires Conjur

Category : Cyber-Ark

Built for Security. Designed for Agility.

Now available for you: An enterprise-grade secrets management solution, tailored specifically to the unique infrastructure and agility requirement of native cloud and DevOps environments, aimed at helping organizations secure and manage secrets used by machines and privileged users throughout the DevOps pipeline.

Frequently Asked Questions

DevOps methodologies have disrupted the application development market, as well as IT operations. But along with the great benefits of speed and computing efficiency, come new security challenges and dramatic new attack vectors for cyber attackers and rogue insiders.

Well aligned with our mission for securing the heart of the enterprise, with Conjur technology CyberArk is now even better positioned to deliver an enterprise-wide solution that addresses enterprise security needs on Cloud, DevOps and on-premises, with the highest security standards, while not compromising on the agility and velocity needs of the DevOps delivery pipeline.

The joint solution combines CyberArk’s strength as a trusted provider of leading-edge security solutions, and understanding of how attackers work and operate, with Conjur’s enterprise-grade security and capabilities for DevOps. The combined solution allows organizations to embrace Cloud and DevOps with maximum confidence. CIOs and CISOs can drive digital transformation initiatives while still anchoring security to their core trusted systems of record.

  • 0

CyberArk Secures Digital Transformation in the Cloud

Category : Cyber-Ark

New Cloud Automation Capabilities Enable Organizations to Begin Securing Privileged Accounts in Amazon Web Services (AWS) in 15 Minutes

CyberArk, the company that protects organizations from cyber attacks that have made their way inside the network perimeter, today announced cloud automation capabilities that enable customers to protect against advanced security threats in dynamic cloud environments.  CyberArk’s cloud automation capabilities incorporate the CyberArk AMIs (Amazon Machine Images) and AWS CloudFormation templates that are specifically optimized for AWS environments.

Today’s announcement builds on existing CyberArk cloud security capabilities, including an integration with Amazon Inspector to simplify the discovery and prioritization of privileged account risk, enhanced AWS Access Key protection, as well as support for AWS Security Token Service to allow secure single sign-on to the AWS Management Console.

Security in a Cloud-First World

Enterprises, especially those adopting cloud-first strategies to transform their business, increasingly recognize that it is their responsibility to secure their applications and other assets in the cloud. Enterprises migrating to the cloud also want an easy way to consistently enforce security policies – on-premises, in the cloud and across DevOps pipelines.

The CyberArk Privileged Account Security Solution enables protection of cloud assets at each stage of an organization’s cloud journey. CyberArk delivers a complete solution to help secure privileged user and application credentials used to manage public cloud vendors’ management consoles, configure virtual infrastructure, enable applications to connect with sensitive assets, and dynamically scale elastic production environments – all critical to effective enterprise cloud security strategies.

For example, to meet increasing business demands while reducing costs, a European-based financial services organization recently selected CyberArk to help support its strategy to evolve from a hybrid architecture model to being fully deployed in the cloud. The organization uses CyberArk to manage privileged access to the AWS Management Console, which in turn manages the full CyberArk environment on AWS.

“This release further expands CyberArk’s cloud security leadership. CyberArk is a trusted partner that expertly supports customers’ cloud migration strategies by incorporating security from the start, and helps better protect cloud assets in alignment with existing controls and security policies,” said Roy Adar, senior vice president, product management, CyberArk. “As forward-looking organizations embrace the cloud to transform and accelerate key business and customer facing processes, they choose CyberArk because they recognize the unparalleled, proven flexibility, scalability and protection that only CyberArk can deliver across enterprise environments.”

Solution Details and Availability

With its flexible, modular architecture, the CyberArk Privileged Account Security Solution enables customers to start securing privileged accounts in as little as 15 minutes. The CyberArk solution was designed to meet a broad range of enterprise architectures, workflows and integrations focusing on quick time to value. The standard deployment architecture utilizes AWS privileged account security best practices. The CyberArk AMIs are available now, contact CyberArk sales to learn more.

Related Resources

  • 0

Linux Security: Securing SSH Keys and other Privileged Credentials in the Cloud

Category : Cyber-Ark

According to AWS over 70% of the VMs provisioned are some flavor of Linux. How is your organization securing credentials – especially SSH Keys – that allow access to cloud instances? How are you allowing administrators to logon to AWS instances for management. Join us to discuss the role of Privileged Account Security and Linux infrastructure in the cloud.


Tuesday, May 9, 2017 2:00 pm
Eastern Daylight Time (New York, GMT-04:00