THICC Clients: No Problem! Reverse Engineering Your Way To Application Admin - Harry Williams

Hello there. Okay, good. The mic works. So, yeah, I'm going to be talking about thick client versus engineering today. Um, patching off thick clients for testing. I am a pentester for Stripe OLT. Um, so I'll be going through some examples, some cool things to remember, and just some sneaky tricks you can use during your pen testing. And I'm also very proud of the title if you got the joke. Um, so the boring stuff. I'm here as an independent today, so not representing my uh employer, so just bear that in mind if you're watching. Um the very boring intro of myself. Um first of all, I love Scapy, so if you use Skape, you're now my best friend. Um

I've been doing pen testing for 5 years, give or take. Um I've gone to a boutique now. I used to be at a big firm. Um I also really do enjoy um Linux in my personal time. My own PC runs Linux because I hate my free time. And if you get really bored today, just, you know, look at the memes. They're fairly educational, I hope. So, if you've switched off, just look at those. That's completely fair. Um, so some useful points. First of all, no shade to anyone who's watching who might be my clients. Um, I haven't put your code in, don't worry. Um, no shade on anyone trying to do research or presentations today. It's

a lot harder than it looks. I don't have all the answers, by the way. I'm just some guy with a microphone just going through something I really enjoy. So hopefully you can go on that journey with me. So the master planish is to go with their clients. What are they if you don't know and why do we care? How we scope them. I'm a firm believer that your test is almost only as good as your scope. So I'm going to go over scoping of the clients very briefly and then some of the reverse engineering stuff itself and patching thereof. Um the focus today is more of the process of finding cool and interesting things when

you're reversing rather than just giving you one example and then you figure out the rest yourself. Um and how we then take thick client abuse and maybe link it to other kinds of testing so you can use it in maybe internal testing for example. And in a massive tangent on research and the quality thereof based on some stuff I was doing when I was trying to look for things about thick clients about 6 months ago. Anyway, so why thick clients first of all? Well, the main reason I wanted to talk about them because they just kept breaking and as they kept breaking, I wanted to know why. What's going on? And I think we should talk about this. Um,

the thick clients to give you an overview, it's essentially an application where the majority of the processing is happening on the client or the host side itself. So rather than being say a thin client or a web app where a lot of is happening on the backend server side, uh, you need a constant connection, all that jazz, thick client, a lot of the magic is happening on the host side. So think of offline games or calendar apps. Um but also other things too. Um lots of data aggregation software uses the clients. Uh in some respects a technology of an older time. Uh you'll see a lot of .NET or C um and also Java as well. Um

they're the main ones I see come in. Although that's fairly anecdotal. There are other code bases of course. Uh a lot of them are quite legacy. A lot of clients come to be a thick client saying hey we got this thing. We don't know what it really does. It's been there 20 years. The guy who made it gone. Um, can you pen test it? And then you start to cry a little inside because you know, oh my god, what is this going to do? Is it really really important if I'm going to break it? Um, and yeah, you can also see them in sandbox environments. So like kiosks and things like that. It's always funny when you get thick clients running

on tills and things because you hear like the doo doo doo doo sound of XP. Like what's that? Oh, it's a till. Nice. Um, so it's full of holes. Um, so more on to the why do we care? So I touched on this just now. There's a lot of data aggregation happening with thick clients for some reason. Um, even big organizations, quite modern organizations, a lot of them still have these thick clients floating around and they just do a specific thing like maybe a time sheet application or some kind of personnel organization or orchestration or some kind of logistics of some description. And you know, if you work for a big organization, you might yourselves have some kind of weird app

on your desktop on your gold build image and think, what does that do? And it's, oh yeah, it's for the the sales department. Oh yeah, it's this app that no one uses. And then when someone says that, I think that sounds awesome. Let's check it out. So that's kind of why I came to the conclusion of we should talk a bit more about fit client testing. Um and also, yeah, they're often overlooked and a bit undervalued. Um some of these are quite important. They do some really important things and they can get a lot less love than almost cooler cousins webs and API applications. Um you know, devs are always hot. Oh, we've got the

