Normal view

There are new articles available, click to refresh the page.
Before yesterdayPentest/Red Team

What is Zero Trust – and How NodeZero Can Help

13 October 2022 at 15:41

Zero Trust. Everyone’s talking about it, but what does it truly mean, and how can you prove that your organization is using a Zero Trust model effectively?  

Where did Zero Trust come from? For the security veterans among us, we remember the old network security adage: inside the network was trusted, and outside of the network was untrusted. Think of the old castle-and-moat image commonly used to describe a network. This perimeter-based approach doesn’t work in today’s modern and agile threat landscape. Additionally, the implicit trust assumed with “inside” the network invokes risk. Hackers no longer hack in – they log in. Your Zero Trust framework goes out the door when an attacker gets in and creates their own trust.  

Modern workplaces have evolved. Gone are the days when everyone walks into a brick-and-mortar building for work. To get the best talent and the most flexibility in today’s evolving business world, remote work has become ubiquitous, and that means you’ve got personnel requesting access to your network from everywhere. You can’t build a moat big enough to protect a network that varied.  

The core tenants of Zero Trust are pretty clear: no one receives automatic trust from your network; if you’re going to grant access, grant only the access required and no more; verify that person’s identity before granting access; and do not assume that once the person (or device) is verified, they are always who they say they are – constantly re-verify to be safe. 

How does this framework align with autonomous pentesting? 

Representation of ZTNA in a stylized graphic form.

Defining ZTA  

Let’s start with some baseline understanding. Rather than implying trust because of the user’s network location, Zero Trust believes that network location or IP addresses do not imply trust – it instead looks at identity and context. To put it simply: no one is trusted inside or outside the network without having their identity verified. Remember the old castle and moat analogy? Once you were on the right side of the moat (to the network), you were trusted. But with Zero Trust, identity authentication, not location, is how organizations keep their data safe.  

 The name “Zero Trust” is borne from the “default deny” posture. If a user or device wants access to anything, they must be verified or that access is denied. And when we accept that hackers don’t hack in, they log in, your credentials and authentication are that much more valuable to your business, and an attacker. If attackers are looking for credentials to get the keys to get to your crown jewels, ensuring usernames and passwords are being used by who they should be, and only so, is top priority. 

Least privilege 

The next tenant of Zero Trust: least privilege. If a user requests access to a document, application, folder, or so on, they are granted access to that resource and nothing more. It’s not unlike locking down a building – not every employee needs a skeleton key to every room in your headquarters. If they lose that passkey and it falls into the wrong hands, a dangerous stranger could be weaving in and out of your entire property. The same principle applies here. 

The trust that is given is ephemeral (time-bound) and continually reevaluated. That user or device is re-verified with new requests to ensure they are who they say they are before further access is granted. Identities are verified through measures like multi-factor authentication, endpoint verification, or even physical keys provided by the organization linked to the user’s identity.  

Who, what, and where  

Zero Trust focuses on more than user identity; it also involves knowing what devices are on your network. With the explosion of cloud services and proliferation of work-from-home users, a company’s attack surface has dramatically changed, and will continue to.  Clearly, this is one more reason why the attraction of Zero Trust frameworks are resonating. For example, home users are often criticized for leaving default passwords or factory settings on Internet of Things (IoT) devices like baby monitors or home security cameras, but businesses have adopted that risk, knowingly or willingly or not! With the number of devices that can be tied to a business’s network (including employee home networks), the professional world is as much, if not more, at risk and it’s up to security practitioners at these organizations to know every asset– hosts and people (credentials)–which is on their network. Understanding your environment is key to a Zero Trust framework.  

How NodeZero can help   

At, our core mission is: continuously verify your security posture. NodeZero does this and does it fast, identifying assets that are reachable, vulnerable, and exploitable. It looks for usernames and weak passwords that would allow hackers to log in easily. It also chains vulnerabilities, misconfigurations, or dangerous default settings and credentials, just like an attacker would in order to delve deeper and persist longer in your network.  

The hardest part in cybersecurity is deciding what not to do. understands that no one has enough time to do everything they need to do – new risks, vulnerabilities, and threats emerge  all the time. Prioritization so you can fix what matters most is a dire need for the best of security professionals. NodeZero context-scores every weakness, host, and credential, based on your environment and what impact that compromised asset led to. NodeZero provides the path with proof, so you know exactly how your “crown jewels” were discovered, and even provides fix actions so you know how to remediate the attack paths immediately.  

