 So I'm super, super stoked to be here. This is my first speaking engagement in any sort of technical capacity. So bear with me here, I hope it's super enjoyable. I also know I have to kind of eat the microphone so I apologize if we have any issues there. So how many of us in the audience have seen the aftermath of a successful attack on a website? Wow, see, it's really, really common. And as we know, it can be a really sort of vulnerable feeling. I use the word vulnerable a lot, but in this case, it really, it's like finding out that there's a person who has been crashing in your house for who knows how long. And it's not super important what they're doing. It doesn't really matter if they're stealing your valuables or if they're just chilling on your couch, eating cereal, and watching TV. If you don't know they're there and you didn't give them permission, it's a big deal. So hopefully, we're going to walk away with a little bit more of an understanding of what is and is not possible in these circumstances. So before we go into it, I'd like to tell you a little bit about myself, why you may be interested in what I have to say of all people. So like she said, I'm a research analyst with the web security company Sightlock. What that means is when I'm not given the great fortune of preparing for an engagement like this, I look at malicious code all day and teach our computers to be better at finding and killing it. I am a certified web application penetration tester, or you could say ethical hacker. And I'm a global information assurance certification advisory board member, which is a super lofty way of just saying that I scored pretty good on a test and I get to sit at the cool kids table. And sort of as part of all of those ventures, I've been developing in PHP and Python for about 45 minutes. So the first rule of cybersecurity in general, and when we're talking about building a layered approach to your security, is that you need to assume breach. Imagine you're building a castle, like we all do on weekends. We start with a moat, we build the moat, and then that's kind of it, we're done. Nothing can cross a moat, right? No, we do the moat, we've got archers, we've got a wall, we've got soldiers on the inside, each of which are implemented with the understanding that it's possible for the previous one to have been broken somehow. And that's important when we're building a website, right? So maybe we have an outer layer, maybe we have a web application firewall, but then on the inside, we've hardened the dickins out of our code, and then behind that, we've got an IDS intrusion detection system or malware scanners for notification. And then at the very back, we have a very robust incident response plan. So if something does happen, what do we do? Because you have to assume at each step that the previous ones have failed. The other factor to keep in mind are the sorts of individuals that are carrying out these attacks, right? Now I'm going to use a lot of words like adversary and attacker and actors, because I don't like the word hacker, we're sort of trying to take it back. But we use strict terminology here to avoid any sort of confusion there. So we've got a few buckets that we can sort these individuals into. The very biggest and smelliest bucket are script kiddies. These are people who don't necessarily have the skill set or know how to launch a sophisticated attack, but they have by some means or another acquired, the means to launch something or other. There's a ton of them out there. And generally, as far as a small business or a very new website is concerned, they're sort of the biggest threat. On top of those, we've got skilled opportunists. These are people who know a little bit more. They can pivot if circumstances change. They still don't necessarily have the backing of somebody that's professional and maybe they don't have the attention span, but they are a little bit more dangerous, though smaller in number. Above that, we're getting into professionals. They have high skill. They actually have resources to invest in their ventures. And they're almost certainly at this point profiting, whether it's directly from what they're doing or service that they're selling. And then very tippy top state level actors or your nation state attackers where best of the best skill wise, money is no object, time is no object, really, really a formidable sort of thing to deal with. Ultimately, across all of them, no matter the skill set, there are the same four steps that they're taking. We need to know who we're attacking and hopefully how. We need to know what we're doing to get in. We need to open some back doors afterwards so that we can come and go as we please. And then we need to actually get something out of this. We need to get some profit of some value out of it. Obviously, the first step is going to be figuring out who we're attacking. So there's a couple of approaches. The first one is really just to already know. The easiest way to figure out who you're attacking is to already have somebody in mind. Maybe there's an organization with some political values that you don't like or maybe it's just a big e-commerce store that's running on ancient code and you want to show them who's boss. Whatever it is, if you already know, that's awesome. But if you don't, we do have a couple of sort of options here. Maybe we know of a recent vulnerability that got disclosed. And we just don't know who's got it. So whenever I know something that I want to know, I Google it. So we use a technique called Google dorking and I hope I'm not pacing too far in either direction here. So Google dorking is basically leveraging search engine queries through Google or DuckDuckGo or Bing to try to dig up sensitive information or vulnerable endpoints on the internet. And it can be really scary effective. So right here, you can see that I've run a search for, I got a little laser pointer, but there's four of them, so. So I'm looking for the text database password and my SQL host name in any text file on the internet. And I don't know how many people at WordCamp have seen WP config file. We maybe think of a couple of reasons why we wouldn't want somebody on the internet to see that. Does it rhyme with database password? Now it's really circumstantial. A database, a set of database credentials can be a wide open door. Now it's circumstantial. Maybe these are really old backup files that somebody made and the passwords aren't good anymore. Maybe they're all local databases. And so I'm a little bit up a creek if I'm trying to remotely connect to a local only database, but think of it this way. So how many of you are on a shared hosting account for any of your sites? So your site lives on the same server as other people. Cool, there's generally nothing wrong with that. But if I'm say a nation state level attacker and money is no object and time is no object, how long do you think it'll take of me spinning up and canceling hosting accounts with your hosting provider before I eventually do land on the same server as you? You know, at scale, at Infinitum, you have to assume it's possible. We are assuming breach in that. So the knee-jerk response is going to be to yank that config text file off of the internet. But good old Googs went and did me a solid and kept a cash copy for me, as they always do. And I'm sure a lot of you do SEO and we're super familiar with how responsive Google is when you request changes to your search engine results and how fast that goes. So really the moral of the story here is never leave sensitive files web readable. Now this is Skelly, my resident anatomy skeleton. He loves spouting off super bite-sized infosec truism, so I brought him with me. Basically the internet never forgets. The only guaranteed way to remove something from the internet is to have never put it there in the first place. So even if something's buried 10 directories deep in a 48 character file name, obviously search engine crawlers have a way to dig it up. So really the best thing to do is just never let it open up in the first place. So yeah, if we have a vulnerability but we don't know a victim, we Google it the same way we Google anything, but what if it's the other way around, right? So we've got a short list of some victims we'd like to exploit but we don't quite know where to start with those so we can use something called a vulnerability scanner. I'm gonna take a drink real quick. Start with that. So vulnerability scanners are tools that we can sort of throw at websites and applications to dig up juicy information about them. The biggest example of which for our purposes is a tool called WP Scan. WP Scan is, if you could guess it, a WordPress vulnerability tester and it can dig up a lot of really interesting material. As we can see up here, it's listing a number of plugins on my test site. It's screaming out, oh hey, these are out of date. It's also saying this one specifically, this version has a stored cross site scripting vulnerability. That's good for me. It's not super good for the victim but it's able to dig that up. It can get me WordPress versions, plugin versions, theme versions, all sorts of good stuff. Additionally, user names. Your user names in WordPress are not actually that, you couldn't really call them privileged, built into it and you can look on track and on all of the dev comments that every now and then somebody tries to say we need to make user names harder to enumerate but that falls under security through obscurity which we'll talk about in a little bit. The big deal is the world knows more than you think and you have to make sure that you're not giving the world too much information because eventually the internet will dig it up and find it. Security through obscurity is basically leaning on the fact that people don't know how something is built as a form of security and you can't trust that because eventually and especially on an open source platform there's not a whole lot of obscurity there to be had and you can't ignore a vulnerable plugin just because you don't think anybody knows you have it. So at this point we know who we're attacking and maybe we've got a couple of hints as to how. So maybe we did find a big wide open application vulnerability we're able to walk through the door on and if that's good then awesome we can skip ahead but what if we don't have that? Well we still've got some options here so the biggest and probably my favorite is credential stuffing. TLDR credential stuffing is I'm taking your leaked passwords from some database leak or some other site breach and I'm saying well they probably use that password on everything else because everybody uses the same password everywhere so I'm gonna use your Yahoo password that got leaked in 2014 and I'm gonna try that on your WordPress site in 2018. A really cool site that you can use to check this out by the way it's called have I been pwned.com. It's a really simple process you just stick in your email address and it'll tell you if you appear on any breaches or any password pastes. It's developed by my InfoSec man crush Troy Hunt. He's awesome, look him up and really if you find yourself on there don't feel too bad. This is actually my personal email address I've had for about nine years and I'm on six breaches. I have three of them. I know what my old password is so don't feel bad it happens to everybody you can't really predict that your Yahoo account is going to get popped because you trusted them, right? So the answer here is to use unique passwords. There's going to be a knee-jerk response from a lot of people saying well my password is unique nobody else uses my password it's mine but you use it everywhere so if one of them gets broken all of them are broken. It's important to diversify and really make sure that no two accounts anywhere are using the exact same password. To that end I recommend something like a password manager or maybe you can keep track of some elaborate system to make sure you remember all thousand of your passwords everywhere. Multi-hydrate, sorry. The next one up is social engineering. Now this is, there's about 100,000 ways to define social engineering but the long story short is I am tricking somebody or manipulating them into doing what I want. There's no really feasible way to categorize every possible type of social engineering or every possible way to trick somebody but a couple methods have been popular enough to get their own name. The biggest of which is probably pretexting. Pretexting is where I am falsely reporting my own authority or motivations to trick people into giving me access to something I'm not supposed to have. Who here has heard of Microsoft calling somebody and saying hey we found a virus on your computer? You need to let us in so we can clean it. That's pretexting. They're not Microsoft but if you believe they are that's good enough for them. It's a big thing about acting like you belong somewhere or act like you're supposed to be doing something. A lot of people don't know this I'm bringing this out into the open today. I actually have a super power. I can turn invisible and all I need to do is put on a reflective orange vest, some safety glasses and hold a clipboard and you can walk into any building in downtown Phoenix because nobody talked to the guy with a vest and a clipboard. He's busy, he's doing something, just leave him alone. And it's crazy and this does happen in real life. This isn't just a what if. 2016, a Walmart in Virginia lost four flat screen TVs because somebody threw on an employee vest and wandered out with them. Nobody looks twice as somebody who acts like they're supposed to be there. Another big example of social engineering is phishing and it is social engineering despite the fact that I'm not personally involving myself in the transaction. I'm not shaking somebody's hand and lying to them saying hey, I'm Facebook. But I am building a webpage with the intent of tricking people into giving me their credentials or their credit card information or anything. And it can be really tough to identify a phishing scam. How many of you have really seen just a really not convincing phishing page? Right? How many of you have seen a really, really, really convincing phishing page? How many of you... Well, this is one that you really can't answer, but I guarantee with some level of statistical certainty that somebody in this room has been phished without their knowledge because of a really, really sophisticated phishing page. It happens. So to recap, we've got a victim in mind, whoever it may be. And through one way or another, we have broken in one time. And that first time is the most important. It's sort of the entirety of whether I am or am not able to accomplish this. So maybe I got in because they had their WP config exposed. They had a remote MySQL connection active. I was able to get right into their database. But they went to a tech conference and a charismatic bearded man told them to change their database password. How do I make sure that I can come and go as I please? I'm going to be establishing a foothold where I can travel freely. So maybe once I'm in, I'm creating an application admin. I'm putting an admin user into your WordPress site. From there, I can upload a zip, say it's a plugin. It can have basically anything in it. And maybe I've got a web shell in there that I can use to pivot around and do some other cool stuff. Maybe I'm installing or activating remote MySQL on a site that doesn't have it to open up that little vector. Or maybe I'm even authorizing my SSH public key. How many of you have looked at your authorized key file in the last month? Wow, I'm proud of the three of you. Yeah, if somebody sticks something like that in there, they can just SSH in as you and nobody's ever going to stop them because it's authorized. It's a file called Authorized Keys on Linux servers with that SSH folder on your home directory. See, a lot of people don't even know it exists. So it's not actually something you can do from the web. It's all server-side. So I talked about uploading backdoor scripts. This is a really super common web shell called WSO. A lot of you may have seen it or something like it. And I say something like it because it is a pastime of script kitties and re-skin this same exact file and pretend that they wrote it in the first place. Interesting fact. But it's remarkably functional. You can see it's a file manager just from here. I can upload files, delete, edit, read all your private stuff. But it's also got a shell emulator. I can talk to MySQL from it. I can open up a backdoor, a reverse TCP shell from your server to mine directly. I can do all sorts of cool stuff from here. And because of that, if I'm able to sneak a couple of these backdoors onto your system no matter what they are, it can be really, really devastatingly difficult to get rid of me from that point forward. Because at that point, you need to dismantle every one of my fail safes at about the same time before I know you're doing it. Then I'm gone. But until then, hi. That's why having an IDS, a detection system or a malware scanner comes in super handy. Because that, if nothing else, it can be the notification that something fishy is going on, right? And the sooner you know that, the better. Because I'm going to be working very hard to avoid detection. I'm all up in their business. I've got all their goodies now. My hooks are in deep. And the longer I can keep that up before anybody's aware that it's happening, the better. So much like my spirit animal croc here, I need to remain inconspicuous. Sorry, I just had to put that on there. If so, if my goal is to deface their homepage and write LOL, Mikey was here, like stealth isn't my biggest concern. But other than that, I'm making very, very sure that I'm not littering their error logs with a bunch of my activity. I'm not doing anything that's going to break their website because what better way to draw attention to the code on their site than to break it. And so mostly, mostly though, I want to make sure that none of my scripts are getting caught by malware scanners. To that end, I'm going to be obfuscating my code. Obfuscating is making code deliberately unreadable by humans. And hopefully, if I've done it well enough, at least in the short term, it will allow me to bypass malware scanners. Also, keep in mind that you can't really trust time stamps. People have a really bad habit of something terrible happening, and then they just only look for the newest files, or hands as soon as they can't find anything that's very recent. The timestamp of any file I upload or change can be very trivially set to any number I want. So maybe I slip a shell in your WPincludes file and make the timestamp look like every other file in there. Timestamps are kind of meaningless. So at this point, we are in, we're in for the long haul at this point. We've established our backdoor, and maybe they don't know we're there yet. So it's a time for us to get something out of this equation. The bottom of the pyramid, in terms of both sophistication and volume, are defacements. And this is actually an actual defacement that we found. Generally, a defacement is just the attacker patting himself on the back for how cool he is. Sometimes, you'll see some political motivations. It doesn't really ever seem super related. I hate turks on grandma's cookies.com. It doesn't really seem to matter where the victim was. They just had something to say, and they needed somewhere to say it. They're typically executed by script kiddies, and they can be, I mean, they're easy to detect obviously. That's a homepage. But they can be very, very, very damaging to a site's reputation. If you have an e-commerce store and one of your visitors sees this instead of your homepage, are they coming back? Even if it's gone, what else is there, right? So it's still just as important to stop. Moving upwards from there, we have resource theft. This is a little bit more sophisticated. Similar to defacements in the sense that I don't really care who you are. It's not personal. I'm not really super worried if you're a big site or if you're brand new or you have any money for me or not. I just want what your server has. So maybe I want to steal your hardware. Maybe I want to use some CPU power to mine some cryptocurrency for myself. That cool with you guys? I didn't get to ask. Maybe I want to use your network. Maybe I just want to use your server as a pivot point from which to attack other people. Just put one more step between them and my activities. Or maybe I just like your reputation. And I don't mean the reputation of your site because, again, I don't care who you are. I just like the fact that your mail relays haven't been blacklisted yet. And so I think I could probably launch 10 or 12,000 phishing emails before anybody at your host is the wiser. They'll find that out eventually. But until then, thanks. Thanks for the assist there. Next up, we've got visitor attack. So this is where I'm actually using your site to attack your visitors. And this kind of gets personal. A big set of these are phishing kits because if I'm hosting my super awesome CD Bank phishing site on my own server, that's probably going to draw some unwanted attention to me. So I'm going to do it on yours if that's okay. I don't care if your domain gets blacklisted from everywhere. So I need to cut some Apple IDs and I hope you're cool with it. So thanks, Rumi. But another big type is keyloggers. And what these are doing, exactly what it says on the tin, I am logging all of the input that your visitors put on your site, whether it's logins, passwords, credit card numbers, pin numbers. And I am having them send me an extra copy. This is where I want to say that SSL doesn't stop this at all because I'm not grabbing the packets out of midair. I am actually telling their browser, hey, also send me a copy. Yeah, use the SSL to talk. It's cool. You're talking to me now. I want that password plain text. Thanks. So SSL doesn't stop much. You just have to make sure that it never gets there in the first place. And then at the sort of tippy top in terms of sophistication is we have directed attacks. And these are usually taking the form of data breaches. There was a pretty big one. A little bit ago, I don't know if you heard of a company called Equifax. They actually just came out a little bit of go and apparently more people were affected than they initially said. BTDubs, a little quick fun fact there. But small sites aren't immune to this. If you are somebody that has sensitive data on somebody that I might want, maybe you're a very small law practice or a medical practice and you have some dirt on somebody that I want dirt on, I'm probably going to take a look. So you don't necessarily need to be Equifax for somebody to want your data. The reason I tell you all of this is we talk a lot about what ifs here. What if I found an open MySQL connection. What if I find your database password. What if you left your site unupdated. But at scale, if there's a million of these monkeys typing at a million typewriters, they're eventually going to write Shakespeare, right? We've all heard that sort of fun thought problem. These attacks are constantly happening. As soon as you spin up a server, who's gone and looked at their SSH logs the minute they spin up a server waiting for the first brute force attempt? Do it sometime. It's fun. It doesn't take long. So it really, we've established that once they're in, they're kind of really in. So this really drives home the fact that an ounce of prevention is worth a ton of cure at this point. The safest thing that you can do is never let it happen to begin with. And since there's no such thing as being 100% secure at any time, you can have a flat filed HTML site on the world's most locked down FTP server. Somebody knows how to get there and if I want it bad enough I can ask your secretary for the password or something. Because they will probably tell me. So defending against a sophisticated threat can be a total uphill battle. It's a whole different ball game with a vast majority of threats that we deal with. So I say this not to be discouraging. I'm not trying to say somebody's eventually going to get in. There's no point worrying about it. Don't worry about any firewalls or anything. Just go home. No, so you have to think about the sorts of threats that you will face. Script kitties and opportunists are almost everybody's biggest nightmare here. But if you think you may have something valuable that could be stolen, you have to sort of gear up for that kind of attack too. I call this Krebs's law. Brian Krebs does not call this Krebs's law. But he says organizations who don't have a clue how to do security think it is a state to be achieved, not a rung to be constantly grasped at. There's never really a point where you're done. You can't pack it up and go home. You're not done with security. It's still a process. There's always sort of a next place that you can go from wherever you are now. So the big thing there is cost benefit and really finding the value that you're adding. You don't want to invest thousands and thousands of dollars in an enterprise level local network firewall when you haven't done any sort of penetration testing on your website. You want to be looking at where you're going to be getting the most bang for your buck there. Priorities are a big part there. So G.I. Joe would always say at the end of every episode that knowing is half the battle. G.I. Joe also used the other half of the battle to shoot lasers at bad guys and we don't have that technology here yet. So knowing is almost all of the battle here. If you know the sorts of threats that you can face, if you know what they're looking for and how they're going to try to exploit that, that gives you a bit of an advantage. The whole unknown, unknown thing, the fewer of those that you have, the more you're able to pivot if something does change. So I hope some of the things that I've babbled about up here for a little while have been enlightening. I hope we've learned some cool stuff. And I really, really hope that this empowers you to do some more research and educate yourselves further on the subject of web security. It's super interesting. It's never going anywhere. And yeah. Thank you guys so much for sticking around. That's my Twitter. Hey, it's Mikey V. I am really terrible at social media. So if you guys want to follow me, that would be super cool. SiteLock, we also have WP district, which is our WordPress specific platform for all sorts of security news about WordPress. And then at SiteLock as well. And I would love to open up for any questions that we may have. Yes, in the front. Should I start over? So preventing people from seeing the files that you do have in this WordPress setting, do you recommend plugins like Hide My WP and things like that that will pretty much hide that entire WordPress framework from people that are viewing the site? So that's going to fall kind of under that security through obscurity thing. People publicly not knowing what you're running isn't as helpful in terms of security as you would think. It's not difficult ultimately for me to figure out what you're up to there. I'm not really super concerned with where your WP admin login page is because I'm never actually going to care to use it. Far back. So the question was if we have a password manager and we're copying and pasting the passwords into password fields, if that's active. And yeah, so there's always going to be the concern that, okay, what if somebody is listening to my clipboard locally? If that is the case, then you've got much bigger problems than whether they know your WordPress password or not. So it is effective in my opinion. It's having that password accessed even in a way that is technically 1% insecure is much better than reusing a password. Yes, a key logger would be able to, because it's not necessarily... I guess it does depend on the type of password manager that you're using. If you're doing something that's completely local, most of them all they do is emulate a keyboard. Reference for security knowledge, whether it's a book, a textbook, a website, someplace where you can go and kind of get a little bit more than just general information of things to do to secure your website. Yeah, so the question was if there was a really good knowledge base for somewhere to go to educate yourselves more about security. Yes, but with an asterisk, because there's no one central place I can say, go do this, because there are so many facets of what security is. If anybody uses Reddit, there is a subreddit called NetSec that I really like. The network security subreddit, there's a lot of really good people there. There's also AskNetSec, and there's huge community there just really devoted to helping people understand more about their web security. There's a lot of security experts on Twitter as well. Following them is a good way to keep at least a breath of news in the security sphere. But as far as learning how to make something secure, rather than from the outside in, just keeping up with updates to the software that you do use. Read the WordPress.org security releases when they come out. Try to understand why they're doing what they're doing. I wish I had just like, yeah, securityhelp.com is a great, I mean, if anybody owns that domain, that'd be cool. If you have any specific questions or something like that, I'm very happy to answer that off the floor as well. What about, so I'm kind of new to this, but my host is WP Engine, and apparently they're really awesome at security. So does that make a big difference and do you worry a lot less in that circumstance? So I guess it depends on the reasons that they're saying that they're really good about security. So there are so many different sort of surfaces that can be attacked, and having a secure web host can protect, say, something leaking from another site to yours within the same host. They also may have local directives that can identify things happening at the file level a little bit better. As far as WP Engine specifically, I don't know exactly what it is that they use. Yeah, exactly. Exactly, yeah, they can lock the fence around the back of the house as much as you want, but if you leave the window open, it's all pointless. Okay. So that's where you're going to want an expert to come in and actually sort of assess the damage and what has and has not happened. As far as general practices go, you do want to do some malware scanning. Make sure you're uprooting as many scripts of theirs as you can. Look at any sort of credentials that you have. So if you've got your WordPress site, you want to look at your WordPress users in the interface, or even go so far as to look in the database, because I've seen it where they're spoofing who is actually there in the WordPress interface. And really just being proactive and identifying, or you said you already know it's been hacked at this point. So it's just sort of a matter of backpedaling through the things I talked about. So make sure that there's not scripts left behind. Make sure that there's no users that are authorized. And having something ahead of time monitoring that is the best way to find out what has been changed rather than playing hide and seek and finding... Backups are a great thing, too, but they're also tough because if you don't know of the exact moment that the infection took place, you could be restoring something that's infected anyway. Very good. Two different data breaches, and I'm like, what do you do? Is there something I should do? Change your passwords. In regards to identity theft, should I look into that? So it depends on what was in those breaches. I don't know if you feel comfortable sharing which ones you were in, or was it River City Spam Media List or River City Media Spam List. So a lot of the ones that say things like they have your home address, those are mostly just marketing spam lists that have just sort of aggregated over time. Those ones I would worry a little bit less about. Those are sort of going to be more leveraged against people that they already have a reason to be attacking, rather than just saying, this random person's address. I'm going to do stuff. One, kind of two quick questions. The first of which, so what are the basics, the very absolute basics I should do to protect my websites or my development stuff? And two, wouldn't hackers like these script kiddies just go somewhere else or hit someone else besides my stuff? So the best practices as far as preventing it from happening in the first place, they're the same things that the token security talk at every word camp is talking about. Do your updates, really there's not, unless you know there's a very direct excuse not to do the updates, you still want to be doing them. Make sure you're using good passwords, make sure you're using principle of least privilege. If you've got a part-time designer that just needs to upload a couple new pictures, you don't want to give them root access to your server. There's a little bit of a hyperbole, of course, but it's really only give people the access that they absolutely need. There's a hundred things. Just don't leave stuff lying around, don't leave the keys in the car, make backups, be proactive. So the thing is with 99% of your attacks that you're considering, these are opportunists and script kiddies are the lowest-hanging fruit. So making sure that you don't have a big red flag in the form of an outdated plugin, you're not using the password, password 123, you're not using a password that's already been owned. The fact that you are at least that difficult to breach is going to make you invisible to script kiddies and opportunists because they are going to move on to somebody easier at that point. If you've got the problem of a professional with his eyes on you or a nation-state attacker, his or hers, it's not a gender thing, then that's the point where we want to be looking into something a little bit stricter. But if you're really wanting to make sure we can talk about web application firewalls and backend detection systems all day, but those are something that... There's not a boilerplate answer to that. It's going to depend on each individual site. So the first thing with the host shutting you down, there are reasons that they go about doing that without them knowing intimately exactly what did take place. Sort of quarantining you in that way is their way to sort of prevent that from spreading and affecting other people. If we're using a web shell to access the backdoors that we've put up, then if we can't access your website, then we are locked out. So it does really kind of suck having that happen, but there are reasons why they do it. As far as why or whether it's a good reason to talk to the host or not, I agree that it is... You did the right thing. If you didn't know what was going on and you wanted to talk to somebody, I wouldn't really let you... I don't want you to take that experience and let it put a bad taste in your mouth because they did have those reasons, but ultimately, they probably would have found out that it was taking place the next time they did scans. As far as what the best thing to do would be, if it happens to somebody without the resources to talk to an expert directly, then it's a tough call. It's really just going to be the matter of is this something that you can manage to rebuild or is this something that is going to be more cost-effective to have repaired? And that's, again, it's... Well, it's good. I mean, ultimately, and regardless of who you're getting this protection from, personally, all I want is a safer internet. I want fewer people to be experiencing these sort of things, so it's... I'm glad that it was eventually rectified. And I know I kind of use a lot of tongue and cheek and I may seem glib up here talking about this, but you sort of have to lampshade a lot of this stuff because for a lot of people this is sort of the scariest moment in their business, is somebody has got their hands and stuff that they're not supposed to. And so I don't want to ever act I'm treating any of this lightly because I do understand the gravity of these situations. I don't have it up just yet. If you're interested, you can shoot me a message on Twitter and I'll make it happen. Again, thank you so much, guys. You made it a really awesome first experience coming here and speaking. I'm Michael Wienstra and I will be out and about. Feel free to stop me and ask me any questions. Thank you, guys.