Name: 40% of Internet-Facing Medical Image Servers Have No Admin Password
Uploaded: 2026-09-24T18:30:08.749Z
Duration: 2 h 30 min
Description: 40% of Internet-Facing Medical Image Servers Have No Admin Password

Transcript for "40% of Internet-Facing Medical Image Servers Have No Admin Password": Alright. Hi, everyone. We'll just give it another minute or two just to see if, anyone else wants to go through, if others others to join. Slides are moving, which is an improvement on the last time we did this or I did this. Okay. It's a couple of minutes past, so we'll, we'll kick off to sorry. I gotta stop reading the chat as I'm going through terrible habit of mine. So what thank you very much for everyone joining. We're gonna go through medical imaging, and exposure layers. There's been a number of, articles that we have done over, the last few months, which have consolidated into sort of one, sort of overall package for the health care industry. And it's not just the health care industry. It's it's, you know, industries at large can take things away from this. So what we're going to do today is is go through, the DICOM work, the the HMO seven, work, and some of the, generic, observations that Flare has made over the last few months. There will be opportunities to ask questions. There's a couple of natural breaks as we go along. I know we have two hours scheduled for this. It probably won't last two hours, but, you know, we do have a little bit of wiggle room, if there's questions and, and anything else that people want to go through. I am gonna turn my camera off. I have a face for radio, so we're going to, make sure that doesn't distract anyone. So, if everyone's happy, I will start going through. So, the reasoning, that we're here is, you know, DICOM, assumes that, you know, people know exactly what is here. There's been extensive, measurement of the environment over the last seven to nine years. So most of what you know already is is, you know, ground in that, those processes which essentially are historic, and, we've gone through, many, many, issues with, you know, trying to find things. So what this hour is gonna cover. So, first of all, we're going to go and try and break this down into natural parts. So we're gonna start with the protocol layer, and that's what's, DICOM assumes about the network it sits on. What the measurements have already found, from an industry standard perspective. You know, we'll go through this piece probably reasonably quickly, as in because this is going over things which, anyone who's working in this environment, in this, in this, sort of, cyber aspect should already know. If there's anything new in here, that's fantastic, but really recovering, you know, what's already known. Part two or section two, as it's listed here, is really the the core of why we're here and, potentially, the new material. I'm gonna say potentially the new material. You know, from a publication standpoint, there isn't a lot of material, out there already, which is why the flare material, that was produced did, raise a a lot of questions. It's not to say that people don't know it's there, but maybe that information is being kept, to themselves or within, you know, bubbles or just an assumption that everyone knew, exactly this this information. We're gonna go through the web layer, some consoles, OHIF views viewers. Sorry. And then then the deployment recipe that ties them altogether. And then who is actually running them, because that's a big part of the question. Partway through that section, I'm probably gonna step away. And, you know, the fun part is let's go through some scenarios. Let's go through some hypotheticals. I haven't put those in the slides for, well, obvious reasons because they are hypothetical scenarios, and we really don't want those scenarios to come, you know, to life. But that you know, we'll have an open discussion around those. Part three, we're gonna sort of move away from the imaging, sort of arena specifically and move into, the rest of the health care surface. So we we'll look at the messaging layers underneath. We'll look at some of the edge devices. And these the edge devices are normally, you know, historically where the ransomware crews come through. And then as much as it begrudges me to say this, we're gonna have to, you know, look at the input channel that AI tooling, has opened up. Not because I'm still gonna sit here and say it is an attack vector, that's openly being used right now, but it is a potential attack vector. And that that sort of issue there, currently falls outside of the scope of a lot of the regulations, a lot of the monitoring, a lot of the requirements that health care organizations are, you know, required to do as per laws and state laws, PII, etcetera etcetera. And then the last part, we're gonna go through, you know, what we can do about this. Again, there is suggestions, recommendations. These are not boiler plates. This is not something where, I'm gonna assume that everyone can do these overnight. It is simply, you know, what checks you can run this week, what questions to put to maybe some of the partners, who run the imaging devices, and then how to map obligations that you already carry or potentially already carry and then how to hunt for some of these things in in your own estate. Some of that is gonna be a lot easier than others. But if you, you know, if you have the understanding or at least the knowledge and, again, the deck will be available, after, this presentation, take it away. Have a look through it. There may be some changes that you need to make. There may be some corrections that you would like us to make, which is fantastic either way. So based on that, we're gonna kick off and go straight into the protocol layer. So as I mentioned before, this is, you know, well covered, essentially, but we need to go through this aspect here because it sort of leads into the other areas that, you know, potentially everyone's here to to listen to and and here we're here to talk about. If we don't go through this part, the potential new findings are not gonna make any sense, at all. And this is really you know, the current protocol layers are really shaped on old research. I'm not gonna say that research is incorrect. It was correct at the time, but we've continued to use that research as the base. And as we go through, you'll see why, we, as a collective, we need to have a shift in mindset. So we're gonna move into, you know, first slide, what DICOM assumes about the network, and I'm gonna get this out now. Acronyms are not my favorite thing. So for those that don't know, which hopefully is is known here, DICOM stands for digital imaging and communication in medicine. So I've got that there now. We can just go through acronyms and use that for the rest of the presentation. Basically, this is two things at once. It's the file format every scan is stored in, and it's a network protocol for moving those scans between machines. Although we have, nineteen ninety three on the screen, DICOM three dot zero is the version, in service today. It's been revised since then, including in 2021. But, essentially, what you're looking at is, you know, the version that has been running since the early nineties. However, the standard itself dates back to the mid mid eighties, mid nineteen eighties. So if you take that into perspective, you know, what we're looking at now from interconnectivity, AI, you know, requests, PII, all this kind all the information now, none of this existed in the eighties when essentially this protocol, was established. And the concerning thing really is that it hasn't really shifted since the eighties slash early nineties to keep pace with, modern technology, with modern inventions, with AI, and and and so on. In the in the, 2021, update, for example, to, you know, on three point zero, you know, security still wasn't part of the revisions, or at least it didn't meet the core part of the revisions. And I'm sure for those that have been in the industry a long time, you probably remember that, you know, there's lots and lots of, there's lots of voices calling for this to, to be implicated. But, eventually, you know, the revisions were heavily focused in other areas, and, again, security was not the main concern. So the important part is the trust model, which is mentioned here. The protocol identifies, the calling machines by an application entity title, which is essentially just a text string the caller asserts. There's no password. Pass encryption exists in the standard as an optional capability, and that's the keyword, optional, and it has done for the last twenty years. People have either chosen to implement it or not implement it. And for seamless integration, encryption, for the most part, has been treated as, it's not required at this point because, theoretically, these layers are sitting behind a lot of other layers, where, you know, two FA, firewalls, etcetera, would be doing their job. Access control was assumed to happen somewhere else, and that that's the key process. It was it's assumed to happen elsewhere, because let's let's try and go back to the nineties for those that can go that far back. Somewhere else, was a physically separate hospital network with no route to the outside world. Bearing in mind, this is the eighties, early nineties model. So, you know, if we use that mindset, none of this is actually a flaw. It's not a bug per se. It's a set of assumptions that were reasonable in the eighties and the nineties that were stopped that have stopped being reasonable, the moment that these systems that we're now talking about obtained a routable address. The standards body's own position is that security is a shared responsibility between the device manufacturers and the health delivery organization, which, you know, if we read between the lines of that, it lands on every single one of us, here that is potentially, involved in networking. So kind of an explosive or scandalous headline, seven years of counting exposed archives. But this is basically seven years of people like us measuring this. And over that seven year period, let's be honest as as a, you know, sector, the numbers just haven't improved. Every other week, we're seeing a breach of something. We're seeing medical records being shared online, dark web, etcetera, etcetera. Again, there's no finger pointing here. This is just, you know, where we live right now. So, Greenbone, first went live in 2019, and they looked at roughly 2,000 just over 2,300 medical image archives worldwide over two months and found 590 freely accessible. So this is 2019. That came to roughly around 24,000,000 patient records across 52 countries. 13,700,000 of those records belong to US patients, key number there, and over 700,000,000 linked images. When they rerun that, the image count had gone up to one one point one nine billion. In The US portion, Social Security numbers were present in around three quarters of the images. So, you know, those numbers, again, had not significantly improved. Then, Appellite presented at Black Hat Europe in late twenty twenty three. They counted over 3,800 Internet accessible DICOM servers. We'll touch on that, a bit later. With about 30% leaking sensitive data and estimated 59,000,000 records exposed over a lifetime time of the protocol. Trend Micro, joined in the fund in May, and I'll put those figures up, in in a second. But, you know, to take away from this slide the two things to notice. First is that the trend line is flat. Different teams, different methods, seven years apart, same picture. Again, I stress. This is not because people are not doing things. Everybody is doing their jobs, and everyone is trying to do the best they can with the resources they have. But the statistics, you know, show the same thing. The trend is maintaining. And the second is a detail, that that's on the blue box on the right hand side here, is that 39 of the servers they found serve patient data through an unencrypted web viewer with no protection at all. That is the web layer showing up in 2019 as a footnote. They added that as a footnote in their research. It wasn't it didn't form the main part of their research. And since that time, essentially, I'm gonna saying nobody, but very few people have actually gone back to measure this. It was taken as a base, accepted as a base, and then over time, hasn't really been revisited. So from our perspective, what a protocol census counts today. Now these numbers here, are from our research, so they're not accurate as of today. They're, a couple couple of months old, a few months old. But, you know, you're you're looking at, 3,627 DICOM servers reachable from the Internet across more than a 100 countries. So this is not a US problem. It's not a Canadian problem. It's not a UK problem. It's a global, problem. The US is the largest single share at 1,000, trying to read my own screen here, 1,189 servers, which is a third of the total. India, Brazil, China, and Germany all follow. Obviously, there is a very long tail to this list that simply just wouldn't fit on the screen. The two numbers in the middle are the ones worth, reading a couple of times. Or, you know, if I could have made them bigger with flashing lights around them, I probably would have. 0.14% of those servers use TLS. TLS being an industry standard, protocol, around encryption and and communication online. Industry standard, but only point 14% are actually using that standard. 99 and a half percent. So for argument's sake, we can say 99% accept a connection without validating the application entity title, which is the only caller check the protocol offers. So, you know, nearest damn it, we can say that a 100%, you know, is heavily reliant on the trust model, which, you know, I described a couple of slides ago. In this day and age, as much as I hate to say it, trust models are just not worth the time and effort it took to write up to explain what the trust model is. Basically, it switched off everywhere. So if you look at the bottom line, where it says hold on to hold on to this, because this is the thread that's gonna run through the rest of what we're gonna talk, about today. 40.4% of those servers cluster into groups running identical software configurations. 321 of them are running the same 2,009 build of OSIRIX. So that is not 321 independent decisions. This is one artifact Copy 321 times. So, again, this goes back to, you know, you have a working model. It's based upon something which was decided upon in the '8 eighties and nineties because it's not broken per se. There's no reason to fix it per se, so we will just keep copying and pasting that same thing over and over again within their own environments. Some of that is cost related. Some of that is technology related, resourcing. There's there's a whole raft of reasons why this occurs. But it is a fundamentally broken process as we'll see as we as we go through. So I said, the same pattern show up, here in much stronger form, and it turns out to be the single most useful thing, that you can take away, in terms of hunting and remediation. We see this in other, environments, for example, GPS deployments elsewhere, in other industries. It's been observed that once you find one device using a standard process, then you can map all of the devices inside that environment because nine times out of 10 or almost 10 times out of 10, they've used the same image to build multiple, instances within their own environment. So once you see one, you see many. So I'm gonna pause here. I did see a a a question, pop up, which was, by .com servers, do you that mean, like, storage nodes for VNAs and packs or edge? Thank you. That's that's really cool when it does that. So this is not the edge. We haven't touched the edge aspect yet. We're about to get into the edge. Well, edge will be more sort of area three. These are storage, essentially, where the images are, and where you keep the images, where those images happen to be, within your own environment. So we're looking at the storage aspect here. So the key takeaway there really is that the server, where all this sensitive PII or sensitive medical information about X rays and CAT scans, etcetera, etcetera, has over time and through, you know, hospitals being more interconnected and and and so on, have are now exposed, to the Internet. If they weren't exposed, I can see them, and we wouldn't be having this conversation. So that's that's kind of where we're talking, where we're going through, this piece. Feel free to drop any other questions, in the q and a section. I'm not looking at the chat, so if people are talking right, I apologize. So we're gonna go through start on the part two, essentially, which is the web layer. This hopefully, or hopefully not in some ways, is is the new material, and essentially why we are why we're here. And this is where I'm potentially gonna spend the the longest block of time. It's it's just going through this, hopefully, step by step or piece by piece, so that the information gets gets, gets through. Everything here, to the end of this part came out of, basically a single collection run, that I made in June of this year. So, you know, we've given it a few months, so that the data is stale enough to be still current, but not current enough that someone could walk away today and potentially, do something. Again, full disclosure, there is gonna be no mention of any organizations, no hospitals, no medical centers, no nothing in any of this work. We do have that data. So for any of those, in the call who are in, you know, those professions, feel free to reach out, and, you know, Flare will be happy to provide that information to you if we have any information. And, again, this is not to say that everyone is doing the same thing. So we're gonna go through now and start looking at some of the information. Essentially, there are two ways to reach an imaging archive from the Internet, and they sit on essentially different different ports. On the left is the layer we just covered on the previous set of slides. We have DICOM listening on memory, ports 104, 4,242, and quadruple one two, so one one one one two. And that's what the census counts. If you look at any research up until probably this date, those are the ports that it will cover. If you go back over over time, back into, you know, the nineties and and eighties and so on, again, these are the accepted, consensus ports that are monitored. And I'm sure that within your own programs for cyber for cybersecurity and, you know, the exercises you have to go through for, you know, NIST and, SOC two and, you know, etcetera, etcetera, HIPAA, these are where, you know, those assessors are essentially looking. But on the right hand side, is essentially the layer that those censuses net those censuses, yeah, teeth never touch. So the same archives are served to a browser on, on ordinary web ports, eighty four four three plus eighty four two, which your phonics default HTTP port, and 3,000, which is common for viewer builds. Two open source components dominated. Orphanec Orthanc Explorer is the administration console for Orthanc Archive, and Ohif is a browser based viewer usually bolted onto the front. I say usually, you know, builds can differ. And so here's why this distinction or the distinction matches in practice. And this is the most useful, hopefully, maybe, the most useful slide in the deck, for your own environments. In a separate census that, you know, we ran, across US health care owned addresses, 16,000 hosts, DICOM port 104 showed up on five of them. So out of 16,000 hosts, Port 104 showed up in five of them, and one one one one two on one. So what I'm basically saying here what we're basically saying here is if the protocol port is your only lens, imaging looks closed or close to being solved. You don't have a problem. Bearing in mind, again, this is industry standard. This is best practice. This is what you're told to look at. So if you look at it from that lens, you don't have a problem. You might as well drop from the call, right now, and we can yeah. Everyone else can, move on. But that's kind of what's what we're being told. But, obviously, why we're all here is it's not solved. It is simply moved, and this is the point that I made right in the very beginning, is the instructions and rules, protocol, and understanding has not moved with the physical layers that we're looking in that at now moving. And the two layers fail independently. A firewall change that closes one zero four four two four the ports we've already mentioned, does absolutely nothing at all for Port 8042. So I personally, going through this research, have seen imaging exposures exposure reviews that, stopped at the protocol ports, signed off as clean, you know, folder shut, moved on, next problem, where you can clearly see if you are if you understand what you're looking for, there's an open console sitting on the same host the whole time. Because, again, we're going through this tried and tested 40, you know, almost 50 year old, process of ticking the boxes. And that's the key piece. Please take that away. If you take nothing else away, from anything that's being said right now, is that you have your checkbox exercises that you have to complete on monthly, six monthly annual basis, and they are based on something which is 40 years old. Please, please, please look at the environment around, you know, those ports. What else is open? What else is, potentially exposed? Maybe it's supposed to be exposed. That's absolutely fine. You can make a note of that. But as a former threat hunter and, you know, someone who did a lot of IRs, One of the questions that I always ask going into these events is, please show me your network map. And in almost twenty years, nobody was ever able to provide a complete up to date full network inventory of their systems. There's partial ones. Some are held by different teams. Some haven't been updated in the last eight months. But I can say no one was ever able to provide that, and that's not a challenge. That's just, just an observation. So we're gonna start, with the authentic consoles, by authentication status, basically. So we're gonna start here because it's the most direct exposure in this entire set. And, again, I'm not pointing fingers. I'm just establishing, establishing fact and some ground rules here. So we actually geolocated 91, authentic explorer consoles just in The US. 36 of them, so roughly around 40%, if my math is correct, returned the management interface to a plain browser request with no authentication challenge and no login page in front of it. So theoretically speaking, and we'll go through this on slide 15 or a bit later on, I've got access as an attacker, to a management interface that shouldn't be exposed, doesn't require authentication, and is responding over just via a plain browser request. In no environment is any of that a good idea. So, 43, however, it's not all doom and gloom. 43%, were actually protected. Fantastic. You know, I'd like to show the positives even though we're talking mostly, hopefully, well, unfortunately, of negatives here. So forty three were were protected. In those organizations, somebody had seen something, whether it was deliberate or by accident. It doesn't matter. Forty three, you know, potentially were protective. More concerning is that out of those numbers, 12 of them, honestly, I couldn't call either way. And all this research is passive. Nothing has been poked or prodded or tried to be compromised, so it's passive observations. So the fact that I couldn't call it either way, doesn't exactly give a a clear picture. So what I what I've done here is I've excluded those, from the open points. So just assume that when I've said 40%, that's just a floor, because, you know, during the, you know, period of, you know, research, Obviously, things went up, things went down, things are not open on a Tuesday, and things are open on a Thursday, and so and so. When I say 40%, just assume that there's not a complete set. The number is not gonna be lower. It's probably going to be higher than that. So, I'm gonna just clarify, having said that this is all passive, about what an open console means just in the context of this research because this is not a pen test. You know, no access has been attempted on any of these environments, so maybe there are other things behind the scenes that, you know, would have prevented access. But given, what happened very, very recently during, the first iterations of the Iran US conflict, I'm not gonna mention the medical facility because that would be totally unfair, but it's well reported. They were essentially doing most things right. They were looking at, you know, security processes. They had, you know, MFA in place, firewalls, EDRs. I'm assuming a lot of this information, because it's just from the public reporting. What they potentially didn't have was an understanding that there was a significant number of their credentials in circulation around, the globe. I could tell you the exact number that Flare had, but, again, that's not fair. And at least one of those credentials potentially was the admin credential that allowed access and, you know, obviously, problems ensued. This is the same scenario that you're potentially looking here. The console lists, the authentic console lists patients and studies. It lets you open and download images in the browser, and the console is a front end to Orthonix REST API, which is the same interface used for uploads and deletions. So in this context, an open console is a confidentiality problem. It's also an integrity question for the archive that sits behind it. Like I said, we didn't test any of this. It's simply how the software behaves and when authentication is off. We'll go through a couple of scenarios. We'll go through a couple of attack scenarios or potential attack scenarios a bit later on where we theoretically can actually leverage this. So, again, key piece, and I'm not gonna claim to be a HIPAA expert, and none of this is obviously legal guidance. But if you want the HIPAA framing, this is an access control on electronic protective health information with nothing in front of it, reachable by anyone at all who knows the port number. It's not a missing control somewhere, hidden away, buried that, you know, someone's forgotten about. This is basically the front door. It's open, and the Internet is walking by. And every now and then, someone is poking their head in that open front door, just to see what color the carpets are. So we're gonna look at, you know, on this slide. You know, it's the same pattern, essentially, but it's the same pattern abroad. And we're gonna look at the default that's that's behind it. So I could sit here, and bash North America, Canada, US, Mexico, etcetera etcetera. But that's obviously not the goal. We're not we're we're not trying to say that one place is worse than others. But if I did the same, research that I just conducted focused on The US but actually then applied it to a global pattern, you know, I saw just in the collection window, 414 authentic consoles. This is outside The US. A 100 and, a 105 out of the 314 classified consoles were confirmed, at least from a visibility perspective, confirmed as open. Roughly, about a third. Put the two together, and it's a 141 open out of 405 classified, which is roughly around 35%, bearing in mind that 40% was The US number. But, again, because of, you know, visibility, collection time frames, etcetera, etcetera, You know, this is the consoles I could see, but, you know, there's another 405 consoles which were resolving but couldn't quite make a determination one way or another. But, geographically, I don't think there would be any surprises by turning around and said the concentrations are India, Brazil, Germany, obviously, the The US as well, with a very, very long tail. And by tail, in cyber parlance, I mean that there is a number of countries that maybe have one or two exposures, but not enough to sort of appear on a page worth of, you know, a league table, so to speak, of exposures. The free imaging stack, you know, this is, you know, the major area for adoption, but both layers, in the research, they they show up together. And, you know, we're gonna go through it. The root cause is all is already documented. You can see, on the previous screen, there was CVE220250896. Again, feel free to pull that off the data, which CISA published as a medical advisory in February of last year. That records that OrthonIQ does not enable basic authentication by default when remote access is turned on. That carried a 9.8 if you look at the, version three of the CVSS score. I appreciate we're going into a little bit of the vulnerability management side, but it's it's, key for an understanding perspective. If you look at version four, it's 9.2. Again, having done this work in organizations, I have been in situations where people, Am I on the right side? Yeah. Sorry. I'd skipped forward a slide there. My my mistake. Thank you for the, nudge. Yeah. So where I've been in a situation where people have decided which version of the CVSS score they wish to use because version one to version four have slight differences between the actual scoring mechanism and how they are, how they are used. So, it's, it's, but the underlying message is, it's overnight. It's bad. And and that that's it. That's what we need need to really know. And the weaknesses class is basically missing authentication for a critical function, and this applies to versions before one point five point eight. So there's a test there to run within your own environments. What versions are you currently running? So, basically, the install the, the process, the sequence is is rather actually mundane from a, you know, inside perspective. Somebody installs Authentic, they need to reach it from another building or from home or from another clinic somewhere. They turn remote access on, it works. Fantastic. Nothing, absolutely nothing prompts them for a password, so no password gets set. There is an assumption put in place that it's it's secure, it's safe. You know, I'm talking to one secure location for another secure location. We don't need to set, set passwords. The two settings to check, if you're going to check this, remote access allowed and authentication enabled. If the first is true, the second needs to be true as well. With users defined, please define your users. Honestly, and I'm gonna make an assumption here, it's about a five minute job. So quick check, five minute job if, if we're not going through if the stars do not align. Now I'll go to the next slide. So now we're gonna touch on the the the viewer, and, I want to stress that a population that no protocol census counts, I accept that that is a broad sweeping statement. But at the same time, if you go back to, you know, the ports that we've already identified, as standard remediation or standard observation ports, this is one of those, protocols that sits outside of that. So by definition, nothing is potentially looking at this because nobody is being asked to look at this. And this is potentially the part that matters most for for the long run. OHIF is a, is a zero footprint viewer. It runs entirely in the browser and pulls images from an archive, over GECOM web, which is the HTTP version of DICOM we've, you know, we've mentioned before. That design is the whole point of it. It's also why it's invisible to every census that, you know, historically, we would have run-in the first part of this this presentation. There is no actual DICOM port port to to find. It's a web application, and that's the key part. It's a web app, not a port. So going through the research, we observed 700 OHF viewers globally and a 138 of them just in The US. That entire population is missing from, you know, the protocol layer counts. It's not undercounted. It's not misrepresented, or counted elsewhere. It's completely absent as a category. So what you're looking at on the left hand side of the screen now on the slide is theoretically new numbers that nobody has seen before, and I'm using air quotes there because I'm sure people have seen this information, before. So but I am gonna sort of tailor this with, and just be a little bit careful, because it's I have to be clear. We have to try and be clear about what this does and does not mean because the viewer is not automatically in exposure. And that's the key part is that, you know, this is not an automatic exposure finding. A viewer with authentication in front of it pointed at an archive that requires credentials is a normal way to deliver imaging, at least to my understanding, and I would be happy to be corrected at any point. And some of these, some of that number are exactly that. Remember, I couldn't you know, through passive, information, couldn't tell you what was running behind these, instances in in most of the, occurrences. So, theoretically, all 700 could be running in the set way that they're supposed to function. But what makes, the population interesting is essentially the the the second finding, which we're gonna go to on, the next slide, which is about what the viewer publishes about itself, and that's the key piece. Hopefully, what makes this worth your attention at that point is regardless, is is basically the scale mismatch. 700 viewers against 414 consoles sitting on ports nobody is watching in a category that did not exist in anybody's asset infantry because nobody was counting at. That's a summary of where we are right now. And I apologize to anyone who is counting and observing and seeing this in their own environments. I am certainly not pointing the finger at you directly. So as I mentioned, what does the viewer publish about itself? And this, in in a way, is almost as key piece of information as we've gone through in the last couple of slides. So screenshot on the right hand side, taken from the actual research itself. Obviously, it's redacted, for the most part. To work in a browser, OHF has to ship its configuration to the client. That's not a bug. It's how, you know, client side applications, get get their settings. The consequence is that the configuration is readable by anyone who loads the page and views the source. Keyword, anyone who loads the page and views the source. You know, for those of you who are looked at a standard web page, a standard, you know, whatever you're looking at and whether using a Mac or Windows device, you can view the source code of that particular page. Some of it's hidden, some of it's not, essentially the full process that you're looking at here. In six seventy four of the 700 instances we observed, that configuration was exposed in the page. So 674 out of 700, we can see or you can see essentially what it is calling itself and what it's doing. The query route and the retrieval route are the addresses of the image store itself. Again, we have a query route and a retrieval route, I'm saying it again, are the addresses of the image store itself. There's no, there's no work that's needed from attackers' perspective to try and then locate where things are being stored. The information is one and the same. So what are the practical consequences? I'm obviously talking about theoreticals, for a large part from an attacker's perspective, but what are the practical consequences? First, treat anything in the viewer configuration as public because it is. It's as simple as that. There's no there's no real argument if if it can be seen, and you present this to, you know, CSA, C suite, etcetera, etcetera, and they start asking, well, are you sure? Yes. This this is as clear cut case as you can possibly get. No credentials, no tokens, no internal host names you would rather not publish. If your imaging vendor, whoever that happens to be, has put something sensitive in a client side config, that decision has already been made public on your behalf. So this goes ties back to the conversations you need to have with your imaging vendors because some of this is outside of your control, but it directly impacts the safety, security, etcetera of your environment. And then secondly, you know, the seven that named the back end directly are worth, worth looking at and worth focusing on. The viewer is a signpost. It tells you where the archive is. You know, same with, websites and so on. You know, everything is directed by signpost that tells something to go and look somewhere else to pull off a piece of information so that you get your images on a website or, you get a new form or something along those lines. So the question really to ask is not whether the viewer is safe. It's essentially whether the address is in that configuration answers or answers a stranger without credentials. If it does, the viewer has published the location of an open archive, and you really, really then need to go away and check to see what it is actually pointing to. So me as the attacker, in this scenario, I've asked a question. The platform, the open platform, has answered that question by telling me exactly what it is, where it is, and the fact that it was open. This is not a sophisticated cyber attack, which is the phrase that every organization loves to roll out through their legal teams and press releases. None of this is sophisticated. We've got to this point by just asking simple, simple questions. So as I mentioned before about, deployments and, you know, restrictions, time, cost, etcetera, etcetera, which will which will all factor into this, but let's push those to one side. Essentially, we have one deployment recipe and is repeated, which is the reason why a lot of this data, a lot of this research actually looks identical because it's identical. Of the 700, viewers, 658 exposed, favicon, which is the small icon, in the browser tab that you can see on your little browser tab. If you hash those and, again, it's a standard practice. So we hash them, from the results. 632, which is roughly 96%, carried one of just two different hashes. An e square on the left is 1% of that population. That is not a good good image to to potentially show. That is the fingerprint of, the canonical OHF and authentic Docker recipe, deployed exactly as published. So it's being deployed as, essentially, it was designed to be deployed, but vulnerabilities, misconfigurations in version one are then being repeated across the entire network. So an attacker, somebody, would just need an archive and a viewer, finds the composed file, runs it, and it works. Nobody changes the icon. No one changes the security defaults either. Hundreds of independent operators end up sharing a configuration decision that none of them actually made. None of you actually made this decision. You are essentially deploying something out of the box, and we've seen many instances where, recently where, let's say, Windows has pushed out an update to something which then breaks something else. And by default, half the globe has Windows updates turned on to yes by default, and suddenly you have a zero day in your environment, which you didn't subscribe to, which is not your fault. It's coming directly from an update. Similar scenario here. You're given an image to deploy over and over again, and that initial image has a potential, flaw in it, which you and hundreds or thousands of other organizations are now deploying across your environment. So, you know, this is the, you know, the findings from part one, where, you know, 321 identical builds, were identified. So, you know, there's some consequences from this, but they're not necessarily bad consequences. Let's start with remediation first. Because the problem was copied, I fix copies too, And that's the good news. A secure default in the upstream recipe reaches the entire population, on your next deployment. If you spot the problem and you fix the problem and you redeploy, that redeployment goes across your entire network of whatever it is where the problem happens to be. None of this individual looking at, individual boxes. One fix, one problem. So that's the plus side of doing this. And, obviously, it's also the plus side of why you're installing these images to begin with because maintenance is made simpler. You know, again, this is somewhere for you to go take away and have a look in your environment. And from a threat hunting perspective, if you have a hunting team or you're just interested in doing that or, you know, you're using third parties to do this, you know, in this instance, a single artifact covers 96% of the population. That's an extremely, extremely efficient pivot. You know, if you want to know whether this stack is running anywhere in in your own estates, or maybe even your suppliers' estates, that hash, that Favicon hash, will find it quicker and faster than any port sweep will. You know, the example I always use in this instance is that, you know, we're we're told by default where to install things, what ports to open, and what ports to close. Not everyone follows those defaults. There's always somebody who decides that, no, I'm not gonna install it on that port. I'm gonna install it on this port because no one ever looks at that port. Therefore, you know, it's security by by obfuscation, which is not always the case. But then if you then go into that environment and scan for all devices on that port, you're maybe only going to return half the fleet. By using the favicon hash as part of your hunting process, you're gonna get close to or near to 100% of that fleet regardless of whether, of of what port they're, you know, installed on. Little hunting tip there. So who is who is carrying this exposure? You know, the question then is who's running this is kind of, where we lead to at this point. The shape of the data fits radiology, pathology operators, self hosting, you know, OHIF, orthanec, and it does not necessarily fit maybe a lot of people here, which is hospital IT departments. Most of these consoles and view viewers sit on, hosting provider networks rather than address space registered to your own health, your own health system. And the operators behind them look like small radiology practices, independent, reading groups, digital pathology teams, using the free stack because it avoids, avoids a PAC license. And I know someone mentioned PACS PACS earlier. So there you go. That's why, you know, where PACS PACS comes in. You know, that's, you know, a broad generic sweep, from from most environments. You know? But the exposure measurement to this is is, you know, held with a higher higher confidence. The characterization of who owns it is an assessment based on, you know, looking at the data and, looking at the information. So what we're looking at is the line on the right. The organizations least equipped to review their own exposure are the ones most likely to be carrying it. And that's kind of uncomfortable, and it's not, I said, 100% accurate. But, generically speaking, it it sort of passes muster. You know, a a two radiologist practice, does not necessarily have the vulnerability management program, the EDRs, the ability to bring in, you know, the big four or the boutique, you know, VM platforms, the tenibles, the Qualysys, rapid sevens of of this world. And, you know, let's be honest, may not even have anyone whose job actually includes the word security, outside of maybe physical security on the building. But, you know and then here is why it still sort of lands on the people here today. If you're a hospital or a health system, your images do not live in your packs. They go out to teleradiology groups for overnight reads, outsource reading services, second opinion platforms, to research, and also research collaborators. Some of those partners run exactly this stack. I can say that with confidence because we can see it in the data. None of it appears in your asset inventory, because none of this is your asset. But, and I hate to say this, it is still your patient's data. Responsibility for that data does not necessarily disappear the moment you transfer it to somebody else to get a second opinion on a scan or an X-ray. So, therefore, it is still your collective obligation to to notify, to, explore, investigate when something does go wrong. And that's like I said, I'm teetering on the borders of legal legal descriptions and interpretations. But the bottom line is if you send an X-ray to a third party for them to review and they're gonna send it back to you, your ownership of that X-ray doesn't disappear the moment it leaves your environment. It's still your X-ray. It's still your patient. It's still your environment. It's still gonna come back to you. Okay. I'm gonna pause there, and just see if there is any other questions. Haven't seen any appear in the QA. Do you have any resources you recommend about malicious embedded DICOM data? I'm new to this. Yes. I I do. Well, yes, we do. And, again, I'm we're happy to provide that at length afterwards. But in terms of, you know, trying trying to find the information, first part is you have to understand that you have these exposures to begin with. And that's you know, we're gonna go through some of this, now some hypotheticals. But until you know that you you actually are exposed, trying to find embedded malicious instances is kind of it it's you need to do one before you step into the other. You can infer the exposure, or the the risk, but, you need to know it's there there first. Not the answer you're potentially looking for, but there are ways of of of doing this. So there isn't so as I mentioned before, there's no actual slides in this particular section. I just want to go through some hypotheticals. Some of these may be based on real instances. But the whole goal here is to hopefully make a few people sit there and go, oh, yeah. That's a good point. Or, oh, yeah. That could happen. We're not gonna get into the hows, you know, you know, etcetera, etcetera. So it's a really high level, piece from my, perspective. So let's start with probably the most obvious. You're potentially looking at the unauthorized viewing of patient images. Now if someone showed me an X-ray of, you know, an arm or a skull, you know, to an untrained eye, I'm probably not gonna see a lot of there, a lot from that. But as someone who has had X rays and scans before in previous lives, I do know that there is patient information normally in one corner or another of the actual image itself. You know, that is information which can then be extracted and used. But the bottom line is that any of those images, any of those scans, are potentially open to anybody viewing them. That in itself, is is potentially a problem. So then you go into the the bulk collection of those, those imaging and those imaging records. If you think of, again, hypothetical, if you think of all the reporting that we have seen over the last few years of bulk collecting, bulk buying of books and things to upload into various different, you know, AI LLM models so that they can learn, what is to say that the same is not happening, from a medical imaging perspective? And in, like, five years' time, one of these vendors turns around and says, we now have a 100% AI generated diagnosis platform slash machine that has simply learned on billions of scan and X-ray records that have been inadvertently leaked, across the Internet. Quite a dystopian dystopian view, but, you know, history shows us that those kinds of things happen. So why couldn't it happen here? And I've probably just given someone a business idea. And to everyone else, I apologize at that point. You then have the exposure of associated patient metadata. It could be Social Security numbers, dates of birth, names, geolocations. When I say geolocations, you know, John Smith going to have a scan in, you know, Tampa. You know, the image itself will show which hospital or which imaging center has taken that image. That indicates that John Smith is actually near or in the Tampa region. So that helps with maybe narrowing down who John Smith is. You know, other data could be collected from the, you know, dark web, open open source collections, etcetera, etcetera. Collecting that information, and we'll go through we'll go through another scenario in a second, helps build a picture for more nefarious reasons as well. You have the unauthorized downloading or copying of studies. You know, a lot of institutions, maybe yours included, are research institutions. A lot of people are writing very, very critical, very good in-depth papers around new processes, procedures, diseases, etcetera. A lot of those papers, will, you know, include images in in those instances to obviously help validate whatever it is that they're saying. This could be something groundbreaking. This could be something that's gonna be patented in, you know, six months' time and, you know, given to the world for free. Now if I'm nefarious and a bad actor, I could take that research, you know, redo it as my own, maybe register the thing beforehand, and then sell that to other people before your research is even exposed. It's happened in other walks of life. There's nothing to suggesting it wouldn't necessarily happen here. Now we're gonna get to something slightly more concerning. So you're looking at the potential manipulation and or deletion of imaging records. Again, imagine if, you know, you've gone in, for, a scan because of some, you know, discomfort that you're experiencing. Scans come back completely negative. Absolutely fine. Go away. Take two aspirins. Call me in the morning. But what's actually happened is that, you know, the images have been manipulated to remove that malicious that, you know, that swelling or that cancerous node or whatever it happens to be. So you've walked away with a false sense of security, that you're actually well when clearly you're not. Obviously, we're all well aware that mistakes can happen. This is not mistakes. This is someone deliberately altering, those images to report something else. And there could be any number of reasons for that, blackmail. Yeah. We won't go down those lines. The insertion of false or altered studies, that's, that's another thing I've noted here. You know, very similar to what I was mentioning before around, you know, the studies themselves. What is stopping me from adding in, you know, inconsistencies? It could be simply something as simple as moving a decimal point or changing a date on a scan to show something else. It doesn't have to be groundbreaking. There's no, like I said, technically, evolved cyber hack here. This is something that I can literally just do today, if we chose to do so. We've seen some of these instances, and it's normally attributed to to a ransomware event. But, you know, what's stopping me theoretically from disrupting the availability of the imaging service itself? If you've got nowhere to upload your images to, because I have nefariously come in and removed the folder or pointed it somewhere else, you can't do your imaging, which then disrupts, you know, medical programs and and and so on. Yeah. Like I said, things like that are normally attributed to ransomware events. So ransomware will always get depressed. But in this instance, this is something quiet. It's something that could happen today. And none of your none of the alerting pro platforms that we've already mentioned this will actually alert you to somebody poking around and potentially they're about to remove this file. First time you've noticed it potentially is when, you try to upload an image and that folder is simply not available anymore. And so we start moving into now the use of the imaging environment as a foothold into adjacent systems. You know, I've been able to access the imaging environment. No password. No authentication. No nothing. But that imaging environment, internally to the hospital network, no doubt, talks to other things. And, again, you know, I'm not gonna question anyone's, you know, network security protocols, etcetera, etcetera. We'll just make a general sort of statement here in that I'm already inside the hospital at this point. Where I go from here is pretty much dictated to where my access levels are, the security channels, programs, etcetera, etcetera. What is my intent at this point? So, you know, it's not necessarily just an imaging or a scanning problem. I've got this far. It shouldn't be too hard a leap to go even further into the hospital environment. I mentioned before around, you know, the the collection of imaging records, but what's now to stop me from extorting any of those patients? I have their medical records. I know that they have an, let's say, an embarrassing medical condition or a medical condition which would maybe impact their employment. And no one wants to lose their job. So I'm gonna start blackmailing that person or that group of people or, you know, as as a whole. You know, extortion is one of the easiest ways to to get paid. Ransomware groups use that very, very efficiently. We can use this imposed infrastructure to identify further health care targets. So, again, if you're using third parties or this is coming via a third party and that third party is used by, let's say, 50 hospitals in the state, I can potentially now identify those 50 hospitals and then go and look at those 50 hospitals for their own problems, their own concerns, their own exposures, etcetera, etcetera. It's a very, very efficient and cheap, mapping environment. And then, you know, clinical decision making influenced by altered or misleading imaging data. Already touched upon this. It's the last one on my list. You know, this is not an exhaustive list. But, you know, someone reading something on the screen, making an interpretation based upon an image which I have altered can significantly impact the patient, from, you know, worst case scenarios, ultimately, you know, death to, to other instances where, you know, wrong diagnosis can be given, the wrong drugs given, allergies, and and so on. So, you know, the exposure is and what I'm getting at here is the exposure element is the precondition to pretty much any of these events that I've just gone through here, right now. It's not the actual event itself. The event would happen after that, but, you know, this is where we're we're sitting right now. Okay. We're going into sort of the the tail end, of of what we're, gonna be talking about today. Conscious of time. So I'll make sure there is time, afterwards for any questions, or, you know, Discord will be open later as well for any questions and and and so on. We're gonna move now beyond the beyond imaging and into the the messaging layer itself. And, essentially, this is going to be another new input input channel. So we're going to look at h l seven and f h I r, and then we're gonna look at measuring them in the same way. So for those not familiar, I would like to do the best I can here, but I'm also not a health care professional, so, bear with me. DICOM moves the images, Admissions, orders, results, and medications, move over two other protocols entirely. So you've got what we've been talking about essentially is, the, you know, the the process that moves the images. Everything else, at least for in this example, moves over a different set of protocols. And we're gonna look at those protocols now because they are intrinsically linked with each other. You know, you've got HL seven version two and FHIR. You know, we'll start with the the honeypot information, the the honeypot, statistic right at the top of the screen, because it kind of frames what we're gonna talk about right now. So a 2026 study stood up decoys impersonating DICOM, h l seven and fear because I'm gonna get tired of saying f h I r services and watched who came essentially knocking at the door. Literally in this and these are published results. The DICOM decoy was scanned every day. So that gives you an idea of potentially the exposures that you're already facing. It was scanned every day. The the HL7 and FHIR decoys drew no observable scanning across an entire nine month period. So just let that sink in for a for a second. One door, and I'll I'll use the door analogy again. One door is being openly watched. Your front door, people are looking at it. People are poking their head inside. People are checking out what kind of the carpets are. Your side door and your back door are also wide open. Realize how that can be taken. And, nobody, researchers, scanning equipment, are actually looking at those. Everyone just assumes the front door is the only door. So what I did at this point is, I went and looked, which is the easiest way to do this. So, again, nothing's been touched. Nothing's been poked, prodded, compromised in any way. So on FHIR, we found or we could confirm at least 1,057 endpoints across North America. These are the ones where we could determine the posture, the endpoints that answered with no authentication. Sorry. The ones that answered with no authentication challenge outnumbered those that demanded credentials by 45 to 15, which is the statistic on the left hand side. In The US, it was 40 to two. FHIR is not an insecure standard. It ships with, smart on f a FHIR, and OAuth 2.0, has been built built in. But as with everything else, somebody has to decide to switch that on. And across the population that we were able to observe, for the most part, somebody has decided not to switch that on. And out of a lot of what was discussing now on the screen, h l seven version two is the one that I would also put, you know, near to or at the top of your list. And I realized by now that the top of your list is getting very, very top heavy. And this is, you know, stems under part of the problem. And it's the number on the right hand side. It has no author authentication, by design. It runs in plain text and exists to write into, clinical systems, essentially. What we could see or what I could see was 656 hosts, 17 of them on live messaging ports. That's live messaging. Essentially, if I had chosen to at that point, I could intercept those messages and write any message or insert a message in those live messaging ports to, you know, do anything that I actually wanted to do at that point. So an Internet reachable h l seven listener is an input to the systems that run a hospital. And integrity problems, there do not produce a bridge letter. That's a clinical event. That is somebody influencing potentially a medical decision. That's not an apology in the press saying, oops. Sorry. We are breached by ransomware gang x. That's potentially the worst things you can possibly imagine happening to to patients. So what is actually running, and where? So there's a couple of details in the FHIR population that are probably which are, sorry, not probably, but that are useful, operationally. First of all is the stack, which is on the the left hand side. It's not a mystery estate. You know, HAPI, FHIR, the open source workhorse accounts for roughly around 655 of the endpoints that, you know, that could be fingerprinted, which is, again, roughly around 62%. Open EMR is another 44. Everything else is, everything else is kind of like a a a a rounding error. You know, things couldn't be pinpointed. You know, this is the same concentration story as the olefonic favicon and the identical OSIRx builds that we mentioned earlier in in the slides. One patch cycle would cover most of this field, which is which is, again, some really good news. It also means that one old release leaves a lot of those doors that we are observing right now ajar. 28 of these are running, HAPI builds old enough to carry the CV, you can see in the bottom left hand corner, which is, 202451132 or 202452007, which is a XXE floor. Both of those, if you wanna go and weigh and look, were rated 9.8. Both of both of them, obviously, public public knowledge. The second is the country comparison, which is on the right hand side of the screen, you know, which is honestly quite interesting. You know, from a researcher's perspective, at least it may not be as interesting from, obviously, from a practitioner's perspective. But, you know, it it is quite quite striking in some ways. The US shows 44 open FHIR endpoints and only two of those that enforce authentication. Canada, however, shows zero opened and six enforced. Again, it's a limited dataset. Do not, assume that this is, you know, a 100%, accurate. But, you know, those six and fours, they're sitting on a smaller and more tightly held footprint. You know, 16 of The US endpoints carry those CVs I just just mentioned. But in again, interestingly or not, none of the Canadian ones that we could observe carried the same CVs. Probably not just down to regulation. You know, there's a lot of things that will come into here at scale, deployment velocity, ecosystem complexity, and and, you know, so on. And, obviously, just from a logistics standpoint, a smaller footprint is much easier to govern. But I'll make an observation, and it's literally just an observation. It's not, you know, backed by, statistics or science. But if you just look at this, you know, straight up the the numbers and the locations, what I'm seeing is basically the larger and faster moving market is also the leakier one. You know, and if so that's just worth remembering if you're operating at scale. Do you have multiple hospitals under your control or your purview? The pressure to deploy is, I'm gonna suggest, is far greater than maybe a small independent one hospital organization that's running in a single location that has the same size team. They can spend a lot more time looking at deployments, mapping things, testing, etc. Whereas you on your multi hospital environment, you're given a template, you deploy the template, you test the template, it's working, you move on to the next project in your list of a thousand things that you have to do by the end of the week. Again, it's not a finger pointing. It's just, you know, it's just realities. And now we can sort of touch upon the edge state around this. And I know this is one of, the questions, that happened, well, over an hour ago now. You know, what is the edge state around all of this? So kind of gonna step away from imaging because, you know, I need to go through you know, we need to establish some proportionality, because, otherwise, this sounds like we're just focusing on one thing when, obviously, there is potentially other issues, that we can cover that do intertwine. So from one of the other pieces of work that we we published, in the health care care space, you know, the census of US health care owned addresses was, you know, part and parcel of one of those, and we did a separate one for the Canadian health care space as well. So touching on The US side, specifically, 15,885 unique hosts, 31,000 service observations, 1,175 distinct only organizations. The, you know, the list is quite substantial. The key part there is that out of all those numbers, at least one CVE finding, was in every single organization, every single organization at the point that the information was collected. Does not mean that they are permanently exposed, but, at the point, of collection. Key number, if you're gonna take one away, 311 of those were critical rated CVEs. Now you may have gone through internally, mitigation strategies. You reviewed things, decided that it wasn't a problem. You have a patching schedule set up, and, you know, if we did the same search today, those wouldn't happen. But 311 critical known, CVEs is a is a very large number for, you know, the health care environment. You could theoretically argue that one critical exposure would be, you know, one too many, but, yeah, let's be a little realistic. So on the left hand side, you can see the table. You know, this is the edge and remote access estate. You got f five VIP, right there at the top, 852 hosts, Citrix NextScaler, Check Point, SonicWall, Outlook Web, Cisco. Presence on this list is not necessarily a vulnerability because some of these things are supposed to be publicly facing. But it is an attack surface with patching cadence attached to it. If you're not keeping up to date with CSIS KEV releases, f five was actually, on the list, from the twenty second, so two days ago, as having a publicly exploitable CV now attached to it. I strongly urge you to go and look at the, Kev releases and check those against your own environment. Do not wait and rely on vendors to come back to you to say, hey. We've got a patch, because some of these are not actually remediated by patching. Some of these require controls and things to be done within your own your own environment. If you don't know how to access the keV environment or don't know what I'm talking about, feel free to reach out. We do have a breakdown of, the KEV releases at least for this week anyway, and, we can go through that in go through that information. So, again, there's a relative risk associated with this. You know? And looking at the statistics, which are publicly available, every major health care ransomware event of the last three years came through this class of exposure, without you know, that's a defensible statement, I think. Change the health care, Ascension, common spirit, etcetera, edge device or credential and natural movement, then encryption, typically inside twenty four hours, seventy two hours max. I think IBM is currently saying, the average health care breach is costing $9,700,000, and it's top of the table for the last fourteen, fifteen years. So, clearly, it's a money spinner. Clearly, it's a revenue generator for the ransomware gangs. And every single event, or most of the events has come or stemmed through one of those, platforms you can see on the left hand side of the screen. It's a necessary evil. You have to have them, but you also need to spend time maintaining them. So, you know, from the screen, if you want one takeaway, one quote, the EDGIS state is where your ransomware risk definitely lives. The imaging web layer is where your quiet, long running patient data exposure lives, different areas, different environments. But, you know, the imaging layer is the one where, essentially, no one is checking. Do not, and I can't stress this a lot, do not suddenly go away now and trade one one for the other. They're they're essentially different failure models or different models, but they operate on different clocks. You know, so, you know, don't suddenly go away and focus on imaging and ignore the the fact that ransomware could be an issue in your environment. So what changes when the models, read the the record? And, you know, this is essentially gonna be the last slide of this little part, and then we'll go into very quickly the what to do about it pieces, and then I'll open the floor to to questions if there are any. And this is the one that, you know, essentially, we can we can observe for the next couple of years to see where things are going. You know, it's shown and, again, we have research, that we have published that shows this. Hospitals are wiring language models directly into their clinical workflows already. I think it's by early twenty twenty six, the FDA had cleared over 1,350 AI enabled medical devices. So that was double from 2022. And that doesn't include the generative tools, drafting notes, triaging, portal messages. Remember those? Portal messages? And they never near and none of those ever go near an actual device review. So, again, I'm sort of highlighting research that we've conducted in this space. Yeah. The clinical notes the doctor is writing with the assistance of AI does not fall under any regulation standards, does not fall within your own hospital standards reviewing safety, security, etcetera, etcetera. It's also a point of entry for a malicious actor to do do bad things. You know, this but the structural reason for this is that the models that are being used have no reliable way to separate instructions it should obey, from data it should process. So in these models, if you're giving it instructions of something it should do and it needs to follow a process to do that, the models, as of today, are not smart enough to determine or distinguish between the two things. So, you know, an instruction to do something and a a diagnosis of something essentially to their eyes, digital eyes, are the same actual actual thing. So the system prompt, the the clinician's question, and the referral letter essentially all arrive as one undifferentiated stream of text. And that's, you know, bolting it down right down to brass tacks. It's a stream of text. There's no conscious decision here. There's no, you know, interpretation of, you know, the the way something is inflicted. It is a string of text. And you're probably asking, well, why is he talking about this right now? Imaging is one of the channels that those models read. Oncology researchers have already demonstrated that, sub visual prompts embedded in imaging that a radiologist's eye do does not register, and a model reads without difficulty. So, you know, again, this is documented as demonstrated. So we're already doing this. So we've now just folded this vulnerability or this potential vulnerability back into the imaging pieces. So, again, we're gonna go into you know, you know, the last thirty years, the concern about an exposed archive has always been confidentiality, someone reading records that they should not. Once, you know, the models read from the archive and act on what they read, what is in it matters in a completely new way. And, honestly, I don't think there's anyone in this room right now who's probably ready for that, or has maybe even thought about it in in this or in this context. You know, your existing controls that we may have remember I said right at the very beginning, they're based on something that was written or a process that was understood thirty years ago. Even if you updated it five years ago, it's five years on a date already based upon the speed that, you know, models, LLMs, etcetera, are are evolving. Segmentation does not open the referral note, in in in this point. Endpoint detection does not parse a prompt. MFA tells you who sent the document, never what the document actually instructs. And, again, from a cyber perspective, these are all the things that we've been drilled into us over the last few years are things that you have to have in your environment, and people have become overreliant on those. And to a small part, you know, vendors play a part here where they come in and sell you something, which maybe the platform doesn't actually do, but they know it's something that people actually want to actually want to hear. So, again, you know, take all those to account. You know, segmentation, which you absolutely have to do, doesn't open the note. Endpoint detection, which you absolutely have to have, doesn't pass a prompt. An MFA, obviously, like I said, doesn't tell you who sent the document, but it doesn't tell you what the document actually instructs because nothing is looking at the actual structure of the wording, the text. So we're gonna switch into, the last section, which is the what to do about it. You know, we're gonna go through, some things that you can go away right now and do, potentially, in your own environment. I'm gonna lay out, potentially, some questions, which you can ask your imaging partners or your third party vendors or or so on. Some of this may be uncomfortable, but, unfortunately, uncomfortable questions have to be asked. And then, eventually, we'll get to how potentially the findings map to existing obligations and then, you know, how how you can hunt, within within your own environment. But we're kind of stepping ahead there. And I will do all of this in five or so minutes so that we get some time to ask any questions. I've not seen any new questions, so we'll we'll we'll kick on. Force default password creation. Do you initially set up some yes. Is is the the simple answer there. But the keyword here is or the key the key piece here is that, the def default password creation, much like your home router when the when you have that delivered, it always comes with a default password. One of the controls that you should put in place is that as soon as the device is, you know, in the testing phase, all default passwords are, changed to passwords of your own creation. Those passwords are not stored in open text anywhere, and it's not your login password, etcetera, etcetera. It's something else. But by default, and, again, probably just my opinion, every platform that you're bringing into your environment should have this installed as standard, and the default operating mechanism should always be open. It shouldn't because then it becomes a just internal justification issue that maybe you have to justify why you decided to turn it off. And it's very difficult it's very easy to forget that things aren't turned on by default, but that's the way that vendors, will always send things. Default should always be on, and then it becomes a justification issue to actually turn it off, which has to go through your board and, you know, your usual internal processes. Maybe it's just me, but that kind of makes sense. Probably doesn't make sense to the vendors. Okay. So most immediate low cost fix is, use a public scanning toolset, your showdowns, your census. There's a couple of others out there to actually have a look to see what is open, what is available, to the public Internet. For the most part, those those platforms come with free access, to a limited scope, but it will give you an idea of where you're actually doing. That's not a technology, reliant query. It can be done very, very quickly. And then, you know, that, kind of give you an indication of where things, things are potentially exposed. At that point, then you can decide if, you want to bring in a third party or, you know, an individual third party consultant because they they exist as well, pay an hourly rate to fix that individual individual problem. I understand completely there is cost implications, involved, and it's not necessarily, you know, to configure complex VPNs. It's we're not talking about VPNs here. We're talking about, you know, the imaging, servers themselves. VPNs, different different question. Again, I'm gonna put this out there, and I'm pretty sure the Flare folks on the call will pick me, afterwards. But if that is an issue that you are facing, reach out. And, certainly, you know, advice can be given in that direction, certainly, around the queries to look for, you know, for for a showdown in the census, etcetera, etcetera. Is there any other magical questions that just appear on the screen, which is quite freaky? Okay. Yes. And, I think the quest I agree. The question, are connected via VPN to share.com and hoseven. The VPN aspect is not necessarily the concern at this point. It's the fact that the the, images are being transferred, from those servers, h l seven, etcetera, in in a non password environment. If you're accessing via VPN, it's not necessarily how you're receiving or how you're transferring that data. It's your own environment and how you're storing that information on what servers, on what folders, etcetera, etcetera. The VPN is just a transfer transport module, to get things from one place to another. We're not that's not the crux of the the conversation here. It's what is it is visible when that essential data is is at rest. Although with h l seven, theoretically, you could sit there there and, intercept messages, etcetera, etcetera. Thank you. And these are great questions, by the way. Fantastic. Thank you. So what can people do this week? And I've tried to make these as, universally generic as possible, and, you know, I completely accept that some people have more, you know, capabilities, to do this than than others, and I'm also not assuming that people don't have a workload at all. So in no particular order, you know, what we can look at this week, test the web layer as its own item. If your imaging review stops at the DICOM ports, it has missed everything that we've just discussed, in in part two. Check eight zero four two, 3,000, and any viewer path from an outside address, not from inside the network where the answer will be wrong. Thank you, Aziz, for the question. That's the very question that's just being asked. If I look internally at these things, I'm ticking every box and everything is fine. Look at it from the attacker or the external perspective looking in because that's potentially where or that is where you're going to get, you know, more relevant information. Moving on to number two for Authentic specifically, confirm and ask for credentials from outside. Again, outside. If remote access allowed is true, authentication enabled needs to be true as well, with registered users defined. If you're running anything before, one point five point eight, yeah, one point five point eight, that is, you know, CVE twenty twenty five, zero eight nine six and enabled and you know, that should be in your patch queue. That needs to be remediated. It's a it's a live active exploitable CVE that needs to be in your queue. Number three, treat the viewer configuration as public because it is. Simple simple answer. Open it in your own browser and read it. If it names a DICOM DICOM web address, that address should never answer a stranger without credentials. Never. Again, no excuse. Number four, pull the image store off the public Internet. It's I know that sounds obvious, but as we've just established over the last period of time, it's not. It's on the public Internet. The viewer can live on the edge if the workflow generally needs it. The archive belongs behind a VPN as we as just come out here, or an authenticating proxy. So for me to view that folder, going back to the VPN question, I need to, VPN into the platform. I've gone through the security controls. I've gone through, multifactor authentication. I have improved login. The IP address is recognized. Whatever your controls happen to be, What we've mentioned before this is that none of those controls are actually in place, but you may have a VPN in place to actually, facilitate the the transfer of the information, but then you're storing it in a place which is open to the to the Internet. That's the piece that needs to be fixed. Number five, fix the recipe, essentially. If your teams are deploying from a a composed file or an internal template, change the defaults in that template so every future deployment, starts starts locked rather than starting open and waiting to be hardened. Again, being in that scenario where you deploy it and then you go back in afterwards and then close everything down after you've, you know, have validated everything is working, what is stopping you from deploying it locked? Therefore, if someone forgets or gets distracted, there's no big deal. It's locked. Perfect. Number six, ask your imaging partners the same questions, which is gonna be in the next slide. So, you know, this can be run on these things can be run on schedules. You know? And for the most part, I've already demonstrated that, you know, the passive measurement aspect doesn't touch production. So there's no scanning window. There's no nothing. You can literally have this running twenty four seven if you wanted to. Don't advise that, but if you wanted to, you can do this at any time, any moment, and it will tell you the information at that moment in time. Scanning publicly available scanning platforms, some are better than others. Some have times time frames, time stamps. Some are live ish time. Got ten minutes left. I'm gonna whip through, some questions for the imaging partners. Again, slides are available. You know, and if you can take a screenshot, take a screenshot at this point, and you can take the take the questions away. You know, none of the questions here, will ask if, the partner takes security seriously because everyone will say yes. Don't ask that question, because they will have the latest and greatest security technology in in place. You know, the questions here, they ask for the observable facts in a which, hopefully, a competent operator can answer in a sentence, and an incompetent operator won't be able to answer at all. You know, you will find often that there is for one word for one sentence answer, they will provide an entire paragraph, which doesn't actually tell you anything at all. I'm sure we've all been in the scenario where a vendor has provided that information to a to a question. Does your image archive have web interface of reachable from the Internet? If so, which ports? Does the console require authentication when reached from the outside? Can you show me? Show me a live example? Show me a live example in my own environment, please. Fantastic. Are you running authentic? If so, which version? You know, given, you know, this CV we've already mentioned covers everything between one before one five one point five point eight. You know, what version are you running? What's your viewers client side configuration? Where does that configuration point? And does the address require credentials? I'm yeah. The list is on on the screen. You know, obviously, put these through your partners, your, you know, client managers, vendor managers, whoever you have have to be. You may have to reword the questions slightly to make it more presentable. I'm someone who asks very blunt questions and expects very blunt answers. So maybe translate these into business speak if if needed. So, again, these are not necessarily, legal, advice, but, you know, from a world speaking, you know, how to map the findings into existing obligations. You know, again, take a screenshot or wait for the slides to come out. I'm not gonna go through every single one, individually. But most of these, you know, will map to, HICP, HIPAA, etcetera, etcetera. So they're all listed on the screen, at least the more obvious ones. There is gonna be more, but it gives you an idea at least, at least where to start. Give that a couple more seconds just in case. And then how to hunt this in your own estate. Again, we accept that there is a lot of skill skill differentials, within various different groups. People can do this. People don't have teams. People do this all the time. So, you know, as a as a hunter, I would, you know, start on the left hand side of the screen. Start with the console fingerprint. So as we've already mentioned, Authentic Explorer, for exam example, has a recognizable page title and a, a body markup. Use that, and it finds the administration consoles without actually touching a DICOM port. The the Favicon hashes spend a lot of time, doing that. Most of the commercially available scanning platforms, will let you search for those hashes. And, you know, from our research, 96% of the things that we found actually co carry those those hashes themselves. So you can already get an idea of potentially the value of of maybe understanding some commercially available scam platforms can can bring. Look at the status code before content. You know, on the right, there's the sort of three way test that was used. A four zero one authentication header means protected. 200 serving the console with no login markup means open. A 200 with login market presence, where you cannot tell from the outside whether the gate is real is yeah, is is ambiguous, at best. But and, personally, I would count those as ambiguous rather than confirmed as open. And that's why, you know, this I said right at the very beginning, the 40% that I mentioned is kind of the floor, because there is a lot of ambiguous, findings in the research. And then, you know, a couple of ground rules for those that are going to do this. You know, everything that I've mentioned or you can see on the left hand side of the screen is, is is passive. I mean, it it can be done anytime. Yeah. And, you know, it's against publicly in-depth data, which is why we can or why I was able to run this myself and, you know, identify hospitals, clinics, etcetera, etcetera, because that information is publicly available. You know, obviously, as soon as you wanna start poking around inside, that's where you need to get into authentication, testing, etcetera, etcetera. Yeah. I'm sure you already have your own processes for that. Or if you haven't, bring someone in who can who can do that for you. So yeah. So last slide. And then if there's any other questions, I'll have you take them to that point. So, you know, where we're essentially leaving this and some of some of the takeaways, you know, is is that imaging has a second has a second layer. You know, so the first point really is the imaging exposure. You know, the sector has been measuring only one of those layers for, you know, the last seven to ten years. You know, 40% of The US authentic consoles that, you know, we could see answered a browser with no password. You know, take these away. 700 o h f, viewers sit in a category that, the protocol censuses do not count at all. So your numbers, your scans, etcetera, don't even include this information. You know, closing the DICOM ports does not touch any of this. So you need to, you know, go through the processes. And the second really is is that, the exposure is copied rather than, invented. And for 96% of one artifact across a whole population is number to remember. You know, the problem, is the solution to the problem is spreading the same way that the problem is being created. You know, organizations carrying most of this exposure, unfortunately, not hospitals. They are, you you know, the small imaging operators, and so on. It's not somebody else's is problem. It's it's your hospital data that is sitting on servers that you, you know, have never infantried, and maybe you've never asked the question to those imaging centers what their security protocols are. Again, things that you can do here. And I'm just gonna reiterate again, before I close that out, that all of this came from data that was already public. Just happened to know where to look for it. The bottom line is there's no sophisticated hack here. If I can find it, then the adversaries can also do exactly the same searches, and so can you, to find exactly the same information. The difference being is how the individuals then use that data or use that information, for the different for different means. So the blog post is still live, is still live. There's a collection of health care reports on there. Feel free to go through all of them. The data taken from here was from June. So it's already, you know, three, four months, potentially out of date, but that was intentional as well. And, again, if anyone wants to reach out, understand how to run this against their own environments, or have any further questions, please please do so. And I will, see if there's any further questions. That is not a question. So do you know how many of the authentic services being used in medical? From the passive research perspective, that is not a question I can answer. Unless they are labeled or tagged in a specific way, I can only make inference, from that. That is a question that only can be answered essentially internally, by your own organizations or your own companies. Generally, you know, use cases are quite strict in scope, so you can you know, it's created for a reason. So you can assume that that's still being used at least for that reason, but, unfortunately, it is not something which, passively, I can identify. Okay. I do think that looks to be open source as being used by or some other imaging software vendor that is leaving it exposed. But the simple answer is yes because the the vendors themselves are not looking at this information anymore than, potentially, you're looking at the information yourselves. So the answer is I don't believe it's intentional, but yes. And we are about to end. So we've hit time. If there is any other questions, like I said, feel free to follow-up, either via Discord or follow-up directly. Thank you very much for your time today. Thank you for everyone who's hung up. I did not believe this is gonna take the full, full time allotted, but, clearly, I was wrong. Yeah. So thank you very much, and, hope to see you on the next one.