Maybe it’s better to start with securing your own systems first?
I’ve seen a lot over the years of doing pentests and quick external assessments, but this might be a new low. Yet another company that proudly claims to “specialize in delivering mission-critical IT systems with unparalleled security, reliability, and resilience” — and they’ve completely outdone themselves in terms of negligence.
Schuberg Philis specializes in delivering mission-critical IT systems with unparalleled security, reliability, and resilience. We work closely with customers to plan, build, and run secure systems that empower industries and infrastructures. As a purpose-driven company with an engineer-focused culture, we prioritize trust, autonomy, and operational excellence. Security, in our view, is not a barrier but a catalyst for growth.
"We are seeking an IT-OT Cyber Security Expert passionate about protecting mission-critical Operational Technology (OT) systems in industries such as utilities, production, and logistics. Operating at the juncture of IT and OT, this role focuses on creating robust security solutions for OT environments, while helping customers navigate the increasingly complex threat landscape."
So, I saw a job posting and decided to check out their web infrastructure to see if it’s even safe to use — say, to submit an application through it. And I was genuinely shocked. How can a company that promises cutting-edge protection of “mission-critical Operational Technology (OT) systems in industries such as utilities, production, and logistics” operate such a poorly structured and insecure IT environment?
1. Overexposure of Internal Subdomains
Shuberg Philis is absolutely leader (for me and for last 6month) of numerous subdomains reveal sensitive internal services:
Examples:
jira.acc.schubergphilis.com,
chef.opensearch.acc.schubergphilis.com,
infra.chef.saas...,
auth.acc...,
reset.acc...,
docker-registry.k8s...,
grafana.k8s..., etc.
Issue:
These names leak architectural and operational details — including CI/CD, DevOps, PKI, monitoring, authentication, and Kubernetes environments.
Risk: HIGH
This provides attackers with an extensive map of infrastructure components that can be used for:
- Targeted phishing
- Recon for CVE exploitation
- Credential stuffing or brute-force against known endpoints (e.g., Jira, GitLab, Grafana)
2. Public Interfaces Responding with Azure 404
Several subdomains respond with:makefileCopyEdi
Server: Microsoft-Azure-Application-Gateway/v2
Title: 404 Not Found
Examples:
jira.acc.schubergphilis.com
gw-ldap.acc.schubergphilis.com
oag-admin.acc.schubergphilis.com
reset.acc.schubergphilis.com
Issue:
These are exposed endpoints of either disabled or misconfigured internal systems.
Leaks internal pathing (reset, admin, gw-ldap) and technology (Azure WAF).
Risk: MEDIUM
Potential attack surface for:
- SSRF
- DoS
- ACL bypass if misconfigured
3. Missing Reverse DNS Entries
Some IPs (e.g., 185.242.221.165) lack proper reverse DNS records.
Issue:
Lack of PTR records can:
Weaken email delivery trust
Indicate incomplete DNS hygiene
Reduce overall infrastructure credibility
Risk: LOW–MEDIUM
4. Exposed Test and Legacy Environments
Subdomains include many clearly labeled test or possibly legacy services:
test.gitlab.saas...
grafana-foo, grafana-foa
confluence-k8s-test1, grafana-saas-201904121518
Issue:
These environments are often poorly maintained and not patched.
Risk: HIGH
Attackers may exploit CVEs in unpatched systems.
Potential lateral movement into production if not isolated.
5. SPF and TXT Records
SPF:
v=spf1 mx include:_spf.schubergphilis.com -all
TXT entries reveal integrations with:
Atlassian
DocuSign
Office 365 (D365)
Dynatrace
Google
MongoDB
Keybase
GitLab CI (Managed via SBP CorpIT Gitlab-CI)
Issues:
Possible information leakage of internal tools and 3rd party services.
No public DMARC or DKIM seen (based on dataset).
Risk: MEDIUM
Attackers could leverage this data to spoof email senders or attack 3rd-party integrations.
6. One IP Hosts Many Critical Kubernetes Services
All k8s.saas.acc.schubergphilis.com subdomains resolve to the same IP: 85.222.238.111
Examples:
grafana.k8s..., alertmanager.k8s..., harbor-core.k8s..., confluence.k8s..., etc.
Issue:
Hosting many critical services behind a single public IP makes it a high-value target.
Ingress exposure risks if role-based access control or authentication is misconfigured.
Risk: CRITICAL
Especially if any dashboards (Grafana, Harbor, etc.) are publicly accessible.
7. Risky Subdomain Types
The following may indicate risk:
pki1/pki2: Public access to internal certificate/key infrastructure
reset, auth, gw-ldap: IAM-related endpoints
docker-registry: Risk of exposed images or credentials
8. Potential Compliance Violations
A moment of positivity
to be fair, there are a few decent aspects to their web platform. Legally, it’s quite solid. In fact, it’s a great benchmark example of how cookie consent should be handled in 2025 — both legally and technically. They’ve done a good job ensuring that users who decline cookies don’t have their data collected or transmitted elsewhere.
Bonus points for the console easter egg designed for prospective developer applicants — nicely done! It’s both charming and practical.
Recommendations
- Audit all DNS entries — remove deprecated and test subdomains.
- Restrict access to all internal/test environments via IP whitelisting or VPN.
- Review Azure App Gateway exposure, ensure WAF and proper routing rules.
- Enforce service segmentation, especially in Kubernetes (e.g. multiple IPs/load balancers).
- Harden and authenticate all dashboards (Grafana, Harbor, Confluence, etc.).
- Implement and verify DMARC/DKIM, and review SPF includes.
- Conduct regular external security scans (ZAP, Nuclei, Censys, Shodan).
- Reinforce CI/CD pipelines, as GitLab CI is referenced in TXT — avoid leaking internal automation logic.
- Verify PKI endpoints (pki1/2) — if exposed externally, they require strict access control and monitoring.
Honestly, my conclusion is simple: working with you is a security risk — it’s unsafe to even send you a CV. With such glaring security oversights, there’s a very real chance it could end up in a data leak. As for the potential regulatory fines Schuberg Philis may face… I’ll just leave that unsaid.
If you lack the internal capacity to implement proper security measures — or perhaps you’ve accidentally hired some highly-certified incompetents — then feel free to reach out to me. I can fix all of this within two weeks.