1 1 00:00:00,750 --> 00:00:02,730 Application logs. 2 2 00:00:02,730 --> 00:00:05,010 In this lesson we're going to talk about finding 3 3 00:00:05,010 --> 00:00:08,550 indicators of compromise inside your application logs. 4 4 00:00:08,550 --> 00:00:12,540 Now remember, the simple idea of unexpected growth of a log 5 5 00:00:12,540 --> 00:00:14,970 could itself be an indicator of compromise 6 6 00:00:14,970 --> 00:00:18,150 but in addition to that, there is contents inside these logs 7 7 00:00:18,150 --> 00:00:19,530 that we can use as signatures 8 8 00:00:19,530 --> 00:00:22,950 as we're searching for indicators or compromise in a system. 9 9 00:00:22,950 --> 00:00:25,320 Now most applications can be configured 10 10 00:00:25,320 --> 00:00:27,330 to log different events. 11 11 00:00:27,330 --> 00:00:28,650 As we go through this lesson 12 12 00:00:28,650 --> 00:00:31,800 we're going to start out by covering four different log types. 13 13 00:00:31,800 --> 00:00:36,800 These are DNS event logs, HTTP access logs, FTP access logs 14 14 00:00:37,440 --> 00:00:39,270 and SQL event logs. 15 15 00:00:39,270 --> 00:00:41,340 Let's start with DNS event logs. 16 16 00:00:41,340 --> 00:00:43,770 First, what is a DNS event log? 17 17 00:00:43,770 --> 00:00:46,050 Well, this is a log that contains a log 18 18 00:00:46,050 --> 00:00:48,150 of all the different events for each time 19 19 00:00:48,150 --> 00:00:50,700 the DNS server handles a request to convert 20 20 00:00:50,700 --> 00:00:53,580 between a domain name and an IP address. 21 21 00:00:53,580 --> 00:00:55,560 So if I pull that up on a Window system, 22 22 00:00:55,560 --> 00:00:57,240 it looks something like this. 23 23 00:00:57,240 --> 00:00:59,460 Notice this is an information level event 24 24 00:00:59,460 --> 00:01:02,040 and it's showing it is a DNS client event. 25 25 00:01:02,040 --> 00:01:05,400 As I look at the details, I can see that a DNS query 26 26 00:01:05,400 --> 00:01:07,980 was called for this particular domain name, 27 27 00:01:07,980 --> 00:01:10,710 the type of query it was, the options it was given, 28 28 00:01:10,710 --> 00:01:13,500 and all the other information about this request. 29 29 00:01:13,500 --> 00:01:17,010 I also know what user did this and which computer did this. 30 30 00:01:17,010 --> 00:01:19,560 This is helpful information as we're trying to figure out 31 31 00:01:19,560 --> 00:01:21,150 where malicious information is 32 32 00:01:21,150 --> 00:01:24,090 on our different systems within our network. 33 33 00:01:24,090 --> 00:01:27,930 The next type of log we have is an HTTP access log, 34 34 00:01:27,930 --> 00:01:30,690 and this is a log containing HTTP traffic 35 35 00:01:30,690 --> 00:01:32,010 that encountered an error 36 36 00:01:32,010 --> 00:01:35,400 or traffic that matches some predefined rule set. 37 37 00:01:35,400 --> 00:01:37,980 So as we start looking through that information 38 38 00:01:37,980 --> 00:01:40,740 we can find relevant information in that log. 39 39 00:01:40,740 --> 00:01:42,060 And this information is recorded 40 40 00:01:42,060 --> 00:01:44,550 in the common log format, CLF 41 41 00:01:44,550 --> 00:01:48,060 or W3C extended log file format. 42 42 00:01:48,060 --> 00:01:50,400 There is no standard of which one of these 43 43 00:01:50,400 --> 00:01:51,270 it's going to use. 44 44 00:01:51,270 --> 00:01:55,080 That is going to depend on the HTTP server that you're running 45 45 00:01:55,080 --> 00:01:58,050 but it will usually be one of these two formats. 46 46 00:01:58,050 --> 00:01:59,100 Now, as you look at it, 47 47 00:01:59,100 --> 00:02:01,590 you're going to get all these different status codes in there 48 48 00:02:01,590 --> 00:02:04,980 and we've talked before about the HTTP status codes. 49 49 00:02:04,980 --> 00:02:06,750 These status codes of responses 50 50 00:02:06,750 --> 00:02:08,400 will indicate if there was an error 51 51 00:02:08,400 --> 00:02:11,250 and whether it was caused by the client or the server. 52 52 00:02:11,250 --> 00:02:12,870 If it's a client-based error code, 53 53 00:02:12,870 --> 00:02:15,450 it's going to be something in the 400 range. 54 54 00:02:15,450 --> 00:02:17,100 If it's a server-based error code, 55 55 00:02:17,100 --> 00:02:20,070 it's going to be something in the 500 range. 56 56 00:02:20,070 --> 00:02:22,560 Now, some web server software logs 57 57 00:02:22,560 --> 00:02:24,900 are going to have the HTTP header information 58 58 00:02:24,900 --> 00:02:27,330 for both the requests and the responses. 59 59 00:02:27,330 --> 00:02:28,620 And this is really helpful for us 60 60 00:02:28,620 --> 00:02:31,110 because we can then get even more information 61 61 00:02:31,110 --> 00:02:32,610 that we can look through it. 62 62 00:02:32,610 --> 00:02:34,620 Now, as you're looking through these logs, 63 63 00:02:34,620 --> 00:02:38,250 one of the fields you're going to see is a user agent field. 64 64 00:02:38,250 --> 00:02:40,200 This identifies the type of application 65 65 00:02:40,200 --> 00:02:42,930 that's making the request, such as the web browser version 66 66 00:02:42,930 --> 00:02:45,420 or the client's operating system. 67 67 00:02:45,420 --> 00:02:48,120 Now, a quick word of warning here for you, 68 68 00:02:48,120 --> 00:02:50,310 the user agent field is very helpful 69 69 00:02:50,310 --> 00:02:52,950 but it is not a reliable indicator 70 70 00:02:52,950 --> 00:02:54,510 of the client's environment. 71 71 00:02:54,510 --> 00:02:57,900 It can be easily spoofed or simply misreported 72 72 00:02:57,900 --> 00:03:01,530 because a lot of browsers use the same underlying code. 73 73 00:03:01,530 --> 00:03:04,530 So let's take a look at a couple of examples here. 74 74 00:03:04,530 --> 00:03:09,090 The first example of an HTTP access log looks like this. 75 75 00:03:09,090 --> 00:03:12,180 Here you can see three entries on the screen 76 76 00:03:12,180 --> 00:03:13,920 and we're going to work through them together 77 77 00:03:13,920 --> 00:03:15,960 so we can understand what's going on. 78 78 00:03:15,960 --> 00:03:20,820 The first entry has 10.1.0.102. 79 79 00:03:20,820 --> 00:03:23,700 In this first entry, we see an unknown user. 80 80 00:03:23,700 --> 00:03:26,100 Notice the second dash after the IP address 81 81 00:03:26,100 --> 00:03:28,230 indicates this is an unknown user. 82 82 00:03:28,230 --> 00:03:30,510 And then we can see this unknown user 83 83 00:03:30,510 --> 00:03:33,540 is trying to receive a file from the downloads directory 84 84 00:03:33,540 --> 00:03:36,240 which is why the command get was being sent. 85 85 00:03:36,240 --> 00:03:39,150 And then we get a response code of 401, 86 86 00:03:39,150 --> 00:03:41,460 which indicates that the user is being challenged 87 87 00:03:41,460 --> 00:03:44,820 to provide a username and password by the server. 88 88 00:03:44,820 --> 00:03:46,440 Then we're going to get some information 89 89 00:03:46,440 --> 00:03:49,050 about the client browser and the operating system. 90 90 00:03:49,050 --> 00:03:50,610 In this case, it's identified 91 91 00:03:50,610 --> 00:03:53,100 as a Windows 64 bit operating system 92 92 00:03:53,100 --> 00:03:55,440 running Windows NT 10.0 93 93 00:03:55,440 --> 00:03:57,960 which is just some version of Windows 10, 94 94 00:03:57,960 --> 00:04:01,890 like Windows 10 Home, windows 10 Pro, Windows 10 Education 95 95 00:04:01,890 --> 00:04:03,540 or Windows 10 Enterprise. 96 96 00:04:03,540 --> 00:04:06,030 Now, from this line alone, we're not sure which one 97 97 00:04:06,030 --> 00:04:08,970 but we do know it's some version of Windows 10. 98 98 00:04:08,970 --> 00:04:10,500 Now, once we see that 99 99 00:04:10,500 --> 00:04:13,080 we can also see the browser's been identified here 100 100 00:04:13,080 --> 00:04:15,510 as either Chrome, Safari, or Edge 101 101 00:04:15,510 --> 00:04:17,580 because they all share a common code base 102 102 00:04:17,580 --> 00:04:20,190 and it makes it really hard to identify positively 103 103 00:04:20,190 --> 00:04:21,843 which of the three it really is. 104 104 00:04:22,980 --> 00:04:24,360 The next entry we have 105 105 00:04:24,360 --> 00:04:27,450 we can see that the user was identified as jason. 106 106 00:04:27,450 --> 00:04:29,070 This is because the user has provided 107 107 00:04:29,070 --> 00:04:30,570 their username and password 108 108 00:04:30,570 --> 00:04:34,470 in response to the status code 401 from the first entry. 109 109 00:04:34,470 --> 00:04:37,050 Here we see a status code of 200 110 110 00:04:37,050 --> 00:04:40,020 which indicates that the resource was successfully accessed 111 111 00:04:40,020 --> 00:04:42,360 and this case that means the file requested 112 112 00:04:42,360 --> 00:04:45,510 in the first entry was now downloaded. 113 113 00:04:45,510 --> 00:04:47,520 Then we get to our third entry. 114 114 00:04:47,520 --> 00:04:50,190 This third entry, we can see another user trying. 115 115 00:04:50,190 --> 00:04:52,350 And again, this is an unknown user 116 116 00:04:52,350 --> 00:04:56,010 by showing that second dash there after the IP address. 117 117 00:04:56,010 --> 00:04:58,890 Again this user is trying to download that same file 118 118 00:04:58,890 --> 00:05:01,470 from the server, but from a different computer. 119 119 00:05:01,470 --> 00:05:06,120 This time, from the 10.1.0.103 IP. 120 120 00:05:06,120 --> 00:05:07,890 Notice we don't see another entry 121 121 00:05:07,890 --> 00:05:09,660 with the proper credentials being accepted 122 122 00:05:09,660 --> 00:05:11,280 with a status code 200. 123 123 00:05:11,280 --> 00:05:13,680 So we can assume that this unknown user 124 124 00:05:13,680 --> 00:05:15,510 has provided the incorrect credentials 125 125 00:05:15,510 --> 00:05:17,400 and received an error message instead 126 126 00:05:17,400 --> 00:05:19,530 and they weren't able to download that file. 127 127 00:05:19,530 --> 00:05:21,150 Now again, this assumes that these were 128 128 00:05:21,150 --> 00:05:22,890 the only three entries we had, 129 129 00:05:22,890 --> 00:05:24,480 but if we went further in the logs 130 130 00:05:24,480 --> 00:05:26,610 we may see that status code 200 131 131 00:05:26,610 --> 00:05:28,620 and a successful attempt later on. 132 132 00:05:28,620 --> 00:05:29,880 All right, so let's go ahead 133 133 00:05:29,880 --> 00:05:32,340 and take a look at a second example. 134 134 00:05:32,340 --> 00:05:36,360 Here we're going to go into another HTTP access log example 135 135 00:05:36,360 --> 00:05:38,760 and here I have a single entry for you. 136 136 00:05:38,760 --> 00:05:40,080 In this log entry, 137 137 00:05:40,080 --> 00:05:42,510 we can see something suspicious is going on. 138 138 00:05:42,510 --> 00:05:44,820 Notice this time it's from an unknown user 139 139 00:05:44,820 --> 00:05:46,770 and we have a get command being issued, 140 140 00:05:46,770 --> 00:05:49,650 but inside that query we can see 141 141 00:05:49,650 --> 00:05:53,160 that there is that question mark, and then variable equals. 142 142 00:05:53,160 --> 00:05:54,531 This is trying to send that variable 143 143 00:05:54,531 --> 00:05:56,640 that's listed here on the screen. 144 144 00:05:56,640 --> 00:05:58,380 Now, what is this variable? 145 145 00:05:58,380 --> 00:06:01,590 Well, it's really just a snippet of JavaScript 146 146 00:06:01,590 --> 00:06:04,710 and what we're seeing here is that we can see this snippet 147 147 00:06:04,710 --> 00:06:07,350 being sent by the user agent of Nikto, 148 148 00:06:07,350 --> 00:06:10,260 which is a web application vulnerability scanner. 149 149 00:06:10,260 --> 00:06:12,360 This entry comes from a vulnerability scan 150 150 00:06:12,360 --> 00:06:13,860 against our web server, 151 151 00:06:13,860 --> 00:06:16,733 and this scan is actually running the test number 000816 152 152 00:06:18,810 --> 00:06:20,760 which is attempting to see if this web server 153 153 00:06:20,760 --> 00:06:23,280 is vulnerable to a code injection attack 154 154 00:06:23,280 --> 00:06:24,960 through a query string. 155 155 00:06:24,960 --> 00:06:27,810 Also, we see status code 302 was returned 156 156 00:06:27,810 --> 00:06:29,100 inside this entry. 157 157 00:06:29,100 --> 00:06:30,960 This is used to indicate that the server 158 158 00:06:30,960 --> 00:06:32,580 found the requested object, 159 159 00:06:32,580 --> 00:06:35,790 but it redirected the browser to a login page 160 160 00:06:35,790 --> 00:06:38,430 if it wants you to be able to access that. 161 161 00:06:38,430 --> 00:06:40,440 For the exam you need to be able to read 162 162 00:06:40,440 --> 00:06:42,120 and understand these types of logs 163 163 00:06:42,120 --> 00:06:45,180 and then identify if something is suspicious or not. 164 164 00:06:45,180 --> 00:06:47,970 Notice in the second example, this is suspicious 165 165 00:06:47,970 --> 00:06:50,490 because we see someone trying to perform a code injection 166 166 00:06:50,490 --> 00:06:52,470 against your web application. 167 167 00:06:52,470 --> 00:06:54,840 Now, if this wasn't your security team, 168 168 00:06:54,840 --> 00:06:57,750 how would you be able to mitigate this type of attack? 169 169 00:06:57,750 --> 00:07:01,860 Well, you could install a web application firewall or a WAF 170 170 00:07:01,860 --> 00:07:04,560 because this will help you analyze the inbound request 171 171 00:07:04,560 --> 00:07:06,660 and strip out things like code injection 172 172 00:07:06,660 --> 00:07:08,790 to be able to prevent this type of attack. 173 173 00:07:08,790 --> 00:07:11,100 For the exam this is the level of detail you need 174 174 00:07:11,100 --> 00:07:12,180 to be able to see. 175 175 00:07:12,180 --> 00:07:15,300 They were trying to inject something and you can stop that 176 176 00:07:15,300 --> 00:07:18,240 by doing what thing, what is your mitigation? 177 177 00:07:18,240 --> 00:07:19,680 If you can know those two things, 178 178 00:07:19,680 --> 00:07:22,200 you're going to do well on the exam. 179 179 00:07:22,200 --> 00:07:24,840 Let's move on to our FTP access logs. 180 180 00:07:24,840 --> 00:07:27,210 Now for FTP access logs, these are logs 181 181 00:07:27,210 --> 00:07:32,210 containing FTP traffic in a W3C extended log format. 182 182 00:07:32,280 --> 00:07:34,350 This might look something like this. 183 183 00:07:34,350 --> 00:07:36,810 Here you can see a couple of different codes 184 184 00:07:36,810 --> 00:07:37,680 that we have. 185 185 00:07:37,680 --> 00:07:42,300 You see 331 and 530 and 230 for example. 186 186 00:07:42,300 --> 00:07:45,840 Now, 530 indicates that a user needs to log in 187 187 00:07:45,840 --> 00:07:47,760 before a command is processed. 188 188 00:07:47,760 --> 00:07:49,620 So in this case we have a username 189 189 00:07:49,620 --> 00:07:51,750 and a password being submitted. 190 190 00:07:51,750 --> 00:07:55,500 Then you see further down we have code 230. 191 191 00:07:55,500 --> 00:07:57,510 Code 230 indicates that a user 192 192 00:07:57,510 --> 00:08:00,150 has successfully logged in with their credentials 193 193 00:08:00,150 --> 00:08:02,520 and has access to perform the command. 194 194 00:08:02,520 --> 00:08:04,950 In this case, they're probably trying to download a file 195 195 00:08:04,950 --> 00:08:07,590 because it says the file transfer protocol. 196 196 00:08:07,590 --> 00:08:09,240 Now if we look in this example, 197 197 00:08:09,240 --> 00:08:11,640 you can see five requests for credentials 198 198 00:08:11,640 --> 00:08:13,230 like a username and password 199 199 00:08:13,230 --> 00:08:15,900 and only one of those was accepted at the end. 200 200 00:08:15,900 --> 00:08:17,460 So what does this mean? 201 201 00:08:17,460 --> 00:08:18,840 Are we under attack? 202 202 00:08:18,840 --> 00:08:20,430 Well, maybe. 203 203 00:08:20,430 --> 00:08:22,320 Maybe we're under attack from somebody attempting 204 204 00:08:22,320 --> 00:08:25,020 a brute force attempt to crack our password 205 205 00:08:25,020 --> 00:08:27,300 or maybe somebody just forgot their password 206 206 00:08:27,300 --> 00:08:29,910 and is trying their top five most common passwords 207 207 00:08:29,910 --> 00:08:31,890 until they found the one that was right. 208 208 00:08:31,890 --> 00:08:33,420 We really can't be sure here, 209 209 00:08:33,420 --> 00:08:35,490 but we do know that they are trying to log in 210 210 00:08:35,490 --> 00:08:37,290 four times unsuccessfully 211 211 00:08:37,290 --> 00:08:40,320 before being successful on that fifth attempt. 212 212 00:08:40,320 --> 00:08:43,500 So if you were worried about a brute force password attack, 213 213 00:08:43,500 --> 00:08:45,120 how could you mitigate it? 214 214 00:08:45,120 --> 00:08:47,220 Well, you could set up a global policy 215 215 00:08:47,220 --> 00:08:49,980 that added a 15 minute or 30 minute lockout 216 216 00:08:49,980 --> 00:08:53,190 for any account after three failed login attempts. 217 217 00:08:53,190 --> 00:08:56,190 This is a common mitigation against this type of attack 218 218 00:08:56,190 --> 00:08:58,080 because it extends the amount of time needed 219 219 00:08:58,080 --> 00:09:01,230 to successfully crack a password by an attacker. 220 220 00:09:01,230 --> 00:09:03,060 And this is all you're trying to do here 221 221 00:09:03,060 --> 00:09:06,810 is delay the timeout, make it take longer for the attacker 222 222 00:09:06,810 --> 00:09:09,480 'cause if you can do that, hopefully they'll give up 223 223 00:09:09,480 --> 00:09:11,550 and they'll go to an easier target. 224 224 00:09:11,550 --> 00:09:15,030 Our next type of log is an SSH access log 225 225 00:09:15,030 --> 00:09:17,220 and this is an unstandardized type of log 226 226 00:09:17,220 --> 00:09:20,610 that can provide basic client server session information. 227 227 00:09:20,610 --> 00:09:24,330 Now, when you're dealing with SSH, this is secure shell. 228 228 00:09:24,330 --> 00:09:27,660 Here on the screen is an example of an SSH log. 229 229 00:09:27,660 --> 00:09:28,980 This is showing somebody 230 230 00:09:28,980 --> 00:09:31,470 who successfully is logging in as root. 231 231 00:09:31,470 --> 00:09:33,480 They went in and they gave their password 232 232 00:09:33,480 --> 00:09:36,030 and it was accepted, and so a session was open. 233 233 00:09:36,030 --> 00:09:39,000 How do we know it was root? Notice the UID. 234 234 00:09:39,000 --> 00:09:40,860 UID equals zero. 235 235 00:09:40,860 --> 00:09:42,300 The root of a Linux system 236 236 00:09:42,300 --> 00:09:46,650 is always going to have user ID of zero, so keep that in mind. 237 237 00:09:46,650 --> 00:09:49,380 Now, let's say we had a bunch of failed logins. 238 238 00:09:49,380 --> 00:09:51,000 What will we do to be able to identify 239 239 00:09:51,000 --> 00:09:53,430 all the failed root logins on a server 240 240 00:09:53,430 --> 00:09:55,890 as part of our threat hunting or our analysis? 241 241 00:09:55,890 --> 00:09:58,530 Well, we could do something like this. 242 242 00:09:58,530 --> 00:10:00,930 We can go through here and use egrep, 243 243 00:10:00,930 --> 00:10:03,990 which is a grep command to search the authentication log 244 244 00:10:03,990 --> 00:10:06,273 at the /var/log/auth.log. 245 245 00:10:08,460 --> 00:10:09,300 And when we do that 246 246 00:10:09,300 --> 00:10:13,380 we can display any instances of the word failed or failure. 247 247 00:10:13,380 --> 00:10:17,280 Here, for example, you can see 15 instances on December 5th 248 248 00:10:17,280 --> 00:10:21,690 from 9:39 to 9:40 at night when somebody tried to log in 249 249 00:10:21,690 --> 00:10:25,020 and they failed to do that using the SSH service. 250 250 00:10:25,020 --> 00:10:27,090 Now again, for the exam 251 251 00:10:27,090 --> 00:10:28,830 you need to be able to read logs like these 252 252 00:10:28,830 --> 00:10:32,280 and identify what type of attack might be going on. 253 253 00:10:32,280 --> 00:10:35,400 In this case, it's probably some kind of password guessing 254 254 00:10:35,400 --> 00:10:38,970 since we have repeated login attempts that are all failing. 255 255 00:10:38,970 --> 00:10:42,000 Also, notice in this log you can see exactly 256 256 00:10:42,000 --> 00:10:45,270 what IP was attempting these connection requests. 257 257 00:10:45,270 --> 00:10:48,120 This way you could use this as part of your analysis 258 258 00:10:48,120 --> 00:10:51,180 and see if that client machine may have been compromised. 259 259 00:10:51,180 --> 00:10:53,310 That device may be something that was compromised 260 260 00:10:53,310 --> 00:10:55,110 by an attacker and now they're using it 261 261 00:10:55,110 --> 00:10:57,300 and trying to pivot onto another machine 262 262 00:10:57,300 --> 00:10:59,100 using the root credentials. 263 263 00:10:59,100 --> 00:11:01,680 This is a way to identify what actions have been taken 264 264 00:11:01,680 --> 00:11:03,903 and what possible root cause there is. 265 265 00:11:04,770 --> 00:11:06,360 The fourth type of log we need to talk 266 266 00:11:06,360 --> 00:11:08,790 about is an SQL event log. 267 267 00:11:08,790 --> 00:11:10,560 This is an event or error log 268 268 00:11:10,560 --> 00:11:13,530 that records events with fields like date, time 269 269 00:11:13,530 --> 00:11:16,650 and the action taken, such as server startup, 270 270 00:11:16,650 --> 00:11:20,100 individual database startup, database cache clearing 271 271 00:11:20,100 --> 00:11:23,790 and databases not starting or shutting down unexpectedly. 272 272 00:11:23,790 --> 00:11:24,960 Now, when we're dealing with this 273 273 00:11:24,960 --> 00:11:26,640 we are dealing with SQL servers. 274 274 00:11:26,640 --> 00:11:29,640 And SQL servers can log individual query strings 275 275 00:11:29,640 --> 00:11:31,470 that are being sent to the database 276 276 00:11:31,470 --> 00:11:33,570 so we can actually look at everything that's been sent 277 277 00:11:33,570 --> 00:11:36,270 to the database by a particular user. 278 278 00:11:36,270 --> 00:11:37,380 Now, as you go through 279 279 00:11:37,380 --> 00:11:39,960 and start looking at your SQL server logs, 280 280 00:11:39,960 --> 00:11:42,150 you're going to find a lot of information there 281 281 00:11:42,150 --> 00:11:45,270 other than the date time and the user who sent the query. 282 282 00:11:45,270 --> 00:11:47,250 For example, you might see things 283 283 00:11:47,250 --> 00:11:49,830 like the query operation that was performed, 284 284 00:11:49,830 --> 00:11:52,200 the schema associated with that operation 285 285 00:11:52,200 --> 00:11:54,690 and the object of the query. 286 286 00:11:54,690 --> 00:11:56,580 By retrieving all this information 287 287 00:11:56,580 --> 00:11:58,020 you're going to be able to get information 288 288 00:11:58,020 --> 00:12:00,300 from the database on what has occurred 289 289 00:12:00,300 --> 00:12:02,850 and identify what data may have been breached 290 290 00:12:02,850 --> 00:12:04,770 if you're investigating a data breach. 291 291 00:12:04,770 --> 00:12:06,900 The particular format of those logs 292 292 00:12:06,900 --> 00:12:09,240 and how you access them is going to vary based 293 293 00:12:09,240 --> 00:12:11,790 on the type of SQL database you're running. 294 294 00:12:11,790 --> 00:12:14,190 For example, if you're using MySQL, 295 295 00:12:14,190 --> 00:12:16,380 you can go into the MySQL workbench 296 296 00:12:16,380 --> 00:12:19,650 and use your audit inspector to go through those audit logs. 297 297 00:12:19,650 --> 00:12:22,170 Notice here you'll see things like the record ID, 298 298 00:12:22,170 --> 00:12:25,590 the timestamp, the type which is a query or a ping, 299 299 00:12:25,590 --> 00:12:30,030 the connection ID, the user, the host IP, the status, 300 300 00:12:30,030 --> 00:12:31,680 the command class that was being used 301 301 00:12:31,680 --> 00:12:34,473 and any information about that particular command.