Where "Logs Are Stored on Your Local Computer and Automatically Removed After 7 Days."

Security Event Log

Botnet Detection: Tools and Techniques

Craig A. Schiller , ... Michael Cross , in Botnets, 2007

Event Logs

The event logs are located in Windows or WINNT directory under %WinDir%\system32\config. These files end in .evt, but we have seen them with different capitalization schemes (.evt, .EVT, .Evt).

The security event log is controlled by the Local Policy | Audit Policy settings. For this type of analysis, the following policies should be set to success, failure:

▪

Audit account logon events

▪

Audit account management

▪

Audit policy change

▪

Audit privilege use

In practice, we usually gather all the logs and then examine them one at a time in real time, then later analyze them in nonreal time. Here we describe the examination process as we tell how to locate each log. Use the Administrative tool and Event Viewer to examine the security event log. In the security event log you are looking first for failed logins (see Figure 5.4). You can sort the file by clicking the Type column. This will divide the log into successes and failures. In our case the entries of interest are the failed logins with a login type 3, the network login. You can find more information about the login types listed in the event log at http://technet2.microsoft.com/WindowsServer/en/library/e104c96f-e243-41c5-aaea-d046555a079d1033.msp, or search Microsoft for audit logon events.

Figure 5.4. Failed Login Record

In addition, we looked for instances of logon type 3 in which the originating workstation name differed from the victim's computer and where the domain name is the name of the attacking computer. In most environments, this should be a rare occurrence. The victim's computer would have to be actively sharing files and adding local accounts from the other computer as users on the victim's computer.

To clinch the deal, password-guessing attacks occur much more rapidly than any human can type. This won't be the case every time. The password-guessing tools we have captured can throttle down the attack frequency (x attacks over y hours), so it might not be so obvious (see Figure 5.5).

Figure 5.5. A Password-Guessing Attack

Both Phatbot and Rbot provide other clues that a password-guessing attack is real. Earlier in the book we listed the default userids they both can use. 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. 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. 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. 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.

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. 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. Using this technique during the analysis phase, we have found over 200 infected computers that were part of one botnet. This is despite the fact that we actively scan for bot C&C activity. This is defense in depth at its finest. However, that is during the analysis step, which we will cover later in this chapter. 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).

Finding these failed login attempts tells us that password guessing was one of the attack vectors. Finding a successful login among the attempts using one of the attempted userids or immediately following the last attempt is valuable because it marks the time of the actual break-in. Take note of this time because you will use it later to look for files associated with the break-in (see Figure 5.6).

Figure 5.6. A Successful Break-in

During the analysis phase you can use a log processor such as Log Parser from Microsoft to process multiple log files at once. At the time of this printing, Log Parser can be downloaded from www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en. Log Parser reads the event files and permits the analyst to craft SQL queries to extract information.

We created a batch file containing a single line: C:\"Program Files\Log Parser 2.2\"LogParser.exe -o:CSV file:LogonFailuresDistinct2.sql?machine=*"

This line says, "Run log parser, read the file LogonFailures.sql, execute the SQL commands you find there, report what you find for all machines, and place the results in a comma-separated value file."

The SQL query LogonFailures says:

FROM .\logs2\*.evt WHERE EventType = 16 AND EventCategory = 2 AND Attacking_Workstation <> ComputerName

This query will cause Log Parser to:

▪

Extract the time-generated field

▪

Extract the user name and login domain and concatenate them to form field called User

▪

Relabel the ComputerName field to Targeted Computer

▪

Find the Workstation field

Log Parser is to do this from all the event logs in .\logs for all logon events (Event Category 2) that failed (Event Type 2) and where the attacking workstation name doesn't match the ComputerName field.

Table 5.1 shows a sample of output from this SQL query. You can see that attacks came from two computers, ATTACKER1 and ATTACKER2. ATTACKER2 shows the pattern consistent with an automated password-guessing attack, with attempts coming one a second for an hour. It is also a bit of a clue that there were 2200 attempts during that hour. You can also see that the attacker in our greatly modified example used a dictionary containing five passwords to try for each userid. When you consolidate all the logs like this for analysis, you can see the attack pattern. Find an attacker and then look for the attacker in the Victim column. 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. 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. Using this technique we are able to turn the bot client attack vector into an intelligence source.

Table 5.1. Sample Output from Log Parser SQL Query

