HackerTarget.com https://hackertarget.com/ Security Vulnerability Scanners and Assessments Tue, 17 Feb 2026 00:09:43 +0000 en-US hourly 1 https://wordpress.org/?v=6.8.5 https://hackertarget.com/wp-content/uploads/2018/03/hackertarget-logo-square.png HackerTarget.com https://hackertarget.com/ 32 32 10 Critical Security Gateway Exploitations https://hackertarget.com/security-gateway-exploits/ Fri, 23 Jan 2026 04:04:26 +0000 https://hackertarget.com/?p=20738 Security gateways are designed to be trusted. They sit in front of authentication, terminate VPNs, and decrypt traffic before it enters the network. When they are compromised, attackers don’t just get a foothold, they control the perimeter. This list examines ten critical gateway exploitations. It looks at how attackers gained access, how that access was […]

The post 10 Critical Security Gateway Exploitations appeared first on HackerTarget.com.

]]>

Security gateways are designed to be trusted. They sit in front of authentication, terminate VPNs, and decrypt traffic before it enters the network. When they are compromised, attackers don’t just get a foothold, they control the perimeter.

This list examines ten critical gateway exploitations. It looks at how attackers gained access, how that access was reused, and why patching alone often failed.

Looking at these incidents together, the same access paths appeared again and again. Almost every gateway compromise in this list fits one of four failure patterns.

Pre-Auth Gateway Takeover
Exposed Management Interface
Session & State Reuse
Credential & Config Reuse

Fortinet FortiOS. SSL-VPN Pre-Auth RCE (Multiple CVEs)

Ongoing (active through 2025)
Over multiple years, Fortinet SSL-VPN repeatedly appeared as an initial-access point in real intrusions, with pre-authentication and authentication-bypass flaws resurfacing across FortiOS versions and exploitation waves rather than as isolated events.

In 2025, attackers exploited authentication bypass and pre-auth weaknesses in FortiOS, including CVE-2025-59718, using crafted SAML traffic to bypass authentication and take control of the gateway itself. Separate incidents in early 2025 described FortiGate SSL-VPN zero-day exploitation that resulted in full device compromise.

  • Vector: SSL-VPN web portal (TCP/443)
  • Outcome: Remote code execution on the firewall, credential harvesting, VPN session abuse, internal pivoting
  • Operational Impact: Showed that Internet-facing SSL-VPN services remain a consistent initial-access path and that gateway compromise often leads to access persisting beyond the initial exploit window.
  • Response: Organisations patched, disabled SSL-VPN where not required, enforced MFA, implemented geo-blocking, and monitored VPN authentication activity.

In some Fortinet cases, attacker access remained after patching. Credentials and active VPN sessions obtained during exploitation were reused for legitimate-looking access, allowing attackers to return through normal authentication paths even after vulnerable firmware was patched.

Ivanti Connect Secure Policy Secure

Ongoing (active through 2025)
Attackers compromised Internet-facing Ivanti Connect Secure and Policy Secure gateways by chaining an authentication bypass CVE-2023-46805 with a command injection flaw CVE-2024-21887 . The initial bypass removed any reliance on valid credentials, while the follow-on command injection issue allowed attackers to execute commands directly on the appliance.

  • Vector: Ivanti Connect Secure / Policy Secure web portal exposed to the Internet
  • Outcome: Remote command execution, credential access, VPN session abuse, internal network pivoting
  • Operational Impact: Revealed that patching alone was insufficient to remove attacker access when exploit chains exposed credentials or modified gateway state.
  • Response: Organisations patched to fixed releases immediately, restricted external exposure, rotated all credentials and keys, performed post-incident access audits, and in some cases replaced appliances entirely.

What set Ivanti apart was the reliability of the exploit chain. In multiple incidents, access persisted beyond patching due to delayed upgrades, Internet-reachable portals, and credentials harvested during earlier compromise.

This pattern continued into 2025, with a critical vulnerability (CVE-2025-22457) affecting Ivanti Connect Secure, Policy Secure, and Neurons for ZTA gateways showing that gateway-level exposure in the Ivanti stack persisted beyond the initial compromises.

Cisco IOS XE. Web UI Remote Command Execution

Observed 2023–2024
Attackers repeatedly gained initial access to Internet-exposed Cisco IOS XE devices through the Web UI management interface. CVE-2023-20198 exposed an unauthenticated vulnerability in the IOS XE Web UI that allowed remote attackers to create privileged local accounts on Internet-facing devices. This flaw was frequently chained with CVE-2023-20273, which enabled command execution through a privileged Web UI component.

In some cases, attackers used the access gained via the Web UI to deploy Lua-based webshells and shell-escape tooling, with implants such as BADCANDY enabling full device takeover and persistence.

  • Vector: HTTPS/HTTP management interface exposed to the Internet
  • Outcome: Privileged exec, ACL manipulation, config and credential exfiltration
  • Operational Impact: Changed assumptions about network device trust. Showed that patching and configuration changes alone may not remove attacker access from compromised devices.
  • Response: Led to many organisations shutting down the HTTP(S) management interfaces, restricted management to out-of-band or trusted IPs only, and rewrote hardening baselines to default web UI off.

The malicious account survived reboots, configuration changes didn't remove access, the web UI could be disabled but this didn't remove the backdoor. Logs often didn't clearly show how the initial access was granted. This allowed access to persist at the network perimeter.

Palo Alto PAN-OS. GlobalProtect Authentication Bypass

Observed 2024
Attackers gained unauthenticated access to Internet-facing Palo Alto PAN-OS firewalls by abusing the GlobalProtect remote-access service, executing commands directly on the firewall and gaining control of routing, VPN configuration, and security policy.

Access for attackers was enabled by an authentication bypass in GlobalProtect CVE-2024-3400 which allowed compromise of the firewall OS without valid credentials.

  • Vector: GlobalProtect portal or gateway exposed to the internet.
  • Outcome: Command execution on the firewall, policy manipulation, credential access, internal network exposure.
  • Operational Impact: Demonstrated that even premium security vendors face zero-day exposure and reinforced the need to treat remote-access services as high-risk entry points.
  • Response: Emergency upgrades, organisations restricted GlobalProtect exposure, hardened management planes, and enforced stricter access controls.

The exploitation occurred entirely through the GlobalProtect service itself. Attackers did not need access to the traditional management interface, this enabled reuse of access across multiple intrusions, with the firewall operating as an entry platform rather than barrier.

F5 BIG-IP. TMUI Authentication Bypass & RCE

Ongoing (active through 2025)
Attackers repeatedly exploited internet-facing F5 Big-IP appliances by abusing the Traffic Management User Interface (TMUI), executing commands and gaining control over application traffic at the perimeter.

Notable examples included the use of this authentication bypass,CVE-2022-1388, and command injection flaw CVE-2023-46747, both of which enabled direct interaction with the BIG-IP control surface without valid credentials.

  • Vector: BIG-IP TMUI / management interface exposed to the Internet
  • Outcome: Remote code execution, traffic manipulation, credential access, application-layer pivoting.
  • Operational Impact: CVE-2022-1388 triggered mass exploitation attempts globally. 2025 F5 breach highlighted supply-chain risk to infrastructure vendors
  • Response: Organisations patched immediately, disabled or restricted TMUI exposure to management networks, enforced management-plane isolation, and audited device configurations.

BIG-IP exploitation was particularly risky due to its reach. Authentication bypass removed any dependency on credentials, allowing reliable compromise during active exploitation periods. Delayed patching and exposed management interfaces meant attackers could repeatedly target unpatched systems, with successful access impacting not just the device but every application routed through it.

The 2025 nation-state breach of F5’s internal systems introduced another risk for BIG-IP environments. Access to source code and internal vulnerability information shortened the time between weakness identification and active exploitation, leaving defenders with less time to patch or detect.

Citrix NetScaler ADC/Gateway. Session Hijacking & Code Injection

Ongoing (active through 2025)
Attackers exploited vulnerabilities in Internet-facing NetScaler ADC and Gateway appliances to hijack active authentication sessions. Successful exploitation provided attackers with immediate access to live, authenticated sessions and control of the gateway handling that traffic.

  • Vector: External NetScaler Gateway (VPN/ICA proxy)
  • Outcome: Session hijacking, credential theft, remote code execution, traffic interception
  • Operational Impact: CitrixBleed showed that hijacked authentication can bypass MFA and persist after vulnerability patching.
  • Response: Organisations patched, invalidated all active sessions, rotated credentials and keys, validated firmware integrity, and enhanced session behavior monitoring.

NetScaler compromises stood out because attackers did not need to defeat authentication. Hijacked live sessions allowed reuse of already-authenticated sessions, bypassing MFA and login controls entirely. From there, code injection enabled persistence directly on the appliance.

CitrixBleed (CVE-2023-4966) was an example of this failure mode, with CitrixBleed 2 in 2025 showing that session handling weaknesses in Citrix NetScaler persisted beyond the initial disclosure.

SonicWall SMA. Pre-Auth Stack Buffer Overflow

Observed 2021–2022
Attackers repeatedly compromised Internet-facing SonicWall SMA appliances through pre-authentication flaws, bypassing user authentication, endpoints, and email controls to gain direct execution on the gateway itself.

A pre-auth remote code execution vulnerability in SMA (CVE-2021-20038), allowed attackers to execute code on the appliance before any login or MFA controls were applied.

  • Vector: SonicWall SMA web-based access portal exposed to the Internet. SSL-VPN portal (TCP/443)
  • Outcome: Remote code execution, credential theft, VPN session abuse, internal network access.
  • Operational Impact: Compromised critical remote-work infrastructure and demonstrated business continuity risk when single VPN gateway fails.
  • Response: Applied vendor patches, enabled client certificate authentication, restricted portal exposure and in some ransomware cases rebuilt or replaced appliances.

SMA compromise frequently caused immediate business disruption. Organisations were forced to take VPN access offline, rebuild or replace appliances, and reset credentials across the environment. In ransomware cases, SMA exploitation was often the initial access, with the real damage coming from losing secure remote access while the incident was being contained.

Check Point Security Gateways

Observed 2024
Attackers exploited a pre-authentication file disclosure flaw (CVE-2024-24919) in Internet-facing Check Point security gateways to retrieve sensitive files from the device. Exposed configuration and credential material allowed attackers to return using legitimate access paths rather than re-exploiting the flaw.

  • Vector: Remote access / VPN services exposed to the Internet
  • Outcome: Credential disclosure, gateway access, internal network visibility
  • Operational Impact: Demonstrated that file disclosure alone can enable full compromise when credentials are exposed.
  • Response: Organisations patched immediately, rotated all exposed credentials, restricted management and VPN access, and audited gateway configurations

Compromise did not rely on weak passwords or MFA failures. Once credentials and configuration data were exposed, attackers could authenticate normally. In practice, environments that applied patches without rotating secrets or auditing access often remained exposed long after the initial vulnerability was addressed.

Cisco ASA / FTD. WebVPN Session Hijacking

Observed 2020–2024
Internet-facing Cisco ASA and Firepower Threat Defense gateways were repeatedly compromised by exploiting information disclosure flaws in WebVPN and AnyConnect services.

Vulnerabilities such as CVE-2020-3259, enabled session hijacking rather than direct code execution, allowing attackers to bypass MFA and reuse already-authenticated access.

  • Vector: Web VPN / AnyConnect services exposed to the Internet
  • Outcome: Session token theft, credential disclosure, firewall compromise, internal pivoting
  • Operational Impact: Showed that long-lived perimeter devices remain attractive targets over many years, and that patched environments remain vulnerable if sessions aren't invalidated.
  • Response: Patched across multiple versions, restricted management-plane exposure, rotated credentials after each disclosure, and audited VPN access.

What kept ASA and FTD attractive to attackers was longevity. These gateways were often deployed for years, migrated slowly, and left Internet-reachable across upgrades. Even after individual vulnerabilities were fixed, exposed services and reused credentials meant attackers could return using normal access paths, making ASA and FTD a repeat entry point rather than a one-time failure.

Zyxel Firewalls. Pre-Auth Command Injection

Observed 2022–2023
Attackers exploited pre-authentication command injection flaws CVE-2022-30525 in Internet-facing Zyxel firewall management components to execute system commands without valid credentials. Successful exploitation provided immediate control of the gateway.

  • Vector: Web management interface
  • Outcome: RCE, botnet agents and backdoors deployed on the OS
  • Operational Impact: Highlighted how widespread exposure of management interfaces in SMB environments can lead to large-scale compromise.
  • Response: Organisations patched where possible, disabled WAN management entirely, replaced EOL hardware, and monitored outbound connections from the firewall itself.

Zyxel compromises stood out for their scale. Management interfaces were frequently left exposed across large SMB environments, and pre-auth command injection required no credentials and produced minimal logging on the device. Delayed patching, end-of-life hardware, and limited monitoring meant many compromised devices remained active and were re-used for botnet activity and further attacks long after fixes were available.

Why Gateway Access Persisted After Patching

In 8 of the 10 cases above, the same pattern appeared; attackers used the technical vulnerability for initial access, then harvested credentials that remained valid after patching. Patching the gateway didn't end the breach, it closed the vulnerability, not the access that followed from it.

Phase 1: Initial Exploitation

Hours to Days

  • Pre-auth RCE or bypass
  • Direct gateway control

Phase 2: Credential Harvesting

Days 1-7

  • Active VPN session tokens
  • Stored authentication credentials
  • SSL/TLS private keys
  • LDAP/AD service account credentials

Phase 3: Legitimate Access

Days 7-90+

  • Vulnerability patched
  • Gateway declared "remediated"
  • Attackers return using harvested credentials
  • Access looks completely legitimate
  • MFA bypassed via stolen session tokens or cookie replay

Phase 4: Detection Failure

Months later

  • Incident response triggered by lateral movement or ransomware
  • Forensics trace back to "legitimate VPN access"
  • Original gateway compromise missed or dismissed

Four Common Gateway Failure Patterns

Across the cases above, most perimeter compromises followed one of a small number of repeatable access paths.

Pre-Auth VPN Gateway Takeover

“Log in without logging in.”

Remote-access portals are Internet-facing by design. When pre-auth or auth-bypass flaws land here, attackers get gateway control without credentials or endpoint interaction.

Typical access: SSL-VPN / portal / SSO flows
What attackers gain: execution on the gateway, VPN session abuse, internal access

