social.ridetrans.it is one of the many independent Mastodon servers you can use to participate in the fediverse.
We are organizers, transit riders, renters, union members, tech workers, musicians, climate activists; we are passionate about mobility justice, a right to housing, and intersectional communities.

Administered by:

Server stats:

59
active users

#pentest

0 posts0 participants0 posts today

On Saturday, October 18th, 2025, OWASP Ottawa conducted the "Pentest 101" workshop.

The workshop was delivered by Chris Shepherd, an important member of our volunteer team, and led 38 attendees through the lifecycle of a web application penetration test. Chris covered reconnaissance (gathering information about our target web application), testing security controls using browser and dev tools only (testing for SQL Injection), and then using ZAP proxy to intercept and replay requests to perform attacks such as XSS and SSRF. Chris also walked attendees through how to prepare a professional write-up for these findings so that technical and non-technical people can understand the details and impact of these findings.

OWASP Ottawa would like to officially thank our workshop sponsors for supporting this event (in no-particular order):
1. @uottawa Faculty of Engineering and the uOttawa-IBM Cyber range for providing the required infrastructure to host the event.
2. @owasp for providing the OWASP Juice Shop application used as the targeted web application and SWAG
3. Packetlabs for providing pizza and SWAG
4. DeviousPlan for providing beverages

Lastly, OWASP Ottawa would like to thank all the attendees for attending this workshop and the volunteers who dedicated their time to make this workshop a success.

If you would like for OWASP Ottawa to organize more such workshops, please leave a comment below indicating what workshops you would like us to organize.

What does @cR0w say? Hack more AI shit or something?