TimeGenerated	User	Targeted_Computer	Attacking_Workstation
8/3/2006 8:40:24	ATTACKER1\jdoe	VICTIM	ATTACKER1
8/3/2006 8:44:02	ATTACKER1\jdoe	VICTIM	ATTACKER1
8/3/2006 8:46:51	ATTACKER1\jdoe	VICTIM	ATTACKER1
8/3/2006 8:50:37	ATTACKER1\jdoe	VICTIM	ATTACKER1
8/3/2006 8:53:33	ATTACKER1\jdoe	VICTIM	ATTACKER1
8/3/2006 8:57:17	ATTACKER1\jdoe	VICTIM	ATTACKER1
8/14/2006 10:25:00	ATTACKER1\jdoe	VICTIM	ATTACKER1
8/14/2006 10:29:09	ATTACKER1\jdoe	VICTIM	ATTACKER1
8/14/2006 10:31:46	ATTACKER1\jdoe	VICTIM	ATTACKER1
8/14/2006 10:35:23	ATTACKER1\jdoe	VICTIM	ATTACKER1
8/16/2006 8:21:06	ATTACKER2\Administrator	VICTIM	ATTACKER2
8/16/2006 8:21:07	ATTACKER2\Administrator	VICTIM	ATTACKER2
8/16/2006 8:21:08	ATTACKER2\Administrator	VICTIM	ATTACKER2
8/16/2006 8:21:09	ATTACKER2\Administrator	VICTIM	ATTACKER2
8/16/2006 8:21:11	ATTACKER2\Administrator	VICTIM	ATTACKER2
8/16/2006 8:21:13	ATTACKER2\Administrador	VICTIM	ATTACKER2
8/16/2006 8:21:14	ATTACKER2\Administrador	VICTIM	ATTACKER2
8/16/2006 8:21:15	ATTACKER2\ Administrador	VICTIM	ATTACKER2
8/16/2006 8:21:16	ATTACKER2\Administrador	VICTIM	ATTACKER2
8/16/2006 8:21:17	ATTACKER2\Administrador	VICTIM	ATTACKER2
8/16/2006 8:21:18	ATTACKER2\Administrateur	VICTIM	ATTACKER2
8/16/2006 8:21:20	ATTACKER2\Administrateur	VICTIM	ATTACKER2
8/16/2006 8:21:21	ATTACKER2\Administrateur	VICTIM	ATTACKER2
8/16/2006 8:21:23	ATTACKER2\Administrateur	VICTIM	ATTACKER2
8/16/2006 8:21:27	ATTACKER2\Administrateur	VICTIM	ATTACKER2

You can find basic explanations in the accompanying help file and by searching the Microsoft site for Logparser. 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. Guiseppini is one of the Microsoft developers of the tool.

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. 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. For this reason, we include as much of the following information as we can in the help desk ticket for this incident:

▪

Computer name and source

▪

IP address and source

▪

MAC address and source

▪

What was observed (e.g., password-guessing attack against Victim1)

▪

Userid used

▪

Date/time of the most recent attempt

▪

User name

▪

Building, room, and jack number

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). The time last observed is important, especially in environments using DHCP, since you are only interested in the computer that held a particular IP address during the time of the event observed in the logs. In our case, the lookup table we used for building, room number, and jack number was horribly out of date and consequently inaccurate. If the computer was online, the networking team could confirm the room number and data jack by reading the switch that detected the computer. The most difficult part of this process proved to be matching the infected machine with a user and location.

Several critical pieces of our infrastructure are missing. There is no asset management system, so the asset database is not linked to the help desk system. The database that links the building room and data jack information to a switch port has not been kept up to date. The building maps to room and data jacks haven't been kept up to date, so we keep sending techs out to rooms that no longer exist. There is no simple way to correlate the computer's NetBios name to its IP address and MAC address. Although there is a standard naming convention for computers, it is loosely followed by other departments. It is next to impossible to find a computer of the name LAPTOP in a population of 27,000 users. In XP, the security event log record only contains the computer NetBIOS name, not the IP address; the way our DNS is setup, few of these NetBIOS names are found using nslookup.

Under these circumstances, we have had to find creative ways to locate these infected computers. If the userid has portions of a name, we try student and faculty records to see if there is a match or a short list of candidates. Sometimes the computer name is somewhat unique, and a search of the university's Web pages can win the prize. One tough case was a computer called ELEFANT. Searching through the university's Web pages revealed a Web page for the chemistry department's lab network that touted ELEFANT as the most important computer in their lab. The Web page also identified the lab manager's name, phone number, and e-mail address.

Once we are confident in the IP address associated with an attacker, the help desk ticket is assigned to our networking group. The networking group places the switch port associated with the attacker into a network jail, although our kindler, gentler customer service interface calls it a "network quarantine" when speaking to our customers. The networking group then confirms the building and room information directly from the switch, to confirm the data base entries we posted earlier.

Once the computer's location has been deter mined, the help desk ticket is assigned to our desktop support techs, who arrange for it to be retrieved for our quick forensic exam and reimaging. We had determined early in the process that with this bot, reimaging was preferable to attempting to remove the virus and chancing that we would miss something. Reimaging also gave us the opportunity to remove the offending local administrator accounts.

As we processed systems, we realized that we needed to collect and correlate information about all the systems we had identified. For that we established a spreadsheet that brings together all the relevant information. That way, if we see a system in an event log two months from now, we can confirm whether the system was reimaged since the time of the new sighting or if this is a reinfection.

We are now experimenting with using a tool called NTSyslog, available for download at http://sourceforge.net/projects/ntsyslog, to automatically forward the Security Event logs to a central syslog server. The central syslog server formats the data for an SQL database and then will run the above query in near real time. This has the effect of turning this approach into an early warning tool instead of a recovery tool.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B978159749135850007X

Securing the Cloud: Architecture

Vic (J.R.) Winkler , in Securing the Cloud, 2011

System and Network Auditing

System and network security event logs are a keystone for managing the ongoing security of any system. In a cloud, audit events will be generated in fundamentally different trust zones; these range from highly secured network and security components to systems where the CSP grants significant control to tenants or users. Thus, security events should be recognized as having different degrees of integrity. The following are key requirements for the generation and management of audit events:

•

Auditing is required for all operational systems, from infrastructure system and network components up to but not necessarily including customer VMs. Tenant confidentiality agreements along with service contracts may set the boundary for what data can be collected within a tenant VM, and in many cases tenant virtual networks.

•