latest web app. It's got this cloud thing. It's got this thing. It's got WS. It's got secure coding from the beast or then say right what about your thick clients that go don't know it's just there and it does a thing and we leave it alone in the corner and it has loads of cobwebs. Okay. So this well wanted to touch on this today with you and also lots of direct connections to SQL. U how many of you do pen testing on thick clients as a show of hands just so I know what I'm talking [snorts] that's a fair amount of people. So that's nice to know. So, I'm sure many of you have seen a lovely SQL connection

going straight back to you from he has a nod here. Cool. Um, I always think thick clients are just SQLI as a service to be honest with you. It's just SQLI as a service. Um, plain text credits and memory dumps and stack traces. Those are great. We'll come back to those later. Um, the conversation I had with a client recently when they said, "Okay, we give you a C fet client." and you get there and they say, "Oh, well, um, we don't really give source code out to clients. Our web apps were really secure. We keep them under control." I say, "Right, well, your thick client is just a nice compiled bit of source code." And they

go, "Uh, okay. Well, you know, who's going to reverse that?" Well, wait and find out. So, first of all, scoping thick clients. I don't know why I'm looking back this way. Um, in terms of architecture, when you scope these things, try and figure out how they're built. Are they two-tier, three tier? Are they directly talking to an SQL database? They're probably two-tier. If you got some weird intermediary proxy, web proxy, HTTP, something or other, it's probably three tier, maybe a bit more modern. But the point of this is to give you an idea of where you can take your testing. You go down the traditional SQL route or maybe more of a web like test, although they're not web

apps. So, uh I see some people treating them as web app tests and taking the OOS playbook and throwing it at thick client testing exactly as a web app. It's not quite the same, but yes, there are crossovers, although they need some special approaches in some respects. Uh, proxy awareness is a mixed bag when it comes to thick clients. So, some of them are aware of proxies, which means they'll have a built-in way of you making a proxy work with thick clients. Maybe a, you know, set manual proxy. You plug in your local IP and port 8080 and you get it proxied and you do a high five and you cheer a little bit and you

cry a little bit inside cuz it works. Although most thick clients won't work like that. A lot of them are not proxy aware. They won't work with proxies outside the box. So then you get into things like um booking the application and trying to force the proxy through. Any mobile app testers in the audience, you'll have had your own fun of this with the likes of free objection and pinning and all the rest of it. Similar boat for thick clients as well. You don't always need to proxy to get big wins on thick clients. By the way folks, sometimes you get some wicked findings just by throwing some really basic out of the box test cases against them. Um,

typically I test for about four or five days. You don't need to go overboard. A similar scope to web app in terms of days is fine. Um, about a week or so. Um, when it comes to where you do the testing, do bear in mind that sometimes you can't just test from your own box. Sometimes you've got dependency issues and this thing's got to talk to this thing and this firewall was over there and I don't know how to set this and the client ends up causing a bit of a mess when you try and get it working on your own box. So just have that conversation early. You know, do I need to be on your

network for this to work or can I just run it on a VM locally? Get that conversation done immediately. Um, and obviously if you're going to be on the network to do this testing, just make sure you got local admin and you got all your tooling requirements and you're not going to get killed by EDR or something on day one of testing, which has happened to me before actually. Um, yeah, and also make sure it's separate from production. This goes for web app testing, but I see a lot of clients still saying to me, okay, yeah, it's not production, but then even though like the domain isn't, maybe the database is, just make sure they're segregating for

production when you test things. And if they are cut to production, some of these things are quite sensitive. So pro them gently at least at the start and then slowly turn up the volume on the the subsequent days, folks. And now for the technical stuff because we don't really want to be looking at text all day. So um actually testing the apps, what do we do? So you've got the OOS playbook for web app. You've also got it for thick client too. And that's really useful. Um but I usually pull out three major test cases myself. And this is obviously anecdotal. You may have your own test cases and that's wonderful. But these are the three that

I usually poke quite um quite hard. The first one's reverse engineering. And we're going to get on to this shortly. But you I think developers um often treat thick clients like a web app and they lock down a lot of the input parameters and they think carefully about those sort of attacks but then they completely neglect the fact that some code can just be decompiled and you can just patch it in way that it makes uh nice pre escalation work or something similar. Uh plain text creds right this one is a fun one. So uh if you're dumping memory um that can sometimes have creds in them. Again, mobile testers in the room will know this. Um,

