So You Want To Get Into Red Teaming: Skills, Mindset, and Myths - Chris Pritchard

Good afternoon everybody. Thank you so much for uh sticking around till half 3 on a Saturday when you probably could be doing stuff in the pub or something along those lines. So I really appreciate you being here. Um, so this talk is about an idea and I get questions a lot of the time from people in industry who want to know how they can get into red team and the answers and the questions always tended to be the same. And so I'm going to give you all of this information so you can refer back to it at a later date. Um, I want to start with what I think is a reputational problem because there seems

to be a lot of myths around what red teaming actually is and what it is like in real life. So, let's start there and uh discuss what it is. Um, the first thing I think that everyone expects when they get into red teaming is this. and they're going to be some matrix style hacker who is going to click their fingers and all of a sudden they have compromised the entire network and they're in. It doesn't work like that, I'm afraid. So, let's bring you back down to earth and talk about some of the realities of that. And I can tell you that a lot of my time is spent doing this. Uh, are there any children in the room?

All right. So yeah, I won't say what the f bit is. I'm sure you can work it out yourself. >> Flip flip my life. That's correct. Yes. Uh and then also a lot of nothing is working and then a lot of no that didn't work either. Um but let's step back a little bit. Let's talk about what red teaming actually is. Uh so that we all are on the same sort of page if you like. Um and red teaming is a realistic uh adversarial simulation trying to test people, processes, technology etc. Um it is not just there to find vulnerabilities. That is not the goal of red teaming. Does anybody want to shout out please

bit loud what you think might be the goal of red team? assessing that your information security risk register is accurate with the actual risk. >> Yeah, that's a good one. I agree with that. Any others? No. Okay. I think and this is just my opinion that the goal of a red team, the end goal of a red team should be that the blue team is better because that is what we are trying to do. Going back to that matrix thing, if you think that a red team is just that matrix simulation and you're going to get domain admin or whatever all the time and you think that that is your goal as a red teamer, I personally think

that is wrong. I don't agree with that and I think that our goal as a red teamer is to improve the company that we are targeting or we're being engaged by and ultimately the the blue team should be better when we come out of it. That's my thoughts on it. Um, so what is red teaming and what is it not? It is not vulnerability scanning. Vulnerability scanning tends to be very automated, broad um, and they find known vulnerabilities in most cases, not things like misconfigurations, which a red team will probably love. Um penetration testing is uh tends to be a bit deeper but it tends to be relatively um uh tightly scoped tightly constrained like test this web app test this server

that tends to be what a a penetration test is and then a red team tends to be this goal orientated simulation adversarial simulation and then there's one further than that which I'll get to uh which is called purple teaming and that is where the red team and the blue team basically sit together and work again to make sure that the blue team spots things. So the red team will run things at very specific times and go right have you seen this? Just run this expert. Just done this. Have you seen it? Yep. Great. Seen it. No, I haven't seen it. Okay, run it again. Right, now I can see it. So tuning stuff. Um I'll give you very very simplified

engagement lifestyle uh sorry life cycle. um tend to start with scoping and talking about engagement rules and stuff. Um and what's in scope and what's out of scope uh and what's what's the end goal, what's the target and the end start the actual [clears throat] engagement itself. You do reconnaissance, you're doing open source intelligence gathering etc. Um, and then you might be trying to get in from that external point of view or you might get an initial uh access uh and then you're in the network hopefully. And from there you'll probably try to do some kind of lateral movement or some kind of priv escalation whatever it is that you're trying to work towards a

goal that you've been discussing and agreed upon in point number one. Um, and then the important bit, and this is an important bit, and I don't think people understand this either. Uh, this is, but this is really important. Reporting and debrief. This is essentially what the client is paying for. This is the bit that they're giving you the money for. They're not giving you money for knowing every single exploit in the world. No, they're giving you money for a piece of paper at the end of it, probably a PDF or something along those lines, because they need something that they can act on. And so there's your job to write in such a way that all of the technical things that

you have found and discovered in your red team cut testing is transferable to somebody who's potentially not technical and that is important. Okay, let's bust some myths. Um first myth I think you need to be a coding genius. Now I am not a coding genius. Can I code? Yes, absolutely. Um, but what I think is that you get lots of job postings and you see uh technical talks and you see um writeups from CTFs and things like that and everyone thinks I must be a coding genius to be a red team. I disagree and I think that realistically what you probably need is some scripting literacy. You need to be able to write some basic scripts to get

