r/security

this starts with a story about how my school does things:

I found this out very recently, on our schools student information system you can connect though port 80, completely unencrypted with no warning. I keep getting excuses from administration to add HSTS into the student information system, such as "yeah it wont happen to us" or "the worst thing happening would be advertisers", and the worst part about this, is the breach to canvas happened a few days after I contacted them to DO THIS!

I dont know how someone could be THAT IGNORANT about simple web security, and be given system administration privilege by the district. so that left some questions:

WHY where they just, ignoring simple security advice, used on most servers including for sites like youtube or facebook, and why wont they just ADD HSTS into their server security policy, its not difficult and could save you from downgrade attacks in addition to simple encryption of the database drives with AES-256 and secure their endpoints with some honeypot databases to deter other means of hacking?

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.

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.

Hello again, I’m azqzazq1, a cybersecurity researcher.

My previous research, SunnyDayBPF, was recently featured by Ollie Whitehouse, CTO at the UK NCSC, in the Cyber Defence Analysis weekly summary.

Now I’m working on a new low-level Linux security research idea and I’d really like to hear opinions from people interested in eBPF, LSMs, AppArmor, and Linux hardening.

While spending more time with BPF internals, I noticed an interesting trust-boundary problem.

At a high level, the LSM framework prevents one LSM from simply overriding another LSM’s deny decision. However, eBPF tracing mechanisms can operate outside that LSM decision flow. This creates an interesting gap when combined with pathname-based MAC enforcement.

The research explores whether pre-LSM pathname manipulation through eBPF can cause AppArmor to evaluate a different path than the one originally requested by the user process.

In other words:

Can the security decision remain technically “valid” while the observed enforcement target is shifted before the LSM check?

I’m currently calling this research:

LID — Linux Integrity Drift

The focus is not “turning off AppArmor”, but understanding how kernel tracing, pathname-based access control, and security enforcement assumptions can drift from each other under specific conditions.

I’d love to hear thoughts from people working on Linux security, eBPF, AppArmor, LSM internals, or runtime detection.

Security assumptions killing all the ecosystem.

Anyone here interested in trying a P2P secure messenger app that doesn't store your chats on the server? Looking for feedback!

View Poll

Mini Shai-Hulud has yet again reportedly compromised 160+ packages, including parts of the TanStack and Mistral ecosystems. The interesting part is the attack path: instead of simple typosquatting, it abused GitHub Actions cache poisoning and trusted publishing/OIDC workflows, making the malicious packages appear legitimately built and published.

Foxconn’s Wisconsin facility outage being tied to the Nitrogen ransomware group after the gang added the company to its leak site and claimed theft of 8TB of data spanning over 11 million files. Foxconn has only confirmed a “technical issue” impacting IT systems and operations, but reports from employees point to a multi-day network disruption that affected production.

Anyone running cPanel/WHM in a homelab, VPS, or self-hosted environment should probably patch soon. cPanel fixed multiple security vulnerabilities (on May 8) including denial-of-service related issues and other security risks that could impact exposed hosting panels (and one of them is cvss 9.8 and pretty easy to exploit). Since a lot of lab environments leave management panels internet-facing for convenience, this is one of those updates worth prioritizing.

A fake “OpenAI Privacy Filter” repo reportedly hit Hugging Face trending with around 244K downloads before being removed. It looked like a legit PII-redaction tool, but the Windows setup path allegedly dropped a Rust infostealer.

The chain abused trust signals pretty well: cloned docs, inflated downloads/likes, and a trending position. Once run, it fetched a remote payload, pushed for admin rights, created persistence via a fake Microsoft Edge update task, and weakened defenses by disabling AMSI/ETW and adding Defender exclusions.

The payload reportedly targeted browser passwords/cookies/cards, crypto wallets, Discord tokens, SSH keys, FTP/VPN configs, screenshots, and files containing words like “seed,” “secret,” and “password.”