also if you're going for processes like say outsource, you know, process could be really good for getting creds and the client's no different. So, think about those memory processes too. Maybe you find something cool in there. You may even need to log in. You may even have creds, but if you look in memory, sometimes you get funky things. Um, system informer, I believe it is, can also look at stack traces. uh you'd be amazed how many thick lines I get where MSSQL credit is just there in plain text and you sort of go well there's a lateral movement that could be very fun. So when you're doing these tests, um, do have a look around at things that are

hiding in the background and try and pull creds because you'll often find them unencrypted, especially the legacy ones, too, which is good for lateral movement. And even if it's a gold build image, you know, just because it's some bespoke piece of client software doesn't make it safe or secure because you can't find a CV for whatever the janky app they built 20 years ago. Um, and obviously SQL injection. Now, escort injection is the big one, but the one thing I do want to say is for some reason developers really like giving you the option to run your own custom ESQL queries in thick clients. Lord knows why. Um, because you will spend a long time maybe trying to get SQL injection

to work, but if you can just tweak a setting, make yourself admin, and now you can just write your own queries. Brilliant. You've just [clears throat] given me SQL injection straight up without even much effort. So even if you haven't got admin, um try and look around for things that are grayed out. You can't see certain functions. Look for admin functions wherever they move found. Look in the code. Look in config files. Just try and get some idea of okay, is there any SQL custom query launcher? Because they're weirdly common in some of these apps. Um right, so reverse engineering. I'm going to focus on C here because the one I'm best at doing for the clients. Uh

although you can do similar things for say Java and etc. So, we're going to assume we got a nice C uh binary which is called vulnerable.exe and it's been written in C. It's uset runtime environment to make it all work. Brilliant. So, it looks like a nice executable. So, what do you do? So, if you never done this before, essentially what you're trying to do is take that executable and make it into something you can read and interact with. So, something like DN Spy is a really good option. Um, I spy as well. There are other tools you can use but essentially what it does is when you have a C applet it essentially works by

um the net runtime takes the intermediate language instructions and then compiles those at runtime and so you get your executable. But DN spy and similar just do it the other way around. It takes those instructions and it takes them and it tries to turn them into pseudo C. I say pseudo because even though it is C, it's not an exact replica of the codebase. It's will sometimes have errors and missing libraries and dependencies. So you may find things don't quite look out the box, but it's work well enough that you probably won't even notice until you try and compile something. [snorts] Most of the time I would say from anecdote that if it's one of these junky C# apps, it's

not going to have obiscation, in which case you're just going to load it into DN Spy and it's an easy win. That's a fine itself, but it's only going to be a fairly low one. And we don't really care that much if you can obiscate it because well, you need to really prove something first. So the other thing as well is if it's not rendering in dnspy or similar it may be that it's not actually in C. It may be assembly. I had a test recently where uh I kept sticking in DNS spy wondering why it wouldn't decompile. Got the p the portable executable header in the DN spy and I thought why would it

decompile it's assembly in which case I thought right okay that's gram magic that's probably going to take a long time. I'm leaving that aside for one minute and going for the easier wins just for now. Um so don't be afraid if it doesn't quite decompile. maybe that it's not quite the language you expected, but there are ways of figuring that out. [gasps] Right? So, I'm very proud of this meme, by the way. Um, if you're doing any kind of work with something like DN Spy, the the way that I go about this is I try and find interesting things first. And this is fairly good for any kind of testing really. But, you know, when you

look at examples online, a lot of them will use uh stock examples like damn vulnerable thick application or something similar and give you a very specific example. But when I do this testing, obviously I'm I'm hitting the unknown. I'm seeing things haven't been pentested before. I need to have some kind of idea how to find things that haven't been found before. So first thing I do is I find interesting classes in C. So say I decompile the app. Uh by default control shift K in the end spy, but essentially you search the assemblies in the C# code and you're looking for anything really obvious. Just search for the basic things. Login, admin, privileges, groups, it doesn't