In this list:
Fortinet FortiOS
Ivanti ICS/Policy
Palo Alto GlobalProtect
SonicWall SMA

Exposed Management Interface

“If the admin UI is exposed, the device is exposed.”

Web management interfaces deliver high-privilege control by design. When exposed to the Internet,
bypass and injection bugs translate into direct control of the perimeter device.

Typical access: Web UI / TMUI / admin endpoints
What attackers gain: policy changes, traffic steering, persistent admin control

In this list:
Cisco IOS XE Web UI
F5 BIG-IP TMUI
Zyxel Firewalls

Session & State Reuse

“Reuse what’s already trusted.”

Instead of breaking authentication, attackers steal or reuse live sessions. The gateway keeps
doing “normal” auth, it’s just authenticating the attacker.

Typical access: session tokens / memory leaks / session reuse
What attackers gain: MFA bypass via valid sessions, app access without login prompts

In this list:
Citrix NetScaler
Cisco ASA / FTD

Credential & Config Reuse

“Patch the bug, forget the secrets.”

File disclosure doesn’t look like takeover until it leaks credentials and configuration. After that, attackers don’t need the exploit. They just log in normally.

Typical access: unauthenticated file reads / config leaks
What attackers gain: legitimate VPN/admin access, silent re-entry after patching

In this list:
Check Point Gateways

What Reduces Gateway Risk

These measures won’t prevent every gateway vulnerability, but they can reduce how long attackers are able to rely on compromised gateways after the initial exploit. Removing access quickly is often the difference between a contained incident and full network compromise.

1.
Patch Without Delay

Organisations that waited for scheduled maintenance windows consistently saw exploitation. Those that patched immediately reduced exposure time while review and cleanup continued.

2.
Monitor Gateway Activity

Patching removes the exploit, not the access. In many of the cases above, attackers returned using harvested credentials or active sessions days or weeks later. Without focused monitoring, that activity goes unnoticed.

3.
Continuously scan the attack surface for exposure and misconfiguration

Most gateway compromises started with something exposed that should not have been; a reachable management interface, forgotten VPN portal, or legacy service left open. Regular attack surface scanning helps identify these issues before attackers do. Scanners such as HackerTarget’s Nmap scanner can identify exposed ports, while Domain Profiler helps track DNS, hosting, and infrastructure changes over time.

Conclusion

Gateways fail like everything else. The difference is what happens after. Once attackers control the gateway, everything behind it treats them as legitimate. In the incidents above, the exploit itself was rarely the end of the story. Credential reuse, session hijacking, and configuration exposure turned short-lived vulnerabilities into long-term access paths.

The post 10 Critical Security Gateway Exploitations appeared first on HackerTarget.com.

]]>
DNS pivoting: Attack surface discovery through DNS https://hackertarget.com/dns-pivoting-attack-surface/ Fri, 26 Sep 2025 04:07:49 +0000 https://hackertarget.com/?p=20364 When exploring an organisation’s internet footprint, DNS often reveals more than expected. It's easy to dismiss DNS as a backend utility that just makes connections happen, a static directory that simply points traffic where it needs to go. But in reality, it's a rich, and underused set of data sources for attack surface discovery. In […]

The post DNS pivoting: Attack surface discovery through DNS appeared first on HackerTarget.com.

]]>
When exploring an organisation’s internet footprint, DNS often reveals more than expected.

It's easy to dismiss DNS as a backend utility that just makes connections happen, a static directory that simply points traffic where it needs to go. But in reality, it's a rich, and underused set of data sources for attack surface discovery.

In this article we’ll use a Threat Hunt example to go through a series practical DNS pivots with HackerTarget tools, showing how lookups, reverse searches, and zone transfers expose parts of a target’s online footprint that are often overlooked.

What is DNS Pivoting?

abstract image show DNS links

DNS pivoting is the process of using one piece of DNS information to discover additional assets and services. Attackers and defenders can use this technique to expand their view of an organisation’s exposed attack surface.

It's not a one-time task. DNS pivoting is cyclical and non-linear due to infrastructure changes, new services being spun up, and old ones decommissioned sometimes cleanly, sometimes leaving traces.

Different record types provide natural pivot points that expand recon. Following the trail from one record type to another can uncover systems that aren’t obvious from the main domain. Common pivots include:

Common Pivot What It Reveals
Shared DNS (NS) Other domains using the same nameserver.
Reverse Lookups Map IP addresses back to domains to find related assets.
Zone Transfers Misconfigured name servers may leak an entire DNS zone file
MX / TXT / SPF Mail and authentication records often point to third-party services.

Each pivot from one record to the next helps build a wider map of systems that may be exposed or forgotten.

Security implications

This has real security implications. Missed DNS assets often translate into forgotten services. A few examples; staging servers, old applications, or third-party integrations that are still exposed to the internet. These are targets threat actors are on the look out for: staging systems can lack patches, old apps can run vulnerable code and any external dependencies bring risk and possible vulnerabilities outside of your control. Overlooked DNS assets that no longer point to active hosts can create issues such as subdomains an attacker might take over. Takeaway: overlooked DNS assets can become weak points even in well-defended environment.

For attackers, DNS pivoting is reconnaissance. For defenders, it’s an opportunity to see what an adversary would find and remediate it first.

Using HackerTarget Tools

HackerTarget.com provides tools that make DNS pivoting straightforward using the web tool or API

Tool Purpose Use Case API Endpoint
DNS Lookup Perform lookups, trace records, and uncover related domains Initial reconnaissance and domain analysis api.hackertarget.com/dnslookup/?q=domain.com
Find DNS Host Records (Subdomains) Discover subdomains linked to your target domain Subdomain enumeration and attack surface mapping api.hackertarget.com/hostsearch/?q=domain.com
Reverse IP Identify all A records associated with an IP address Find domains sharing the same hosting infrastructure api.hackertarget.com/reverseiplookup/?q=1.2.3.4
Reverse DNS Find other domains sharing the same infrastructure Infrastructure correlation and threat actor profiling api.hackertarget.com/reversedns/?q=1.2.3.4
Zone Transfer Test Check for misconfigured name servers that leak entire DNS zones Identify DNS misconfigurations and data exposure api.hackertarget.com/zonetransfer/?q=domain.com
Domain Profiler Combine DNS data with banner information for comprehensive analysis Complete attack surface profiling and reconnaissance Domain Profiler - Web Interface only
DNSDumpster DNS reconnaissance with visual network mapping Domain intelligence gathering and visualization dnsdumpster.com (Web interface with downloadable results)
Domain Profiler Advantages:

All pivots can be done manually, or automated in one run with the Domain Profiler

  • Visual Mapping: Provides network diagrams showing relationships between domains, subdomains, and IP addresses
  • Comprehensive Results: Combines multiple DNS reconnaissance techniques in a single interface
  • Pivot to Vulnerability Identification: Feed IP's and Hosts directly into Port Scanners and other tools for real time status
  • Export Options: Download results in various formats for further analysis and reporting
API Usage Notes:
  • Rate Limiting: Free API access is limited to 100 queries per day. Consider API key registration for higher limits
  • Authentication: No authentication required for basic queries. Optional API key available for increased rate limits and priority access
  • Response Format: All endpoints return plain text responses by default. Some tools support JSON format by adding &output=json parameter
  • Usage Example: "https://api.hackertarget.com/dnslookup/?q=example.com"

By chaining these tools together, you can replicate the pivoting process attackers use and build a more accurate picture of your exposure.

Example Scenario: Threat Hunting with HackerTarget's Tools

Imagine you are a security analyst who has identified a suspicious domain, malicious-example.com, from a recent phishing campaign. You need to investigate the full extent of the threat actor's infrastructure. In this case it all starts with the domain name malicious-example.com. The first step is to see what IP address(s) it resolves too.

Start with DNS Look up for Initial Recon:

Use the DNS Lookup tool (or use the API) to map a hostname to an IP address. This quick search reveals the current A record (IPV4 address) and AAAA record (IPV6) plus MX, NS, TXT, SOA and other records. So, even from this one query, we can see the web servers, mail routing, DNS provider, and verification tokens.

# Using the HackerTarget DNS Lookup web tool or API
query: malicious-example.com

A : 266.107.226.40
A : 266.107.223.40
AAAA : 2203:1030:20e:3::23c
AAAA : 2203:1030:b:3::152
AAAA : 2203:1020:201:10::10f
MX : 10 example-com.mail.protection.outlook.com.
NS : ns3-39.azure-dns.org.
NS : ns1-39.azure-dns.com.
NS : ns4-39.azure-dns.info.
TXT : mixpanel-example-verify=5803bc4c-5beb6-4ce1-8076-753800097373
TXT : fake-site-verification=123uFg3wr5PWg74nelV029RoXXBBUW0_E6qf1WEWVHhetkOY
SOA : ns1-39.azure-dns.com. azuredns-hostmaster.example.com. 1 3600 220 2519200 300

Most importantly, a map of the target’s external footprint is starting to build. As a rule, attackers and penetration testers use DNS data to expand their view of a organisation’s infrastructure and understand its attack surface.

Record and Review:
• Verify: check whether the exposed IPs and MX records match your asset inventory.
• Record: note verification tokens and provider info (TXT, MX, NS) for later pivots.
• Log: store all record types to build a baseline map of external services you can revisit.
Try to Expand with Zone Transfer

A Zone transfer goes further. If a name server is misconfigured it can leak the DNS Zone, possibly revealing the list of hostnames under the domain. Zone transfers aren’t common as most DNS providers and admins block them but when you do find one, it changes the recon game. Instead of brute forcing or pivoting slowly, you get the whole map in one hit.

# Using the HackerTarget Zone Transfer web tool or API
query: malicious-example.com

admin.malicious-example.com #likely sensitive, higher-value target.
api.malicious-example.com   #backend services, often overlooked in hardening.
mail.malicious-example.com  #communication system, possible target for credential attacks.
staging.malicious-example.com  #usually less secure than a production server.

The results above show admin portals, APIs, mail infrastructure, and a staging environment. Each of these expands the attack surface:

Tip: Want to try this safely? The domain zonetransfer.me is intentionally left open for testing zone transfers. Use it with the our Zone Transfer tool to see what a full zone dump looks like.
Record and Review:
• Flag misconfigured name servers (a critical issue to remediate).
• Prioritise sensitive hosts such as admin, staging, and mail for further testing.
• Store the full zone file as a reference for ongoing recon.
Passive DNS Pivot - IP to Domain:

From the IP address discovered earlier with the DNS Lookup tool (266.107.226.40) now try to find what hostnames point to that same IP. Two tools work here:

Reverse DNS shows a single PTR record, which often reflects internal naming conventions (webserver1 here). On its own, it doesn’t give much, but it confirms the IP is tied to the threat actor’s namespace.

# Using the HackerTarget Reverse DNS Lookup web tool or API
query: 266.107.226.40

PTR : webserver1.malicious-example.com.

Reverse IP shows a broader picture and how the IP address is shared across multiple domains. Two of them: scam-example.net and fake-login.org look obviously malicious, linking the phishing campaign to other suspicious activity.

# Using the Reverse IP Lookup web tool or API
query: 266.107.226.40

scam-example.net
blog.malicious-example.com
unrelated.org
fake-login.org
images.mscode.in

Also revealed is blog.malicious-example.com and other unrelated domains. Each hostname is another pivot. If it’s related to the threat actor (or target) the recon expands. If not, it's just noise (common when the attacker's or target’s site is on shared hosting).

This is where the circular nature of DNS pivoting comes in. A result from Reverse IP takes us back to a fresh DNS Lookup, where subtle relationships can be uncovered. For example:

# Using the HackerTarget DNS Lookup web tool or API
query: images.mscode.in

CNAME : cdn.malicious-example.com.
A     : 266.107.223.40
AAAA  : 2203:1030:b:3::152

In example above, the domain images.mscode.in doesn’t look related at first, but the lookup reveals a CNAME pointing to cdn.malicious-example.com on the same infrastructure. That small connection ties it back into the threat actor’s footprint and shows how pivots loop back around.

DNS pivoting doesn’t move in a straight line. Each new discovery can branch off into parallel paths with some worth chasing immediately, others worth recording and circling back to later.
Record and Review:
• Pivot on hostnames clearly tied to the target.
• Discard unrelated noise (shared hosting is common).
• Keep suspicious related domains logged for possible campaign links.
Shared DNS Infrastructure

In parallel with earlier pivots, the domains uncovered in the Reverse IP lookup should also be checked for shared DNS infrastructure, so lets check whether they also share the same name servers.

Start by running a DNS Lookup on each domain:

# Using the DNSLookup web tool or API

query 1: malicious-example.com
query 2: scam-example.net
query 3: fake-login.org

# Results (both domains share the same NS set)
NS : ns1.badguyshosting.com.com
NS : ns2.badguyshosting.com.com
NS : ns3.badguyshosting.com.com

Since the 3 domains return the same common nameserver set, they’re tied to the same backend DNS setup.

From here, the analyst pivots on one of the shared nameservers (e.g. ns1) to expand the picture:

# Using the Find Shared DNS Servers web tool or API

query: ns1.badguyshosting.com

Example output:

malicious-example.com
scam-example-2.net
fake-login.org
phish-example-portal.org
staging-app.net
example-badservice.com

A single NS pivot now links multiple domains under the same provider. Some of these like fake-login.org and phish-example-portal.org belong to the phishing campaign. Others like staging-app.net and example-badservice.com may not be malicious but are logged for review later. These could turn out to be part of the same infrastructure cluster once more pivots are run.

Record and Review:
• Group domains that share the same NS to map the cluster.
• Investigate suspicious ones now; log the rest for later.
• Use shared NS data to link scattered domains to one operator.

From Recon to Defense

For this scenario, the investigation pauses here. The analyst has built out a cluster of phishing domains, staging systems, and shared hosting evidence all tied to the same DNS infrastructure. With these findings logged, there’s enough to brief the defensive team.

Defensive Actions:

With this recon in hand, Defenders can:

  • Expand the scope: link one phishing site to a broader set of malicious infrastructure (scam-example.net, fake-login.org, and all the domains from the shared name server lookup).
  • Proactively Defend: Block the discovered domains and IPs at firewalls and network security appliances, preventing future attacks from the same actor.
  • Enhance Intelligence: Document the badguyshosting.com name servers as a known indicator of compromise (IOC).