Well, here ya go. (Actually gonna play with this tomorrow on POINT's AI, Chiron.)

arxiv.org/abs/2508.17155

arXiv logo
arXiv.orgMind the Gap: Time-of-Check to Time-of-Use Vulnerabilities in LLM-Enabled AgentsLarge Language Model (LLM)-enabled agents are rapidly emerging across a wide range of applications, but their deployment introduces vulnerabilities with security implications. While prior work has examined prompt-based attacks (e.g., prompt injection) and data-oriented threats (e.g., data exfiltration), time-of-check to time-of-use (TOCTOU) remain largely unexplored in this context. TOCTOU arises when an agent validates external state (e.g., a file or API response) that is later modified before use, enabling practical attacks such as malicious configuration swaps or payload injection. In this work, we present the first study of TOCTOU vulnerabilities in LLM-enabled agents. We introduce TOCTOU-Bench, a benchmark with 66 realistic user tasks designed to evaluate this class of vulnerabilities. As countermeasures, we adapt detection and mitigation techniques from systems security to this setting and propose prompt rewriting, state integrity monitoring, and tool-fusing. Our study highlights challenges unique to agentic workflows, where we achieve up to 25% detection accuracy using automated detection methods, a 3% decrease in vulnerable plan generation, and a 95% reduction in the attack window. When combining all three approaches, we reduce the TOCTOU vulnerabilities from an executed trajectory from 12% to 8%. Our findings open a new research direction at the intersection of AI safety and systems security.

You’ve probably heard of Cold Boot attacks [1], but have you ever seen a practical example? If not, I recommend reading this report securitum.com/public-reports/m (point 002, page 15).

There is even more: for example, as a bonus, in point 001 there’s an interesting analysis concerning the incorrect configuration of PCR banks of the disk encryption process using LUKS.

[1] en.wikipedia.org/wiki/Cold_boo

Mini Pen Test Diaries story, happened in the last couple of years. The debrief meeting went like this:

“In your report you said you we’re able to crack the domain admin account instantly because the password was stored using the LM hash?”

“That’s right, yes.”

“But we’ve had LM hashing disabled for like 15 years, that can’t be possible?!”

“When was the last time that password was changed?”

“Well it’s been the same since I got here, 20 years ago.”

“And what hashing mechanism do you think was used back then?”

“Oh no."

For more, less mini stories like this, check out infosecdiaries.com.

Infosec DiariesInfosec DiariesLearn Pen Testing, Blue Teaming and Digital Forensics

A friend is looking for an ICS pentesting gig in the UK. He has lots of experience in maritime, power, water, gas OT & SCADA.

He's also excellent on internal inf / red team especially when there's an OT element to the org and you need a safe pair of hands.

If you have any leads please message me and I'll hook you up.

Hi everyone! I recently released 3 blog posts!
All of them are writeups on CTFs where I make some scripts and tools in bash and golang!

I'll leave you the link of the blog posts and if you have any suggestions or interact with me, don't hesitate to comment or DM me!

I hope you all can enjoy reading them!

blog.jackrendor.dev/posts/tryh

blog.jackrendor.dev/posts/tryh

blog.jackrendor.dev/posts/tryh

Jack Rendor's blog - Penetration Tester and Security Researcher · Tryhackme Security FootageWriteup on Security Footage, a room from TryHackMe where I explore the possible ways to extract files from a pcap file.

AI-powered features are the new attack surface! Check out our new blog in which LMG Security’s Senior Penetration Tester Emily Gosney @baybedoll shares real-world strategies for testing AI-driven web apps against the latest prompt injection threats.

From content smuggling to prompt splitting, attackers are using natural language to manipulate AI systems. Learn the top techniques—and why your web app pen test must include prompt injection testing to defend against today’s AI-driven threats.

Read now: lmgsecurity.com/are-your-ai-ba

Web app security prompt injection testing iage
LMG SecurityAre Your AI-Backed Web Apps Secure? Why Prompt Injection Testing Belongs in Every Web App Pen Test | LMG SecurityDiscover how prompt injection testing reveals hidden vulnerabilities in AI-enabled web apps. Learn real-world attack examples, risks, and why your pen test must include LLM-specific assessments.

So, a client hit me with this today: "We've got tons of security tools, so we *must* be safe, right?" My face: 😅 If only it were that simple...

Here's a wild stat for you: a staggering 61% of companies have been breached, even though they're juggling an average of 43 security tools. This just goes to show, piling on more tools doesn't automatically boost your security. What's the real game-changer? It's all in the **configuration!**

As a pentester, I see this scenario play out constantly. Businesses will pour money into the latest and greatest tools, but then the foundational stuff? Often overlooked. Seriously, getting regular pentests (and I'm talking thorough ones, not just some automated scans!) is absolutely vital. Plus, "Security by Design" isn't just a trendy phrase; it’s a mindset you actually have to live and breathe.

Over to you: what are the most common security tool configuration blunders you've come across? And on the flip side, which tools are your saviors for getting things optimized? Let's hear it!

Yikes, just stumbled upon some news about new Go modules floating around GitHub that can seriously wreck Linux systems!

So, here’s the scoop: Three particularly nasty Go modules have been spotted. When executed, they're designed to completely trash the system. How? Basically, they use obfuscated code to fetch a payload, and *that* payload proceeds to overwrite `/dev/sda` (your primary hard drive!) with zeros. Poof! Your data is gone. Keep an eye out for these repos: `github[.]com/truthfulpharm/prototransform`, `github[.]com/blankloggia/go-mcp`, and `github[.]com/steelpoor/tlsproxy`.

The really scary part? This is a stark reminder of how supply-chain attacks can turn even code you *think* you trust into a major threat.

And honestly, this isn't an isolated incident. Think about those malicious npm packages caught stealing crypto keys, or PyPI packages abusing Gmail for data exfiltration. Unfortunately, the list goes on.

What steps can you take?
* **Always** double-check package authenticity. Look into the publisher's history and verify GitHub links.
* Make it a habit to regularly review your dependencies. What are you *really* pulling into your project?
* Implement strict access controls, especially for private keys. Don't make it easy for attackers.
* Keep tabs on unusual outbound network connections, *particularly* SMTP traffic.
* Don't just blindly trust a package because it's been around for a while. Age isn't always a guarantee of safety.

Speaking as a pentester, these supply-chain attacks are genuinely tricky and folks often underestimate the danger. Sure, automated scans can catch some things, but nothing beats staying vigilant and truly understanding the risks involved. I see it all the time – clients sometimes get a false sense of security just because something is "open source."

Have you encountered anything similar? What tools or strategies are you using to lock down your supply chain? Drop your thoughts below!

Mini Pen Test Diaries Story:

During the open source enumeration phase of an external footprint test, I found a virtual machine that bore the name of the client in its NetBIOS response in Shodan.

Connecting to the machine over HTTP, I found a web app that was very relevant to the industry of the client - so I knew it was likely related.

The strange thing, however, was that Shodan was telling me NetBIOS and SMB were open (that’s how I found the machine in the first place), but I was unable to connect to it over SMB. Port scan showed closed.

I needed to figure out why Shodan was telling me one thing, but my reality was different.

The machine was hosted in Azure, so I figured I’d try rerunning my port scan from a source IP in my own Azure account, to see if I’d get a different result.

Sure enough, SMB was open when scanned from an Azure machine. They’d opened it up to any IP in Azure. No auth. Just an open file share accessible to anyone who was connecting to it from an Azure public source IP.

I reported it, and it turned out that the machine was hosted by a vendor on behalf of the client.

The vendor was insistent that my description of “public access to SMB share” was wrong, since technically it wasn’t open to the internet - just to Azure.

I then pointed out that hey, Azure is a famous example of a “public” cloud for a reason.

They fixed it.

Lesson: always try from different perspectives - such as from within the same providers IP space, you might find what I found.

For more, slightly less mini stories like this ones check out infosecdiaries.com

Infosec DiariesInfosec DiariesLearn Pen Testing, Blue Teaming and Digital Forensics