And similar to Zero Trust access, our philosophy is always verify. NodeZero can be re-run immediately – and as often as you need to – in order to make sure the fix actions you have taken are in effect. Don’t wait for an annual pentest or an actual data breach to find out you missed a misconfiguration or if a patch wasn’t completed.   

Zero Trust isn’t a single tool – it’s a philosophy and a framework. And that means for many organizations, Zero Trust is cobbled together using various tools, policies, and practices. A cobbled-together system, no matter how well thought out or considered, will have blind spots and weak links as tools run up against each other that are not designed to work well together. NodeZero’s find, fix, verify loop can find chinks in the armor of an organization’s Zero Trust plan to ensure those gaps are identified, repaired, and in working order. Introduced a new tool or process? NodeZero can act fast to ensure no new risks have been introduced before someone else finds them.  

Everyone has blind spots – we’re human. NodeZero’s autonomous pentesting is a force multiplier for identifying those blind spots so you can shine a light on them and secure them before a bad actor can make use of them. 

Want to learn more about NodeZero? Set up a demo today 

The post What is Zero Trust – and How NodeZero Can Help appeared first on

Are Your Kubernetes Clusters Configured Properly?

31 August 2022 at 18:16

TL;DR: Given recent news about misconfigured Kubernetes clusters, it’s a great time to review best practices for ensuring the security configurations for your own Kubernetes network. Read on to learn more.

Researchers recently discovered some 900,000 Kubernetes clusters that were potentially exposed to malicious scans and data theft during a threat-hunting exercise. The vast majority of those clusters responded with 401 Unauthorized or 403 Forbidden errors, and while that’s better than being completely exposed, it doesn’t mean that they’re necessarily configured properly. Any time a number like that hits the headlines, cybersecurity professionals can feel that familiar twist in their stomach: please don’t let that number include me.   

Let’s take a look through the eyes of an attacker at a Kubernetes environment. First, it’s important to understand that Kubernetes utilizes HTTP and HTTPS APIs for communication between its various components. The APIs are well documented and transparent, meaning the APIs we’ll be using are the same ones the Kubernetes components use. There are no hidden APIs that get used behind the scenes which makes enumeration fairly and interacting with Kubernetes straight forward. 

Our generalized attack flow will be: identify IPs hosting possible Kubernetes components, enumerate against default Kubernetes ports, determine the version of Kubernetes running, check the cluster for vulnerabilities or misconfigurations and finally exploit the vulnerabilities.   

As mentioned in the above article, identifying Kubernetes clusters can be done with online scanners like A few default Shodan queries include: 

  • title:”Kubernetes Dashboard” 
  • product:kubernetes 
  • Kubernetes 

For a more targeted attack, an IP address, GET requests and knowledge of the Kubernetes API is all you need. The responses from GET requests can indicate whether or not Kubernetes is running on a given port. For the rest of this article, we’ll be using a cluster set up in our development lab and deliberately misconfigured. We’ll use ‘curl’ to send a GET request to the default Kubernetes API server port (6443) and check the response. Initially we get a ‘403 Forbidden’ error. The message “forbidden: User \”system:anonymous\” cannot get path” is a hint that the request was blocked by Kubernetes Role-based Access Controls (RBAC) as ‘system:anonymous’ is a built-in Kubernetes user and is used when an authenticated user or service account isn’t used to make the request. 

A GET request to the default Kubernetes API server port (6443) to check the response.

A GET request to the default Kubernetes API server port (6443) to check the response.

Let’s make the same request but this time ask ‘curl’ to display the response headers as well using the ‘-i‘ flag. 

An additional request, asking ‘curl’ to display the response headers as well as the ‘-I' flag.

An additional request, asking ‘curl’ to display the response headers as well as the ‘-I’ flag.

While we still get the same 403 Forbidden response back, there are two headers that stand out in the response: ‘x-kubernetes-pf-flowschema-uid’ and ‘x-kubernetes-pf-prioritylevel-uid’. These headers are included in responses from default Kubernetes deployments. An additional method to identify a cluster is to inspect the Subject Alternative Name (SAN) in the SSL certificate being used. If the certificate is a self-signed certificate generated by Kubernetes during its deployment, you’ll see something similar to the following: “DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local”.  

