We discovered that it was necessary to know what was solid information (found in the logs) and what was derived (e.g., IP address from NSLookup of computer name). What was observed (e.g., password-guessing attack against Victim1) ▪ For this reason, we include as much of the following information as we can in the help desk ticket for this incident: ▪ For example, you might discover that a small group of workstations in a lab have set up shares between them, and users periodically connect workstations. The computers listed in the Attacking Workstation column are the infected systems, unless you can discover a legitimate reason for the failed attempt to connect two workstations. Guiseppini is one of the Microsoft developers of the tool. There is also a much more in-depth treatment of uses of Log Parser in the Syngress book, Microsoft Log Parser Toolkit, written by Gabriele Giuseppini and Mark Burnett. You can find basic explanations in the accompanying help file and by searching the Microsoft site for Logparser. Using this technique we are able to turn the bot client attack vector into an intelligence source. This will often show the pattern called “fan out,” where the botnet infects a single computer in a new subnet, then that computer fans out to infect others in the same subnet.
You can note which computer infected that one and trace it backward in the Victim column, thus reconstructing the timeline of the spread of the botnet. Find an attacker and then look for the attacker in the Victim column. When you consolidate all the logs like this for analysis, you can see the attack pattern. You can also see that the attacker in our greatly modified example used a dictionary containing five passwords to try for each userid. It is also a bit of a clue that there were 2200 attempts during that hour. ATTACKER2 shows the pattern consistent with an automated password-guessing attack, with attempts coming one a second for an hour. You can see that attacks came from two computers, ATTACKER1 and ATTACKER2. Table 5.1 shows a sample of output from this SQL query. In this step we are trying to determine the attack vector, the time of the successful attempt, and the userid that successfully logged in (which should now be considered compromised). However, that is during the analysis step, which we will cover later in this chapter. This is despite the fact that we actively scan for bot C&C activity. Using this technique during the analysis phase, we have found over 200 infected computers that were part of one botnet. Here's the value of this analysis: The computers listed in the workstation field of the failed login records type 3 login, where the workstation field differs from the victim's computer name, are all infected computers. So, what's the point of analyzing this data? You are examining this computer because someone already said it was virus infected or because one of your intelligence sources spotted it talking to a known C&C server. If the attempts happen to take place during times that no one is supposed to be working in that department, you can be even more certain. If you see attempts using userids of Administrador, then administrateur as the login ID, you can be sure that this is password-guessing attack and that a bot (likely Phatbot, Rbot, or another related bot family) is attacking the victim's computer. They almost always try Administrator, so if you have renamed this account, its appearance in a failed login attempt raises the probability that this is an attack. You might not see this in every attack, but if the bot hasn't gathered any userids locally yet, or if the gathered userids haven't gotten in, the bot might try userids from the default list. Earlier in the book we listed the default userids they both can use. Both Phatbot and Rbot provide other clues that a password-guessing attack is real.
0 kommentar(er)