you started to automate tasks that you do. Small tasks, whether that be reconnaissance, whether that be uh enumeration, something along those lines. You need to be at a level that you can do that yourself. But I'd also suggest that you be at a level that you are able to take tools that already exist and be able to change them, amend them, look at them, and understand what those tools are doing. So some kind of level of literacy understand it. Uh Python is pretty common because Python is cross language crossplatform works on Windows you know etc etc. PowerShell obviously if you're in a very Windows dependent area shell is a good one to work on as well. If you

can do both, really good. Um, the next myth that I [laughter] like to bust, you need to be competent enough, and this is just to start out in red teaming, and I see this a lot. You need to be competent enough to be able to write your own malware and write your own C2. No, no, no. I'm sorry. You do not need to be confident as a starter in red teaming. You do not need to be able to do that. Um and again I think we see these things we see all these high-profile talks uh and and you know what there is there is that there are conference organizers are wanting people to come and listen to talks so they pick

things that interesting exciting and so they will pick people who have written their own C2 or their own malware because it draws people in great but that's a selection bias that isn't necessarily the real world um so what I'm saying there is that most companies or most businesses that you go and work in as a consultant, as a red team consultant will already have tools. They already have cobalt strike or whatever tool that you know C2 tool that you're going to be using. And what is more important is that you understand [clears throat] roughly how that works and what it does. Writing your own, [clears throat] you're not going to be doing a red team or starting in a red

team role. If you can write your own C2, you probably should be doing something else. Um but yeah um so again learn to use that tool understand it and then that is enough to make a start in my opinion. Another myth that I think is quite common uh you need to have every certification and you need to be doing every CTF. I see this a lot. I see this a lot especially on um you know social media people posting hat box they are in the top 1%. Brilliant. But for me as a hiring manager what does that mean? You you could be the top 1% anything within Hackbox. Now don't get me wrong, there is some really really fantastic

learning opportunities in things tools like Happy Box, but proving you were top 1% to me as a hiring manager doesn't mean a great deal because and I'll give you a great example. I went to a hat the box evening uh in London probably about a year ago, something along those lines. And the idea was lots of people come together, we all work and do hatbox challenges together and it's a fun good community-driven event. What I noticed was at the end the average number of boxes that people had completed was about 3 to five, right? That's a reasonable number in in about 3 hours. One person had done 20. Now, I am instantly suspicious because 20 is a lot in 3 hours. And what have

you probably done there? Well, you've probably done those boxes before and brought the solutions from last time that you did them and just pasted the code, the commands, etc. so that you can do 20 in 3 hours. Well, what have you learned from that? Probably not a great deal because you've just copied and pasted commands. you haven't engaged your brain to challenge yourself to learn something or recover memory that you've been taught or something that you've been taught already. So, h yeah, no, sorry, I'm not down with that. Um, what I would say is that um pick one or two of those credentials, one or two that accessible if you're looking to get into red teaming. uh RA

stands CRTO is a fantastic starting point. It is cheap considering um and it gets really good ratings in the industry and it teaches you some very very good fundamentals. You can then go away and take those things and apply them to the real world. Um, I'd also suggest if you can that you build a home lab because home labs will allow you a to learn how to build things which is basically what the system is that you are about to attack has gone through. So you will come across common pitfalls uh and common configuration errors and things like that but you can then go and attack it and those two things together are fantastic. That's really great knowledge

because you've done it and you have learned from that as well. [clears throat] Um, hacking as as a solo sport, it's not. Hacking is definitely not a solo sport. You will be working with a team, a team of people and you need to collaborate. You need to collaborate together because as a team you will have different skill sets and you'll have different uh expertise levels about different things and so you need to work together as a team. Now we've all seen you know the the Neo picture there the GIF and it's one person the real world does not work like that. Even if you go and look at all of the real factors in the world,

you know, you go across and look at North Korea and stuff like that, there's not one person doing that. There's a team working together. So, learning and understanding how to work together as a team is really, really fantastic and important. But also it helps you because you have to practice explaining non-technical things sorry technical things to non-technical people which again you are going to have to do in your role as a rect um so let's talk about some skills that I think matter networking fundamentals I think this is really underrated Nearly everything we do as a red team is going to be against or including or with some kind of network [clears throat] whether that's understanding how DNS

