Triggering the case

A fairly large multilocational organization implemented a Call Data Analysis & Management System, or CDAMS in short, (this is a telephone log data analysis solution.). As a part of the setup process, the team of implementation consultants were requested to ingest and analyze a very large volume of calls received by the in-house IT help-desk. The year long data of call logs from the existing organization-wide electronic private automatic branch exchanges (EPABX) system were ingested by the system. Calls were filtered on the basis of call direction and destination (incoming calls to the IT help-desk) and were geolocated as well as classified based on the department. A preliminary look showed the following interesting trends:

  • Calls from some cellular numbers (similar to the series owned by the company in particular geographies) at odd hours from a senior personnel
  • Calls from Computerized Numerical Control (CNC) manufacturing/machine departments requesting assistance relating to performance issues of their systems due to unidentified reasons
  • Calls from foreign countries where the organization did not have operations
  • Calls from corporate HQ at out-of-office hours
  • Repeated calls from a few specific users at intervals of every two hours or so

While most calls signify just another day in the life of an IT help-desk technician, an in-depth analysis of the calls seemed to signify that something was amiss.

All of the preceding incidences were examined in more detail. Some were found to relate to requesting a password reset that turned out to be social engineering attempts, others related to persistent infections, as well as ongoing attacks; the CNC department had open-USB access as a functional requirement and this led to the proliferation of malware and expensive downtime.

Once these patterns were identified, it became quite easy to take preventive actions by putting external social engineering numbers and extensions requesting password resets the out-of-office hours on telephone watch lists. Other telephone patterns were correlated with security incidents and these were identified as early Indicators of Compromise (IOC). All in all, the introduction of CDAMS added a brand new dimension to network forensic investigations, as well as acted as an early warning system based on the behavioral analysis.

The story illustrates how different sources of information can act as a trigger leading to a full-fledged network forensic investigation. This could also be based on rules implemented in various perimeter security devices such as firewalls, intrusion detection system (IDS), and intrusion prevention system (IPS).

Some triggers are enumerated in the following:

  • Multiple outbound connections: Multiple outbound connections from an internal host in a short span of time could indicate a compromised host being used to attack the external systems. An example for this would be a compromised corporate computer mass mailing unsolicited e-mails with malicious content as illustrated in the following image:
    Triggering the case
  • Communications with block listed malicious IP addresses or URLs: As the malware economy booms, the number of URLs and IP addresses serving up malicious software is on the rise. Any internal host communicating with a known malicious IP address or URL would be a definite cause of concern to any system administrator. To enable organizations in order to block access to such malicious websites and URLs, a number of organizations constantly maintain and publish block lists. Some of these are as shown in the following:

    Communications between corporate networks and the outside world are depicted in the following image:

    Triggering the case

    These communications could be directed inward or outward. IP addresses and URLs that serve up malware are subjected to constant surveillance and take-down operations. Therefore, these lists are dynamic in nature and need to be constantly updated in order to ensure an organization's defenses are up-to-date.

  • Standard services using non-standard ports: Communication with external IP addresses using non-standard ports is a red flag and could be indicative of compromised systems. For example, FTP is a protocol that normally correlates to ports 20 and 21. In the event we come across entries in our logs relating to FTP usage on higher numbered ports (that which we are not aware of), there is a strong possibility that our system has been compromised as given in the following image:
    Triggering the case
  • Lateral movement of data: Excessive data transfer to a specific system from across the enterprise is another good IOC. Any collection of data in an obscure location of the network can signal a planned exfiltration of data after the compromise. Indications of this occurring may include the out-of-hours data transfer to a system that is divergent from the normal operational practices, excessive use of network resources, the presence of data in locations where it is not supposed to be, and so on. The way Advanced Package Tools (APTs) work is by gaining access to the network, identifying the digital assets of interest, lateral movement of these assets, collecting the digital assets in one place, building manageable archive segments, encrypting them, and finally exfiltrating them. In the end, these archives on the victim's networks are deleted to cover the tracks and increase persistence. Exfiltration can be a complex process as it involves uploading large volumes of data without the knowledge of the victim or detection by the victim's perimeter defenses. In cases involving internal complicity, the exfiltration may happen by something as simple as carrying the data out on an external hard drive; while in cases involving remote action, exfiltration could follow more complex paths. Cases where the exfiltrated data has been disguised as normal HTTP or HTTPS traffic are common. More exotic methods such as disguising the exfiltrated data as videos and uploading them to the cloud (onto video-sharing sites) have also been observed as shown in the following image:
    Triggering the case
  • Multiple inbound connections: Multiple inbound connections simultaneously sending requests to a specific network resource could be indicative of an attack in progress. If the logs indicate an abnormal number of requests (such as pings), there is a strong possibility that an attempt is being made to overwhelm the available network resources and a denial-of-service attack is in progress, as shown in the following image:
    Triggering the case
  • Multiple logins: Multiple logins from different locations to the same or different resources at the same time may indicate a case of compromised credentials. It is fairly common for attackers to rapidly exploit the compromised credentials to gain maximum mileage possible in the shortest possible time. This results in multiple login attempts at different organizational resources to help in determining the extent of the access available. These credentials may also have been sold online and could be used by a multitude of people for different nefarious purposes, as shown in the following image:
    Triggering the case

As we can see, there are a large number of known and previously unknown actions that may trigger an investigation. It usually starts with a user complaining of strange system behavior, including slow access and can continue in an upward spiral.

Let's take a look at the case that we are required to investigate.

Trigger of the case

One fine Monday morning, an organization was hit by a ransom demand. An e-mail, sent directly to the CEO, threatened the exposure of a very large volume of company's confidential information on the Web unless a large sum was transferred to a specified Bitcoin wallet. Some very sensitive sample data was attached to the e-mail to lend credence to the threat. Furthermore, recent media coverage had brought the subject of the companies being hit by ransomware to the forefront of the CEO's attention.

The CEO was thoroughly shaken and did not know whom to call. Just the idea that the confidential information could appear on the Web was enough to cause major distress. He could imagine the negative publicity, fall in the share prices, loss of customer confidence, layoffs, government intervention, and other repercussions that would follow such event.

After much deliberation, he called in the CFO, who in turn called in the CSO and CISO to discuss this issue in detail. A lot of thought and discussions later, it was decided to get in a trusted key InfoSec Team member with network forensics skills to identify where the leak occurred from and contain such exposures further. The team member was required to keep the information to himself and conduct the investigation as confidentially as possible. A cover story was created to make the investigation seem like a routine audit.

The investigator was charged with the following brief:

  • Keep the investigation absolutely confidential; even the cover story was to be communicated on a need-to-know basis.
  • Gather information about the breach and determine its extent—did the datanapper actually have all the data that they claimed to have?
  • Find out how the breach occurred.
  • Were the insiders involved?
  • Suggest controls to prevent a repetition of the incident.
  • All of this was to be done by yesterday (a sad fact of a network forensic investigator's life is that all jobs need to be done by yesterday).
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.142.166