matter. just try and pull back the really like stupidly obvious and usually you'll get something back. Login's a good one because you can um almost always guarantee you have some kind of login or process to login. So you can go and start there. Um read through those interesting classes. Um think of things you want to achieve in the app. If you know your end goal, if you know what you're trying to do, even if you don't, just think, well, what would a thread actor try and do had they been given that? Is it data compromise? Is it an application um take it? What is it? Okay, think that way. Um, another way of doing it, if you're really struggling,

if you open the thick client locally and you start running it, clicking through things, um, look for strings that come back in text boxes. Look for error, not an admin, take that string, go back to your DNS spy, your iOS, whatever it is, and search by string, pop in that string, and then work backwards from there. So if you if you search for that string, you can usually find the corresponding function and therefore the corresponding class and you can work backwards there. So that can at least tell you, okay, this bit enshrines pone in the in the application. Okay, it's located here. Brilliant. I can I can go from there. Um, next thing to do once you've done that,

let's say you've got an interesting function. Okay, let's say uh you got a class called login and there's a function for checking if you're an admin. So check is admin blah blah blah. Fine. Um, that is obviously a very interesting function to us because we all know in this room that if you find something is admin equals if you can change that, that's a that's a good win, right? So once you've got that function, you want to try and change that. And often times it's going to be an if statement. Nice and simple. If if is admin equals 1, do a thing else do another thing. It's usually that straightforward. Sometimes it's not. I'm going get on to certain specifics

shortly, but you can guarantee that at least some kind of wonky boolean are going to be around in a few of these apps that you test in the future. Um, once you found those, you want to actually change them. Um so the way that you do that is I mentioned earlier in the talk about intermediate language and I kind of rushed over that quickly but to give you a better understanding intermediate language or common intermediate language um it's basically somewhere between say C# and more machine code although it's fairly readable closer to C# it's basically a way of pushing instructions to the stack. So when you come to your DN spot, you decompile your code, if you just try

and backspace out um equals true equals false and you try and save that application, you're probably going to get an error most likely because when DNC tried to decompile that code, there was missing dependencies, missing things and it's not saving properly. So the way you get around that is you use CIL from an intermediate language and applications like DNS spy come with some really nice functionality. So you can mess around with this. So in the case of DNS spy you can edit the instructions >> [snorts] >> um for intermediate language themselves. Um once you're in there and we'll get into an example so you can visualize this in a moment but essentially once you're in there you're looking for the

exact function you're trying to target say check is equals true and then you're trying to edit those um intermediate language uh instructions. And there are some examples on the on the board here. Um but essentially if the examples seem a bit wonky and meaningless that's fine. Essentially, just start by looking for keywords, things like true and false. You start there, zeros and ones. Um, I usually keep a little cheat sheet of instructions next to me when I do this because you can get quite a lot of different ones. You can be thrown off sometimes. Uh, but usually you'll have an interesting function here. And if you look underneath that, you'll have your instructions that you can start uh

manipulating for what you want to do. Uh, and also sometimes things don't always um get represented as really nice strings. Sometimes things get interpreted as say hexodimal. I had a test recently where the thick client application was vulnerable to priv through patching the app. But in order to get the escalation, it wasn't like um it wasn't actually taking say if like a one or a zero is an argument. It was taking hexodimal in the instructions. And to get the correct hexodimal value, you had to go into the code, find all the groups that were um granular permissions for the application. admin, sales, user, whatever it was, and then you had to figure out the corresponding

hexodimal from that list. Um, so if you ever get stuck on what a value is, just click through it. Uh, usually in tools like the Inspire, it will give you uh a way of recursively clicking through functions and strings and values and variables so you can pinpoint exactly what it is you need and what something actually means. Once you've made your changes, just make sure you save them as a new file if you can. Sometimes you can't or in my case sometimes I just can't be bothered. Um I had one recently where I tried to make it a new file. I just kept throwing errors at me and I gave up trying to fix all the issues. I just thought, you know

what, we're going nuclear. I'm just going to save it and overwrite the old one. I don't care. Um thankfully it didn't break anything. So that's fine. Um you may also need to implement several changes to those instructions. So don't be afraid if you've made one change and nothing's happened. Um, that's usually normal as long as the app runs if you made a change. That's a good start because it means you haven't completely bought the instructions. Um, but I found things like you might find recursive tabs or toolbars, nav bars that have permissions in them. So you got to make several changes and several boolean changes to make it all work and flow nicely. Um, so don't be alarmed if