works whether it's understanding how CMTP works whatever what I think is really really important is just what's good enough to start uh and you know these kind of concepts here again at a conceptual level do you need to know how uh NLM Keraros works deep deep down probably not to start. Is it a good skill to have later on? Absolutely. Do you need to start? No. Think about the concepts. How does it work? Um and another one there tucked on the end, reading a network diagram. Again, really, really underrated skills that you're going to need because if you're scoping stuff or helping to scope stuff or if you've been given a network diagram, unusual in the red team, but

you need to know how to read it and what it looks like and what it could do and how you could then potentially go, oh, this bit is supposed to be separated from that bit, but maybe it's not. Maybe I should test that. um Windows and Active Directory basics. Most of the environments that I come across are Windows environments with active directory probably 90%. if not a tad more. So understanding how uh attack paths work through misconfigurations and I'm purposely using the word misconfiguration there rather than a vulnerability or an exploit because nine times out of 10 what we're doing is exploiting or taking advantage of a misconfiguration rather than a specific vulnerability. Sure, there are vulnerabilities in

Windows active directory as we well know, but nine nine times out of 10 you're going to be abusing this configuration. So, I purposely use that word there. Um, so good enough. I think understanding what users look like, groups look like, uh, OUS, GPOS, etc. Those are the good things I think you need to know to start with. going deeper than that. Yeah, sure. You're going to need to know about it. You're going to need to know about what's the favorite one of the new one about. Great. You're going to need to know that at some point. Do you need it to start with? Not necessarily. Um, but if you do do things like CRTO, you will come

across ADCS for example. But misconfiguration things, that's the things that you are probably going to want to start with. Um, I'm going to touch on this again because I think this is really important. Scripting. You want to be able to automate repetitive tasks. Whether you do that in PowerShell, whether you do that in Python, don't mind, doesn't matter. Pick your poison and go with it. But stick with one to start with. Don't have to do both. Doing both would be great. You don't have to do both. Um, what I would also suggest is being able to have the ability to read and modify existing tools. So get yourself to a level whether you've picked Python or whether you pick

Python for example that's an easy one to start with. Lots of tools out there in the industry are written in Python. Cool. But that also means that lots of common detections are written for those tools. So if you can amend those scripts and those tools so that they are different, there's a good chance that detections will go undetected. So being able to look and modify those kind of things, useful useful skill. Um again, pick one language really. You don't need to be uh writing a you know everything in a software engineering degree. No need not to start with. Sure, maybe later you might get into C, for example. I'm struggling when I say C because

um but you might you might decide that's where you want to go. Um so yeah, pick one of those languages, but you don't need to think about how you're going to architect an entire system. Just start simple. Focus on something. Um, another skill that I think is really really important as I mentioned earlier, the client is paying for a report. They're coming to you and your consultancy and your engagement and your team and whether this is regulated or non-regulated testing, they're paying for a report. They're paying for a piece of paper. They could be paying hundreds of thousands of pounds to your company for 10page report. You need to make sure that that 10page report, I'm just using 10 as an example,

it could be hundreds, um, is value for money. You need to be able to make sure that that report says in non-technical terms, look at all these crazy technical things I've found. So, think about that. Think about how can I communicate technical things to a nontechnical person because that's difficult. Try [clears throat] thinking about how could you explain to your mom or your dad what uh stock project for example. Could you do that? Pretty hard. But that's the kind of level of reporting that you're probably going to have to do. So yeah, think about how you could take real findings and you could take something that has been published recently in the news and break it down

into impact and remediation to a non-technical level that your mom and dad really understand. That's quite difficult, but I think it's really important because there is a good chance that your report is going to end up on somebody's desk who is not technical. the uh the finance person you you you managed to get into their finance database they don't understand about SQL servers or credentials or anything along those lines active directory they don't understand any of that they just need to know what is the impact and [clears throat] what is the so think about how you would talk about those things um this is what I think that is a little underrated Um especially when

as red teamers we are often required to be highly highly technical and I think one of the underrated skills and this is a difficult skill to put across if you [clears throat] are being interviewed or if you are interviewing is some of these non-technical traits and you have to be ready for these things because if you are going to get into red team you are going to need some of these non-technical traits. Patience is a big one um because you are going to be doing things that involves [snorts] lots of waiting um lots of confirming that that thing is in scope today or in scope at all. Uh, and you need to be really, really

