Long story short, we discovered someone had maliciously set up an email forwarding address on the webmail interfaces of several of our users' email accounts so any email those users sent, through webmail or otherwise, was forwarded to a specific address. While our security team is convinced the culprit was likely a series of Trojans that had gone undetected for a long period of time, unfortunately there's a lot of finger-pointing in our organization right now regarding a potential malicious insider. How would you recommend starting a forensic investigation to determine who or what was responsible for this unauthorized mail forwarding?
Ask a question
SearchSecurity.com expert Michael Cobb is standing by to answer your questions about enterprise application security and platform security. Submit your question via email: firstname.lastname@example.org.
How this problem is handled depends largely on whether an organization has a forensic readiness policy. If such a policy is in place, an organization possesses the appropriate webmail forensics capability to collect, preserve, protect and analyze digital evidence to determine how the email accounts were compromised and by whom. If an organization does not have a policy, it must identify all of the different sources of evidence available and their locations. All forms of potential evidence should be considered. This includes not only log files and hard drives, but also data from CCTV cameras, personnel records and access control systems. Fragments of information and evidence can be found in various network locations that can provide clues as to how the breach occurred, so remember to be thorough. An organization’s system and application logs play a key role in any investigation, as these records can be used to detect events such as inappropriate access attempts and repeated failed attempts to log in.
If the Trojan is possibly still present on the network, use a network packet analyzer, such as Wireshark, to search for traffic that points to potential malicious activity. Nearly all malware initiates a DNS lookup in order to communicate with its controller. This activity involves receiving instructions, downloading further malicious files or sending back stolen data. DHCP logs, which record IP address assignments, reveal unusual machine activity, while VPN access logs expose unusual access patterns and network logins from unexpected locations. Firewall and proxy logs enable an organization to trace back and determine where requests and traffic originated, which is an obvious place for further investigation. Suspicious connections on one machine can help pinpoint other machines that require further investigation.
If an account is determined to be malicious or has been compromised, review any files created by that account, both locally and throughout the network. Emails and file content stored by the user should be checked for signs of a targeted attack. Also, review which other systems the compromised account may have access to, and what services it has been accessing. If an employee is suspected of breaching company policy, the employee must be given the opportunity to account for the information that has been gathered because it could potentially be inaccurate or ambiguous. If the employee is culpable, they must be disciplined according to the organization's rules and standards, be it a reprimand, suspension or termination.
Once an attack has been thoroughly investigated, infected machines should not simply be rolled back to a previous restore point. Hard drives must be fully reformatted and rebuilt from a known-good image to ensure all malicious code is removed. Any removable media previously connected to the machine should be thoroughly checked for malicious documents, executables and autorun files. Suspicious removable media should be reformatted before reuse. The passwords for compromised accounts must be changed. If the attack has penetrated deep into the network, all administrative passwords and high-privilege network or service passwords must also be changed.
This was first published in April 2012