it doesn't work the first time. So putting it together and trying to use a junky example of C. I'm not a programmer by any stretch, by the way. I'm very good at, well, not very good at I'm okay at breaking things, but I really suck at building things. So, I have some janky C here, which you definitely probably won't be able to read. But essentially, what you need to know is that is for all intents and purposes a login function. And when you come to your DNA, you take code, you decompile it, you'll see plenty of these, and it's your job to figure out, okay, where's the interesting bit? Where's the interesting class the function and the subsequent um

point of takeover in this case there's a check for admin being true or false depending on account from the database and this is the rest of the code that you couldn't see in the previous slide. So this is the bit that we really really care about and if you can read it you can almost exactly see what I'm trying to explain here ignoring the catch statement at the top if the count equals one. So if you've got a valid user um check is admin if if is admin. If it's an admin you do a thing. If it's not an admin you do another thing and you have the other else statement there to catch anything which doesn't um match the

count. So it's an invalid username or password. So sometimes it really is this simple. You'll see functions this simple in the code. You got a great that's probably going to be a takeover. So how do we actually take that and run with it and make it do something funky? So looking at the intermediate language instructions here that go to stack. So if you look at that and it's your first time looking at that you might think what in the hell is that? But actually if you break it down into little chunks it starts to make a bit more sense. So remember I spoke about strings earlier. This is why strings are handy because you can take the string that you know is

in that code and you can cross reference it with what's in the CIL. So things like try harder scrub or you know you are an admin. You can start to piece together parts of the code. So for example, congratulations, you're an admin. On line nine, we flick back. Okay, that's probably the um bit that's deciding you're an admin. So you get do admin things. Line 16, try harder to scrub. I don't know why I picked that phrase. Um you can see that's probably corresponding to the user dashboard. You can see the user dashboard function there. Uh you can see a message box for displaying that string. So okay, we've got two functions which are being um set

in the instructions there and push to stack. Um and at the bottom there we can see the value username and password that gets written as well. So we can start to piece together parts of this and there might be a lot more of these in that those instructions. So don't be you know put off if you can't immediately find it but it's something like this usually. So that takes the top and essentially um line four is where we'll start actually and let's skip the first three lines because line four um the word false should grab your attention and the line 21 reference afterwards should grab your attention because if line 21 is invalid username or password um and it's false

so we can start to piece together okay maybe that's corresponding to the count. So if the count is false, we hit the else statement. It's invalid password or username. So it's the failed login. So that brings us to line six. [snorts] So false line 16. Okay. So false. If false go line 16, use a dashboard. If we flip back and if is admin, do admin stuff. So perhaps if not is admin. that basically you're not an admin, jump to line 16. So okay, that means that if we're not an admin, we get to like 16 and we do non-app stuff. So what happens, you can see where this is going. If we change this, well, this is also the breakdown

I've just mentioned to this. So I've just taken the false and [snorts] made it true. So if we say we invert that logic now when we log in as a non-admin well we're going to go to line nine. So now we do admin stuff and that's how it works in theory. So you're essentially trying to take this code, should I say this code, break it down to this, start to piece it together, and sometimes it really is as simple as looking for zeros, ones, trus, and falses. Um sometimes you'll find new operations. Um don't let those throw you. Um sometimes you'll find um several instructions that layered and you can try and find the right one. If you get

the wrong change the first time, it's not the end of the world. um you'll likely break the first one you try and patch. I've done it so many times and sometimes it is trial and error to find that exact call. Uh it's almost like looking for a needle on a haststack sometimes. Once you've got that, you can actually do admin things. So I had this on a recent test where um the application was vulnerable to this and it was just an if is admin or similar to that where I just made it the inverse and then you had admin um which was also really bad because the every admin for that application could run custom SQL

queries. So even if they patched SQL injection on the app didn't matter because I could just run SQL queries straight up. So this was quite a good finding for them actually as well. Um so I want to bring us to chains now and exploit chains. So when you're doing testing and this goes for any testing but I'm going to specifically talk about thick client testing here. Um thread actors don't operate the way we write reports often times uh especially pentest reports leaving say more like red team and breach creds reports for a second to one side. Um, when we're doing our attacks, it's our jobs to make sure we're trying to demonstrate pox and chains where we can kill chains because