All security-relevant events must be recorded with all relevant information that is necessary to analyze the event; this shall include the correct time, resolvable system, and user IDs and appropriate event codes and supporting information.

•

Generated audit events must be logged in a near-real-time manner. The correct operation of auditing and logging shall be verified on an ongoing basis using means such as heartbeat or call-and-respond.

•

All audit events and logs shall be continually and centrally collected to ensure their integrity and to support timely alerting and monitoring.

•

All audit events and logs shall be retained and securely archived for at least as long as the security policy requires, preferably indefinitely to support retroactive long-term analysis to either support legal action or to improve security and security monitoring.

•

As necessary to support the validated legal or operational needs of tenants or customers, audit records will be sanitized to allow sharing with tenants and customers—either as a part of a security service or as needed.

•

Controls must be implemented to protect the confidentiality, integrity, and availability of audit events, audit log collection, log centralization, archiving, processing, and reporting.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B978159749592900004X

Managing Security Essentials

In How to Cheat at Microsoft Vista Administration, 2007

NIST Common Criteria

By enabling the Windows Firewall to log audit events to the Security event log along with the default firewall log. The Windows Firewall in Windows XP SP2 and Windows Server 2003 SP1 keeps firewall log information in two locations:

■

%windir%\Pfirewall. log

■

Security event log

The problems with this scenario are that it is difficult to troubleshoot Windows Firewall connectivity issues, and you are not compliant with the Common Criteria. The Common Criteria state that all security auditing needs to be comprehensive and contain all security-oriented events. They also mandate that if auditing cannot be performed, the system fails. For example, if the audit log becomes full—a condition known as CrashOnAuditFail—the Pfirewall.log file doesn't satisfy these two criteria. On the other hand, the Windows Security event log does. Therefore, all logging of both filtering and policy happens in the Security event log, complying with the Common Criteria requirements, which makes it easier for enterprises in the government, healthcare, and financial industry sectors.

Note

Windows Vista allows administrators to continue using Pfirewall.log, although it is now stored in %windir%\system32\LogFiles\Firewall\Pfirewall.log .

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597491747500094

Post-Mortem Forensics

Cameron H. Malin , ... James M. Aquilina , in Malware Forensics Field Guide for Windows Systems, 2012

Examine Logs

☑ Look in all available log files on the compromised system for traces of malicious execution and associated activities such as creation of a new service .

► Log files can provide some of the most useful historical detail relating to a malware incident, giving visibility into past events, the sequence of activities related to an attack, and clues about what the intruder did on the compromised system. The logs that are available on a Windows system will depend on its configuration and installed programs. Some of the more common log files are summarized here with examples of their usefulness.

•

Windows Event Logs : Logon events recorded in the security event log, including logons via the network, Remote Desktop, and Remote Authentication Services, can reveal that malware or an intruder gained access to a compromised system via a given account at a specific time. Other events around the time of a malware infection can be captured in Windows Event logs, including the creation of a new service or new accounts around the time of an incident. Windows Event logs can be examined using tools such as Log Parser ⁸ and Event Log Explorer ⁹ as shown in Figure 3.8 with the ability to filter on specific types of events. Additional information about Log Parser and its flexibility is available in Microsoft Log Parser Toolkit from Syngress. ¹⁰

Figure 3.8. Windows System Event log being examined using Event Log Explorer, filtering on errors associated with services (Event IDs 7026 and 7030)

•

Web browser history: The records of Web browsing history on a compromised computer can reveal access to malicious Web sites and subsequent download of malware. In addition, some malware leaves traces in the Web browser history when it spreads to other machines on the network.

•

Desktop firewall logs: Windows firewall and other desktop security programs may be configured to record access attempts and other activities on the compromised system.

•

AntiVirus logs: When a Windows system is compromised, AntiVirus software may detect and even block malicious activities. Such events will be recorded in a proprietary log file with associated date-time stamps, and any quarantined items may still be stored by the AntiVirus software in a holding area.

•

Dr. Watson: The Dr. Watson log, located in "Drwtsn32.log," can contain information about programs that crashed and produced debug information. When Dr. Watson traps a crashing program, it can create a file named "User.dmp" containing memory contents from the crash, which may provide additional information.

Investigative Considerations

•

Log files can reveal connections from other systems that provide links to other systems on the network that may be compromised.

•

It is common to extract Windows event logs from a forensic duplicate for examination. However, message details that were unique to the compromised system may not be available when performing this type of analysis. Therefore, it may be necessary to reconstruct the event details or review specific log entries of interest on a resuscitated clone of the compromised system as discussed in the "Forensic Reconstruction of Compromised Windows Systems" section later in this chapter.

•

Windows event logs may be deleted in a malware incident, requiring a search of unallocated space for important entries.

Analysis Tip

Domain Controller Security Event Logs

In some enterprise environments domain controllers are relied on for security logging, so local security event logging is disabled on the Windows computers that are part of the domain. In addition, DNS logs from a domain controller can be extremely important when tracking beacons to DNS host names. Given the volume of event logs on domain controllers, there may be a retention period of just a few days and digital investigators must preserve those logs quickly or risk losing this information.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597494724000032

Investigating Network Traffic and Investigating Logs

In The Official CHFI Study Guide (Exam 312-49), 2007

Auditing Unsuccessful File Access Attempts