Now that we, the attackers, have identified a Kubernetes cluster, we’ll again use ‘curl’ to see if we can determine the version of Kubernetes that is deployed. There are two API resources we’ll check. The first is the API server running on port 6443 and the other is the kubelet with runs by default on port 10250 (HTTPS). First we’ll check the API server to see if it leaks the version information. 

Checking the API server to see if it leaks the version information.

Checking the API server to see if it leaks the version information.

Looking at the output, we see the major, minor, and gitVersion listed. This tells us that we’re running Kubernetes 1.24.3. Now let’s try the kubelet component to see if we can get it to respond. If it responds, there’ll be a flood of information. We can narrow down the output to the version information by using ‘grep’.  

Narrowing down the output to the version information using ’grep’.

Narrowing down the output to the version information using ’grep’.

Here again we see the git_version in the output with the value of “v1.24.3”. Why is the version information important to an attacker? Well, the Kubernetes APIs are ever evolving and improving as new features are added and old APIs are deprecated. This means that the Kubernetes components are sensitive to version skew. Attackers can use the Kubernetes command-line tool, kubectl, to interact with a vulnerable cluster. They’ll want to make sure that the version of kubectl they are using matches with the major and minor version of the cluster they are attacking as this will eliminate any issues they may encounter due to changed APIs.  

Getting a response from the kubelet indicates that it is misconfigured. The kubelet is a Kubernetes component that runs on each node as the primary “node agent.” It communicates with the API server and is responsible for ensuring the containers on that node are running and healthy. A kubelet with open access means an attacker may have the ability to read information about the pods on a node or read the logs of the containers. Worse yet, the attackers may be able to run arbitrary commands inside of the existing containers or to start containers of their own. 

Using ‘curl’ we can get a list of pods on the node. We’ll use ‘jq’ to clean up the output and extract only the pod names. 

Using ‘jq’ to clean up the output and extract only pod names.

Using ‘jq’ to clean up the output and extract only pod names.

Taking this a step further, let’s see if we can run a command inside one of the containers. We’ll keep it simple and see if we can run an ‘ls -al’. In addition to the pod name, we’ll need the namespace and container name we want to run the command in. We can of course get all that information from the kubelet and in fact we’ll use the same command we just used with just a small tweak to the ‘jq’ output. 

Testing to see if a command can be run inside one of the containers.

Testing to see if a command can be run inside one of the containers.

Now with all the information we need, we can attempt to run a command in the calico-node-8krgh pod. This time instead of a GET request, we’ll use ‘curl’ to send a POST to the /run API with the namespace, pod, and container as parameters and the command we want to run as the body of the request. 

Using ‘curl’ to send a POST to the /run API with the namespace, pod, and container as parameters and the command we want to run as the body of the request. 

Using ‘curl’ to send a POST to the /run API with the namespace, pod, and container as parameters and the command we want to run as the body of the request.

At this point, the attackers have free rein within this pod and container to do what they like. The next step would be a container escape and full compromise of the host running the cluster. 

Improving Your Kubernetes Environment’s Security Configurations 

We’ve just demonstrated how a couple of simple misconfigurations can quickly lead to a significant compromise of your infrastructure. But that’s just one example attack path against one or two misconfigured items. With as complex as Kubernetes can get, it can be easy to misconfigure a component. So instead of resolving the specific misconfigurations one-by-one from above, here’s some overarching guidance that will help improve your overall security posture. 

First, understand and correctly apply Role-Based access controls (RBAC) to your cluster. RBAC provides a system to restrict access and prevent subjects from making requests to resources that they don’t have access to. It consists of three primary items; the resource, the verb and the subject. The resource is the Kubernetes API resource type like a node or a pod. The verb is what operation can be performed on the resource like create or list. The subject is a user, group, or service account that is making the request. Properly applied RBAC in the scenario above would have prevented any of the anonymous requests.   

Second, limit your exposed surface. The Kubernetes dashboard is a good user tool that can aid in the administration of your cluster. However, it is likely not a good idea to expose the dashboard to the internet even with the correct permissions and authentication in place. If the only people that need access to the dashboard are the infrastructure team and they only access it from your intranet, then make sure it hasn’t been accidentally exposed to the internet. There are several ways to expose a service to external users. The variety of methods and complexity of Kubernetes networking can make it non-trivial to do correctly. Don’t assume that because service is exposed on an ephemeral high port that it’s configured correctly and not accessible from external sources. 