no one cares if you just obscate the code and read it. Like that's so on its own doesn't really mean much. Okay? And given that the client's got to go through a bit of a painful escapade to try and fix that and obiscate that code. Um, if you just give them a low finding of the obiscate code, they're not going to care. They're not going to listen. So you got to put things together. So when it comes to thick clients, do the opposite of the code. Find an interesting vector for Pesk. Find an interesting vector that you can exploit. Patch it, run it, build a park. Okay? Everything you do, try and build a park.

Give it to the client and make them care. Remember who you're talking to, you might not be talking to a dev. You got to talk to someone in seuite. You got to approve budgets. So you need to show them something of interest. had a client recently who uh rightly pointed out that my patched uh application gave me admin but so what was I mean they were their main interest was data exfiltration of the database that's what they cared about customer data and that's completely fair and justified so one thing that we did was once I got the patch working I went back to the code and I found that there was a a call for

custom SQL queries so I also changed that for any non-admin on the app. Meaning that okay, now I've got the admin and I can run custom queries. So now not only have I got the escalation, but I've also proved compromise of data too. Often times if you can prove data compromise on app, clients start to pay attention and they start to listen because that now means something very very different for their risk. Um something for its own sake only serves your ego. It doesn't serve the client's interests. And at the end of the day, we're trying to make clients more secure. Whether we're red team, blue team, or anything in between, we're just trying to help clients be more secure.

So, um, think about how you build your PS that so what factor. Um, some exploit chains you might consider a thick client testing. We've talked about patching to SQL queries, but there are some other ones too. Um, try and hook those applications. You know, pull out echo mirage and look at encrypt unencrypted traffic. Sometimes you find weird creds flowing around and encrypt the traffic. pull out Wireshark. Don't just pull out the creds either. What are the creds doing? Where do they go? Follow them. If you're inside that client's network, definitely follow them. Um because even though you're thick client in scope, at least pointing it out to the client, hey, did you know your file transfer mechanism for this

app is all unencrypted, you know, maybe that should be your next focus for the next test or maybe you should think about this because even though it's technically not in this specific thick client scope, it's a separate server. It's still important enough for you to care and do something about it. Um we talked about escort to death to be honest. Another thing that's interesting too is go and read the code um line by line or at least class by class and just even it's control F and find interesting strings. You'd be amazed how many plain text creds are in legacy apps like this you find even if it's a URL um clients don't always expect you to go and you

know use a thick client to kick off an API endpoint attack or something like that. you know, clients just see, hey, they got a thick client. This what they're going to do. A threshold injection against it, but we've protected against that. So, so, you know, it's fine, but the janky API endpoint that the thick client calls is probably unprotected, and they didn't think you'd find that. So, now you've got a vector. Um, so think about that, too. You can sometimes turn these into um pseudo web app tests if you find the right endpoints because some thick clients are just rappers for endpoints for some reason. Um, so this brings me on to the latter part of my talk. Now, and this is a bit

of a tangent and I want to tread this carefully because this is something that came to my mind when I was doing thick client research or say research thick client testing over the last year or so. Um when I was researching how to do thick lines and ways to go about it and ideas of thick line testing, a lot of things I was finding um were regurgitations of very very similar examples in what's called uh DBTA or down vulnerable thick application which is a great piece of tooling. It's a great piece of software really good for learning thick client testing by the way. But the thing about this is when you're searching for something, especially as a beginner and you see the

same 100 articles coming back saying do this one thing and get admin. It's not helpful. It's not helpful because as as a beginner, you feel completely overwhelmed. But if you're, you know, seasoned veteran of a particular application test or some kind of technology, you think, well, this doesn't teach me anything new. Um, which is why when I talk about these things, I try and focus on the process of discovery and how you can apply that to your own tests and any test that you do. Uh, I wouldn't be helping you very much if I just gave you, you know, the same example, the cookie cutter example and said, "Cool, this is how you do it