When auditing is enabled for NTFS objects, Windows adds events to the Security event log to indicate the objects that are accessed. As part of this event entry, information is recorded as to the object that was accessed, the user accessing the object, and the date/time that the object was accessed. You can use Log Parser to quickly collect the events around these object access attempts.

Obviously the area more administrators are interested in is the objects that a user tries to access when they're not supposed to. With a good security implementation, this typically results in an unsuccessful file access attempt. Using Log Parser to scan through the security logs, you can quickly identify these events and export them for analysis. The command and query shown here will identify all of the unsuccessful file access events in your security log:

When this query runs, it looks for any events in the security log with an eventID of 560 (Success Audit), but further refines that data to events with a type of Failure Audit event. It also parses through the associated event description to ensure that we look only at files, not directories. From that subset, Log Parser extracts the time of the event, the username associated with the event, and the filename. All this data is then displayed in a datagrid format. You can take this further by having Log Parser export the data into an XML file or some other format for evidence gathering needs.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597491976500109

Network Investigations

Eoghan Casey , ... Terrance Maguire , in Handbook of Digital Forensics and Investigation, 2010

Overview of Enterprise Networks

Digital investigators must be sufficiently familiar with network components found in a typical organization to identify, preserve, and interpret the key sources of digital evidence in an Enterprise. This chapter concentrates on digital evidence associated with routers, firewalls, authentication servers, network sniffers, Virtual Private Networks (VPNs), and Intrusion Detection Systems (IDS). This section provides an overview of how logs from these various components of an Enterprise network can be useful in an investigation. Consider the simplified scenario in Figure 9.1 involving a secure server that is being misused in some way.

Figure 9.1. Simplified depiction of components and associated logs on Enterprise networks.

Logs generated by network security devices like firewalls and IDSs can be a valuable source of data in a network investigation. Access attempts blocked by a firewall or malicious activities detected by an IDS may be the first indication of a problem, alarming system administrators enough to report the activity to digital investigators. As discussed in Chapter 4, "Intrusion Investigation," configuring firewalls to record successful access as well as denied connection attempts gives digital investigators more information about how the system was accessed and possibly misused. By design, IDS devices only record events of interest, including known attack signatures like buffer overflows and potentially malicious activities like shell code execution. However, some IDSs can be configured to capture the full contents of network traffic associated with a particular event, enabling digital forensic analysts to recover valuable details like the commands that were executed, files that were taken, and the malicious payload that was uploaded as demonstrated later in this chapter.

Routers form the core of any large network, directing packets to their destinations. As discussed in the NetFlow section later in this chapter, routers can be configured to log summary information about every network connection that passes through them, providing a bird's eye view of activities on a network. For example, suppose you find a keylogger on a Windows server and you can determine when the program was installed. Examining the NetFlow logs relating to the compromised server for the time of interest can reveal the remote IP address used to download the keylogger. Furthermore, NetFlow logs could be searched for that remote IP address to determine which other systems in the Enterprise were accessed and may also contain the keylogger. As more organizations and ISPs collect NetFlow records from internal routers as well as those at their Internet borders, digital investigators will find it easier to reconstruct what occurred in a particular case.

Digital investigators may be able to obtain full network traffic captures, which are sometimes referred to as logging or packet capture, but are less like a log of activities than like a complete videotape of them—recorded network traffic is live, complete, and compelling. Replaying an individual's online activities as recorded in a full packet capture can give an otherwise intangible sequence of events a very tangible feel.

Authentication servers form the heart of most enterprise environments, associating activities with particular virtual identities. Logs from RADIUS and TACACS servers, as well as Windows Security Event logs on Domain Controllers, can help digital investigators attribute activities to a particular user account, which may lead us to the person responsible.

Practitioner's Tip: Virtual Identities

Because user accounts may be shared or stolen, it is not safe to assume that the owner of the user account is the culprit. Therefore, you are never going to identify a physical, flesh-and-blood individual from information logs. The universe of digital forensics deals with virtual identities only. You can never truly say that John Smith logged in at 9:00 am, only that John Smith's account was authenticated at 9:00 am. It is common, when pursuing an investigation, to conflate the physical people with the virtual identities in your mind and in casual speech with colleagues. Be careful. When you are presenting your findings or even when evaluating them for your own purposes, remember that your evidence trail will stop and start at the keyboard, not at the fingers on the keys. Even if you have digital images from a camera, the image may be consistent with the appearance of a particular individual, but as a digital investigator you cannot take your conclusions any farther.

As discussed later in this chapter, VPNs are often configured to authenticate via RADIUS or Active Directory, enabling digital investigators to determine which account was used to connect. In addition, VPNs generally record the remote IP address of the computer being used to connect into the network, as well as the internal IP address assigned by the VPN to create a virtual presence on the enterprise network. These VPN logs are often critical for attributing events of concern within an organization to a particular user account and remote computer.

Practitioner's Tip: Tracking Down Computers within a Network

When a computer is connected to a network it needs to know several things before it can communicate with a remote server: its own IP address, the IP address of its default router, the MAC address of its default router, and the IP address of the remote server. Many networks use the Dynamic Host Configuration Protocol (DHCP) to assign IP addresses to computers. When a networked system that uses DHCP is booted, it sends its MAC address to the DHCP server as a part of its request for an IP address. Depending on its configuration, the server will either assign a random IP address or a specific address that has been set aside for the MAC address in question. In any event, DHCP servers maintain a table of the IP addresses currently assigned.