methodical and you need to be able to communicate your things to the rest of your team as well. And they might not always be around or they might not always be available because they're doing something else in terms of what's on the engagement. So having patience is a vastly vastly underrated skill. Um, I have no idea how you would interview somebody or or as an interviewee how you would tell somebody you have patience other than saying, "Hey, I've got patience." Yeah, I don't know. But think about that. That is a skill that I think is massively massively underrated. Um, you need an amount of curiosity. What do I mean by this? Um obviously there's the obvious side of

the curiosity where you exploit come out and you want to understand how it works etc etc. There is also the dull side as I would call it of curiosity where you are in an active directory environment [clears throat] that has 300 servers. How do you find out which of those 300 are the file servers? Might not be obvious from the naming convention. Okay, I'm going to [clears throat] go and check each one individually. The service that requires a lot of dull curiosity and then you might find something on those file servers and think, "Oh, this looks really interesting. I'm going to dig into this. I'm going to be curious." And it might be something really innocuously named,

not passwords. Obviously, cuz we know that that's probably a honey or something along those lines. But you have to have what I would call a dull curiosity. You need to be able to go and explore things and discover whether they are actually valuable. Are they going to get you an attack chain that gets you to your goal or your end point? Um, next one, judgment and ethics. Um, you need to use an amount of judgment [snorts] when you are doing engagements to think about whether the thing that you are looking at currently is of value. Is it going to get you to your next point, your next path down the attack chain? Maybe not. Maybe it will

have a look. Go down a rabbit hole for a little bit. But be wary about going too deep into that rabbit hole and being able to pull yourself back out. ethics. Um, I appreciate that I'm standing in front of a room full of the Packers and ethics probably on the good side, I'm guessing. Um, but yeah, we need ethics. [snorts] Uh, I am doing an engagement at the moment that is a multi-tenant thing. There are 30 different companies all using the same core bit. I can see a tap path from the other side that would get me into the core bit that I want to get into. But they're about to scope. Now, ethically, I can't do that. So, you

have to put a break on it and you have to go, "Oh, I can see how I can get to that domain admin by coming in the side door." You can't do it because ethically it is not correct. Now, you might be able to influence or persuade your client contact to go, please let me try this little bit because I know I can get it. Um, but ethically to start with, you have got to get agreement with that first. Just jumping ahead and doing it can't do. Okay. Um, let's talk about some mindset things as well. [clears throat]

So I think the first one to talk about is thinking in attack paths not in a single exploit. Um and this is quite common. You might get very very excited because you see I don't know active directory template gets you somewhere but it doesn't get you all the way. So you need to think about how I get all the way. My goal is over here. I am here. How do I chain these things together? Yeah, that might be the first one of the chain, but if it doesn't take you to the next step of the chain, it's worthless and [snorts] you're not going to use it and you're not going to follow it. You're not going to do it. So, um, a beginner

will often thinking just an exploit. And this probably comes back from the pentesting side of things. If you've come in from that path, there was an exploit. Found it. Brilliant. I exploit it. Great. I put it on the port. Is it valuable in a report? Does he get you to the goal? I don't know. You have to think about that. You have to think in these chains, not just in the single expert. Um, another flip that I think is really, really important when you potentially come from a pentest side and move into a red team side, thinking about a defender that is potentially reading your traffic. Do things that you do trigger a scene? Do trigger alert? is a defender, is the

blue team going to be looking at that thing and go, "Hey, what's Chris doing? That's unusual. That's naughty." Um, so yeah, think about how running a tool or a thing or a script or whatever it is that you're doing, think about what would flag, what would flag on the Bluetooth device because you're going to need to try and keep under the radar. You're not running a pen test anymore. you're trying to be quiet and and low and slow and not get detected. So, think about how a defender would see your traffic. What would they see? What would they look at? What would they go, "That doesn't look right. Are you going to trigger alert?" Um, understanding why a technique works

and not just that it does work, I think, is also really important. Uh, I think we're very good at just running tools and we work and they give us an output and we walk away with the output and it we've gone to an essay or an essay. It's not it's not quite right. It's not quite the thing that we want to do here. We want to be able to know that it has succeeded, but we also want to understand what misconfiguration underneath it we've abused to make it work. because at some point when you get to the report, you need to be able to explain that to a non-technical person. So, think about that. Um, and the second