Close-Up of domain map showing A records

Conclusion

DNS pivoting is an essential technique for any cybersecurity professional performing reconnaissance. Every pivot explored: lookup, reverse lookup, subdomain discovery, zone transfer, shared DNS, and analysing record details, plays a role in uncovering hidden infrastructure that otherwise evades detection. Use them in combination, use them iteratively, and use them creatively. Start from one tiny DNS clue and snowball it into a complete picture of a target’s external network. The more knowledge gathered in recon, the better prepared for the next phases of any security assessment.

Domain Profiler:
If you run this workflow regularly, the Domain Profiler saves hours of manual pivoting.
It produces consistent, reproducible output in multiple formats (XLSX, dashboard, visual maps)
ready to hand to defenders or drop straight into SIEMs and reporting.

Try Domain Profiler

The post DNS pivoting: Attack surface discovery through DNS appeared first on HackerTarget.com.

]]>
Joomla Security Testing Guide 2025 : Recon and Exploitation https://hackertarget.com/joomla-security-testing-guide/ Fri, 15 Aug 2025 05:47:56 +0000 https://hackertarget.com/?p=20285 From passive recon to active exploitation, this Joomla 2025 guide shows the techniques attackers use. Explore common vulnerabilities and attack techniques targeting Joomla websites. By understanding how attackers identify and exploit weaknesses, you can secure your Joomla installation before it becomes a target. Penetration testers and red teams will also find useful insights for testing […]

The post Joomla Security Testing Guide 2025 : Recon and Exploitation appeared first on HackerTarget.com.

]]>
From passive recon to active exploitation, this Joomla 2025 guide shows the techniques attackers use. Explore common vulnerabilities and attack techniques targeting Joomla websites. By understanding how attackers identify and exploit weaknesses, you can secure your Joomla installation before it becomes a target. Penetration testers and red teams will also find useful insights for testing Joomla in security assessments.

close-up image of rack of servers in greyscale

Introduction to Joomla Security

In 2025, Joomla continues to be a widely-used open-source content management system (CMS) with around 2.5% of all CMS-powered websites using it (approx 2 million websites globally). With the release of versions 4.x and 5.x security features have been enhanced in Joomla, including stronger password hashing, built in rate limiting for brute force protection and improved session management. But alongside this attackers develop new techniques to bypass these protections. Additionally the large ecosystem of extensions, templates and components continue to present a large attack surface.

Joomla's ease of use, free licensing, and flexible architecture, enhanced through 'extensions' much like WordPress plugins, make it a highly capable CMS. This popularity also makes Joomla a frequent target for attackers seeking to exploit vulnerable websites for malicious purposes. Many security issues stem from poor security hygiene, outdated installations, weak or reused passwords, insecure or poorly maintained extensions.

Understanding these risks are the first step in securing your Joomla site.

Using these attack techniques and tools against systems you do not own or have permission to test is illegal in most jurisdictions. This article is for educational purposes and to raise awareness about the need for proactive security.

Enumeration and Reconnaissance

The first step in assessing a Joomla-powered site is technical reconnaissance, ie gather as much technical information as possible about how the site is configured. This information forms the foundation for identifying vulnerabilities and working out potential attack vectors.

Now is the time to put yourself in the hacker's mindset. Whether performed passively or actively, reconnaissance helps defenders understand what a real-world attacker might see. This may involve:

  • Passive inspection: use standard HTTP requests to gather metadata and configuration details without interacting with the application.
  • Aggressive probing: techniques such as directory brute-forcing could uncover and identify hidden components, extensions or misconfigurations. This generates noisy traffic which can be logged by web servers, detected by IDS or blocked by WAF's.

With the reconnaissance approach defined, the next step is to find out if the target is running Joomla and identify its core version.

#1 Joomla Identification & Version

To determine if the site is running Joomla, and identify the Joomla Core version, several straightforward methods can be used.

1. Meta Generator

One of the simplest ways to detect Joomla is inspecting the page's HTML source code. Look for the meta generator tag in the HEAD section.

<meta name="generator" content="Joomla! - Open Source Content Management" />

This example is taken from the source of a default Joomla install however, some site admins remove or modify this for security reasons.

2. joomla.xml

To identify the version in use, check the joomla.xml file located within the directory /administrator/manifests/files/

https://www.joomla.org/administrator/manifests/files/joomla.xml

This file typically contains version metadata such as:

Screenshot showing detection of metadata with Joomla core version

If this is accessible, this will give an accurate core version, but security admins often block access to this path.

3. Language File Disclosure

Another, sometimes overlooked source is the language XML file.

https://example.site/language/en-GB/en-GB.xml

Example entry:

<version> 3.6.5 </version>

This method can be effective even if other version indicators are hidden.

4. Version in README.txt

Check for the presence of /README.txt from the web root of the install. While it may not include the full version number, it will, usually, reveal the major release e.g. 4.x at the top of the ReadMe file which helps narrow down the attack surface.

Joomla readme example
5. Automated Detection Tools

In addition to the manual checks listed above, automated fingerprinting tools can be used to quickly identify whether a site is running Joomla and show other technologies. Using the passive options with Whatweb and Wappalyser, these tools analyse HTTP headers, file paths, and HTML signatures to detect CMS platforms and components.

Risks of an outdated installation

These version discovery techniques are commonly used by attackers. Regularly auditing your Joomla installation for exposed metadata and unprotected files is essential in reducing your security footprint.

If an attacker discovers a site running an outdated Joomla core, it may be vulnerable to known security exploit. These publicly documented exploits can often be used directly, especially if the site hasn't applied patches.

Outdated core versions can be indicative of a poorly maintained site, which can extend to other components, such as extensions, templates, and backup files. These may also be unpatched or misconfigured, which increases the likelihood of a successful attack. An unmaintained Joomla site presents a significantly expanded attack surface.

#2 Identifying Extensions and Version Enumeration

Like WordPress plugins, Joomla's functionality is extended through "Extensions", these fall into several categories:

  • Modules
  • Components
  • Templates
  • Plugins
  • Languages

Each can introduce vulnerabilities when poorly coded or outdated. An common example unauthenticated users having access to the same features as logged-in (authenticated) users.

The goal of extension Enumeration is attempting to identify as many installed extensions as possible, including disabled or inactive ones. This information is valuable for discovering known vulnerabilities by checking versions against public exploit databases.

Limitations

Visibility of all installed extensions typically requires administrator access. Without this access, attackers or those testing the site can only rely on other methods, both passive and active, to enumerate extensions.
If you're looking for all extensions in a Joomla installation, you need to check multiple directories since different extension types are stored in different locations.

Passive

Hints to extensions present in a site may be found in the HTML source of the page. For example, information may appear in Javascript files, CSS files or comments on the page source. Once an extension is identified, additional details, such as version info, author, files, database tables, and installation instructions, can sometimes be gathered from the manifest file /components/com_example/manifest.xml.

Active

Some extensions do not leave traces in the HTML source. To discover installed extensions you may have to be more aggressive. Several tools can brute force Joomla paths using known extension/component names. There is no one size fits all when it comes to Joomla. Using a combination of available tools will get the best results.

One example is the Metasploit Joomla Plugin Scanner. This metasploit auxiliary module uses a wordlist to locate valid paths scanning for extensions and identify known vulnerabilities.

Active scans generate noticeable traffic and may be logged or blocked by defensive systems.
Vulnerability reference

Joomla maintains a live resource called - The Joomla Vulnerable Extensions List (VEL). This list tracks vulnerable extensions for which no patch is known to exist. It is strongly recommended to uninstall these extension from you site. A separate list 'Resolved Vel' includes extensions that have a patch available. Check this list and patch / update as necessary.

Extension Version Enumeration

You have compiled a list of extensions of the site, now for the version. The design of Joomla means this information isn't forthcoming or comprehensive, especially when attempting to find it passively.

It is possible version numbers can be found in an extensions manifest file or other within such as the addon's stylesheets or javascript. While inconsistent, these areas may provide enough information to help with recon.

With a valid version you can compare what has been found against known exploits or the Joomla VEL List. This comparison will attest if the site is likely vulnerable, before throwing any exploits.

#3 Template Enumeration

Joomla Templates can contain vulnerabilities that may expose the site to compromise. Templates are simply collections of PHP, HTML, CSS and JavaScript resources to define a site's design but more Complex templates have additional components and code, increasing the likelihood of security vulnerabilities.

Template Enumeration is similar to extension detection. Inspect the HTML and locate the template. Alternatively, run a passive scan on Hacker Target's Joomla Security Scan and scroll through results to find the Joomla Template.

joomla theme enumeration
Detecting inactive but accessible templates

One important point when testing is that Joomla Templates and components may still be installed even if they are not active. And if accessible, and vulnerable, can still be exploited. For this reason, brute-force enumeration of known template paths during an assessment is a possible additional step when assessing an unknown Joomla installation.

#4 User Enumeration

Gaining access to Joomla's administrator panel can result in the full compromise of the site. Including database access and remote code execution (RCE) via PHP. Attackers will attempt to enumerate usernames before deploying a password guessing attack.

Administrator Login Page

A quick tip is first see if the Administrator login page is publicly exposed.

https://exampledomain.com/administrator

or run a basic curl command to check if admin panel is publicly accessible:

curl -I https://exampledomain.com/administrator/ 

if response is

 HTTP/1.1 200 OK 

Then login page is exposed and publicly available. However, hardened Joomla set ups will return a 403 or redirect to main site to hide the admin panel. If accessible, this page becomes a target for brute-force or credential-stuffing attacks.

User enumeration challenges

Unlike WordPress, where simple techniques like WordPress User Enumeration can expose valid usernames, Joomla doesn't make it as easy. There are no default endpoints for listing users, and login forms do not reveal whether a username or password is incorrect.

However, most Joomla installs create a Super Administrator account with the default name of admin. As part of the install, Joomla requests a password for this account and encourages changing the name of the account from 'admin' to something more difficult to guess, but many users leave it unchanged. This makes admin a good starting point for username guessing.

Joomla login form
Privileged User roles

Joomla defines 3 privileged user groups which have access to the control panel:

  • Managers: content creation and backend system info.
  • Administrators: Elevated access, admin functions excluding global options.
  • Super Users/Administrator: ultimate power. Access all areas.

From version 3.2 onwards two-factor authentication (2FA) is available and can be enabled from the User Manager in the Control Panel. By enabling this, it increases login security and reduces the effectiveness of brute-force attacks.

Password Re-use and Breach Datasets

A common technique used in targeted attacks is mining public or breached datasets for credentials associated with the target. Its not uncommon for users to reuse passwords across platforms and sites. If a Joomla username is guessed or leaked, previously breached passwords can be tested. However, Joomla doesn't easily expose user lists or login info.

Credential stuffing attacks based on breached data are particularly dangerous when paired with a valid username.

#5 Directory Indexing

Directory listing occurs when a a misconfigured server allows public browsing of folder contents. Instead of doing a redirect or returning a 403 Forbidden, the responds with a 200 OK and shows a list of files with the directory.

Viewing the contents of the directory allows an attacker to gather sensitive information not intended for public viewing about the existence and contents of the files. Such as hidden files, backup files, config files, plugins, and templates, without the need to brute force the paths.

How to check for directory listing

Start by browsing to Joomla-related folders and see if list of files / folders in the browser.

Screenshot showing an example of directory indexing

If enabled the browser returns a list of files and subdirectories. These can then be explored further.

#6 Content Discovery

Looking for sensitive information, database credentials, backups, are just a few items that can be found with content discovery using tools such as Gobuster, FFuf or Feroxbuster. Content discovery is attempting to find any interesting items contained within a web path of an application..
In 2025, many wordlists now contain CMS-specific paths, making Joomla admin areas and component directories easier to locate.

Common locations to check are:

    /robot.txt
    /backup
    /images/
    /bin/
    /uploads/
    /components/
    /administrator/
    /.htaccess.txt
    /index.html
    /index.php
    /templates/exampletemplate
    /administrator/templates/exampletemplate
    /phpmyadmin/
    /phpinfo.php

Gobuster example for finding hidden content:

gobuster dir -u https://example.com -w /usr/share/seclists/Discovery/Web-Content/common.txt

FFuf example:

ffuf -u https://example.com/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt -mc 200
Useful file examples

Backups
Files such as /backup.tar.gz or /site.zip can be accidentally left in the publicly accessible web root and can give an attacker access to all files of the installation including all installed components as well as the configuration file containing database credentials.

phpinfo()
Files like /phpinfo.php can reveal loaded modules, PHP version and configuration settings. All of which can help an attacker create or tailor exploits.

#7 Leftover Installation Scripts

Joomla's installation process creates a /installation/ directory. This directory contains scripts and files needed for the initial site set up therefore becomes a security risk if left accessible.
Joomla versions from 4.x up include protections to prevent re-running the installation file, however older Joomla installations may not have such strong protections in place and allow attacks to access the installation interaface directly.

curl -I https://example.com/installation/

#8 Joomla Scanning Tools

There are various tools for assessing and scanning Joomla installations. From passive to aggressive. Below is a breakdown of a few recon and vulnerability discovery tools.

Joomla Security Scan - Hacker Target

Hacker Target hosts a free, simple passive Joomla scan. Discover vulnerabilities, web server details, configuration errors, identify template, and test for directory indexing and others.

The freely available tools perform analysis from a simple page grab. Through the examination of the HTML source code, javascript, and a few other open publicly accessible pages, it is possible to gain an insight into the state of security on the target site. Because it performs no aggressive probing its safe to use for initial assessments.

Nuclei - Project Discovery

While not Joomla-specific, Nuclei is a fast and customisable vulnerability scanner powered by templates. In the community repo there are templates that cover Joomla version disclosure, known component vulnerabilities, admin login detection.

Here is a snippett of the joomla-detect.yaml template taken from the github repository:
nuclei-templates/http/technologies/joomla-detect.yaml

 http:
  - method: GET
    path:
      - "{{BaseURL}}/administrator/manifests/files/joomla.xml" # >= 1.6.0
      - "{{BaseURL}}/language/en-GB/en-GB.xml" # >= 1.5.0 and <= 1.5.26
      - "{{BaseURL}}/README.txt"
      - "{{BaseURL}}/modules/custom.xml" # < 1.5.0
      - "{{BaseURL}}" # >= 1.5.0 and <= 1.5.26

    stop-at-first-match: true
    host-redirects: true
    max-redirects: 2