Finally, regularly verify the security of your cluster. Kubernetes is a complex system. The more pods you deploy, the more services you expose, the more complex it gets. Your security posture today isn’t the same as it will be tomorrow. Verify your security whenever you make a change to your configuration or deployment. This can be the hardest recommendation to follow as infrastructure is constantly changing and thoroughly checking your cluster security COULD be a long and painstaking process, but it doesn’t have to be. This is where NodeZero shines! 

Verify your cluster security with NodeZero 

NodeZero runs an autonomous penetration test when you want or need to. You’ll get results quickly, and rather than a laundry list of risks, your vulnerabilities will be listed by criticality, so you can move quickly on the biggest risks right away. NodeZero will also show you how it was able to discover the vulnerabilities and it will provide proof of the exposure so you don’t have to wonder where or how you are exposed. 

We’ve significantly expanded our coverage of Kubernetes vulnerabilities and misconfigurations. NodeZero will enumerate your endpoints and determine if a Kubernetes cluster is being hosted. If it determines that there is a cluster present, it will proceed to test the cluster for exposed nodes, services and ports. As soon as NodeZero finishes, you’ll get a prioritized list of weaknesses discovered. 

Prioritized weaknesses discovered in a cluster.

Prioritized weaknesses discovered in a cluster.

NodeZero won’t just tell you that your cluster is vulnerable though. It’ll show you, both how it discovered the weakness and proof of the weakness either in the form of a screenshot or output from a command abusing the weakness. 

Path to Unauthenticated Kubernetes API Server Access.

Path to Unauthenticated Kubernetes API Server Access.

Proof of Unauthenticated Kubernetes API Server Access.

Proof of Unauthenticated Kubernetes API Server Access.

The fact that so many Kubernetes clusters exist today, misconfigured and exposed, highlights the need for more frequent penetration testing with faster turnaround time. NodeZero finds misconfigurations and vulnerabilities so fixes can happen quickly, and those fixes can be verified just as fast.  

Run the test. Get the results. Make the fixes you need to make – and then, re-run the test to verify that your Kubernetes clusters are not at risk. Don’t wait for your annual pentest to find out you’ve still got clusters running default settings, or that your dashboard is unprotected.   

And best of all, with NodeZero, the next time you see breaking cybersecurity news that keeps you up at night, you can run a test right then and there to make sure you’re not on the list of potential victims. 

Schedule a demo today to find out if you’re vulnerable.’s Travis Fahlgren, Senior Engineer, and Trampas Howe, Offensive Security Expert, contributed to this report.  



The post Are Your Kubernetes Clusters Configured Properly? appeared first on

Beyond Password Issues: How NodeZero Found Access to an Organization’s Azure Cloud Environment  

25 August 2022 at 19:24

NodeZero is a generational leap beyond a traditional pentest – organizations often see that for themselves from the moment they give our autonomous pentesting platform a shot. NodeZero surfaces risks and weaknesses that would never have come up during a general vulnerability scan as it chains together attack tactics and techniques to illuminate your most critical impacts an attacker could generate.

Take for example a recent NodeZero operation run by an organization in the wholesale distribution sector. What at first appeared to be minor “password issues” led to a high-risk attack path enabling NodeZero to access the domain admin accounts, and even break into the organization’s Azure cloud environment. 

From here, NodeZero could pivot and impact day-to-day operations, such as compromising their business email, but more to follow on that below. 

To start, NodeZero performed a host discovery and found weaknesses through the LLMNR (Link-Local Multicast Name Resolution) protocol, poisoning a host and capturing an unverified credential. (LLMNR is a service used by Windows to resolve hostnames to IP addresses when a DNS request fails in a network.) 

The first thing NodeZero did at that point was to try to crack the hash, which it did in under five minutes. 

NodeZero obfuscates usernames and passwords prior to destroying those records after every pentest, in order to verify that NodeZero was successfully able to obtain them. In this case, “when we see a capital P at the beginning and an exclamation point at the end, that doesn’t bode well,” says Monti Knode, Director of Customer Success with This usually, as you likely already know, means it’s a default or extremely common password. 

Making matters worse, this was a privileged account.

Now that NodeZero had the name and password, it attempted to log in to the domain – and in this case, it was able to do so as a Domain Administrator immediately leading to a domain compromise on this domain controller with full read/write access permissions. 