because that's not always the case." Um, so knowing how and why and the context of is sometimes easier or better than just getting some random example. Um, sometimes you get blogs that are just dropping tools on you just saying these are the top 10 tools or these are the top 10 methods or the iss conversation. I could get that somewhere else. Um, everyone starts somewhere. Everyone's, you know, taken steps into research blogging, you know, we've all done it. But it's important to recognize, um, sometimes when you, you know, discuss things, it's think about how you add to that conversation, what you're putting out there because also clients see that. And you know, sometimes I'll have clients come to me

with random blog posts and I'll look at and think this is not really something you should be focusing on or actually this isn't applicable to you. It's not properly contextualized. This is just going to waste your time. Uh with the greatest respect, um there are some really good resources out there um from talks to papers, white papers especially. Um but it can be difficult to cut through the noise uh especially these days of LLMs. Um but you up against it really when you're trying to post something and have a saturated environment as the cyerspace and trying to give uh good research and good insight. You can always be drowned out by the same blog post over and over

again. Um so I put declining research quality as a question mark and this is more of a I don't have an answer for this. I just want to open this conversation up when you leave this room because something that I think um I want to talk about and I want to bring up and I don't think it's being talked about enough which is how are we how are we doing of research as an industry from offensive to defensive and everything in between. How are we doing? Um you know it's wonderful when we have talks like this. You've got some brilliant people with some amazing ideas and some really good original contributions. But unfortunately sometimes I feel like as a community u

we talk a lot amongst ourselves and we share content with each other but sometimes clients don't see that and the people that need to have eyes on this seuite and etc don't always see that. Um a lot of what I'm talking about today is you know what I've found from hours upon hours of head bashing on real tests. It's stuff that I've picked up from doing tests on real clients, real apps with real data. Um although you will see some of these things will be online, it's good to add in how you find these things in the first instance, especially if you're taking infant steps and do this kind of realm of testing and upping

your game there. I think what I'd really like to see, and maybe it's me being um looking back at nostalgia, I want to see some janky Millennium blogs again with the static HTML that's badly formatted and the really bad glaring color schemes and the crazy effects and, you know, just people with original ideas and content and just putting it out there and having an idea. You know, it doesn't always need to be right. Sometimes just give a hypothesis. You know, even if you got something good to say, uh it's how you say it and put it across like, "Hey, I've seen this thing. Maybe it needs more testing. I don't have the time or I

don't have the proper capabilities, but I know there might be something there. Um, I want to see blogs like that. They're cool to read. It's just it's just an interesting take sometimes. Um, a good idea method is a lot more interesting to me than just the same regurgitated message. Uh, hyper specific examples are not always a good thing. They're good for grasping a highle concept, but they don't really teach you a lot in the long run. And you miss that process. And if you don't know the process, you start to become a box ticker. You just look for the thing you know to do. You look for that same example, that same CVE, that same

method, that same chain that you know and trust, and you miss some of the cool stuff that's beneath the surface. Um, sometimes it feels like if you're in an ever connected space, everyone's an expert, everyone's got the blog, everyone's got the podcast, everyone's got the talk, and we've got a saturated space. And sometimes we need to um go back to the basics a little bit and think about um really putting out original ideas. Um we've seen some great research recently, some recent bugs and I want to see that continue and a lot of stuff from today that's really interesting with all the talks we've seen. I want to see that be, you know, pushed out there and I want to see that

being built upon and promoted because there's some really good content out there. And the last bit here I want to really focus on is regarding certifications. Um, don't get me wrong, I've got certifications. I've got CSTM and CRTO recently, and they're great. They serve a purpose. They're a tool. They're effective for getting into cyber for, you know, using as a baseline. Clients use them as baselines, um, certain types of testing. And that makes sense. That's great. But how many clients are asking for CVs? How many clients are asking for research papers? How many clients are asking for that stuff? And you know, as great as SS are, and as much as I respect them, support

them, want us to get more of them, they're not Pokémon, okay? And if if the best testers are always, you know, chasing the next, then are they missing opportunities? So, original research, is there, you know, a missed opportunity there? Is there something we should be looking into in that regard? Um, I don't know, but it's something I think we should think about as a community. Um, so doom and gloom over many ran over. Um, talk about better standards. Even if it's just for, see, even if these are things that I want to do for myself, you know, they're not necessarily, you know, pointing fingers at anybody or anything or any kind of body. It's just original