one lets you adapt. So, remember that picture of me banging my head against a lamp post constantly. There is going to be a lot of that and there's going to be a lot of times when a tool that you've been given or or downloaded doesn't work to start with and you need to understand why. and being able to adapt and understand why that tool doesn't work again is a really important skill set. Uh, this one's awkward. Um, real engagements have got scope limits and they've got things that are out of scope and there are going to be times especially in longer engagements where your client contact does not know whether the exciting thing that you have

found is actually theirs in scope or going or or you are allowed to attack it. And what will often happen on a routine is you will have a daily catch-up call with your client and you will talk about the things you're going to do today, but also the things that you found yesterday. And if you found something exciting yesterday, you talk to them about this morning and go, "Hey, I found ACS vulnerabilities and it's going to get me to main admin. Can I exploit it?" You then have to wait. And there's going to be a lot of sitting around waiting. And sometimes they will come back and say, "No, that's not yours. It's not ours. We can't do

anything with that. Okay, no problem. Um, and unlike a CTF, there are very, very rarely clean attack paths. They are going to be cranky. Was that the word you? Yeah, clanky. They're going to be cranky. They're going to be all over the place. They never are like in a CTF. They're always like, "Yeah, you do this, you do this, you do this, and then you doesn't work like that in real life." So, think about that. Think about that ambiguity and that constraint that you're going to come across. Um, you're also going to have to make some judgment calls on incomplete information and say, "I don't know the answer to that. I don't know. I bet I'll go away. I'll

find it out." Um, you're also going to have to be a problem solver. Most of the things we come across are problems. It's a challenge. It's a wall. Something you have to overcome and break into or break through. Um, and it's your job to work it out and solve that problem. So, puzzles essentially think about puzzles. Um, and it's what I find is interesting. Uh, my wife is, uh, an executive assistant. Uh, she runs her own business. She will talk to clients and clients will say to her, "Have you ever used zero accounting software?" Yes, I have. Okay, [clears throat] great. The next man comes along and says, "Have you ever used QuickBooks?" And she says, "No, I

haven't used QuickBooks, but it's the same logic as there is in Zero, so I can apply the same thought process and use it the same way because the buttons are going to be the same. The logic behind the software is going to be the same. It's just that the interface is different. It's the same for us as red teams. We're going to come across loads and loads of random pieces of software that we don't know anything about, but the logic behind it is going to be the same. That's something that you have already seen. You just need to work out what the buttons are and what the process is. Um, some next steps, um, build a home

lab. I really really recommend this. It's it's hard if you and I suggest [snorts] starting small. One or two things, uh, an AD controller maybe in a workstation. Start still small so that it doesn't become a massive project on its own which believe me I've done. Um but that's really useful because you are learning to build something which you were then going to break but in the process of building it you are learning about the misconfigurations and the potential steps that can go wrong that will then help you use later. Um study some real world attack reports and some brief writeups. Um, these environments, you know, the real environments that you're in are far far

messier than a real CTF. In a real CTF, or so, in a CTF, you're probably going to get four boxes to attack. In a real environment, there could be thousands. You need to understand how you can get through them, but also how uh the real world attackers do it so that you can apply the same logic because that's really useful. >> [snorts] >> Um, take some breach reports if you can and uh some some writeups if you find them and uh look at the attack path. Not just the headline, not just [snorts] the fancy glitzy headline, but actually go and look at the attack. What did they do? How did they do it? That's useful.

Um, practice some writing, even some fake findings reports if you can. Again, the value that you were giving to your client is in the report writing. It's not really knowing every single exploit. So, if you can practice some of that stuff beforehand and be good at report writing when you get into a job, brilliant. You're going to be really valuable to the team. Um, find some community and some mentorship. Well, obviously we're in a fantastic community now in Bites. Uh, there are plenty of mentors out there. There are other Slack channels, Discord channels. Get in those. Ask questions. There are always people willing to help. Um, ignore people who give you grief. find the people who help because there

are lots of people out there who are going to need help. [clears throat] Um, just to say also there's no single correct starting point. I started an IT support and now I'm red team lead. Like is that the right path? I don't know. There isn't one. So start you can there are various different ways of getting into the industry. So who remembers this? You still think red works like that? It doesn't. Um, and getting into the industry doesn't work like that, just to be honest. But what I would say is you do not need to be an expert to start. And you just need some fundamentals, some curiosity, and a bit of consistency. Okay, we're short on time. Questions?

