Penetration Testing in Rennes: Testing the Chain of Trust Before a Supply-Chain Attack

Other

During a penetration test in Rennes, on a system exposed to the Internet, the entry point was neither an end-of-life VPN appliance nor a high-profile CVE. The real problem stemmed from a trust relationship between a partner portal, a poorly segmented remote access point, and overly permissive technical accounts. This is exactly what makes a penetration test valuable for a modern organization: it’s not just about finding a vulnerability, but about demonstrating how an external dependency can become an attack vector. This cybersecurity audit conducted in Rennes is particularly relevant when examining the attack surface, third-party access points, Active Directory, APIs, and the trust mechanisms that connect the IT system to its ecosystem.

Rennes: a dynamic economic landscape, and thus a broader scope for growth

Rennes presents a particularly interesting profile from an “offensive security” perspective. The metropolitan area highlights several strategic sectors, notably digital technology, cybersecurity, health and biotechnology, agriculture and sustainable food, mobility, and the creative industries. This concentration of interconnected sectors involves a great deal of data exchange, shared portals, APIs, VPNs, and integrated cloud services. Simply put, the more seamless the ecosystem is for business operations, the more the chain of trust becomes a distinct audit focus.

For a city like Rennes, whose municipal population remains below 300,000, it makes more sense to discuss sectors rather than randomly naming local companies. Why do companies in Rennes need a more in-depth corporate penetration test than a simple scan? Because an attacker doesn’t think in terms of “websites” or “servers.” They think in terms of access paths:

  • a vendor account with too many permissions;
  • a B2B API exposed without adequate controls;
  • a forgotten subdomain linked to SSO;
  • an accessible machine that then allows for lateral movement;
  • an application secret reused across multiple environments.

The most accurate metaphor is not that of a fortress, but rather that of a logistics hub. The main gate may be fortified, but if temporary badges, side docks, and maintenance contractors are moving freely throughout the facility, the attack will come through the secondary access points.

How did this penetration test in Rennes go, in a modern environment?

For more information on pentesting : https://www.hackmosphere.fr/test-intrusion/

A thorough penetration test follows a step-by-step approach. The goal is not to “make a fuss” with tools, but to provide a credible demonstration of business risk.

1. Assessment: Mapping Actual Exposure

The first step is to identify what the company is actually disclosing, whether intentionally or not.

In this article, the tools highlighted are:

  • Amass to map domains, subdomains, and the DNS exposure surface;
  • Shodan to identify publicly visible services, technical banners, and certain equipment on display.

This phase often helps identify forgotten assets: administration interfaces, open pre-production environments, remote services, partner portals, access devices, or legacy applications.

2. Identifying Vulnerabilities: Linking Vulnerabilities to Attack Scenarios

Once the map is in place, we look for defects that can actually be exploited.

Here, the two tools selected are:

  • Nuclei to automate the detection of misconfigurations, known vulnerabilities, and recurring weaknesses;
  • Burp Suite for in-depth analysis of web applications, HTTP traffic, authentication, access controls, and APIs.

This is where the penetration tester distinguishes between a “catalog” vulnerability and a flaw that is useful to an attacker. A poorly filtered third-party API, a broken authorization check, or a reusable token often have greater offensive value than a simple outdated software version.

3. Operations: Demonstrating Impact Without Disrupting Production

The operation must remain controlled, documented, and proportionate.

For this scenario, the tools used are:

  • The Impacket suite for testing actions in Windows environments, service accounts, remote access, or interactions with Active Directory;
  • NetExec to detect unauthorized use of accounts, credentials, or permissions on Windows hosts and services.

When an IT security audit is conducted properly, it shows, for example, how limited third-party access can become a pivot point leading to:

  • an integration server;
  • a poorly insulated stronghold;
  • a sensitive SMB share;
  • a privileged service account;
  • a promotion in the directory.

4. Report: Turning Technical Evidence into a CISO Decision

The report isn’t just a collection of screenshots. It must answer three questions:

  • How does the attack begin?
  • How far can she go?
  • What measures can quickly reduce the risk?

A comprehensive report on this penetration test in Rennes describes the attack vector, evidence, prerequisites, and impacts on confidentiality, integrity, and availability, and then prioritizes the necessary fixes.

5. Retest: Verify that the correction actually closes the path

The retest confirms that the remediation addresses the entire chain. Fixing the symptom without addressing implicit trust, excessive permissions, or insufficient segmentation is like repainting an emergency exit while it remains open.

Real-world attack example: the supply chain, a credible and well-documented point of entry