...
Legacy Tools Still Valuable for Joomla Reconnaissance

While several Joomla scanning tools, like those listed below, have not seen updates in a while, they remain useful in environments where Joomla is deployed in legacy or maintenance mode where updated scanners might not be applicable. These open-source tools continue to provide essential functionalities for vulnerability scanning, component enumeration, and basic fingerprinting.

  • JoomScan :OWASP Joomla! Vulnerability Scanner written in Perl. Detects Joomla version, known vulnerabilities, admin login page.
  • JoomlaVS: Ruby-based scanner (archived Oct 2020). Scans for components, modules, templates and basic fingerprinting.
  • CMSMap: Written in Python, a scanner for Joomla, wordpress and drupal. Useful for automating scans for low-hanging fruit.
Before Moving Into Exploitation

This section outlined a number of techniques attackers use to passively and actively enumerate Joomla sites. Understanding these reconnaissance steps is vital for defenders to know what information is leaking and how attackers build their strategy. In the next section, we'll explore this information gathered and how it might be used.

Attacking and Exploitation

Securing a Joomla site requires understanding of both reconnaissance methods attackers use and the exploitation techniques that follows. This section covers exploitation tactics, including brute force attacks, vulnerabilities in extensions and core components, and misconfigurations that can lead to a sites compromise.

#9 Brute Force Joomla logins

Joomla 3.2 (2013) introduced two-factor authentication 2FA, in 2025 it still remains disabled by default. Enabling 2FA is a critical step in securing a Joomla site as attackers continue to exploit weak or default passwords.

More recent versions such as Joomla 4 and 5, have login rate-limiting and better password hashing making brute-force less effective without bypassing these protections. However, weak or reused passwords are still a risk and can be detected through various methods.

joomla administration panel

Below are a few common ways to brute-force a Joomla login page.

Nmap NSE Scripts

NMAP is most known for network discovery, however, NSE scripts extend the functionality of the popular NMAP port scanner. An Nmap NSE script is particularly helpful for performing a brute-force password against a Joomla install.

Example without a wordlist:
If you do not include a wordlist Nmap will use its default internal wordlist.

$ nmap -p 80 --script http-joomla-brute target_ip

Example with a wordlist:

$ nmap -p 80 --script http-joomla-brute --script-args userdb=/path/users.txt,passdb=/wordlists/passwordlist.txt exampletarget_ip
Burpsuite

If there is a login form on the site or you have found the administrator interface, then burp suite can be used to try to brute force the password.

There are other tools around such as JoomBrute, and others such as Hydra and Ncrack, though the latter two are most suited for other protocols.

Metasploit

Metasploit's legacy module: Joomla Bruteforce login utility works only on older Joomla installs. As you can see from the github snippet below this module attempts to authenticate to Joomla 2.5 or 3.0. It does not work against Joomla 4/5 as security has been improved for features like stronger password hashing, rate-limiting and other mitigations.

msf > use auxiliary/scanner/http/joomla_bruteforce_login

Metasploit modules are frequently added and existing modules updated. So make your Metasploit is up-to-date and look for vulnerabilities or modules relating to newer versions of Joomla.

Brute-forcing generates alot of noise in failed login requests. Admins can detect this via log monitoring, WAF rules and enabling 2FA.

#10 Bypass WAF

When a Joomla site is protected by a Web application Firewall (WAF) such as Sucuri or CloudFlare, some exploits or reconnaissance techniques may be blocked.

However, knowing the site's real IP address, it may be possible to bypass the WAF simply by directing traffic straight to the origin server, avoiding the DNS routing that would normally send traffic through the WAF.

Bypass via /etc/hosts

An attacker could modify their local /etc/hosts file to resolve the domain name directly to the IP:

204.0.123.23 example.com

Discovering the real IP Address

A few methods that may expose the original IP address tied to a Joomla server.

Historical DNS Records

Historical DNS record may reveal original IP address before the firewall service was implemented. Services such as DNSDumpster can reveal previous A records.

MX Records

If site hosts email on the same server as the website, records might also reveal IP addresses. Though many modern WAF/CDN setups now separate web and email hosting, which reduces this leakage.

Certificate Transparency Datasets

TLS/SSL searches against Certificate Transparency Datasets may show hostnames associated with the sites actual IP address.

Attempting to bypass a WAF without explicit permission is illegal in most juristdictions. These techniques are provided for educational purposes only to understand potential risks and apply mitigations.

#11 Exploiting Extensions

One of the most common attack surfaces for Joomla sites are vulnerable extensions including components, modules & plugins. Components carry the highest risk due to their complexity. Modules and plugins are smaller but can still contain exploitable flaws such as XSS or SQL injection.
1,450

published exploits
for Joomla and its components.

#12 Exploiting Vulnerable Components

Components are often the most targeted extensions in Joomla. They are attractive due to their complexity and widespread use.

From an attackers perspective a component vulnerability can be an entry or access point to a full site compromise. The Joomla Extensions Directory (JED) distributes popular extensions installed on thousands of sites. One vulnerability can expose a large number of websites to exploitation.

Example: Directory Traversal Creative Contact Form (2019)

A directory traversal vulnerability was discovered in the Creative Contact Form V4.6.2 2019. This vulnerability occurred when a user uploaded an attachment to the form and the filename field wasn't property sanitised. This allowed an attacker to manipulate the filename to in an attempt to navigate outside of the intended directory on the server. The attacker could use this:

../../../../../../../../etc/passwd

With the "Send me a copy" option enabled to receive any files from the servers filesystem via email.

Example: SQL Injection in JoomShopping V 1.0.0-1.4.3 (2025)

CVE-2025-22111: This SQL injection vulnerability in the JoomShopping component versions 1.0.0-1.4.3 allows authenticated attackers (administrator) to execute arbitrary SQL commands in the country management area in backend.

# Sample sqlmap usage with placeholder data. No exploit strings included.

$ sqlmap -r /path/to/redacted_request.txt -p ordering --dbms=mysql --batch --risk=1 --level=1

#13 File Upload Vulnerabilities

File upload vulnerabilities are one of the most dangerous flaws in Joomla and its extensions providing a direct path to site compromise. The combination of PHP's server-side execution and weak upload validation creates just the right conditions for attackers to gain shell access. Joomla's file and PHP structure make upload vulnerabilities particularly dangerous.

Common Techniques and Targets include:

File extension bypass:
Such as Double Extension shell.php.jpg with the server processing as PHP despite the .jpg ending used in galleries and document managers.
MIME Type Spoofing:
Often seen in contact forms with attachment uploads that fakes the content type to bypass filters.
Malicious File Content:
Embedding PHP or other code inside file types such as EXIF metadata in user profile avatars.

Example payload that could be embedded in EXIF data or to an image file.

?php system($_GET['cmd']); ?

Possible result if server is misconfigured and processes the PHP. The attacker could possible run system commands with:

http://target.com/uploads/image.jpg?cmd=whoami

#14 Exploiting Templates

While templates are less prone to vulnerabilities than extensions, they are not immune. Templates are responsible for the front-end presentation of a site and are less likely to introduce complex functions, they can still have security issues.

Example: XSS in Joomla HTML Mail Templates (2024)

CVE-2024-27186 : a XSS found in Joomla's HTML mail templates. Affecting versions up to 5.1.2 and mitigated by upgrading to version 4.4.7 or 5.1.3 where issue has been resolved.
An attacker can exploit this flaw by writing a malicious email template that includes unsanitised user input. An example could be an unsanitised user logo field. When the admin or a user view the email the script executes in their browser.

# Sample script with placeholder data. No exploit included.

    script type="text/javascript">
      alert("A malicious XSS exploit.");
      document.example = "http://example.com/malicious"; 
    /script

#15 Exploiting Joomla Core

Vulnerabilities in the Joomla Core are critical as they affect the entire system and not dependent on specific extensions. A core compromise can lead to the possibility of an attacker taking control of the entire system.

Example: CVE-2016-8870 & CVE-2016-8869 (2016)

These 2 critical vulnerabilities CVE-2016-8870 and CVE-2016-8869 allowed remote privilege escalation in versions 3.4.4 to 3.6.3. Attackers were able to create accounts even if registration was disabled, escalate privileges and install backdoors.

These flaws were fixed in Joomla v3.6.4 (Oct 2016) and the attacks quickly disappeared against patch sites.

Example: MFA Authentication Bypass CVE-2025-25227 (2025)

2025 has seen a few security announcements relating to Core vulnerabilities. A recent example is CVE-2025-25227 - Core - MFA Authentication Bypass. It was resolved by upgrading to version 4.4.13 or 5.2.6.

Joomla Core Vulnerability Quick Reference (2016–2025)

CVE ID Year Type Severity Fixed In
CVE-2016-8870 2016 Account Creation Bypass High 3.6.4
CVE-2016-8869 2016 Privilege Escalation Critical 3.6.4
CVE-2024-21726 2024 XSS ? Potential RCE High 4.4.3 / 5.0.3
CVE-2025-22207 2025 SQL Injection (com_scheduler) High 4.4.11 / 5.2.4
CVE-2025-25227 2025 MFA Bypass High 4.4.13 / 5.2.6

Beyond Joomla: The wider attack surface

A Joomla site is only part of the security picture. Attackers will expand their scope to the surrounding server and network environment. Compromises result from exposed services, weak protocols, and misconfigurations. Compromising these can give them direct access to the host, bypassing Joomla entirely.

#16 Sniff and Capture Credentials over non-secure login

Any public website in 2025 should be served over HTTPS (HTTP over TLS). If only HTTP is used, credentials and session cookies are sent in clear text, making them easy to intercept by anyone on the same network, at the ISP, or anywhere between the client and server. Attackers capture this traffic with tools like tcpdump or Wireshark.

sudo tcpdump -i eth0 -A port 80 | grep -i "POST /login"

With the availability to Free certificates (eg Let's Encyrpt) there is really no reason to be not using HTTPS. Check your TLS configuration with tools such as sslyze.

#17 Network Services and Server Risks

Modern web apps, like Joomla, rely on an entire ecosystem. A simple misconfiguration, outdated or unpatched server package can provide entry points for an attacker which could lead to compromise of the server and all hosted applications. Services such as

  • FTP: running outdated software with known exploits
  • SSH: vulnerable to brute-force attacks
  • Webmin: and other administration tools such as cpanel
  • MySQL: :

Finding services is often the first step attackers take to identify open ports and fingerprint running services. A quick nmap scan using Nmap Port Scanner or running the following command;

Example scan for common services and versions

nmap -sV -p 21,22,3306,6379 target-example.com

Working from these results, an attacker can identify server applications, version numbers and look for exploitation opportunities.

While Nmap and other tools similar are effective for discovery they are active and therefore noisy and can be detected by firewalls, IDS and server logs. Even when using stealth modes such as -sS and -T1, scans still generate network traffic.
Consider starting with a passive discovery tool such as Shodan.

https://www.shodan.io/search?query=joomla

#18 Compromising Server Administration Tools

Applications like phpMyAdmin, Webmin, or cPanel expose powerful administrative functions. Attackers can try default credentials eg admin/admin or use known vulnerabilities present in outdated versions.

With a weak password, a misconfiguration or unpatched vulnerability they can lead to database compromise or open the possibility to remote code execution.

Final Notes on Exploitation Tactics

Weaknesses in Joomla, whether in the core, its extensions or templates combined with flaws in the underlying server, or exposed administration tools, can be used together for a sites compromise. Attackers often combine multiple techniques to gain access, from brute-forcing logins, exploiting outdated components and finding hidden files. Understanding these methods leads to recognising the tactics that attackers use so you can detect and stop them before damage is done.

Conclusion

Securing a Joomla site in 2025 requires more than just keeping the CMS uptodate. This guide focuses on core Joomla application security examining the CMS itself, its extensions, and direct server-side attack vectors. However, modern Joomla deployments present additional security considerations beyond the scope of this article. Cloud infrastructure misconfigurations, API endpoint security in headless implementations, containerised deployment vulnerabilities, and content delivery network bypasses represent emerging attack surfaces that security professionals should evaluate alongside traditional application testing.

The post Joomla Security Testing Guide 2025 : Recon and Exploitation appeared first on HackerTarget.com.

]]>
Offensive security tools 2025 https://hackertarget.com/offensive-security-tools-2025/ Tue, 01 Jul 2025 03:17:32 +0000 https://hackertarget.com/?p=19953 To stay ahead, security teams must think like attackers — discovering vulnerabilities before they do. By understanding and using Offensive Security tools, organizations can better harden systems, quickly detect intrusions, and respond effectively during security incidents. Introduction Back in 2016 we assembled 16 Offensive Security Tools for Sysadmins. Nearly a decade on, some of these […]

The post Offensive security tools 2025 appeared first on HackerTarget.com.

]]>

To stay ahead, security teams must think like attackers — discovering vulnerabilities before they do.

By understanding and using Offensive Security tools, organizations can better harden systems, quickly detect intrusions, and respond effectively during security incidents.

Introduction

Back in 2016 we assembled 16 Offensive Security Tools for Sysadmins. Nearly a decade on, some of these tools have not only survived but evolved while others have reached end-of-life, and others rendered ineffective as defenses caught new tools and technologies emerged.

Close-Up of computer monitors in grey-scale

In 2025, the attack surface and threat landscape are more complex, and malicious actors far more sophisticated. The right tools are more important then ever for security professionals to defend against daily attacks.

The mitigations listed for each tool are high-level pointers for sysadmins (systems administrators) to consider. While some of the recommendations may appear to be common sense, far too often the basics are overlooked.

Offensive Security Tools

MetaSploit Framework
Metasploit Framework continues to rank high in the offensive security world after many years in use. It now integrates into automated workflows. Both Attackers and Defenders use Metasploit - security teams train SOC analysts on real world attacks scenarios with it. It has an active open source community who continuously add new exploits modules for latest CVE's, giving sysadmins the ability test, patch and validate their defenses.

Defending against Metasploit:
  • Keeping systems up to date is critical.
  • Monitor network traffic. Deploy IDS/IPS such as Zeek or osquery
  • Use strong passwords on all systems.
  • Deploy network services with secure configurations to minimise attack surface.