An attack graph demonstrating how NodeZero obtained access to the customer's Azure network.

An attack graph demonstrating how NodeZero obtained access to the customer’s Azure Cloud.

Domain compromise not once but twice

 A business email compromise enabled NodeZero to take a regular user’s credentials – found while trying to log into the domain – and leverage that to find other credentials. It then could find a domain user, impersonate them, and gain additional control over a second domain admin. 

With this second credential, NodeZero elevated a regular user with no rights to domain admin by taking advantage of the noPAC vulnerability. A little background: In mid-December 2021, noPac, a public exploit that combined two Microsoft Active Directory design flaws, was released; it allowed escalation of privileges of a regular domain user to domain admin, which then enabled malicious actors to launch multiple attacks, including domain takeovers or ransomware attacks.

“That’s why this vulnerability is at the top of the weakness list,” says Knode. “If we were to recommend one thing to fix in this case, it would be that noPac vulnerability.” 

NodeZero offers a Fix Action linking to the knowledge base information needed so the organization could move on a fix action to get those domain controllers patched and protected. 

NodeZero offers context for the vulnerability, related credentials and impacts, and the knowledge needed to fix and maintain so the organization has the education and tools to keep it updated in the future. 

The impact component is vitally important, as by offering context scoring, the customer can see why a weakness that leads to critical impacts in a network gets prioritized to the top of the list of recommended fixes. 

The customer can even rerun a “1-click Verify” pentest on just those hosts where there is a known weakness. “Something like this should be a fairly easy one to do, and we highly recommend it – follow our Fix Actions for those noPac vulnerabilities, select the 1-click Verify option to follow up, and then rerun this more surgical operation as soon as you get the chance,” says Knode. 

 Business email compromise 

NodeZero was also able to execute a business email compromise chaining an attack from the previously successful LLMNR poisoning technique. In this case, NodeZero found that this user was a tenant on the company’s Azure account and from the domain user, was able to pivot for further access. Multi-factor authentication (MFA) was not activated, so NodeZero was able to gain access into their Azure cloud environment and then get into Outlook. 

With this valid domain account, NodeZero accessed 25 business emails, and as proof, NodeZero showed the customer the subject lines of the  emails it was able to access. 

“NodeZero took advantage of the Active Directory login because MFA was disabled on Azure,” says Knode. 

With MFA turned off, NodeZero stuffed the newly captured credential and the issue bumped up to a 9.9 on the criticality scale. Implementing Multi Factor Authentication is recommended throughout network zones and data access points, and it was highly recommended that MFA was turned “on” for cloud access, limiting an attacker’s ability to take advantage of their Azure service. 

Some of these paths can get complicated, but there are fix-actions the customer can go forward with. 

“They have password and credential policy problems, but there were some really high priority fixes they could remediate and see immediate risk reduction,” says Knode. “You don’t have to fix everything. You can fix what matters most, and then verify the fix by running a pentest and aligning it to the scope to see immediately if the fix worked.” 

What are you using, and does it work? 

One question that comes up time and time again in IT is: are the solutions I’ve already paid for effective? 

The NodeZero customer success team asks an organization if they received any alerts about this vulnerability. Was it detected, logged, alerted to, and was it stopped? 

In these instances, this did not happen. 

When NodeZero was able to dump these credentials, an EDR should absolutely have issued an alert and their antivirus solution should have stopped it. 

“We recommend looking into this,” says Knode. “We’re transparent with every action NodeZero takes, so you can go through and see. Export the report and take a look.” 

We recommended this organization go back, check logs to see if the incident was detected and logged, and if it wasn’t, ask how someone was able to dump your credentials and why it wasn’t logged, alerted, or stopped. 

“Nobody should be able to do this without setting off a trigger and an alert,” says Knode. 

From there went through the ops, helped plan a strategy, and looked at next steps. Customers can also take the information NodeZero provides in its reporting features to take the steps on their own. 

“We’re not trying to ‘pwn’ organizations, we’re not trying to poke them in the face and make them look bad – we want to make sure their security stack is putting out every ounce of protection they want from it,” says Knode. 

Want to see NodeZero in action for yourself? Schedule a demo today. 

The post Beyond Password Issues: How NodeZero Found Access to an Organization’s Azure Cloud Environment   appeared first on