DHCP servers can retain logs to enable digital investigators to determine which computer was assigned an IP address during a time of interest, and potentially the associated user account. For instance, the DHCP lease in Table 9.1 shows that the computer with hardware address 00:e0:98:82:4c:6b was assigned IP address 192.168.43.12 starting at 20:44 on April 1, 2001 (the date format is weekday yyy/mm/dd hh:mm:ss where 0 is Sunday).

Table 9.1. DHCP Lease

lease 192.168.43.12 {

starts 0 2001/04/01 20:44:03;

ends 1 2001/04/02 00:44:03;

hardware ethernet 00:e0:98:82:4c:6b;

uid 01:00:e0:98:82:4c:6b;

client-hostname &quot;oisin&quot;;

}

Some DHCP servers can be configured to keep an archive of IP address assignments, but this practice is far from universal. Unless you are certain that archives are maintained, assume that the DHCP history is volatile and collect it as quickly as possible.

A DHCP lease does not guarantee that a particular computer was using an IP address at a given time. An individual could configure another computer with this same IP address at the same time, accidentally conflicting with the DHCP assignment or purposefully masquerading as the computer that originally was assigned this IP address via DHCP. The bright side is that such a conflict is often detected and leaves log records on the systems involved.

The same general process occurs when an individual connects to an Internet Service Provider (ISP) via a modem. Some ISPs record the originating phone number in addition to the IP address assigned, thus enabling investigators to track connections back to a particular phone line in a house or other building.

Obtaining additional information about systems on the Internet is beyond the scope of this chapter. See Nikkel (2006) for a detailed methodology on documenting Internet name registry entries, Domain name records, and other information relating to remote systems.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123742674000094

Forensic Analysis

In Virtualization for Security, 2009

Collecting Intelligence about Botnets or Virus-Infected Systems

Using virtualization to execute the code on a suspected bot client or virus-infected system permits the investigator to gather valuable insights about the workings of malicious code. From the security event log you can see any attempts to guess passwords using brute force. You also find the identity of other bot clients that are involved in the brute force attacks. Using the firewall logs you see any inbound-opens that have been attempted. You can learn the identity of websites that delivered malicious code by looking at the firewall logs around the time of the malware detection. Watching network traffic from the suspect computer, you can identify ports opened by malicious code and the ip addresses of other parts of the botnet. These other parts of the botnet may be providing malicious code, such as retroviruses, to kill off your anti-virus protection, or lists of email addresses and spam templates. If the bot client uses Internet Relay Chat (IRC) you may find the Command and Control server, nick, userid, and password. You can then use this information to detect other infected computers in your organization and prevent future communications with the mother ship.

Locating the actual malware is a primary goal of a forensic examination of a bot client or virus-infected computer. Chapter 6, "Malware Analysis," describes the process of running code samples in a sandbox to perform malware analysis.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597493055000098

Post-Mortem Forensics

James M. Aquilina , in Malware Forensics, 2008

Relational Analysis

A simple example of relational analysis relates to trust relationships between a compromised system and other systems on the network. For instance, some malware spreads to computers with shared accounts or targets systems that are listed in the "system32\drivers\etc\lmhosts" file on the compromised Windows system. Alternately, an examination of mounted network shares may reveal that a user on the compromised machine inadvertently clicked on malware that was stored on a file server. In such cases, discovering such relationships between the compromised system and other computers on the network may lead digital investigators to other compromised systems and additional useful evidence.

Another common and effective use of relational analysis arises when a worm spreads across a network and there are network-level logs that record the incident. Other infected hosts can be located by searching network logs for the Internet Protocol (IP) address that connected to the compromised computer at the time of infection.

Case Scenario

"Worm Sign in Windows Event Logs"

A worm infected several workstations on an internal network via NetBIOS, and digital investigators want to determine its origin. Unfortunately, there is no network-level logging on the internal network, making it difficult to determine which hosts were involved. However, using Windows Event Logs on compromised systems, it was possible to determine when and where a worm propagated. When a worm spreads via NetBIOS, information in the Security Event logs on a compromised computer can show which computer and user account the worm came from. The sample log entry in Figure 4.5 shows the name of the computer ("WKSTN-EG265") and the username ("otoor") that was attempting to logon to the compromised system immediately prior to the worm infection.

Figure 4.5. Event Log Entry Shows Workstation Name

Searching the logs of all computers on the network for this computer name and username could lead to other compromised systems. In some instances, the IP address of the remote computer is also recorded in the Security Event log or other logs related to the failure of a service, providing digital investigators with another piece of information to determine the source and scope of the malware incident.

Other Tools to Consider

▪

Logparser Microsoft tool for examining various log formats, including NT Event logs

▪

Sawmill Log analysis tool that facilitates searching and drill down of various log formats, including NT Event Logs (www.sawmill.net)

▪

Splunk A format-independent log analysis and correlation tool that interprets log data dynamically, providing indexing and categorization to provide flexible searching and correlation of logs from any source (www.splunk.com)

▪