ideas for me. Um, take the content you read with a grain of salt. And this is true today more than ever. Uh, and that includes my own talk. You know, take it apart, build upon it, and consider it critically. It's not perfect. I get things wrong. But hopefully there's enough here that gives you original ideas. Uh don't just read about it and don't regurgitate it. Replicate it. Do it for yourself. Figure it out. Um if you could try and make it better, even even better. Um I'm sure there people in this room who could take what I've done and make it 10 times better. Um and also if you're say a consultant, if you're working in the pentest space like I am,

or if you're an employer, um one thing I would say is think about research days. Think about promoting research dates and think about the importance of that for the community. Um, you know, these kind of things are really crucial. Think of the biggest books that we keep finding. You know, some of that stuff wouldn't be possible without people taking the time out to to find them in the first instance. Um, so consider that one. I know it's easier said than done with chargeable hours and that makes sense, but think about it if you can talk to your employees. So, some closing remarks on this and some key takeaways from what I've said. First of all, for any testing you do,

try and learn the process. Don't just learn the example. More often than not, XC's can be just gifted source code bundles, especially the C# variety. So, don't just treat them as some kind of, you know, mystical thing that you can't really touch or don't think, oh, I've never seen a do any I don't know what I'm doing. just it's okay. Take a break. You can do it. Um decompile it and just move slowly. Fit clients may give you some nice pivot opportunities. Look at those stack traces. Look at those memory dumps. Look at those config files. Look for SQL creds. They're more common than you think. If you're stuck on a latch movement, look for SQL creds in those

clients. You might find one even on your goldboard laptops. Always go kill chains over standalones or at least almost always. Um it demonstrates good value for a client. It demonstrates threat capability in context rather than just hitting risk ratings for our own ego. I know it's cheesy, but uh do get it wrong. Uh you can learn a lot. It's fine if you get stuff wrong. Okay, do you know how many hours this you know trying to figure this out took when I first started learning it? It took a while, but it gets easier and you learn a lot from the process. So bear that in mind. But anyway, that's enough of me rambling. I'm very thankful for you all

being here. Thank you for paying attention and enjoy the rest of the day. [applause]

>> Thank you, Harry. Thanks for your talk. Has anybody got any questions at all? >> Um, hi. I was I was just wondering if um you found there was a specific benefit to editing the intermediate uh code rather than editing the C# and then recompiling or is it just a personal preference? >> Personal preference to be honest. Um I ended up walking across IRL and intermediate codes uh when I was starting out with thick clients and it just kind of made sense to me. Um I completely appreciate that there may be other ways of doing it and I suppose when you're doing it it's all about finding that thing that works for you. Again, like I say, it's about process.

You find the process that works for you, then more power to you. But that's just my personal way of doing it, I should say. >> Thank you. >> Anyone else? >> Okay, that's great. Ah,

>> um, great talk. Um, one thing I've done a few of these tests and one thing I found hard is suggestions for the client to fix issues cuz like you say often these are old legacy apps. There's no one maintaining them anymore. So I was just wondering if you had any advice on you know providing the client value there. >> That's a really good question. So I'm going to repeat that. So how do you like recommend those for legacy apps and they're very broken. Um, how do you get around that? Um, so one of the things I recommend is split with the short-term and long-term goals. This how I do my recommendations. So shortterm if they

can get things obvisiscated that will at least slow down or stop your script kitty hackers and your very simplistic or you know board actors who will just move on to the next thing. Um it's not going to stop the terractors and it's almost a reverse engineer. Your athlete will um but it's also layering protections. Sign binaries are underrated. Um I know that falls on the customer then who has that application they got to set things and you know change uh detections of things but that can also be really useful. Checksums are great too. Integrity of applications. I mean when you downloaded you know ISO for Linux it's got a checksum. It's really powerful stuff. Um, so yeah, I'd

say obscation shortterm and think about long-term protections that from what I've said, but if they can, I would say get it over to some kind of web app in the long term. That's where it's going anyway. But appreciate it's all legacy. >> Anyone any more questions or Okay, that's great. Thanks very much, Harry. That's a great talk. Thank you very much.