Tag Archives: IH&R

DFIR Problems in the Cloud

As more and more companies are starting to use cloud because of ease of deployment and integration with business needs and due to its scalability, the pandemic and changing business models forced usage of it more.

From IT perspective, cloud usage provides a lot of convenience. With using cloud, companies can pay for only the resources they need and scale up or down to meet their needs easily. With this scalability, they do not need to guess future usage and butgeting it. Additionally, while it takes days or weeks to implement a new server, it only takes a few minutes to get a new one in cloud and it saves on expenses like cabling, staff, broad network access and data center. Cloud also provides a global infrastructure and high availability for systems easily.

Because of reasons above and more, it is very understandable why cloud market will keep growing in next years and the expectations are the market will have more than $800 billion in value in 2025. However, this convenience causes different problems and challenges on the security, incident response and digital forensics side.

Separation of Responsibilities in the Cloud

Security is difficult in cloud for customers because the cloud customer does not have access and responsibility of all the systems those need to be secured. So, it is crucial to know shared responsibility models of the cloud.

As the content of this article, we do not go into the description of what these cloud services are one by one.

Challenges of Security

This shared responsibility model shown above, makes security, incident response and digital forensics more difficult. It is not enough to know the organization’s assets only, security teams need to work together with cloud security provider’s (CSP) security teams. For all types of models, the organization’s teams will not have access and control on data, OS, storage, network traffic, or etc. The difficulties are not these only. Most of the organizations are using hybrid clouds and more than one CSP. This means, systems are distributed between different data centers and locations and teams need data from these different systems in different CSP and structures.

The distributed multi CSP structures causes difficulties to collect data during an incident. So, investigation real-time incidents in the cloud becomes more difficult. One of the reasons of this situation is the access rights; in all types of cloud service model, the incident handler and forensic analyst has limited access and control over data. And the other can be differences in the operational details and procedures in different CSPs. Also, with using different CSPs, and according to the CSP’s structure, logs can be stored as distributed across different servers and locations. This situation also creates difficulties investigation an incident. A correlation an activity between different CSPs is challenging due to lack of interoperability. Time stamps of the logs and time correlation will contribute to this challenging too.

Many new items can be added to this technical challenges list. However, there is also legal side of using cloud. As CSPs distributed their structure in different location all over the world, customers can face some legal issues. Data collection, protection and governance laws change according to the region that the servers located in. It creates a challenges to standardize processes. This differences can also reflect on SLAs.

We can easily increase the items that challenging security teams on cloud like; having experiences in handling cloud environments for admins, gathering and knowledge of cloud investigation and forensics tools, international communication, privacy concerns, unknown location of data, data volatility, time and timestamp synchronization, log format differences, etc.

The Newest Ransomware: Epsilon Red

Sophos announced that analysts uncovered a new ransomware – called Epsilon Red – that developed in Go programming language. The code is placed in PowerShell script.

This malicious file is written in Go programming language and a 64-bit executable file. It is said that spreading in systems by exploiting security vulnerabilities in Microsoft Exchange servers. It is using vulnerabilities like CVE-2020-1472, CVE-2021-26855 and CVE-2021-27065 that recently discovered Microsoft Exchange servers vulnerabilities. Epsilon Red ransomware scans files and encrypts for ransom when it reach to the target systems. It seems like still there are more than three thousand exchange servers that including these vulnerabilities and this shows us Epsilon Red attacks would be more painful.

According to Sophos, Epsilon Red has been seen in hospitality industry in USA mostly, and it seems like one of their victims paid 4.29 BTC after being affected.

For not being affected, organizations should keep the applications up to date and detect these IoCs below to prevent this attack. Also you can read our short post about prevention agains ransomwares.

Domain:

epsilons.red

Hash:

57ee78299598170c766ff73cefca9e78b9b81ac6999e8adb61903bc89be313ba

ce5ba1e5d70d95d52b89a1b8278ff8dd4d1e25c38c90ca202b43bdc014795d78

699ffb898864bf804cf726f39b5e8168d55e44fc1584b71ba25e31b43ae543e8

35ffc1263005fd0a954deed20a7fb0cd53dbab6bb17ff8bd34559a5a124686c7

7259975d7e3b3d9d059a38f4393ab920764b46ca243e192e08f7699999382e07

172bbf46e5f46dd7a9ea0c22054b644f60efc3a9ad26a6f0e95ca57e38af60a7

9845619cb9c3612055a934c4270568391832eab40a66dbb22b1b37fa05559c92

5120998fa1482d4d0d0099d91aab2af647c0272819d7dcf792eec01c77ab9391

4d6272aeadf7fc131ac126dc07d7bfd2e878d359e5e7bb5376a67295ce05fc15

0794c8630f40f04c0e7cea40f11dc3f1a829a3be69852fe9e184aa8b7ed20797

7a8128f8788524e54a69619b69870dfd4c50db46e3eb786899f7275dab73d2d9

4eaf5e93953756bc2196bfcfb030b6eaad687fa1e8db9f47b09819f3b4315230

a9a6d35469e471666758ed5d1174edc5b650c0acb2c351213eadfb408f74bdcb

039da6b099303fdfd087bb7df94012780dfe375c67234ce495c78cf2dcf7fd9d

ee10f3a798aaa03f4ced2ddb28d2b36fe415ea2cbbd9c3b97b2a230a72d77f5c

5aa7de7eab570522c93d337d395396057033ad6596db4a0bda15d77a6d4c6c3a

84755b2177b72364918f18c62a23854e7a8a66c4f5005cc040357850adf9d811

c1f963aba616680e611601e446955e9552c69db23dabab8444718d82ad830029