Any questions? [clears throat]

Um you know some of the startups like these regulated uh startup companies they don't prefer to have inhouse uh red team. Why do you think that is and do you think having a in-house red team is more beneficial than um going for a third party consultancy to check? >> It's a good question. Um, if it was me, if I was starting up my own startup, I would get a third party in first to find the simple stuff, find the open, easy things. And then as I matured as a company, as an organization, I would then start recruiting internally and having my own internal routine because when they're internal, they are able to see more of

the day-to-day stuff and understand how systems work and understand how the platform works, understand how things are linked together. An external on their team will have trouble unless you give them a long amount of time to find that information. At that point, I think I didn't tell you. Okay. Any other questions?

>> Um, yeah. So, I'm a pen tester and um I find my job like uh you get a bunch of IP, you can go for it quite reasonably in the time frame you're given. Um but when it comes to like red team and then go into that how do you stop yourself getting so overwhelmed like I could do attack on these accounts I could do you know attack I do so much how do you like go on a a network or like assume breach and then decide where you going to go with I I find it really overwhelming when I do the labs. >> Yeah. >> So I just want to know what your approach is.

>> Okay. Uh yeah, it's I think it's uh and I I talked about that mindset if you like um between going between fantas think and also thinking about what the defender will see in terms of your actions. So as a red team you were trying to be low and slow. um you will find that you have to be quite methodical in terms of I've seen an IP address but I have to wait until I can scan it or I have to pro it very very gently or I have to uh approve it sometimes with the client and this is that patience thing again that you need to get approval um so yeah I think you have to slow down

uh the positive side is that pen tests tend to be I let's say weak Yeah. For example, you're probably going to get two months, three months maybe depending on how it's been scoped. Um, so you've got a longer period of time. So you have to bring in that meth methodological thought process. Um, you have to bring that thought process in to be thinking about stuff, documenting things, collaborating with the team because someone else might have seen the same thing as well. two of you attacking at the same time is a bad idea. It's one of you. Um so yeah, you have to be thoughtful and mindful about going slow whereas before it's like fast. It's it's the opposite. Finding stuff in

is the probably the biggest challenge that we have as there's lots of things and we've got time to find it and exploit it finally. >> [snorts] >> Hi. Hello. Uh, all four ethics ethics are obviously great, but do you find that sometimes given that obviously the threat actor mentality is not confined by ethics that that can actually be a bit of a drawback when it comes to kind of reporting um [clears throat] back to clients? And I guess the second aspect of that question is if you come across stuff that is technically out of scope, >> do you still kind of relay that in a way to the client so that they can pass on

that information? >> Yeah, absolutely. And again, it's that providing value to the client. I want to try and provide as much value to the client because I want I want my client to be more secure than when I started. >> So yeah, if I see something like, you know, let's go back to our example where I'm testing this core network at the moment and there's 30 peripheral bits. If I see something that is on the periphery that I can't attack when I know it's vulnerable, I will absolutely report that to the client. I will try and influence and persuade the client as much as possible to put that thing in scope for sure because I want it to be

in scope because then I can prove that and somebody can't go a fine it's been like that 10 years it's not difficult nowadays

yeah and you will find and again this is where that patient comes in you will find lots of people who do not want to know that information as well and so will purposely put [snorts] some stuff out of scope because they don't don't need to find it and don't want to know about it. So ethically as we were talking about it's a challenge and you have to use your judgment. But referring back to that that first bit about you know what is the goal of having a red team? The goal of having a red team is to make the company better, more secure than when I started. So if that adds to that, I will absolutely tell them about

it and I will probably reference it in a report if I can. >> Okay. A two month job is quite a big whiteboard. Have you got any useful for software cultures you've come across to help making running a job that long? I haven't I I will tell you use spreadsheets uh and notes um uh and teams templates or one template loaded into teams. I have not found anything that is pretty at all or [snorts] helps. If there are any software developers in the room, please write something for that cuz it would make my life so much easier. Um, yeah. >> Thank you. >> Word of the day. Thank you. >> It's the word of the day. Yeah.

>> Any more questions, Chris? All right. Thank you very much. >> Thank you.