Logger.pl Script specifically for examining Security Event logs and identifying patterns (http://pantheon.yale.edu/~kjh27/logger.html).

Another form of relational analysis involves looking for commonality or interactions between the malware and other objects on the compromised computer. In the simplest case, the folder where the malware resides may contain additional pieces of malware or associated log files. Alternately, the file system permissions or flags set on a piece of malware may be distinctive enough to be useful for finding other files with the same settings. As an example, Windows can assign "ownership" of a file to a particular user account. If this account is not in widespread use on the system, a digital investigator could look for other files that are assigned the same user account.

In some cases, malware is programmed to download additional components or create files on a compromised system. For instance, one bot generated a ".reg" file to reconfigure the system, and used a simple batch script to load these changes into the Registry (e.g., W32.Spybot.ANDM).

Once the components that relate to a piece of malware have been identified, digital investigators can look for them on the compromised system and in network traffic. In one case, the malware was programmed to connect out to a server periodically, and it maintained a log of these connections. Once this log file was discovered on one system, digital investigators were able to locate other compromised systems in two ways: 1) searching network-level logs for all connections to the remote server, and 2) looking for the presence of this log on computers.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597492683000049

Malware Incident Response

James M. Aquilina , in Malware Forensics, 2008

Publisher Summary

This chapter demonstrates the value of preserving volatile data, and provides practical guidance for preserving such data in a forensically sound manner. The value of volatile data is not limited to process memory associated with Malware, and includes passwords, Internet Protocol (IP) addresses, Security Event Log entries, and other contextual details that can provide a more complete understanding of the Malware and its use on a system. In a powered-up state, a subject system contains critical ephemeral information that reveals the state of the system. This volatile data is sometimes referred to as stateful information. Incident response forensics, or live response, is the process of acquiring the stateful information from the subject system while it remains powered on. The Order of Volatility is considered when collecting data from a live system to ensure that critical system data is acquired before it is lost or the system is powered down. The chapter provides methodology for preserving volatile data on a Windows system during a Malware incident, and uses case scenarios to demonstrate the collection process as well as the strengths and shortcoming of the data acquired in the process.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597492683000013

File Analysis

Harlan Carvey , in Windows Forensic Analysis Toolkit (Third Edition), 2012

Event Logs