8c294f1ef05df823460bd11ce34ea7860178de6bc3d9b0127a3b9c08cf62437f

Incident Handling and Response to Insider Threats

Because an insider is an employee, is a trusted person and has access to various data, insider threats are major risks for organizations. Organizations are investing to prevent perimeter against external threat but focusing less on internal threats. This is the other factor that making insider threat more risky.

Attacks may come from different type of employees. These attackers may be system admins or managers who have authorized access to critical data, some unhappy or terminated employees, users who lost a device including sensitive data, or sending e-mail to incorrect receipints, or untrained personnel about security policies and best practices who subjected to social enginneering attacks.

All types of incidents require similar steps to respond. Here, we will try to explain the stages incident responders and actually whole organization must realize against an insider attack.

IH&R Steps for Insider Threats

EFFECTIVENESS OF INSIDER THREAT

Insider threat is a major risk because these kind of attack are very effective. It is difficult to detect and can go undetected for years. It is very easy to attack from inside since users have authorization to some data and systems, and can easily cover their actions by reaching to logs and deleting or modifying them. This makes also difficult to detect these type of attacks. Organizations need to monitor users’ behavior to detect and respond quickly.

As against all type of attacks, organizations need a well planned and regularly tested incident response plans to contain and eradicate insider attacks.

PREPERATION

The organizations must always be ready to an insider attack. Preparation stage is important to detect and respond these attacks.

  • Conduct security awareness trainings regularly to inform users against social engineering techniques. Insider attacks are not only done by malicious employees. Regular security awareness trainings will prevent your users with access to sensitive data from being used by malicious people.
  • Train users how to report any policy violation.
  • Classify organization’s data, identify the critical ones and apply need to know approach to reach to data.
  • Be sure all necessary logs are collected in SIEM.
  • Use privileged access management tools for storing passwords for all types of accounts reaching to critical data or production environment.
  • Make sure that terminated employees’ access rights are immediately removed both for logical and physical systems.
  • Deploy data loss prevention tools, but never trust that DLP will fully protect you. It is important to know the gaps of DLP tools to prevent data better. Make sure you read our post about DLP 🙂
  • Install NDR to detect abnormal behaviors of users. You can access our article explaining the importance of NDR against insider threat.
  • Install honeypot and honeytokens to lure attackers.
  • Segregate backup network from production or test networks and implement secure access methodologies to backup files.
  • Device control should be applied in the whole systems of the organizations. Users should not be allowed to use external storage.
  • Employees should sign a confidentiality and nondisclouse agreement bu Human Resources department.
  • Regularly and objective interviews and feedbacks from employees will help organization keep employees more peaceful.

DETECT AND ANALYZE

Indicators for insider threats are mostly abnormal behaviors of users. So, NDR with artifical intelligence technologies to detect anomaly in the network, UEBA, and Honeypot tools are critical to detect these type of attacks. The changes in network usage pattern may be indicator for ann insider threat.

It is important to collect logs in SIEM but in most cases, we saw in real life that huge amount of log data causes missing of malicious activity. It is more important to collect valuable logs and corralate them than collecting. Also, missing or modified logs may be indicator for insider threats. All log sources must be checked regularly to detect such an incident.

Accessing resources in unusual time and from unusal location may be indicator of insider threats. However, multiple login fail attempts may be used with these time and location information to cover unauthorized access attempts.

Users’ social media actions should be monitored. Unhappy and unmotivated users may try to post some unnecessary information about the organization.

Incident responders must analyze different logs from different sources after a suspicious activity has been reported. These logs may include IDS/IPS, proxy, NDR, EDR, DLP and email logs. They should check for a suspicious network connection and data transfers outside the network.

CONTAINMENT

For all types of attacks, containment is an indispensable stage for incident responders. It is fatally important to contain the source in question to prevent bad actors’ actions both laterally and outbound. Containment will minimizes the damages. Advanced EDR tools allows containment of such sources without having to be physically present near the source and incident handlers can still keep analyzing these sources while the threat could not be spread.

After detecting the malicious insider and containment, all privileges and credentials of this actor should be blocked, including e-mail and domain account and physical access cards.

ERADICATION

The organization should have an incident response plan and procedures to be able to move fast after an incident occurs. Eradication is also an important stage for incident handling and incident handlers should know in advance what to do in a case of insider attack by checking the policies and procedures.  However, eradication is not just CSIRT’s job. These are some processes all departments and emmployees must be involved. Malicious actor’s behaviors should be determined step by step and the preventive or detective control missings that allow her to do must be corrected. New security controls should be added and preperation stage should be reviewed again.

RECOVERY

The recovery stage must begin immediately after detecting, containing and eradicating the insider threat incident. If data is stolen and exfiltrated, incident responders should contact immmediately with the threat actor before selling or disclosuring it publicly.

Incident responders must be sure to gather ennough evidence for legal proceedings. This evidence will also help insurance processes.

In case the attacker placed malware or a backdoor inside the network, all systems should be checked carefully and all outbound connections should be checked against a C&C communication. A threat Hunting activity may be required.

If information is stolen and the stolen data is including user credentials, passwords should be changed whole over the organization.

POST-INCIDENT ACTIVITIES

This is one of the most important steps in incident Response. CSIRT should create a lessons learnt document after all incidents, this is also goes for insider threat incidents too. This lesson learnt documents will help organization preparing more effective to possible future incidents. In this stage, all the confusion caused by the incident will be gone and teams and responsible can identify what needs to be done for future readiness. Also, policies and procedures should be reviewed and changed if needed after lesson learnt works.

Also, all incidents and evidences should be documented properly to use in future.