Nuclei
Nuclei is high-speed, open-source, versatile, template driven tool you can use for vulnerability scanning, endpoint discovery, asset-fingerprinting and more. Using templates, or craft your own custom template, Nuclei can detect vulnerabilities, misconfigurations, networks, exposed services. Its speed and ease of use makes it a valuable tool for Red teams, but also makes it a tool malicious actors reach for. Nuclei makes probing targets easy with the ability to launch thousands of probes at the same time with results returned as JSON or grep-friendly searchable, making it easy to filter and make a list of exploitable weaknesses.

Defending against Nuclei:
  • Patch and update. Nuclei uses vulnerabilities to exploit your system so keep everything up to date.
  • Use Nuclei for Defense: run it against your own IP ranges, subdomains and API's. See which vulnerabilities are detected or security gaps are revealed.
  • Put critical systems behind authenticated gateways so scanners can't probe them directly.
Bettercap
Bettercap was originally released (v1) as a framework for MITM attacks on local networks. Version 2, written in Go, extends well beyond just local networks and is an extendable 'swiss army knife' for attacking wifi networks, CAN-bus networks, Bluetooth, ARP-spoofing and more. It can now be deployed on Android devices, making it more portable for penetration testing.

Defending against Bettercap:
  • Use properly configured switches, vlans and host setups.
  • Lock down unused network ports.
  • Verification, encryption and monitoring.
  • Detect and analyses ARP/DNS anomalies with Zeek IDS, Suricata and Arpwatch.
Bloodhound
Using Graph theory to reveal and visualise relationships within Active Directory, Entra ID and Microsoft Azure Iaas, Bloodhound comes in a Enterprise and a Community Edition. Bloodhound Community Edition is free opensource used as a security auditing tool.

Defending against Bloodhound:
  • Tighten Group Permission. Lock down who can add or remove members of high-privileged groups.
  • Segment and Isolate Critical Assets
  • Continuous monitoring with your choice SIEM eg Splunk
Social Engineer Toolkit
Social Engineer Toolkit remains one of the most widely used open-source frameworks for social engineering. It's modular toolkit includes how to craft phishing emails, create fake login pages, build a malicious website, USB attacks, and more. Installing SET in a lab environment is a great way to learn typical phishing indicators.

Defending against SET:
  • User awareness training including simulated phishing campaigns to identify high-risk users.
  • Enforce Strong Email Authentication.
  • Apply MFA. This won't stop credentials getting phished but can prevent easy account takeover.
BeEF
BeEF: Browser Exploitation Framework is an open-source pen-testing tool focused on client-side attacks, particularly web browsers, using vulnerabilities to gain a foot-hold in its targets network. This differs to Metasploit which focuses on network frameworks. BeEF can be used to assess real-world impacts of browser vulnerabilities.

Defending against BeEF:
  • Strong Content Security Policy (CSP).
  • Use secure coding practices when developing web applications.
  • User awareness training including simulated phishing campaigns to identify high-risk users.
Binwalk
Binwalk identifies and extract files and data embedded in other files. For an attacker, its used in the search for hard coded passwords, API keys, and other sensitive information hidden in firmware images. Binwalk is commonly used as part of a workflow which utilises other tools such as angr to dig deeper into the analysis of the extracted information.

Defending against Binwalk:
  • Don't leave any plain text hard coded passwords, API keys and other back doors in your firmware.
  • Treat your firmware as an adversary would. Test your systems, attempt to extract and decode anything that looks like a secret.
Nmap Scripting Engine (NSE)
NSE - Nmap Scripting Engine is a powerful Nmap tool and feature that enables advanced network discovery, backdoor detection, vulnerability detection and exploitation,. There are 100's of existing nse scripts and with the ability to create and customise your own, NSE continues to grow in capability and versatility.

Defending against NSE:
  • Reduce your attack surface. Close unused ports.
  • Regularly patch and update vulnerable systems before the NSE scripts can exploit them.
  • Run Vulnerability scans and code review.
  • Use an IDS/IPS (or both) such as OSSEC (host based) or Snort (network).
SQLmap
SQLmap not only accurately identifies injection vulnerabilities, but also automates exploitation from database identification and dumping data to file-system reads and even spawning shells on vulnerable targets.
SQL Injection remains one of the easiest ways attackers can extract an entire database — still ranking in the OWASP Top 10 nearly two decades after its discovery. Its simplicity and impact make it a favorite technique for dumping sensitive data.

Defending against SQLmap:
  • Validate and santiise all user input.
  • Filter all input on dynamic websites (secure the web applications).
  • Have a multi layered defense, include regular vulnerability scanning and code reviews.
  • Use mod_proxy or other web based filtering controls to help block malicious injection attacks. Keep in mind that a WAF should only be a layer of defense (attackers can find bypass for web application firewalls).
Mimikatz
First released in 2007 and actively maintained since Mimikatz remains a popular tool in 2025. Mimikatz has multiple modules tailored to different areas of attack e.g. extract passwords and NTLM hashes from Windows memory. This tool is used by an attacker once they are able to execute code on the system.
An alternative to Mimikatz is PyPyKatz written in python and runs on all operating systems that support python.

Defending against Mimikatz:
  • Use of EDR to detect Mimikatz activity. Open source suggestions to give you visibility into endpoint behaviour: Velociraptor, osquery.
  • Reduce your attack surface and keep your system patched and up to date
Hashcat
Turn a simple hash dump into password credentials with Hashcat. This fast offline cracking tool has been part of the offsec world for around 15 years. Beginning as a CPU-based tool it evolved into oclHashcat for GPU-accelerated attacks. In 2016 the CPU and GPU versions merged into Hashcat, now supporting hundreds of hash types, including PMKID and Wireless WPA/WPA2 handshakes captured with tools such as Aircrack-ng. While Hashcat remains a standard for password cracking in 2025, John the Ripper offers different attack modes and rule-based approaches that are worth exploring.

Defending against Hashcat:
  • Passwords are the weakest link. Enforce password complexity and enable mfa.
  • Protect the hashed passwords. Encrypt your database.
  • Salt the hashes.
Aircrack-NG
aircrack-ng continues to provide a suite of core offsec tools for wireless assessments and audits. It can be used for capturing WPA/WPA2 handshakes and PMKID and cracking on a small scale. Aircrack-ng ships with most linux pentesting distros such as kali and Parrot. Its suite of tools also includes airmon-ng, airodump-ng and aireplay-ng for monitoring, packet capture and injection.

Defending against aircrack-ng:
  • Never use WEP. It can be cracked in seconds due to flaws in its RC4 implementation..
  • When using WPA2 with pre-shared keys (WPA2-PSK), ensure passwords are strong (16+ characters non-dictionary based passwords).
  • Use strong modern encryption.
Tor Network
The Tor Network is maintained by The Tor Project. It is a system to push your traffic through an onion network that is designed to provide anonymity to the user. Note your traffic from the exit node is not encrypted or secured. Make sure you understand what it does before using it, Tor provides anonymity not encrypted communication.

Defending against Tor:
  • Block Tor exit nodes on your firewall, if Tor traffic is linked to a threat to your environment.
  • Monitoring and logging traffic from the Tor Network.
Cobalt Strike
Cobalt Strike (Commercial) - A post-exploitation and C2 framework billed as software for adversary simulations and red team operations. Built around its Beacon Payload, it has a focus on lateral movement (pivoting commands through multiple hosts) and C2 (command and control). Checkout the official training videos for real-world examples of Cobalt Strike in use.

Defending against Cobalt Strike:
  • Advanced attackers need to be discovered by advanced blue teams. Solid network analysis capabilities and well defended networks.
Sliver C2
Sliver C2 An open Source Command and control (C2) designed for security teams to test their own environment with adversary imulations. It has become a popular alternative to Cobalt Strike for malicious actors and APT groups to wreak havoc with malware, exploit zero day vulnerabilities and more.

Defending against Sliver C2
  • As with Cobalt strike - Advanced attackers need to be discovered by advanced blue teams. Solid network analysis capabilities and well defended networks.
OwaspZAP (Zed Attack Proxy)
OwaspZAP is an excellent, free, open-source web application security scanner that serves as a strong alternative to Burp Suite. Both tools offer intercepting proxy, automated spider, fuzzing, a library of add-ons, and automated scanning capabilities. Use Zap to discover and map out urls, test forms, endpoints and parameters for vulnerabilities.

Defending against OWASP ZAP
  • A well-configured perimeter with logging, monitoring and altering in place.
  • Use a WAF to include rules to identify and block ZAP behavior
  • Traffic throttling, rate limits
Rustscan
Rustscan bridges the gap between broad port sweeps and deep enumeration by piping discovered ports directly into Nmap. By default, RustScan can probe all 65,535 TCP ports in under 10 seconds (under 3 seconds in ideal conditions). It also allows for stealth with slower, evasive scans.

Defending against Rustscan
  • Rate limiting or throttle new TCP connections per second per host/subnet on firewalls or routers.
  • IDS/IPS scan detection. Use Suricata or Snort to spot and block.
  • Harden and segment firewall.
Zmap and Masscan

While Nmap remains unquestionably the top choice for detailed port scanning, Zmap and Masscan remain the go to solutions for ultra-fast, large-scale port scanning in 2025. Both can sweep the entire IPv4 space in under six minutes, making them essential for penetration testers conducting internet-scale reconnaissance and threat actors mapping wide networks globally.

Defending against Zmap & Masscan
  • Know your attack surface—keep an up-to-date inventory of all public IPs and exposed ports.
  • Harden firewalls with geo-IP restrictions, rate-limiting, and port-knocking to block mass scans.
  • Deploy network segmentation so a compromised scan appliance can’t enumerate your entire environment.
Ffuf and Gobuster

Ffuf (Fuzz Faster U Fool) and Gobuster are Go-based tools for web application reconnaissance. Ffuf can fuzz URLs, headers, POST bodies and cookies with a single command, letting you hit multiple attack surfaces at once. Gobuster focuses on directory and subdomain enumeration with minimal setup. Feroxbuster, written in Rust, is gaining popularity as an alternative with built-in recursion and auto-filtering capabilities.

Defending against Ffuf and Gobuster
  • Web fuzzers are noisy. Check your logs for spikes in 404, 403 and 500 per IP.
  • Deploy a WAF and tune its rules to identify and block repetitive fuzzing requests.

Conclusion

The 2025 threat landscape has evolved significantly since 2016, with attackers rapidly updating their toolkits. These 18 offensive security tools give you and your team visibility into attack methodologies and help you understand your vulnerabilities from an attackers perspective. Pick the ones that fit your environment, build hands on workflows, use them to find weaknesses and fix them before the attacker can exploit them. Start with network reconnaissance - our online Domain profiler and Nmap port scanner helps you discover your attack surface in minutes.

The post Offensive security tools 2025 appeared first on HackerTarget.com.

]]> Claude Code is more than just Coding https://hackertarget.com/claude-code-more-than-coding/ Mon, 16 Jun 2025 06:46:32 +0000 https://hackertarget.com/?p=19931 Following recent updates I felt it was time to give Claude Code a spin. One thing that has jumped out after using it for a few days is that this is not only a code development tool for programmers. It is far more capable and perhaps even an "agentic" platform for anything you do on […]

The post Claude Code is more than just Coding appeared first on HackerTarget.com.

]]>
Following recent updates I felt it was time to give Claude Code a spin. One thing that has jumped out after using it for a few days is that this is not only a code development tool for programmers. It is far more capable and perhaps even an "agentic" platform for anything you do on the command line.

If you are a system administrator or security analyst who works on the command line, I would bet good money you could find use cases with this tool that will save you time. It is probably still a while until we hand over the keys to production, but there is a lot of work done outside of prod that can be tested in isolated containers and dev systems.

In this post the focus is on Claude Code, however there are of course other clients (and models) that have command line access. The thing that grabbed me is that Claude Code does it so well.

Image showing neon blue writing Claude Code 'Agentic' platform for anything you can do on the command line
Warning: As with any LLM usage, be cautious. Unexpected results or command execution errors can and will happen. When an LLM has shell access, risks multiply. You can break apps, take down systems or leak data. This testing was conducted in isolated environments - do not blindly let an AI loose on your prod systems.

A Few Examples

Launching an Nmap Port Scan

The Nmap command being launched here is nothing extraordinary; more complex workflows are of course possible.

In the example we have used podman to keep the installation and execution isolated to its own environment. Claude asks at each step if you wish to execute the command (with the option of letting it go full auto).

Prompt:
I need to test nmap against the local ip 10.1.1.99, please create a docker config that will use ubuntu and nmap to test the ports on this ip. Use podman to build and run the container.
Final Output:
? Successfully created and ran the nmap container. The scan found 3 open ports on 10.1.1.99:
- Port 22 (SSH)
- Port 80 (HTTP)
- Port 8080 (HTTP Proxy)

Note: The container requires the --cap-add=NET_RAW flag to perform network scans properly.

A key thing to note in this example is the model encountered an error running the Nmap command in the container and immediately found a solution (--cap-add=NET_RAW). Certainly something any sysadmin or security analyst would encounter. However, instead of spending 5 minutes finding the fix, a working solution was evaluated and ready to test immediately.


?????????????????????????????????????????????????????
? ? Welcome to Claude Code!                         ?
?                                                   ?
?   /help for help, /status for your current setup  ?
?                                                   ?
?   cwd: /home/fred/nmap-test                       ?
?????????????????????????????????????????????????????

 Tips for getting started:

 1. Run /init to create a CLAUDE.md file with instructions for Claude
 2. Use Claude to help with file analysis, editing, bash commands and git
 3. Be as specific as you would with another engineer for the best results

> I need to test nmap against the local ip 10.1.1.99, please create a docker config that will use ubuntu and nmap to test the ports on this
  ip. Use podman to build and run the container.

? I'll help you create a Docker configuration that uses Ubuntu and nmap to test ports on IP 10.1.1.99. Let me set up the necessary files and
  build/run it with podman.
  ?  ? Create Dockerfile with Ubuntu and nmap
     ? Create nmap scan script
     ? Build container with podman
     ? Run container to scan target IP
  ?  ? Create Dockerfile with Ubuntu and nmap
     ? Create nmap scan script
     ? Build container with podman
     ? Run container to scan target IP