Windows systems are capable of recording a number of different events in the Event Log, depending on the audit configuration (we will discuss in Chapter 5 how to determine the audit configuration). The Event Log files on Windows 2000, XP, and 2003 systems are made up of event records that are stored in a well-documented binary format (found at http://msdn.microsoft.com/en-us/library/aa363646(v=VS.85).aspx ). Part of this format includes a "magic number" that is unique to individual event records (including the header record, which contains information about the Event Log file itself), as illustrated in Figure 4.2.

Figure 4.2. Partial Windows XP event record format.

As illustrated in Figure 4.2, the "LfLe" "magic number" can be used to identify event records within the Event Log file. The 4 bytes immediately prior to the event record (0xE0 in Figure 4.2) tell us the size of the event record in bytes. This information is not only useful in parsing through the Event Log file on a binary level, extracting each record in turn (and writing tools to help us do this), but it can also be used to extract event records from relatively unstructured data, such as unallocated space (or the page file), which will be described later in this section.

Many analysts have discovered that when extracting Event Log files from an acquired image and opening them in the Event Viewer on the their analysis system, they will often encounter a message stating that the Event Log is "corrupt." This is usually not due to the Event Log files actually being corrupted, but instead is often due to the fact that some message dynamic linked library (DLL) files may not be available on the analysis system. As such, I've written several tools to assist me with collecting information pertinent to my analysis from Event Log files. The first is the Perl script "evtrpt.pl," which collects information about the event records, such as the frequency of events based on event sources and identifiers (IDs), an excerpt of which, from an Application Event Log, appears as follows:

Source	Event ID	Count
-------	---------	------
SecurityCenter	1800	2
SecurityCenter	1807	192
Symantec AntiVirus	12	17
Symantec AntiVirus	14	17
Symantec AntiVirus	16	12
Symantec AntiVirus	53	3

This information is a quick way to determine the type and number of the various event records within the Event Log, based on event sources and IDs. This is a great way of providing an overview of the Event Log content, and whether or not I can expect to find any records of value to my analysis. Having this information available has let me see some things very quickly. For example, if I'm working a malware issue and see that there are several event records with the source "Symantec AntiVirus," I know that the system had the application installed at one point, and that can help guide my analysis. In particular, if I opt (as part of my malware detection process, something we will discuss in Chapter 6 ) to mount the image as a volume and scan it with an AV product, I know not to use the product that was installed on the system. Similarly, while I most often start my analysis of the Event Logs by looking at what is actually being audited via the audit policy, there have been times when, although logins are being audited, the system has been running for so long that no one has needed to log into it. As such, I have found Security Event Logs with no login events available in the visible event records.

"Evtrpt.pl" also provides the date range of all of the event records within the file, as follows:

Date Range (UTC)

Thu Jan 18 12:41:04 2007 to Thu Feb 7 13:39:25 2008

The date range information can be very useful, as well. There have been times when I've been asked to provide information regarding which user was logged into the system on a certain date or within a specific timeframe. Evtrpt.pl provides me with a quick view into whether or not digging deeper into the Event Logs is of value, or perhaps I should decrease the priority of the logs as a source of information and focus my analysis on more profitable targets.

Note

AV Logs

Most antivirus (AV) products produce some sort of logs; many produce text-based logs that are easy to view and parse, particularly if you load them into Excel. Many AV products will also write their logs to the Application Event Log, but for some, this can also be a configurable option. I have analyzed systems on which I have easily located the AV application logs, but have not seen any corresponding entries in the Application Event Log.

Another tool that I like to use for parsing Event Log records is the Perl script "evtparse.pl." This Perl script reads through the Event Log files on a binary level, locating and parsing the records without using any of the native Windows API functions. This has a couple of benefits; one is that you don't have to worry about the Event Log file being deemed "corrupted," as will sometimes occur when using tools (such as the Windows Event Viewer) that rely on native Windows application programming interface (API) functions. The other is that the Perl script is platform-independent; it can be used on Windows, Linux, and even Mac OS X. The script is capable of parsing event records into either CSV format, suitable for opening Excel, or into a format suitable for timeline analysis (which will be discussed in greater detail in Chapter 7).

Parsing the values is only half the battle, though. There are a number of resources available that provide information and details regarding what the various event records, either individually or correlated together, can mean. One of my favorite resources is the EventID web site ( http://www.eventid.net ). The $24 annual registration fee is well worth the expense, as I can log into the site and run searches to not only get additional information about Microsoft-specific events, but also see information with respect to issues that others (mostly system administrators) have observed or encountered, as well as links to pertinent Microsoft KB articles. All of this can be very revealing, even if it only provides me with additional leads or places to look. Application-specific event records are usually best researched at the vendor's web site, as blogs and forum posts can provide a great deal of information about various events generated by these applications.

Another resource for finding information about Security Event Log entries is the Ultimate Windows Security Event Log site ( http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx ). This site provides an easily searched list of Security Event Log entries, with some explanations to provide context. The site provides information regarding Security Event Log entries for Windows XP and 2003 systems, as well as corresponding entries for Vista and Windows 2008 systems.

Tip

Event Log Analysis

When conducting analysis on a Windows system, I don't have specific event records that I search for every time; rather, what I look for depends heavily on the goals of the examination and the system's audit configuration. While many of the systems I've analyzed have had fairly default configurations (minimal changes, if at all, beyond the default, out-of-the-box settings), I have found great value in those systems where settings had been modified, to include the Event Log size being increased. I once had the opportunity to analyze a Windows XP system on which not only were both successful and failed logon events being recorded, but Process Tracking was also enabled. When analyzing this system, I created a timeline (discussed in detail in Chapter 7) of system activity, and the additional detail provided by the Event Log configuration was invaluable.

The Event Logs themselves are not always the sole source of event records on a system. Event Log records, like other data, may be found within the pagefile or within unallocated space. I was once asked to analyze a system from which very few event records were found in the Event Logs and the Security Event Log had an event ID 517 record, indicating that the Event Log had been cleared. As such, one of the steps in my analysis was to attempt to recover deleted event records. My first step was to use the Sleuthkit ( http://www.sleuthkit.org/ ) tool "blkls.exe" to extract all of the unallocated space from the acquired image into a separate file. I then loaded that file into BinText ( http://www.mcafee.com/us/downloads/free-tools/bintext.aspx ) and saved the list of strings located within the file. I then wrote a Perl script to go through the list of strings and locate all those that contained the event record "magic number" (i.e., "LfLe"); when BinText reports the strings that it locates, it also provides the offset within the file where that string is located ("strings.exe," available from Microsoft, will do the same thing if you add the "-o" switch to the command line—the utility can be downloaded from http://technet.microsoft.com/en-us/sysinternals/bb897439 ).

For every string that BinText located that began with "LfLe," the Perl script would go to the offset within the file containing the unallocated space, "back up" 4 bytes (a "DWORD"), and read the size value. As the event record structure begins and ends with this 4-byte size value, the script would then read the total number of bytes, and if the first and last DWORDs in the sequence were the same, the event record was assumed to be valid, extracted, and parsed. Using this technique, I was able to recover over 330 deleted event records. Another way to do this would be to simply have a slightly modified version of either the "evtrpt.pl" or "evtparse.pl" script parse through unallocated space 4 bytes at a time, looking for the event record "magic number," and then processing each event found to be a valid record. However you go about doing this, it can be a very valuable technique, particularly if you're trying to construct a timeline, as discussed in Chapter 7. The point of this is to illustrate how understanding the various data structures on Windows systems can lead to the recovery of additional data that may significantly affect your overall analysis.

Tip

Interesting Artifacts

While I do not have a list of specific event IDs that I look for during every analysis engagement, there are some records of interest that I do look out for when required by the goals of the engagement. As mentioned previously in the chapter, a Security Event Log entry with event ID 517 indicates that the Event Log was cleared. Further, on most systems, some Windows services being started will result in an event with the "Service Control Manager" source and an ID of 7035 being generated by the system shortly after the system is booted. As such, services started by a user hours or days after the system was last started may indicate normal system administration activity, or provide indications of a compromise, such as an intrusion or malware being installed. Further, a number of organizations may use tools such as "psexec.exe" ( http://technet.microsoft.com/en-us/sysinternals/bb897553 ) to access and remotely manage systems; however, intruders will sometimes use "psexec.exe" or similar tools (such as "rcmd.exe," the remote command utility available from Microsoft) to remotely access systems. The use of such tools usually results in a service being started in the context of the user account used to launch the tool, and is preceded by a network logon (security event ID 540, type 3).

Windows Event Log

With Vista, Microsoft modified a great deal about how events are recorded, as well as the types of events recorded, the location where the events are recorded, and the structure of those recorded events. This new mechanism is referred to as the "Windows Event Log," rather than just "Event Log" as seen on Windows XP and 2003 systems. On Vista through Windows 7 systems, the Windows Event Logs are stored in the "C:\Windows\system32\winevt\Logs" folder (by default), and are stored in a binary extensible markup language (XML) format.

On a system with a default installation of Windows 7 and only MS Office 2007 installed, I found 134 different .evtx files in the "winevt\Logs" directory. There are two types of Windows Event Logs: Windows logs and Application and Services logs. Figure 4.3 illustrates these logs, visible via the Event Viewer.

Figure 4.3. Windows 7 Event Logs (via Event Viewer).

You can see a number of the Event Logs that you'd expect to see on a Windows system in Figure 4.3 . For example, there are the Application, System, and Security Event Logs, which correspond to "appevent.evt," "sysevent.evt," and "secevent.evt," respectively, on Windows XP/2003 systems. The Security Event Log records many of the same events as you may be used to seeing on Windows XP systems, including logons and logoffs (depending on the audit configuration, of course). However, there is a difference—many of the event IDs you would be interested in are different for the same event. For example, on Windows XP, an event ID of 528 would indicate a logon; for Windows 7, that same event would have an event ID of 4624. The difference between these two event IDs is 4096; this holds true for a number of Security events. The Ultimate Windows Security site has a fairly exhaustive listing of both Windows XP and Windows 7 Security Event Log records that you might expect to see, which can be found at http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx .

You will also see the Setup and Forwarded Event Logs in Figure 4.3. According to Microsoft, the Setup log contains events related to application setup; however, reviewing the various entries on a live system reveals that the statuses of Windows Updates are also recorded in this log. The Forwarded Event Log is intended to store events forwarded from other systems.

The remaining logs are Applications and Services logs and store events for a single application or component, rather than events that would affect the entire system. These logs have four subtypes: Operational, Admin, Analytic, and Debug. By default, on a normal Windows 7 system, you're likely to see Operational and Admin logs, although now and again you'll see Analytic logs. Admin events are targeted at end users and system administrators, and provide information that an administrator may use to fix an issue or take some other action. Operational logs are generally used to diagnose an issue. For example, the Microsoft-Windows-WLAN-AutoConfig/Operational log provides information about wireless networks that the system has associated with, and through which network adapter, as illustrated in Figure 4.4. Events such as this can be instrumental not just in diagnosing problems, but can also provide clues to examiners during an investigation.

Figure 4.4. Event from the WLAN-AutoConfig/Operational log.

The Debug and Analytic logs are intended for developers and used to diagnose problems that cannot be handled through user intervention.

Tip

VHDs and VMs

I've done a bit of testing of virtual hard drives (VHDs) while writing this book (see Chapter 3), mounting and removing them from my Windows 7 system. As such, the Microsoft-Windows-VHDMP/Operational.evtx log has a number of events visible that are associated with the "surfacing" (mounting) of VHD files (event ID 1) and "unsurfacing" (removing) of those files (event ID 2). However, this log applies only to the mounting and removal of VHD files. The Microsoft-Windows-Virtual PC/Admin log maintains records of the use of Virtual PC to create and start virtual systems or machines (VMs), including "XP Mode," a version of Windows XP available to maintain compatibility with applications that may not run well (or at all) on Windows 7. This log also maintains information about applications installed in XP mode, but launched from Windows 7. Both of these may provide valuable information during exams, particularly when you're looking for files that may not be in the Windows 7 file system, but may have been accessed from a VHD or VM.

All this aside, what are some of the ways to get at the data within the Windows Event Logs? One means for parsing Windows Event Logs that I've found to be very effective is to install Microsoft's free Logparser tool ( http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24659 ) on a Windows 7 analysis system, and then either extract the Windows Event Log files from the acquired image, or mount the acquired image as a volume. From there, I then use the following command to extract all of the event records from each log:

logparser -i:evt -o:csv "SELECT * FROM D:\Case\System.evtx" > output.csv

When using this command, it's important to remember that Logparser relies on the APIs (available via DLLs) on the analysis system. As such, you won't be able to use it to parse Vista or Windows 7 Event Logs if you're running Windows XP on your analysis system, as the Event Log APIs on Windows XP aren't compatible with the Vista/Windows 7 Windows Event Log format. Similarly, you can't use Logparser to parse Windows XP or 2003 logs on a Vista/7 analysis system. Sending the output of the Logparser command to CSV format allows for easy viewing and analysis via Excel, in addition to providing additional columns for you to add references or your own notes. The format also allows for easy parsing, as we will see in Chapter 7.

Tip

Converting Event Logs

While attempting to use Logparser running on a Windows 7 system to parse Windows XP Event Logs won't result in anything useful, you can use "wevtutil.exe" (native to Windows 7) to convert the XP Event Logs to Windows 7 Event Log format, using a command line similar to the following:

D:\tools>wevtutil epl appevent.evt appevent.evtx /lf:true

Andreas Schuster, whose blog can be found at http://computer.forensikblog.de/en/ , has put a good deal of effort into deciphering and decoding the Windows Event Log format, and creating a Perl-based library and tools collection for parsing the events from a log. As of this writing, the version of his library is 1.08. You can download and install Andreas' library, or you can use tools that have the library and tools already installed, such as the SANS Investigative Forensic Toolkit (SIFT) Workstation that Rob Lee developed. SIFT version 2.1 was available at http://computer-forensics.sans.org/community/downloads when this chapter was being written.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597497275000040

Where "Logs Are Stored on Your Local Computer and Automatically Removed After 7 Days."

Source: https://www.sciencedirect.com/topics/computer-science/security-event-log

Share this post