Red teaming
Understanding attack paths and how weaknesses combine across systems.
Independent security researchTsarevo, Bulgaria
pseudmous.
Borislav Nikov / Cybersecurity student
Curiosity finds the gap.
Discipline makes it count.
I explore how systems break, document what matters, and report responsibly. Building toward a career in penetration testing, one finding at a time.
Observe. Validate. Disclose.01 — Portfolio
01 /Behind the alias
A student of systems.
A researcher by instinct.
I’m Borislav Nikov, a cybersecurity student from Tsarevo, Bulgaria, researching under the name pseudmous. I’m interested in the point where an application’s assumptions stop matching what it actually allows.
My goal is to become a penetration tester, develop my red teaming skills, and continue bug bounty research alongside that work. I have multiple valid findings; this portfolio shares the one I have permission to discuss in anonymized form.
Currently studying
BSc Cybersecurity
Nikola Vaptsarov
Naval Academy
Penetration testing
Turning technical observations into reproducible findings and useful fixes.
Bug bounty
Investigating real-world security issues with restraint and clear evidence.
02 /Selected research
Small entry point.
Meaningful impact.
One public case study.
Permission to share. Identity protected.
A public proxy.
Private support data.
An unauthenticated support integration exposed ticket data and allowed ticket creation through a publicly reachable proxy/API.
Reward received€2,000Organization withheld
The finding
A public-facing application exposed a proxy to a Zendesk support integration. Requests could reach ticket operations without an authenticated application session.
Minimal validation confirmed access to support tickets, customer order information, and internal support metadata, as well as the ability to create a support ticket without authentication.
I stopped after confirming the impact. I did not carry out large-scale enumeration or automated extraction.
01
Unauthenticated visitorNo application session
Missing access check
02
Public support proxyTicket operations reachable
Request reaches integration
03
Support serviceRead tickets / create ticket
The behavior exposed a boundary failure. The internal implementation was not inspected.
Impact assessment
What the exposure made possible
Observed / confidentiality
Support data exposure
Ticket contents, customer order information, and internal metadata could be read without a signed-in session.
Observed / integrity
Unauthorized ticket creation
The integration accepted a ticket creation operation from an unauthenticated requester.
Potential / not exercised
Workflow abuse
Repeated submissions could burden support operations. Wider collection could expand the data exposure; neither was tested.
Technical analysis & recommended remediation
Where enforcement was missing
The observable issue was missing access control at the application’s public integration boundary. A trusted connection to a support provider does not establish the identity or permissions of an incoming visitor.
This account describes external behavior only. It does not establish how credentials were stored, which internal component was responsible, or whether other routes were affected.
No live endpoints, request payloads, ticket samples, or organization-specific implementation details are included.
Recommended controls
- Authenticate at the boundary. Require a valid session before privileged support operations reach the upstream integration.
- Authorize each operation and record. Enforce roles and ownership on the server; separate intentionally public intake from privileged ticket access.
- Minimize integration privileges. Keep service credentials server-side, restrict scopes, and return only the fields the caller is entitled to see.
- Limit and monitor abuse. Add rate limits and audit events; review access logs and rotate credentials if exposure is suspected.
- Verify the fix. Test signed-out, low-privilege, and cross-account requests, including both read and write operations.
These are recommendations, not claims about the organization’s implemented fixes. Remediation and retest status are not published here.
Disclosure journey
From observation to recognition
Milestones shown without calendar dates.
- 01
Discovery
Observed a publicly reachable support integration.
- 02
Minimal validation
Confirmed unauthenticated read and creation capabilities, then stopped.
- 03
Private disclosure
Reported the issue and impact to the organization.
- 04
Recognition
Received €2,000 and permission to publish an anonymized account.
03 /Research principles
Skill matters.
Judgment matters too.
A useful finding is more than a broken boundary. It needs evidence, restraint, and a clear path toward making the system safer.
- 01
Respect scope
Work within authorization and defined testing boundaries.
- 02
Prove only what is necessary
Use the minimum evidence needed. Avoid bulk collection, disruption, and unnecessary access.
- 03
Report clearly and privately
Explain the behavior, reproduction conditions, and practical impact to the responsible team.
- 04
Protect trust after disclosure
Publish only what is permitted and keep sensitive information out of public writeups.
04 /Where I come from
Bulgarian roots.
A global ambition.
Despite the political challenges my country faces, I am proud to be Bulgarian. I want to represent Bulgaria through ethical hacking — with skill, integrity, and work that earns respect.
My ambition is to become a hacker my country can be proud of, and to carry that pride into every system I help make safer.
Keep in touch
Let’s talk security.
Research, learning, and the next step toward penetration testing.