Supply chain attacks are no longer just a theoretical scenario. CERT-FR has recently issued several alerts regarding supply chain compromises, particularly involving compromised NPM packages and a compromise of the Notepad++ update server at a third-party hosting provider. These cases illustrate a key point: an attacker does not need to directly target the end user if they can compromise software, a component, or a trusted third party upstream.

From the MITRE ATT&CK perspective, this type of scenario often revolves around Valid Accounts (T1078) and Lateral Movement (TA0008). In practice, once valid credentials have been obtained or reused, the attacker moves through remote services, bypasses certain controls, and blends in with legitimate activity. This is precisely why a supply-chain-focused penetration test must assess partner access, service accounts, and bounce paths between technical zones.

In the context of Rennes, the risk is particularly real for organizations that meet all of the following criteria:

  • connections with service providers;
  • applications showcased for clients or partners;
  • centralized directory;
  • hybrid cloud services;
  • Automated exchanges between business units and subcontractors.

How to Protect Yourself Against This Type of Security Breach

Protection does not rely on a miracle solution. It relies on a systematic reduction of risk.

Priority Measures

  • Require MFA for all third-party access;
  • reduce the privileges of technical accounts;
  • segregate traffic between partners, administration servers, and production servers;
  • isolate the integration and pre-production environments;
  • harden Active Directory and monitor privileged groups;
  • store secrets in a dedicated safe;
  • centralize the logs relevant to detection;
  • Regularly review trust relationships and historical exemptions.

Technical risk reduction chart

Observed Risk Recommended control Expected Security Impact Priority
Third-party account is too permissive MFA + least privilege Reduced risk of initial access High
Poorly Segregated Partner API Object-based access control + network filtering Limiting application abuse High
Lateral movement from an exchange server East-West segmentation + dedicated administration rules Containment of the attack High
Secrets Stored in Plain Text Secret Vault + Rotation Reduced bounce and persistence High
Insufficient Logging SIEM centralization + authentication and administration logs Accelerated detection and investigation Average
Historical Trust Not Reviewed Periodic review of partner access Reduced supply-chain risk High

Why carry out a pentest with Hackmosphere

A penetration test is only valuable if it demonstrates a real impact. That is precisely the value of an evidence-based approach, such as the one Hackmosphere offers in its penetration testing services.

For a CISO, the challenge isn’t to come up with an endless list of vulnerabilities. The challenge is to determine:

  • What pathways allow the information system to be compromised;
  • which vulnerabilities are actually exploitable;
  • Which assets put data, the data center, business applications, or availability at risk;
  • Which mitigation measures offer the best balance between effort and risk reduction?

In the context of enterprise cybersecurity, this approach aligns penetration testing with the real challenges: business continuity, data breaches, identity compromise, propagation within the IT system, and regulatory exposure.

FAQ

What is the difference between a penetration test in Rennes and a simple vulnerability scan?

A scan detects technical indicators. A penetration test verifies whether these vulnerabilities actually allow for compromise, bypassing access controls, lateral movement, or data exfiltration.

Can a penetration test in Rennes be used to assess a risk associated with a service provider?

Yes. A penetration test can simulate the exploitation of third-party access, a partner API, a service account, or a trust relationship between environments to assess supply-chain risk.

How often should a cybersecurity audit be conducted in Rennes?

At a minimum, after a major IT system update, the launch of a new exposed service, an architectural change, a sensitive integration, or before a critical project. For exposed environments, a regular schedule is recommended.

Conclusion

Following this penetration test in Rennes, a thorough cybersecurity audit should not be limited to visible web exposure. It must test the trust relationships between partners, remote access, technical accounts, cloud services, and Active Directory. That is often where the real risk lies. A well-conducted penetration test allows you to verify whether your organization can withstand an attacker who thinks in terms of access paths, not Excel spreadsheets.

Contact us to assess your attack surface.

Webinaire gratuit · Hackmosphere × UrgenceCyber

Vos collaborateurs utilisent l'IA chaque jour. Votre surface d'attaque a déjà changé.

L'IA s'est installée dans vos équipes, et c'est une vraie opportunité. Mais chaque nouvel usage (prompts, agents, connecteurs...) élargit discrètement votre surface d'attaque, et c'est une bonne raison de faire le point. Un webinaire à deux voix, Hackmosphere et UrgenceCyber Région Sud, pour comprendre les risques réels et repartir avec une feuille de route applicable.

Mardi 24 novembre · 11h 1 h · En ligne (Teams)
Je m'inscris