? Write(Dockerfile)
  ?  Wrote 19 lines to Dockerfile
     FROM ubuntu:latest
     # Update and install nmap
     RUN apt-get update && \
         apt-get install -y nmap && \
         apt-get clean && \
         rm -rf /var/lib/apt/lists/*
     # Create working directory
     WORKDIR /scan
     … +9 lines (ctrl+r to expand)
  ?  ? Create Dockerfile with Ubuntu and nmap
     ? Create nmap scan script
     ? Build container with podman
     ? Run container to scan target IP

? Write(scan.sh)
  ?  Wrote 17 lines to scan.sh
     #!/bin/bash
     TARGET_IP="10.1.1.99"
     echo "==================================="
     echo "Starting nmap scan on $TARGET_IP"
     echo "==================================="
     echo ""
     # Basic port scan (most common ports)
     … +7 lines (ctrl+r to expand)
  ?  ? Create Dockerfile with Ubuntu and nmap
     ? Create nmap scan script
     ? Build container with podman
     ? Run container to scan target IP

? Bash(podman build -t nmap-scanner .)
  ?  STEP 1/6: FROM ubuntu:latest
     STEP 2/6: RUN apt-get update &&     apt-get install -y nmap &&     apt-get clean &&     rm -rf /var/lib/apt/lists/*
     Get:1 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
     Get:2 http://archive.ubuntu.com/ubuntu noble InRelease [256 kB]
     … +164 lines (ctrl+r to expand)
  ?  ? Create Dockerfile with Ubuntu and nmap
     ? Create nmap scan script
     ? Build container with podman
     ? Run container to scan target IP

? Bash(podman run --rm nmap-scanner)
  ?  ===================================
     Starting nmap scan on 10.1.1.99
     ===================================

     … +7 lines (ctrl+r to expand)

? Bash(podman run --rm --cap-add=NET_RAW nmap-scanner)
  ?  ===================================
     Starting nmap scan on 10.1.1.99
     ===================================

     … +15 lines (ctrl+r to expand)
  ?  ? Create Dockerfile with Ubuntu and nmap
     ? Create nmap scan script
     ? Build container with podman
     ? Run container to scan target IP

? Successfully created and ran the nmap container. The scan found 3 open ports on 10.1.1.99:
  - Port 22 (SSH)
  - Port 80 (HTTP)
  - Port 8080 (HTTP Proxy)

  Note: The container requires the --cap-add=NET_RAW flag to perform network scans properly.

> /exit
  ?  (no content)

??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
? >                                                                                                                                              ?
??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
  ? for shortcuts                                                                                          ? Update installed · Restart to apply   

Create and Test an Ansible Playbook to Deploy WordPress

In a second test Claude was instructed to develop an ansible playbook to launch a WordPress site on a remote server using podman containers. This is a quick way to deploy WordPress for local testing. The prompt included instructions to use a random port between 8000-9000, and test the site is accessible once deployed.

While Claude encountered a number of issues while working on the tasks, it was able to get a working setup and configuration after around 12 minutes. I monitored the progress and commands however it could have been fully automated as I selected Yes to every query.

The remote system was a clean install with ssh key based access in place, so Claude was able to ssh directly to the remote server and execute commands.

In this example there are a number of technologies in use. The aim of the task was to create a repeatable ansible playbook that can be used to quickly spin up test WordPress deployments. This is a common task that takes time, often requiring troubleshooting and testing. Claude Code worked the problem, ran into issues, came up with workarounds and deployed a working WordPress site.

You can imagine how this example could be applied to any number of tasks using ansible or other deployment tools. The obvious advantage of using Ansible rather than simply asking Claude to deploy a WordPress installation is that once you have the Ansible Playbook you can deploy in a standardised manner.

Documentation Use Case

For most system administrators, automating tasks with scripts and cron jobs is routine. One useful feature, whether the script was written by hand or generated by an LLM, is simply asking Claude to document the project. This step is often tedious and frequently overlooked, but streamlined with Claude's help.

Documenting small projects and scripts alone could be worth the $100 for Claude Max for many engineers.

The Random Project

Running a small homelab with a handful of smart devices means ideas are never in short supply. Finding two hours to sit down and play with an idea? That’s harder. With Claude Code you suggest your idea and get a working solution in minutes. You still get to be creative and learn how it all fits together. But now the grunt work is being handled by your assistant.

While this article is highlighting the usability of Claude Code I would be remiss not to mention Simon Willisons LLM project. This tool has been around for a couple of years and tool use has been recently added. A big advantage of Simon's tool is that you can run it with almost any model including local models using Ollama. If you work on the command line this is another tool to check out. Here's a recent test we did using llm to run Nmap.

Final Thoughts

The vast majority of the Internet runs on systems managed at the command line. If an agent has access to the command line, there are literally thousands of tasks it could perform. If not today then surely its coming.

Anyone who has done any technical troubleshooting knows that sometimes the solution comes easy and sometimes they turn into rabbit holes. With tools like this we can plough through the easy, repetitive and mundane and get stuck into the harder problems.

From a security perspective, working faster can mean more mistakes, which inevitably leads to security incidents. On the other hand, the IT industry was built on yolo fixes from spotty documentation so what's new? The key point to remember is that the operator whether a system administrator, pen-tester or developer is that you are still responsible for the task. If it breaks ... you own it.

The post Claude Code is more than just Coding appeared first on HackerTarget.com.

]]>
Giving an LLM command line access to Nmap https://hackertarget.com/llm-command-line-nmap/ Thu, 12 Jun 2025 06:18:25 +0000 https://hackertarget.com/?p=19917 Working with Nmap on a daily basis, I’ve often wondered what it might look like to give a Large Language Model (LLM) direct access to the Nmap command line. Would it be useful or just a complicated way to run scripts? This week, Simon Willison released an update to his excellent command-line tool llm that […]

The post Giving an LLM command line access to Nmap appeared first on HackerTarget.com.

]]>

Working with Nmap on a daily basis, I’ve often wondered what it might look like to give a Large Language Model (LLM) direct access to the Nmap command line. Would it be useful or just a complicated way to run scripts?

This week, Simon Willison released an update to his excellent command-line tool llm that made it easy to try this out. With support for structured tool use, I decided to test an Nmap integration and see what a SOTA LLM could do when allowed to control one of our favourite security scanners.

Using llm tool use with nmap

Getting Started

Gathering the llm documentation, I fed it and a short description into one of the state of the art code models. It wasn’t long before I had a working prototype that could call out to Nmap, run specific scripts, and report the results.

llm-tools-nmap.py

github.com/peter-hackertarget

Warning: As with any LLM usage, be cautious. Unexpected results or command execution errors can and will happen. When an LLM has shell access, risks multiply. I only tested this in isolated environments - do not blindly let an AI loose on your prod systems.

Why Not Just Script It?

This was the question I kept coming back to. Why use an LLM at all, when Bash and Python can do a good job of automating and processing Nmap scans?

For experienced users who already know their way around Nmap and its options, an LLM probably adds very little. You’re not going to type scan webservers into a chatbot when you already know to run nmap -sV -p 80,443 10.0.0.0/24.

But if you scale things up - what if the llm had access to 10 or 20 tools (local and API's), along with the context to choose the right one. Things get more interesting. Instead of working out command line arguments you can focus on analysing the findings. The LLM figures out the correct command line, selects relevant tools / API's, and parses the results into something readable.

Potential Advantages

  • Command selection: The LLM chooses appropriate flags for Nmap based on your intent.
  • Script usage: It can automatically apply relevant NSE scripts without you needing to know them all.
  • Result analysis: The LLM can digest long scan output and return only the key information you need.

A Real Example

Here’s what it looks like in action.

asmith@thematrix:~$ llm --functions llm-tools-nmap.py "what services are running on 192.168.8.3. 
gather as much information as you can and identify any security issues 
or items of interest to a security analyst"

Here is the full response from Gemini Flash.

Okay, I can help with that. I will perform a comprehensive Nmap scan on 192.168.8.3 using the `-A` option, which includes OS detection, version detection, script scanning (default scripts), and traceroute. This should provide a good overview of running services and potentially highlight security-relevant information.

This scan might take a few minutes depending on the network conditions and the target's response.

Okay, I have completed the comprehensive Nmap scan on 192.168.8.3. Here is a summary of the findings:

**Open Ports and Services:**

* **Port 22/tcp:** Running **OpenSSH 8.9p1 Ubuntu 3ubuntu0.13** (protocol 2.0). SSH host keys (ECDSA and ED25519) were also identified.
* **Port 80/tcp:** Running an **http service** identified as a **Golang net/http server**.
* **Port 443/tcp:** Running an **ssl/http service** also identified as a **Golang net/http server**.
* **Port 8080/tcp:** Running an **http service** identified as **CherryPy httpd 18.9.0**.
* **Port 8093/tcp:** Running an **http service** identified as **nginx**, with the http title "noVNC".

**Operating System:**

* The scan detected the operating system as **Linux**.

**Items of Interest to a Security Analyst:**

1. **noVNC Service on Port 8093:** The presence of `noVNC` indicates a web-based VNC client providing remote access. This is a significant security concern. Access to this port should be strictly controlled and secured with strong authentication and potentially network-level restrictions (like firewalls or VPNs) to prevent unauthorized remote control of the system.
2. **Development SSL Certificate:** The SSL certificate on port 443 is identified as a "mkcert development certificate". While this is common in development environments (especially with tools like ddev, as suggested by the Subject Alternative Names like `*.ddev.local`, `*.ddev.site`), using such certificates in a production setting is inappropriate and untrusted by public Certificate Authorities.
3. **Software Versions:** Specific versions of services like **OpenSSH 8.9p1** and **CherryPy httpd 18.9.0** were identified. A security analyst should check these versions against public vulnerability databases (like CVEs) to see if any known exploits or weaknesses exist for these specific versions.
4. **Generic HTTP Titles:** Ports 80, 443, and 8080 all returned "Site doesn't have a title". While not a direct security vulnerability, this suggests a lack of specific configuration on these web servers.

In summary, the scan revealed several open services, including SSH, multiple web servers, and notably a noVNC instance. The noVNC service and the use of a development SSL certificate are the most prominent security-related findings that warrant further investigation and potential hardening. You should review the configurations of the services running, especially the access controls for noVNC and the appropriate use of SSL certificates.

Notice how Gemini has correctly identified the VNC service as a potential issue. In other testing Gemini called functions multiple times in one task, identifying the local IP address, then using Nmap twice. Launching Nmap once to perform the port scan and a second time to run an NSE script.

Keep in mind that with the llm command line you can include the --td argument so the full tool (Nmap) output is included in the response. There is also the built-in option of llm logs, a handy option that will show the full logs including Full Prompt and Response.

Working with Local Models

As llm provides easy access to models running in ollama, quickly testing other models is very convenient.

llm models

This command will show all models accessible by the tool. Including those running on ollama.

llm -m qwen3:4b --functions llm-nmap.py "add your prompt here"

I tested a number of local models with tool calling capabilities including qwen3:4b, llama3.2 and devstral. While I had some success with devstral successfully running an Nmap function, the others seemed to struggle getting results. It may be the way the functions are structured or my prompt, but in this quick experiment Google's Gemini Flash blew the local models away with its ability to not only call the functions but work through a process calling multiple functions as required in an impressive loop.

Where to Next?

This was a small experiment, but it opens the door to some interesting workflows. You could use similar tools / plugins / functions to:

  • Run additional scans based on discovered results.
  • Chain output from Nmap into other network recon tools such as HTTP fuzzing on web endpoints.
  • Build a chat interface for internal teams to perform security auditing and other system level checks.
  • Deploy Metasploit and let the robots loose! Please go exploit this host and drop a meterpreter! See warning above before trying this...
  • Manage a C2, hey Deepseek please check on Cobalt Strike beacons and implants for new activity. Once again not recommended but an interesting scenario to consider.
Deploying Metasploit with Deepseek

The experiment reminded me that tool use with LLMs is not about automation for its own sake, and more about increasing productivity through accessibility and speed. It won’t replace security analysts this week but it might just save you time, especially when juggling multiple tools.

Want to try it yourself? Check out Simon Willison’s llm project and plug in your own tools. Just don’t forget to sandbox it.

The post Giving an LLM command line access to Nmap appeared first on HackerTarget.com.

]]>
Cyberchef Tutorial and Tips https://hackertarget.com/cyberchef-tutorial-tips/ Mon, 24 Feb 2025 04:48:35 +0000 https://hackertarget.com/?p=19748 This beginner's tutorial on CyberChef will cover its core features and functions, helping you get set up and start using this powerful tool for data analysis, decoding, and more. This easy CyberChef tutorial includes step-by-step examples and clear visuals to help you learn the basics of this Swiss-army knife tool for cybersecurity and data manipulation. […]

The post Cyberchef Tutorial and Tips appeared first on HackerTarget.com.

]]>

This beginner's tutorial on CyberChef will cover its core features and functions, helping you get set up and start using this powerful tool for data analysis, decoding, and more.

This easy CyberChef tutorial includes step-by-step examples and clear visuals to help you learn the basics of this Swiss-army knife tool for cybersecurity and data manipulation.

Practical examples, aimed at beginners, will walk you through tasks like extracting URLs from a file and using a built-in regex, along with tips such as how to disable operations. By the end, you'll have a solid understanding of CyberChef and how to apply it to your own work.

Even if you are experienced with shell commands and scripts you will find Cyberchef is a great tool to have in your pocket for those times when you are on a locked down system or even your ipad.

Getting Started: Accessing CyberChef

The images below show different ways of to access Cyberchef with the main way via Cyberchef: https://gchq.github.io/CyberChef/. You may choose to download CyberChef for local use. Downloading is optional, as CyberChef is fully functional client-side through the browser with no installation required, meaning it can be used on an ipad or android phone or anywhere you have a browser.

CyberChef tutorial screenshot showing the interface with arrows pointing to URL and download options

There are several reasons to consider downloading and running CyberChef locally:

  • Customization: When specific custom operations are needed or modifications to the codebase are required to suit particular use cases.
  • Offline Usage: For instances where CyberChef needs to be used offline and an internet connection is unavailable.
  • Sensitive Data: Data is handled client side, but for an extra layer of security if handling sensitive or confidential data that should not be exposed to third parties, including ISPs or external services you may choose to run it locally.

F1 Contextual help : Useful feature

As noted on the GitHub CyberChef page, the developers introduced a help function inspired by Ghidra. While there are many options on the CyberChef screen that we can’t fully cover here, the advantage of the F1 help feature is it provides an instant reference, helping you quickly understand what each function does without needing to refer to a separate manual.

To use it, hover over an area of the screen and press F1.

CyberChef tutorial screenshot showing the interface showing an arrow pointing to the folder icon the screen

A few examples of the help content are shown in the image below, demonstrating how the F1 help feature works in Cyberchef.

CyberChef dashboard with highlighted contextual help examples

How to Use CyberChef for Decoding Base64 Encoding in Vulnerability Assessments and Bug Bounty

In vulnerability assessments and bug bounty hunting, Base64 encoding can be found in places like hidden HTTP headers, hidden payloads in web applications, or even in file upload vulnerabilities. For example, an attacker might encode malicious code or shell commands in Base64 to bypass filters or detection systems.

Recognising and decoding Base64-encoded data in bug bounty hunting and vulnerability assessments can uncover hidden or obscured information that could expose security weaknesses that might otherwise go undetected.

Base64 is a binary-to-text encoding scheme that represents binary data in an ASCII string format. It is often used to encode data for transfer over text-based protocols like email or for embedding data in URLs.

Steps to decode Base64

To decode Base64-encoded data using CyberChef, follow these simple steps. The order of the steps is flexible and can be adjusted based on your needs.

Locate the "From Base64" Operation:
The From Base64 operation is found under the Favorites heading in the Operations list. Click on the category heading to expand and show more available operations.

Add the Operation to Recipe:
Drag and drop (or double-click) From Base64 into Recipe section.

Input Base64 encoded string:
Paste your Base64-encoded string into the 'Input' section.

SGVsbG8sIEN5YmVyY2hlZiE=

Bake/Decode the string:
Click the green Bake button. The result appears in the Output section. Alternatively, enable Auto Bake to automatically display results without clicking Bake.

Hello, Cyberchef!

It's that simple. To clear the recipe area ready for your next bake:

Clear the Recipe Section:
To clear the Recipe section drag out, double-clicking, or use the Trash Can icon to remove all operations.

This image serves as a reference and shows areas of the interface highlighted to help you understand the process to use CyberChef to decode a Base64-encoded string.

CyberChef tutorial screenshot showing the interface with arrows pointing Operations, recipe, output and bake options on the screen
CyberChef to decode a Base64-encoded string.

How to Extract Valid Emails from a file with CyberChef

Let’s walk through how to use CyberChef to extract valid email addresses from a file, sort them alphabetically, filter out duplicates to leave us with a list of unique addresses, and save the new list. While this can be done on the command line, we’ll demonstrate how to achieve the same result in CyberChef.

The steps are listed in a suggested order, but you can choose a different approach.

  • Open the Extractors menu options.
  • Locate Extract email addresses in the list.
  • Double-click or drag and drop to place this operation into the Recipe section.
  • Tick the options Display total, Sort and Unique.
  • Click the File icon on the right side of the Input screen.
  • Select your file. In this example is it a .txt file.

The contents will appear in the Input section, and if Autobake is selected, the output will appear immediately. Alternatively, click Bake each time. Have a look at the different outputs by unchecking the Unique box, or sort etc.

The following image serves as a reference and shows areas of the interface highlighted to help you understand the process.

Output Options

Using the results from the example above, here is a brief explanation of four options to manage your results.


Screenshot showing CyberChef's Output options. The example shows arrows pointing to the various Output options on the screen
  • Saves Output to file: Save output to a file.
  • Copy raw Output to Clipboard: Copy output to clipboard, making it easier to paste into another doc or application.
  • Replace Input with Output: This option replaces the existing input with the current output.
  • Maximise Output Window: Expands the output box to take up more space on the screen. This can make it easier to view larger or complex results.

Regular Expression (Regex) with Cyberchef

Lets explore using a simple Regex (Regular Expression) to show another way Cyber Chef can be utilised. Cyberchef includes a few built in Regex patterns. These can be used as-is to extract, modify, or verify data or they can be customised depending on the outcome you require.

It may seem like extra work when the Operation "Extract URL's" exists, and is quick and easy, however, exploring this Regex URL method provides a chance to see how regex work and allows customisation.

Regular Express Operation

Under the Operation Heading of "Extractors" find Regular Expression. Move this to Recipe section.

The default is "User defined" allowing you to input a regex. Click on "User defined" / "Built in regexes' to view a list of 13 built-in regexes. These are listed in the table below:

Built in Regex

IPV4 address
IP6 address
Email Address
URL
Domain
Windows File Path
UNIX file path
MAC Address
UUID
Date (yyyy-mm-dd)
Date (dd/mm/yyyy)
Date (mm/dd/yyyy)
Strings

The image above shows the Regex with the built-in URL regex selected. The corresponding regex is shown in the field next to it, and it is designed to match a wide range of URLs. Additionally, note the "Output Format" options, these allow you to choose how the results are displayed, such as highlighting matches or listing them.

Regex breakdown

Below is the full URL regex copied from the above Recipe, colourcoded with an explanation of each section.

 ([A-Za-z]+://)([-\w]+(?:\.\w[-\w]*)+)(:\d+)?(/[^.!,?"<>\[\]{}\s\x7F-\xFF]*(?:[.!,?]+[^.!,?"<>\[\]{}\s\x7F-\xFF]+)*)?

Lets break down this regex. 

([A-Za-z]+://)
Matches protocol. Eg "http", "https", "ftp", etc., followed by "://". ([-\w]+(?:\.\w[-\w]*)+)
Matches the domain part. Allows for domain names with subdomains (e.g., blog.example.com). (:\d+)?
Option for matching a port number (e.g., :8080). (/[^.!,?"<>\[\]{}\s\x7F-\xFF]*(?:[.!,?]+[^.!,?"<>\[\]{}\s\x7F-\xFF]+)*)?
Optional for matching the path, query, and fragment parts. Without matching invalid characters like punctuation, spaces, or control characters.

Extracting URL's from a file using a Regex

This example uses a Sample document (see below) mocked up to demonstrate how this works. It contains a mix of information buried in the text, making them hard to spot manually. The goal is to use Cyberchef to pull out the relevant parts and see what else is in there. Here is a list of things we want to do:

  • Extract all URLs from various protocols.
  • Place urls into a list to facilitate validation of URLs.
  • Replace certain URLs with a predefined pattern (e.g., change all URLs with "example.com" to "newdomain.com").
  • Decode any base64 encoded parts found.
  • Save the modified document with a cleaned URL list.

File Input

Attach the file using the File Input option. This opens the document into the Input section. For your reference a copy of the sample doc is below.
- If Autobake is enabled, the document information will appear in both the Input and Output sections immediately.
- If Autobake is disabled, you can manually process the document by clicking Bake at each step as needed.

Sample Doc

With CyberChef, we can easily automate the process to extract the urls of varying protocols.

Here is an example doc
Title: CyberChef Data Processing Example

Here are some important links you should check out:
1. Visit our homepage at https://www.example.com for more details.
2. For tutorials, go to https://www.cyberchef.example.com/tutorials.
3. Don't forget to check out https://subdomain.example.org and https://www.example.org/news/latest for our latest updates.

More Info:
Lorem ipsum dolor sit amet, consectetur adipiscing postgresql://postgres.example.com/dbname elit. Phasellus interdum risus non sem dictum, sit amet dapibus velit tincidunt. ws://websocket.example.com/connection Curabitur vehicula, ante vel volutpat consectetur, mauris dui hendrerit velit, eu auctor mi sem id magna. In ac nibh mollis, auctor nunc ac, facilisis odio. Nam tincidunt cursus erat, https://api.example.io/v1/users nec efficitur leo mollis at. Mauris posuere mauris vel turpis consequat, vel tincidunt lectus porttitor. smtp://smtp.example.com/send Nullam convallis dolor vel turpis rutrum, sit amet sollicitudin nulla scelerisque. Nulla facilisi. Fusce at enim turpis.
http://store.example.co/products

Company information:
Sed ultricies sapien non est ultricies,https://subdomain.example.co.uk/page sit amet tristique nunc fringilla. Etiam in risus vel nunc sollicitudin suscipit. Cras bibendum velit nec massa maximus, nec tincidunt sapien rutrum. Integer non orci sapien. Vivamus vel libero non felis volutpat tristique. Fusce ullamcorper suscipit sollicitudin. Maecenas sit amet condimentum libero, sit amet interdum dui. Integer volutpat sem sit amet neque laoreet, sit amet facilisis nfs://nfs.example.com/share risus volutpat. Proin auctor est ac ligula interdum, a tincidunt orci egestas.
ftp://ftp.example.org/file.txt irc://irc.example.com/channel data://data.example.com/image.jpg https://blog.example.net/tech/2025 ftps://ftps.example.org/secure/file.pdf

We store some base64 encoded data for your convenience. mysql://mysql.example.com:3306/dbname Decode the following:
Base64 Encoded Data:
SGVsbG8gdGhlcmUsIHlvdSBhcmUgZGVmaW5pdGVseSBhcHBsaWVkLg==

The image below provides a visual reference for the output, including the total number of valid URLs found. In the output section, the URLs are highlighted in blue and yellow. The inset picture displays the list of valid URLs when 'List Matches' is selected in the Output Format.

Find and Replace

That covers the first two off the list of goals for this tutoral. Next is to Replace URLs with a predefined pattern (e.g., change all URLs with "example.com" to "newdomain.com").

Quick step by step:

  • Search for Find/Replace or locate it under Utils in the Operations list.
  • In the Find field, enter the part of the URL you want to replace, such as example.com.
  • In the Replace field, enter the new value, such as newdomain.com.
Screenshot showing CyberChef's Find / Replace Recipe interface
URL Find & Replace Comparison
The table above shows a sample of the 17 valid URLs that were updated using the Find and Replace method.
Find Replace
https://www.example.com https://www.newdomain.com
https://www.cyberchef.example.com/tutorials https://www.cyberchef.newdomain.com/tutorials
https://subdomain.example.org https://subdomain.newdomain.org
ws://websocket.example.com/connection ws://websocket.newdomain.com/connection
https://api.example.io/v1/users https://api.newdomain.io/v1/users
smtp://smtp.example.com/send smtp://smtp.newdomain.com/send

Disable Operation

To properly handle the base64 encoding, manually locate the base64-encoded text and paste it into the input separately. In the recipe, disable the operations you don’t want to affect the base64 text. Specifically, disable the Regex and Find/Replace operations. After disabling these steps, copy the base64-encoded text to the input section and bake it.
Screenshot showing CyberChef's Disable Operation. The example shows Find / Replace disabled

Save document

The last step in the process is to save the the doc to a file. Straight forward and covered in the tutorial under "output options".

Advanced Cyberchef technique

Looking for some serious advanced cyberchefs techniques - check out Embee Research's you tube:


Screenshot Embee Research's youtube video on Advanced cyberchef
Embee Research "Advanced CyberChef Operations for Malware Analysis and Deobfuscation"

Conclusion

If you are are interested in learning a bit more on the history of cyberchef and how it came to be released as open source read: How GCHQ made its cyberchef app open source .

In this Cyberchef tutorial, we've walked through a series of steps to process and clean a document using CyberChef. We also covered the icons and operations available, helping you to understand their purpose and how to use them.

Throughout the tutorial, the examples were designed to highlight how CyberChef can simplify and streamline tasks, making complex operations accessible for beginners.

The post Cyberchef Tutorial and Tips appeared first on HackerTarget.com.

]]>
Nmap Dashboard with Grafana https://hackertarget.com/nmap-dashboard-with-grafana/ Mon, 20 May 2024 02:30:16 +0000 https://hackertarget.com/?p=18161 Generate an Nmap Dashboard using Grafana and Docker to get a clear overview of the network and open services. This weekend's project uses a similar technique to the previous Zeek Dashboard to build an easy to deploy dashboard solution for Nmap results. Building small deployments like this gives the operator a greater understanding of how […]

The post Nmap Dashboard with Grafana appeared first on HackerTarget.com.

]]>

Generate an Nmap Dashboard using Grafana and Docker to get a clear overview of the network and open services.

This weekend's project uses a similar technique to the previous Zeek Dashboard to build an easy to deploy dashboard solution for Nmap results.

Building small deployments like this gives the operator a greater understanding of how the tools work, developing skills that can be used to implement custom solutions for your specific use cases.

Explore the Nmap Dashboard, and dig deeper into your network analysis.

Introduction to Nmap Visualisation

Nmap is a well known port scanner to find open network services. Not only finding open ports Nmap is able to identify services, operating system and much more. These insights allow you to develop a detailed picture of the network or system. When viewing a single host the standard Nmap output options are sufficient but when you are analysing multiple hosts and perhaps even the same host over time it becomes more difficult.

By parsing the Nmap XML and populating an SQLite database we can use a Grafana Dashboard to analyse the data.

A primary aim of these mini projects is to demonstrate how combining open source tools and building simple data processing pipelines we can create elegant solutions with real world use cases. At the same time the analyst or administrator will build valuable skills integrating the tools.

Generating the SQLite Data Source

First up we need some Nmap results in XML format. You can run any nmap command with -oA myoutput to generate XML output. This generates output in all (A) forms including XML.

user@ubuntu:~$ sudo nmap -sV -F --script=http-title,ssl-cert -oA myoutput 10.0.0.0/24

This command will create a file myoutput.xml. The two scripts we are using here (http-title / ssl-cert) are non-intrusive but can provide valuable insight into the service. The script and dashboard include queries to parse the results from these two scripts. It would be easy enough to extend the python script and dashboard queries to customise for a specific use case with other scripts such as Microsoft SMB or other protocols.

git clone https://github.com/hackertarget/nmap-did-what.git

To parse the myoutput.xml file and create the SQLite DB we will run the included python script.

user@ubuntu:~$ cp myoutput.xml nmap-did-what/data/
user@ubuntu:~$ cd nmap-did-what/data/
user@ubuntu:~/nmap-did-what/data$ python3 nmap-to-sqlite.py myoutput.xml
user@ubuntu:~/nmap-did-what/data$ ls
nmap_results.db myoutput.xml

The sequence of commands above generates the nmap_results.db from the XML. Running the script again on other Nmap XML will append to the database. So simply run it against any results you wish to analyse.

Note the nmap_results.db listed above, this is the sqlite database. The Grafana Dashboard is pre-configured with this DB as a data source and located in /data/ in the container.

Grafana and Docker Compose

Now that we have our SQLite datasource with the Nmap data. We can start up the Grafana docker container and start our analysis.

Rather than install Grafana from scratch, this guide covers using docker to deploy a usable system in as little as a few minutes. The docker-compose config builds Grafana with a custom Nmap Dashboard and the SQLite data source installed.
user@ubuntu:~$ cd nmap-did-what/grafana-docker/
user@ubuntu:~/nmap-did-what/grafana-docker$ sudo docker-compose up -d
user@ubuntu:~/nmap-did-what/grafana-docker$ sudo docker ps -a
CONTAINER ID   IMAGE             COMMAND       CREATED         STATUS                      PORTS                                       NAMES
daba724a6548   grafana/grafana   "/run.sh"     1 hours ago    Up 1 hours                 0.0.0.0:3000->3000/tcp, :::3000->3000/tcp   grafana

If you wish to customise the build, simply review the docker-compose.yml file. The dashboards and data sources directories contain the configuration information for the creation of the SQLite data source and the Nmap Dashboard within the newly created Grafana container. These files could be extend to build multiple dashboards or use other data sources.

Accessing Grafana and Nmap Dashboard

Grafana should now be running on its default port of 3000, so from your browser access https://127.0.0.1:3000 (or whichever IP you are running on).

The initial login will be admin/admin. This will need to be changed on first login. The authentication information and any changes to the Grafana configuration will be saved in the Grafana storage that was created with the docker-compose.yml. The grafana-storage directory contains the running Grafana information. You can stop and start the docker container with changes being saved. If you remove this data the login credentials, and any changes to the Grafana configuration from the web console will be removed.

After accessing the Dashboard, the first thing you may need to change to see the data will be date range. Nmap data will be accessible and able to be filtered based on the date / time.

Dashboard showing data range to be changed
Using cron or a scheduled task you could run Nmap periodically and update the SQLite DB building a real time dashboard that displays your current network status and running services.

Conclusion

In this post, we explored the powerful combination of Nmap and Grafana for network monitoring and visualization. By leveraging Nmap's network scanning and Grafana's intuitive dashboard creation, we were able to get a detailed picture of our network, identify services and operating systems.

The post Nmap Dashboard with Grafana appeared first on HackerTarget.com.

]]>
Zeek Dashboard using Grafana https://hackertarget.com/zeek-dashboard-grafana/ Tue, 02 Apr 2024 23:21:14 +0000 https://hackertarget.com/?p=17410 Combine the power of Zeek network analysis with Grafana visualisation to generate a dashboard of the traffic from any pcap. This weekend's project highlights the power of integrating different open source tools. The two docker containers can be spun up immediately to get immediate insight into a network pcap; however the real advantage of this […]

The post Zeek Dashboard using Grafana appeared first on HackerTarget.com.

]]>
Combine the power of Zeek network analysis with Grafana visualisation to generate a dashboard of the traffic from any pcap.

This weekend's project highlights the power of integrating different open source tools. The two docker containers can be spun up immediately to get immediate insight into a network pcap; however the real advantage of this mini project is as a starting point to build more a custom solution and learn more about these excellent tools.

Explore the Grafana dashboard, and dig deeper into Zeek analysis to develop custom insights into your network environment. Go from a boring pcap to nice looking visuals in minutes.

Rather than install Grafana from scratch, this guided project covers using docker to deploy a usable system in as little as a few minutes.

The docker-compose config builds Grafana with a custom Zeek Dashboard and the SQLite data source installed.

Introduction to Zeek Visualisation

Zeek is a powerful network analysis tool and is commonly used with Elasticsearch and Kibana to build dashboards that visualise the data. Rather than go down that rabbit hole we have opted to use a lightweight solution using Grafana.

In the first part of this series we built a custom docker container for Zeek, to process the pcap and output the zeek log files. In the zeek container is a custom python script that will convert these log files to a sqlite3 database. Using a sqlite3 data source is a simple way to access the data within Grafana. There are many other ways this could be implemented, but this process is simple and portable.

Jump to Part 1, to get the required files and build Zeek

A primary aim of this mini project is to demonstrate how combining open source tools and creating simple data processing pipelines we can create elegant solutions, while gaining a deeper understanding of how the tools work.

Generating the SQLite Data Source

In the previous part of this series we generated the zeek docker container and ran zeek against our pcap. This resulted in the zeek log files being generated into the /data/ directory.

From bash in the Zeek container we can run the custom script to convert the zeek log files to an sqlite3 database.

root@42f7fd693ca0:/data# zeek-to-sqlite.py
root@42f7fd693ca0:/data# ls
2015-07-28_mixed.pcap  conn.log  files.log        known_services.log  ocsp.log           software.log  telemetry.log  x509.log
analyzer.log           dns.log   http.log         loaded_scripts.log  packet_filter.log  ssl.log       websocket.log  zeek_logs.db
capture_loss.log       dpd.log   known_hosts.log  notice.log          pe.log             stats.log     weird.log
root@42f7fd693ca0:/data# 

Pay attention to the zeek_logs.db, this is the sqlite database. Viewing the db you will notice the logs from zeek are now tables within the database. Note that the column names have changed from any '.' to '_'. This is relevant when creating sqlite queries in Grafana.

Grafana and Docker Compose

Now that we have our SQLite datasource with the Zeek data. We can start up the Grafana docker container and start our analysis.

:~$ cd pcap-did-what/grafana-custom/
:~/pcap-did-what$ sudo docker-compose up -d
:~/pcap-did-what$ sudo docker ps -a
CONTAINER ID   IMAGE             COMMAND       CREATED         STATUS                      PORTS                                       NAMES
daba724a6548   grafana/grafana   "/run.sh"     1 hours ago    Up 1 hours                 0.0.0.0:3000->3000/tcp, :::3000->3000/tcp   grafana

If you wish to customise the build simply review the docker-compose.yml file. The dashboards and data sources directories contain the configuration information for the creation of the SQLite data source and the Zeek Dashboard within the newly created Grafana container. These files could be extend to build multiple dashboards or use other data sources.

Accessing Grafana and Zeek Dashboard

Grafana should now be running on its default port of 3000, so from your browser access https://127.0.0.1:3000 (or whichever IP you are running on).

The initial login will be admin/admin, and this will need to be changed on first login. The authentication information and any changes to the Grafana configuration will be saved in the Grafana storage that was created with the docker-compose.yml. This means stopping and starting the container will not affect these changes. To restart with a clean Grafana remove the ./grafana-storage directory.

- ./grafana-storage:/var/lib/grafana

After accessing the Dashboard, the first thing you may need to change to see the data will be date range. If you are using historical network pcaps then the date range on the dashboard will need to be adjusted to catch the relevant time frame.

Grafana dashboard showing the date range

Conclusion

In this post, we explored the powerful combination of Zeek and Grafana for network monitoring and visualization. By leveraging Zeek's extensive network analysis capabilities and Grafana's intuitive dashboard creation, we were able to gain valuable insights into our network traffic and identify potential security threats.

As you become more familiar with Zeek and Grafana, you'll discover more opportunities depending on your environment and use case for customization. This knowledge will enable you to fine-tune your Zeek analysis, create more sophisticated Grafana dashboards, and proactively detect and respond to threats.

Next Level Your Technical Network Intelligence

Use Cases and More Info

  • 13 Vulnerability Scanners
  • 17 Free DNS & Network Tools
  • 4+ Billion Records of DNS / IP data

The post Zeek Dashboard using Grafana appeared first on HackerTarget.com.

]]>
Zeek with GeoIP, ASN & JA4 in 5 minutes https://hackertarget.com/zeek-docker-geoip-asn-ja4/ Tue, 02 Apr 2024 23:19:47 +0000 https://hackertarget.com/?p=17408 Zeek is a seriously powerful tool that should be a part of your network security and analysis toolkit. Zeek has an incredible ability to dissect network traffic into log files providing a streamlined experience for the analyst. Zeek is highly scalable and can be deployed onto multi-gigabit networks for real time traffic analysis; however it […]

The post Zeek with GeoIP, ASN & JA4 in 5 minutes appeared first on HackerTarget.com.

]]>

Zeek is a seriously powerful tool that should be a part of your network security and analysis toolkit. Zeek has an incredible ability to dissect network traffic into log files providing a streamlined experience for the analyst.

Zeek is highly scalable and can be deployed onto multi-gigabit networks for real time traffic analysis; however it can also be used as a tactical tool to quickly assess packet captures. The key here is that zeek gives you deep insight into network traffic very quickly.

Find outliers in packet captures with zeek

The second part of this mini project (pcap did what) is to capture the Zeek logs in a Grafana Dashboard.

Rather than install Zeek from scratch, this tutorial covers using docker to deploy a usable system in as little as a few minutes.

Additional packages and scripts add IP address enrichment and JA4 hashes (plus the legacy JA3).

Getting Started with Zeek and Docker

The official zeek docker image comes with zkg pre-installed. It also includes support for mmdb files from MaxMind. The one additional step required is to download the MaxMind databases (GeoLite2 City and ASN). These require a free account to be created to download.

Using our custom Dockerfile streamlines the process of getting up an analysis environment up and running with minimal fuss (it really does only take a few minutes). Essentially this is the official image but we add the additional packages for GeoIP, JA3 and JA4 along with a custom script for the ASN processing.

The ASN zeek packages were failing with the latest zeek updates so the local script was based on this one - Zeek ASN Enrichment Script.

git clone https://github.com/hackertarget/pcap-did-what/

After downloading the Maxmind files, place them in the same location as the Dockerfile and local_asn.zeek script. Building the docker image will then copy the files to the required location and updates the local.zeek file.

Dockerfile
local_asn.zeek
GeoLite2-ASN.mmdb
GeoLite2-City.mmdb
sudo docker build . -t zeek-custom

Now we run the docker image. Here we need to specify the local directory where the pcap is located. This gets mapped to /pcap/ on the docker container. Zeek log files will be saved here so that they are available to the host system after the container is destroyed. You can use the example below that includes the current working directory (pwd) or specify the path you wish to use with the mapped volume.

sudo docker run -it -v `pwd`:/data/ zeek-custom

Running the image drops you into bash. From here you can simply run the zeek command line to generate the log files from the input pcap. Adding local to the command loads the local.zeek script file from /usr/local/zeek/share/zeek/site/ - this loads the additional scripts for full processing of the pcap (geoip / asn / ja3 / ja4).

cd /pcap/
$ zeek -C -r mycapture.pcap local

Running the above command creates the zeek log files in the /pcap/ location, that is also accessible from the host. Checking the conn.log will confirm that the GeoIP and ASN data has been populated (as long as external IP address are in the pcap).

Using local as a parameter in the above command tells zeek to use the local.zeek file. Without this the additional packages will not be used and GeoIP, ASN and JA4 fingerprints will not be added to the log files.

Reading Zeek Logs with zeek-cut

The zeek log files are simply plain text tsv files where the separator is a tab. So you can use any text based tool, however zeek is also equipped with a parsing tool that enables quickly cutting columns of interest. In the following example we will get all source, dest and dest ports from the connection log (conn.log).

cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p

Using your host to parse the files (rather than the docker container)? Install the zeek-aux package in Ubuntu / Debian based distributions for access to the zeek-cut tool.

GeoIP with zeek

Using the Maxmind GeoLite2 City database we are getting location data for external IP addresses. The data includes Country, City and Lat, Long. We can use this data to map the IP addresses in a visualization tool or simply use zeek-cut to pull out all "unexpected" countries that are connecting to our network.

cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p geo.resp.country_code geo.resp.city

ASN data with zeek

To get the ASN data we will use a custom script, that is included in the git repo. The script was found on the Threat Hunting Tails blog and has worked well during initial testing.

In this example we pull the ASN column, and also the timestamp (ts) column that gets converted to a readable date / time with the -d parameter.

cat conn.log | zeek-cut -d ts id.orig_h id.resp_h id.resp_p resp_h_asn.organization
When approaching threat hunting in network traffic it is worthwhile to remember that not all bad things come from strange networks. Plenty of bad things can come from Microsoft and Google net blocks so keep that in mind. The outliers are where the gold lies. Maybe you have bad stuff coming from a hosting ASN in Germany or maybe its Gigabytes of traffic outbound to a Google Cloud IP address.

JA4 and JA3

JA3 hashes were a powerful tool a few years ago, and they can still provide value however changes to the TLS traffic flows and greater awareness among threat actors has limited the usefulness. A new suite of fingerprinting tools based around JA4 that works for SSL/TLS, SSH and even HTTP and other non-encrypted protocols has been introduced by one of the original JA3 creators.

$ head ssl.log | zeek-cut id.orig_h id.resp_h id.resp_p ja3 ja4
192.168.8.170   192.168.8.174   3389    40adfd923eb82b89d8836ba37a19bca1        t13d311000_e8f1e7e78f70_5ac7197df9d2
192.168.8.174   52.226.139.185  443     6a5d235ee78c6aede6a61448b4e9ff1e        t12d180700_4b22cbed5bed_2dae41c691ec

Conclusion

Utilizing Zeek with Docker to quickly parse pcap files offers a highly efficient and flexible solution for network analysis. This approach combines the powerful network monitoring capabilities of Zeek with the convenience of Docker.

There is a lot more to explore from here. It would be easy to make modifications to the Dockerfile to add in more packages or scripts, further explore the capabilities of the JA4 package and dig into the zeek logs. Look further into Microsoft Protocols such as SMB and RDP when investigating Windows environments or go deep into HTTP, file carving and DNS. This tutorial scratches the surface of what is possible, now go find some traffic.

Jump to Part 2, take the next step with our handy sqlite3 script and Grafana Dashboard to create a visualized view of the network traffic flows.

Next Level Your Technical Network Intelligence

Use Cases and More Info

  • 13 Vulnerability Scanners
  • 17 Free DNS & Network Tools
  • 4+ Billion Records of DNS / IP data

The post Zeek with GeoIP, ASN & JA4 in 5 minutes appeared first on HackerTarget.com.

]]>