
Energy Talks · 2026-06-11 · 31 min
Key moments - from our scoring
Substance score
54 / 100
Five dimensions, 20 points each
This episode brings penetration testers Benjamin Floriani and Patrick Pongratz from ZECCOR to explain what separates dangerous vulnerabilities from noise. They walk through vulnerability discovery methods - fuzzing, crash analysis, reverse engineering - and emphasize that finding a vulnerability is fundamentally different from exploiting it. The conversation centers on CVSS scoring limitations: a Linux privilege escalation and a BitLocker bypass may have different scores, but their actual risk depends entirely on context and attack surface. The guests highlight how published exploits on GitHub combined with AI-assisted exploit development have accelerated weaponization, but also explain why basic defenses remain most effective. They point to OT environments as particularly vulnerable due to legacy systems (Windows XP, Windows 7, old Linux kernels) that sit unpatched for years, and stress that network segmentation, least privilege access, and removing unnecessary attack surface prevent exploitation far better than software mitigations. The episode is invaluable for security leaders, CISOs, and infrastructure operators trying to prioritize which vulnerabilities actually matter for their environment.
Finding a vulnerability (like a crash or unexpected behavior) is the first step; exploitation requires analyzing that behavior, understanding the underlying code, and chaining together multiple conditions to make the system do something unintended - a process that can range from a single HTTP request to weeks of reverse engineering and debugging.
CVSS scores rate vulnerabilities in isolation without context; a high-scoring Linux privilege escalation might be less important than a lower-scoring BitLocker bypass if your company uses stolen laptops more than internal Linux servers, so you must assess each vulnerability against your specific attack surface and threat model.
With AI-assisted exploit development, working exploits appear within hours of public vulnerability disclosure, especially for open-source software; if a vulnerable system is internet-reachable with known exploits available, it has a very high chance of being exploited.
Network segmentation to isolate OT from IT, least privilege access so users only have permissions they need, minimal attack surface by closing unnecessary ports, and architectural choices like preventing domain admins from logging into client systems - all of which remove preconditions for exploitation.
OT patch cycles are measured in months or years rather than days, and facilities commonly run operating systems like Windows XP, Windows 7, and legacy Linux kernels from 2017; this creates a massive lag where exploits from the IT world a decade ago are still dangerous in active OT networks.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode covers standard cybersecurity concepts (vulnerability discovery methods, CVSS scoring, exploit development, network segmentation, least privilege) but rarely goes beyond textbook explanations. There are some useful contextual observations about OT environments (old systems, long patch cycles, Linux prevalence) and one genuinely valuable insight about chaining design choices rather than exploiting traditional vulnerabilities. However, much of the episode recycles common security wisdom without novel angles or surprising claims.
if you have experience in looking for vulnerabilities You can see some signs are going to tell you there is something going on
so basically similar in OT, where you don't have some kind of authentication. You just send the IED to command and that does what its told
The discussion relies on well-established frameworks (CVSS scoring, network segmentation, least privilege, attack surface reduction). While the WordPress-to-OT analogy is somewhat useful, it's not particularly novel. The Spectre/Meltdown discussion and BitLocker example are used to illustrate context-dependency of risk, which is sound but not original. The episode lacks contrarian takes, first-principles thinking, or counterintuitive arguments about vulnerability management.
Especially with IEDs coming from web servers and web interfaces and web applications
if you have a vulnerable system it now depends how it is installed. if It's reachable from the internet There's really good chance that this system Is going to be exploited
Benjamin and Patrick are credible practitioners with legitimate pedigree: founders of a penetration testing firm (ZECCOR), over 8 years in red teams at larger companies, and background in competitive hacking (Austrian Cyber Security Challenge). They clearly do real offensive security work and speak from hands-on experience. However, they are not exceptionally senior operators (no Fortune 500 CISO background, no published research, no widely-recognized thought leadership), and their discussion occasionally lacks depth in certain areas.
Patrick and I we met at the Austrians house security challenge. afterwards We worked like eight years In big company where we founded the penetration testing team or red team. After eight successful years, we decided to do it again this time for our own. And yeah that's how we found out on company called Zecco
As penetration testers where say okay they got us there did everything they could
The episode provides limited concrete data. A few named examples appear (Spectre/Meltdown, DirtyFrag, BitLocker vulnerability, Windows XP/7, WordPress exploitation) but without specific metrics, timelines, or numbers beyond vague references. The discussion of OT environments mentions 'systems from 2017' and general observations about patching but lacks named customer examples, incident data, or quantified risk metrics. Most claims are illustrative rather than evidenced.
Those vulnerabilities allow you get more privileges on the linux system if your just normal user
That vulnerability has lower score than the linux ones
Simon's questions are generally competent but surface-level, following a predictable arc (background → vulnerability discovery → CVSS limitations → OT specifics → defense recommendations). He asks reasonable follow-ups but rarely pushes back, challenges assumptions, or pursues disagreements. The guests are not meaningfully pressured to justify claims or explore nuance. The conversation flows pleasantly but lacks the intellectual friction that would generate sharper insights.
Patrick, I've known you from CTF and hacking games where more or less real life scenarios are simulated. Can you tell me a little about how you in Benjamin started?
ironically so you said on Windows devices there's one way another to get the password hash?
Computed from the transcript - who did the talking, and the words that came up most.
Get insights from penetration testers on risk context, AI use, and OT defense. In this episode of Energy Talks, host Simon Rommer , OT Cybersecurity Consultant at OMICRON, is joined by Benjamin Floriani and Patrick Pongratz , founders of SecCore GmbH , an Austria-based company specializing in penetration testing, red teaming, and offensive cybersecurity. Together, they explore how security researchers and penetration testers identify cybersecurity vulnerabilities, assess their real-world impact, and develop exploits. The discussion highlights why context is often more important than vulnerability scores when evaluating cybersecurity risks and how attack surfaces, system architecture, and business requirements influence risk assessments. Benjamin and Patrick also share insights into modern exploit development, including the growing role of AI-assisted tools in vulnerability research and offensive security. The conversation also covers practical measures for improving cyber resilience, including network segmentation, least-privilege principles, asset inventories, and regular penetration testing to identify weaknesses before attackers do.
Transcribed and scored by The B2B Podcast Index.
Welcome to Energy Talks, a regular podcast series featuring expert discussions on power system testing data management cyber security and important trends in the power industry. My name is Simon Romer from The Podcast Team at Omicron And I will be your host. Hello everyone As in all Energy Talks episodes that are host, I will be covering topics related to OT, cybersecurity and the power industry. In this episode i'll be speaking with my guests Benjamin Floriani and Patrick Pongratz who have founders & penetration testers at ZECCOR.
We talk about some vulnerabilities of how they can become exploits. So without further delay welcome Benjamin and Patrik to this episode of energy talks. Hi Simon! Patrick, I've known you from CTF and hacking games where more or less real life scenarios are simulated.
Can you tell me a little about how you in Benjamin started? And what do you're doing now? Yeah so Benjamin and i we started our career let's say our passion in offensive security with the Austrian Cyber Security Challenge. This was already a long time ago, I think twelve years.
I think we started twelve years ago and the Austrian Cyber Security Challenge is kind of a hacking competition which is organized by the Bundesministerium für Interesse in Austria like military and some other operating bodies in Austria. but you have to do there is you have to solve hacking puzzles. It's not like it's a one-hundred percent real life competition, but what do we have? You've got some problems and use your brain or skills to try and solve those hacking related problems find vulnerabilities in systems exploit them then gain points.
if enough points win the competition. So it's the inofficial, official hacking championship of Austria basically. Yeah you could say that there is also a European version. if you manage to win the Austrian version You can go into the European version.
I was there once and yeah The Austrian version is the Austrian Champions League Of Hackers i'd say. Yeah Patrick and I we met at the Austrians house security challenge. afterwards We worked like eight years In big company where we founded the penetration testing team or red team. After eight successful years, we decided to do it again this time for our own.
And yeah that's how we found out on company called Zecco. So there is already a lot of experience. before founding your own company and bringing this experience now with you I guess There are lots of vulnerabilities that have been seen and exploited. at Yuhuf Ritten Especially nowadays.
currently has been theory of new vulnerabilities released from Linux to Windows and everything in between. AI makes it possible Sometimes even with exploit codes already available, so with exploits published. So how does one find vulnerabilities and where do you start looking if your not using AI tools? We can do it the old way like just playing around with software at programs.
we want to look when abilities in. When you play a round sometimes the software crashes or arrows out or brings some stack trace. This is when you know found something which was worth looking further into. If you want to find vulnerabilities in low-level software, hardware crashes are exactly what your looking for.
But there also other vulnerabilities that can be found e.g. in web apps or operating systems even but it almost always starts with something doing not kind of the right thing... but if you have experience in looking for vulnerabilities You can see some signs are going to tell you there is something going on.
like benjamin said for example if i want a website and suddenly the websites gives us server error. There's really good chance something is going on that should not be going on, and if we have hardware device in that hardware device keeps crashing it will do some weird inputs? You also know this program code can look into or make your application do what they shouldn't. This is basically what vulnerabilities are about.
Getting a program, getting something to do something that it should not normally do. like before AI used to do all this stuff because we have To be honest here AIs doing a lot of vulnerability research right now. You also had tools like fuzzers and the Fuzzer Is Basically just another tool That generates random inputs And puts those Inputs into an application or a program Or a hardware device sees how it reacts. And its not doing that manually, its not like five inputs a second but millions of inputs if the hardware allows.
And then you have to look into what the FASA gave and see if this is a real vulnerability or it's not. For example, also for web applications... you can just try a list of a million input strings like script or alert or something like that. If the application gives us some things back Then we know how to start looking at where the real work starts And you then have to dig into it and see how the program reacts, or their website reacts.
If you get lucky because there's a lot of luck involved too... then maybe you'll be able to exploit your vulnerability here! Especially with IEDs coming from web servers and web interfaces and web applications. So this type of classical IT vulnerability research is more valuable in OT space then you have found a vulnerability and is automatically reason to panic or if the device shuts off.
Maybe that's bad, maybe it not bad. so how do you determine whether its valuable to invest more time and investigate weird behavior? It depends on context like... If we see or analyse the found vulnerability leads to a crash in the software or server.
We of course reported through vendor, but it's not worth at least for us do fully exploited since we are not looking for vulnerabilities that only crashed systems. so four vulnerabilities? We always have the question what context did we find this vulnerability? and as Benjamin said Sometimes we only find crashes, sometimes really low-level vulnerabilities that give you some information about the system.
If we stay with web applications for example... sometimes you get vulnerabilities that only give you an internal IP address of a web server which is something that the web server should not do but can't use it to do damage. I like your question if every vulnerability is reason to panic Because if you look at some social media pages like LinkedIn, You are getting the impression that yes every vulnerability is a reason to one hundred percent start panicking right now. But of course in real world.
this isn't the case. As quick example I would say Spectre Meltdown. So Austria representing TU Graz defined side channel attacks on hardware level basically. So everybody was panicking, oh yeah, expect a meltdown really bad.
But at the end of today it was just bad if you are already owner of data center and have lots of hypervisors. so what I'm mad about is that they put out patch or mitigation inside the linux kernel And this was like fifteen percent performance lost. The first thing i did on my personal device I turned the mitigation off and gave my fifty percent performance back. This is a good example of vulnerability that was hyped quite a lot, but it's not really reason to panic even though...
It seemed like the whole world panicked at the same time! It's the same thing with CVSS scores. so if you wanna talk about the CVSS score? That was what i wanted to talk right now because reliability such as backturn meltdown they exist all the time.
Like, there are some new vulnerabilities coming out and especially if you're a SUS admin or a CISO and want to try to triage those vulnerabilities You will have really hard times because maybe for listeners There is a scoring system called CVSS The Common Vulnerability Scoring System And it's basically just linear systems from zero-to-ten. If we look at vulnerability At its core without any context, without anything else that vulnerability is going to have a CVSS score. Some newer vulnerabilities you may be aware of are those Linux vulnerabilities which came out just few weeks ago like DirtyFrag.
Those vulnerabilities allow you get more privileges on the linux system if your just normal user. In general Linux has either non-root users, normal users or root users which are the administrative user. Those vulnerabilities allow basically any normal user to get the permissions of their root user or administrator user and this is super critical. just like Spectrum Elton if you have a data center where there's a server with lots of websites that host web sites on your servers then one customer can get an administrator get to all other customer data and custom websites.
Of course, this is a super critical vulnerability. if you are for example server owner This I think has the CVSS score of seven point eight. so we have pretty high up from the CVS score which correct because it's a really great ability. On the other hand also some new vulnerabilities in Microsoft windows.
So play both sides here. For example, one rather new one is a yellow key. I think it was called and that vulnerability allowed you to bypass Microsoft or Windows BitLocker by just plugging in the USB drive And booting into recovery i think? You were in and bitlocker was bypassed with that!
That vulnerability has lower score than the linux ones. so now your job. think about what vulnerability is more important for me, from my context and company. Is it the one in Linux that allows every user to get root permissions?
Or does it allow everyone who has a BitLocker encrypted laptop to read data into your text? even though maybe the score is lower I would say most companies. we have seen the BitLocer vulnerability much more important for them because laptops get stolen, Linux servers are what I have seen. Internal linux servers which i've seen is not that much of a target for attackers because you even need to get SSH or something else on this system.
but if the laptop gets stolen it's pretty critical as now the thief can read all data on this laptop. So you always have to see the contacts here, let's introduce a new vocabulary. attack vector attacks surface. so it all depends upon what kind of threat your dealing with.
for example if we had a lot of users on your database or any kind of service within your company A lot of external uses then maybe the Linux vulnerability is more critical For You. Or If We Have A Lot Of Sales People That Forget The Laptops And There Is A Lot Critical Information On It Then The physical access restriction is more important for you. So knowing what to deal with and then threat vectors, threats surface. I think it plays a big role when talking about vulnerabilities.
but the vulnerability in the BitLocker For example Is that You can read It In A Certain Kind Of Way But How Do You Get From Knowing? Okay There's A Fault In The BitLocket Encryption to actually exploit it. or how do you get from? Okay, there is a fault in some kind of Linux authentication service.
To being able to get root permission. and what does the process here? Yeah as we said before depends on your vulnerability You found let's say It starts with a crash you played around. if the software crashed then Your job Is to analyze the memory Of the software because maybe The software tried to read something From file HTTP request of some other protocol and tried to load it into a memory buffer.
And this buffer got overwritten because the data I wanted to read was too long, then you have to find this place and tamper with that data thread so that the software in best or worst case depends on which side your own behaves how you want it to behave. for maybe execute some operating system commands. For that you need some low-level debugging skills, need to read assembly instructions and do a lot of dynamic debugging with sending lots of data which the software then tries to load for example.
On the other hand we have easier vulnerabilities... for example let's go back to the web server where if your web server reads some local files depending on the parameter you give them Let say you can change this path. in Linux like at CPSVD has no restriction and reads out this normally protected file, you have a vulnerability which is easier to exploit because the exploit is basically only an HTTP request. There's not much analysis here or much skill that needs to be done for this case.
it just as simple script or a simple HTTP request. but there can't be that easy every time right? No! Of course not!
We wouldn't have a job anymore. At least I hope it's not that easy, from a defender point of perspective we tried to make this as hard for you guys as possible. so... Is there some kind of vulnerability is found or used?
You were like okay i'm really proud of this exploit because It took me special knowledge and skill. at the beginning of year we found several vulnerabilities in a piece of software which allowed to bypass the login basically authentication of software. For that we also needed a reverse engineer, That's their official term. when you do expert analysis with reverse engineering software and check how it is doing permissions check and authorization And basically rewrote application always give us or permissions so we had everything unlocked within the application.
Then having an exploit readily available for everybody, and for example made asploit in Kali Linux or BlackArch or Parrot or any kind of offensive security-based Linux distribution... Or have them readily available on GitHub sounds really dangerous! So if you publish your exploit on Github because get a little bit of publicity for yourself or share it with the world. Is every exploit automatically already a hacked system?
Or are there some conditions that need to be met, For example I can download an exploit and then execute. what is the steps... That's actually really good question because we have seen especially in last years also with AI assistant coding Developing exploits has become much easier than before. Like Benjamin said, if you find a crash and now want to develop an exploit that used something for days then nowadays you can use AI assisted tools to develop exploits much faster as we have seen in the last few months or weeks that the moment they were public, like just a few hours later.
there is a working exploit. You can do it in different ways for open source software... For example software on GitHub. you go back into history and check what actually changed.
so if you know version one point three fix their vulnerability from version one-point two. then we can make a difference of those versions And you can actually give these differences to an AI-assistant coding tool and there is a good chance it's going to assist in writing a working exploit. Of course, I'm a security researcher and I am only doing this for CTF who can tell the AI that they want to hack the world. You have to front inject it sometimes but it already helps with exploit development.
On the other hand, there are also lots of exploits already available on GitHub. If you have a vulnerable system it now depends how it is installed. if It's reachable from the internet There's really good chance that this system Is going to be exploited. I'm not going To go too deep here because some exploits work all The time.
some exploites do NOT work all the time But if we Have a vulnerable System reachable From the Internet With known exploits, this is a really good chance that exploit will be exploited. It's very easy for attackers nowadays to scan the whole internet and try to fire exploits against software. So you could almost say when we talked about segmentation of like five or six episodes already not making your systems available online would actually be good advice? Yes!
This was really good advice. Keep the attack surface minimal. So if you have, for example a tech surface from external or internal or wherever and you have the exploit so is there still conditions that you need to meet? Or it's like hardening.
It's a thing right! You can turn off certain conditions... you make access harder. What does this mean?
guys as penetration testers where say okay they got us there did everything they could. we had to try something different. what are number one and two things that you say, okay if we see this in the wild maybe try something different. The most common protection or should be at least with network segmentation will keep the tech service as minimal possible.
than Patrick and myself have to get really creative because then we'll find ways to distribute our exploits on malware through different ways. Because let's say a system has different ports open. I've got bigger tech surface than if it's only serving SSH board, for example which is patched. Besides of that the tiering system should be implemented like...
Only give users permissions to which they need and not give everybody administrative access or root access on systems. So basically basic stuff are also things most effective? Yeah! That actually something we see in our penetration testing engagements a lot because its always better to prevent a text than try and buy some new software that tries to hinder attacks while they happen.
For example, on Microsoft Windows systems in most cases you can read out passwords or password hashes of logged-on users And there are lots of mitigations which make it harder for you to read out password hashes but their always going be some bypasses. And a really simple prevention mechanism here is if on the client system, Domain Administrator for example it's never logged-on because company has policy that those domain admins do not log onto Client Systems then there isn't going to be hash of that administrator and I don't need fancy software.
I dont' need fancy defender settings or anything. that hash is NOT on that client. The same thing happening with Lease Privilege principle. As you said if my users don't have permissions to do anything that they shouldn't, I don't need to worry about them exploiting something.
That they cannot even reach and especially in the OT space. what we see a lot is with network segmentation. If the client network can not reach their OT network then some ransomware or malware on the client cannot attack it because they are different networks and they are blocked. So I'd say yeah, their basics is what helps them most.
ironically so you said on Windows devices there's one way another to get the password hash? You know we know its per design. Microsoft does not call it a vulnerability. We called something that was helping us in this case Something that is a new making your job easier.
So sometimes vulnerabilities are not really vulnerabilities, but you also use design choices or use functionality as vulnerabilities to do your action on objectives and on targets. Can we talk about this little primary example? I like it a lot with WordPress. so if we look into wordpress maybe We found the password online or in the dark net or the administrator has some easy password to guess.
We can log in into the WordPress admin panel and modify a web page or even upload PHP files, for example. this itself is not the vulnerability. Not even an easy-to-guess password is a vulnerability. It's bad practice but it's not the one ability.
then we can upload as I said a php file onto the website which Then gets executed on the web server. This by design because wordpress used To create web pages right? What we can do is create a php reverse shell or web shell which executes commands. We give it.
so let's say, if you want to enumerate local files... we simply send the ls command to the phb reverse shell and the web server in the backend executes this command. This an example for me how we chain design choices. So it's basically similar in OT, where you don't have some kind of authentication.
You just send the IED to command and that does what its told. so if your on a station or some engineering Windows PC with password hash do the crack-the-hash things. when you sent one out four packages then there is nothing you can not do. So in the OT space, what does that mean for us?
If you say okay. You have to get creative I know you guys can quite creative. as a defender we're always on the back foot so the offense has little bit of an advantage here. and then talk about some kind of OT things that you've done like especially in OT.
As you all know patch cycles are not measured in hours or days. usually When we do penetration testing engagements and our target is to get into the OT network or production network, it doesn't really matter. We always see old computers like classic Windows XP machines CNC machines that operate with MS-DOS Or some really old Linux distribution. So what you can see in OT networks are mostly as I said old computers, old operating systems with as you said exploits already available.
So usually we don't even have to get too creative here. it can just check if there are old versions of webpages. for example OT devices usually tend to FVNC servers or Web pages. so What we mostly do in OT environments is check for already existing vulnerabilities and see if they apply to this environment.
Just as a reminder, Windows X has been over ten years old since October of last year. so having Windows XP I have not seen Windows XP in the wild in our environment quite some time. Windows seven, yeah. I have seen Windows XP not even that long ago.
Yeah i think in manufacturing it's more common. but again just as a reminder windows ten is already end of life Even though windows eleven takes its time to be there To be updated. so it doesn't need to be like window six p win ms dos Windows three point eleven or something. So justice and remind on this point.
I would be curious, however, like Windows X has the TPM secure boot requirements and all that. Are OT vendors going to Windows XI? And implementing all of this stuff?! I'm not sure.
i haven't seen a Windows X PC in an OT environment as of right now... I'd be curious what future brings here! As far as I've seen most companies pay for extended support so they use Windows X. nobody is jumping ship trying first who adapts Windows X.
But also for the IEDs and the industry devices, they all run on Linux. Sometimes a custom kernel sometimes proprietary... sometimes open source kernel with some certain versions. but here it's not only Windows is old or like older version of windows..
but also older versions of linux. For example what we had was something from twenty seventeen. And i'm always joking that you can see the future Because everything that is happening now in IT, it's going to happen in OT like ten years. So the tech surface here also quite big.
Do you guys have a message from your perspective? That want give an audience To be more protected against bad guys like you? Yeah I think one of the most important messages in offensive security and penetration testing In general is context is important Like as security scanner is going to give you seven hundred vulnerabilities with some CVS scores, some of them being really important. Some are not very important.
but finding the context for a vulnerability things here. You need to keep track of, is that vulnerability relevant in my environment? Is it a vulnerability that has huge preconditions? for example...
is the vulnerability where an attacker needs already get on their system and then they can do something? or is there point and exploit with an IP address at the system. And I get full access on that system, then is it important for me or just a test system running in some random house? Putting vulnerabilities into context would be my number one tip if you want to make your environment more secure.
Otherwise, I think the basics mostly apply here. Like check the systems regularly have an inventory of system so you are even aware of new vulnerabilities. if You know what systems in OT and IT use then you can Even see If there are new vulnerabilities. otherwise your blind there maybe are critical vulnerabilities that fly over your head because you don't have an inventory of all your systems and when they were last updated.
Also network segmentation, as we already talked about... You cannot attack something that you can not reach. so many attacks in companies who do have IT or OT could've been prevented if the IT Network was not reachable from the OT Network And the OT network is not reach-able on the IT network. you can contain an attack much better.
And also, of course when we do penetration testing We encourage companies to do regular penetration testing and check if, for example your network segmentation holds or if your vulnerability update process is working. Because we always see that a company has some update processes in place but then two of three computers are not updated because something did not work. and when you do the penetration test we can exploit exactly those machines because we don't need to exploit one hundred machines.
In most cases We only need to find one machine That was not updated Or where some policy wasn't affected the machine. That's why we think it is pretty important to have some bad guys like us that are not really bad, but play or simulate bad guys and try to attack systems and networks so you can see where your blind spots are." So those would be some points I'd give all listeners here? Yeah!
Totally agree with Patrick. The basics are one of our most important things As Patrick said, the network sanitation, least privilege principle. Do not download everything you get by mail in attachments and stuff like. that is important!
And yeah do not double click every file you see and download. And with it. thank you Benjamin and Patrick for talking to me... and also a big thank-you to our audience for listening today's other episodes of Energy Talks.
We always welcome your questions & feedback. please send us an email at podcastatomicronenergy.com. Omicron has several years of experience in power system testing, data management and cybersecurity.
And offers the matching solution for your application. For more information visit our website at omicronenergy.com. Please join us for next episode of Energy Talks.
Goodbye from now everyone!
Other episodes covering the same guests and topics, from across The B2B Podcast Index.