In the mindset of a threat actor

WEBINAR ON DEMAND

Please find below the questions that where asked during the webinar on Cyber Crisis Management.

1. I guess there is no "Tripadvisor" for Ransomware agents - how likely are you to have your data restored if you paid?

The answer is it depends. It is within the interest of the threat actor to help you recover once you have paid the ransom, to build their own credibility for future attacks. There are many examples of organizations successfully recovering post payment. That said, the decryptor tool provided may not work or be trustworthy, and you may encounter your own issues in the recovery process.

2. In your experience, have you found that many organizations indeed have actionable Incident Response Plans that are simulated and then actually followed in the event of a severe incident? Or is it more a case of the Incident Response Plan exists to satisfy compliance requirements, but they aren't actionable/practiced, and organizations rather reach out to incident response experts?

This is a great question. Unfortunately, it tends to be developed to satisfy compliance. In our experience, the most valuable aspect of these plans is in their development, where key stakeholders can actually discuss their response and collaborate.

They become more effective with simulations and actual live incidents when lessons learned are implemented. Adaptability is key, as each incident is unique, but not having a process is detrimental.

3. I'm concerned with single sign on, as it can give threat actors easy access to multiple systems once breached. If those systems are OT related, it is a real concern. Would you advise SSO for OT related systems? I'm not convinced on the benefits vs risk. Especially if users are low, less than 5.

The answer may depend on who you speak to, but I am inclined to agree with your statement that SSO, especially on OT and critical systems, can be a significant risk. From an attacker's perspective, if I can compromise an internal asset and find that an application inside the environment automatically authenticates through SSO, I am free to move around the environment with ease.

Often in defensive security, we talk about "Privilege Separation". My view is that, especially in critical systems, the separation of privileges should be enforced even from trusted internal assets.

4. Can you touch upon incident response for a large multilayer organization and how to handle crisis management on different levels (for example: global steering from HQ to operational tasks at local sites)

Hopefully, the explanation given during the webinar helped answer your question, but to expand a little further: for larger organizations, having a crisis framework that details how your operational local teams will work with your strategic teams will be key.

You should seek to clarify roles and responsibilities at each level, and identify the best ways for these groups to interact. This can be done through effective briefings, situation reports, and ultimately practicing this in simulations, etc.

5. Are there any specifics to consider for cyber incident response for the OT environment?

There certainly is. As referenced on the webinar, threat actors could potentially manipulate OT systems to cause more physical damage, or at least threaten to in an attempt to apply pressure. They could also halt or slow production. There are many specific risks related to the OT environment, with some more information on our website if this may be helpful here.

6. Given the entry point of weak passwords into ABC/CBA, how much improvement would MFA be?

MFA always provides significant improvement in preventing compromise, especially with common initial access vectors focusing on credentials. However, during Red Team engagements, we still commonly see organizations not implementing it thoroughly across their estate, allowing attackers to target areas.

It should also be noted that there are publicly available tools that allow the capture of the MFA token during phishing campaigns (such as evilginx2), which can allow an attacker to compromise accounts regardless.

The key to identify this from an incident response perspective is to ensure that logins are set to log location based MFA access attempts to identify "out of the norm" login attempts.

7. Are there known cases where blob storage from a big tech company has been compromised and encrypted (so no hosted file servers but actual cloud storage)? Like Google Drive...

Attacks against blob/cloud storage are less common, but still performed. S3 was a significant factor in the Capital One breach a few years back. Often these breaches are due to misconfigurations which could have been avoided.

While ransomware could still impact these storage solutions, the likelihood is reduced primarily due to the ability to configure immutability of files and the range of flexible recovery options. The way your blob/cloud storage solutions would be impacted is when they are synced with local and on-premise solutions (similar to OneDrive and DropBox).

If the local copy becomes encrypted, it can sync back and change the cloud stored copies to the encrypted variant. More often than not, threat actors who do not have access to local storage would likely exfiltrate and extort without encryption, which we have seen in more cases recently.

8. When looking at the framework in stage 4, where do you place the specific disaster recovery plans per team in the framework?

In the framework, at the operational layer, I would expect a technical representative to be on the team to advise on recovery plans and pull together a plan for recovery around the specifics of the incident. Then at the tactical layer, I would expect a senior member of the IT team to be able to report on this more holistically to the wider business, providing estimated timeframes and costs, and obtaining the business view on recovery prioritization.

9. What's your advice to increase protection for admin and domain admin accounts?

The most common issue I see when conducting engagements is the sheer number of administrative accounts. The first suggestion would be to limit the number of high privileged accounts to those who need them. Furthermore, a user who requires domain administrative access should not directly log in at this level of access.

A way to combat that is to implement a "2nd admin" policy, where the user's standard account is low privileged, and to conduct their administrative activities, they would need to login again, with the higher privileged account. All administrative accounts should also have a significantly tougher password policy to reduce the potential of attackers cracking extract hashes.

As a final belt and braces approach, adding user behavior analytics tools to spot irregularities in account usage will help provide an early warning.

10. Can you tell me how to detect and stop an attack in an early stage? We are trying to do this with the cyber kill chain in mind.

From a Cyber Kill Chain perspective, you will almost never spot anything in the reconnaissance phase, nor the weaponisation. Therefore, delivery is the first time you can definitively spot an attacker. Strong controls on email security, perimeter security, and most importantly user education will allow for early prevention against a breach of the external perimeter.

However, it is still necessary to think about internal threats and existing connections (e.g. business to business). This is where I like to take the metaphor of epidemiology. In the spread of a pandemic, people are infected and often unaware until symptoms arise. We have vaccinations to help limit infections. You can view tools such as EDR/AV as vaccinations, while they help, they do not entirely prevent infection.

That's why we need scientists and doctors to identify early symptoms and help the public understand how to spot those symptoms. Taking that back to Cyber Security, a robust logging/monitoring solution that feeds through to a SIEM with specific and tailored rule bases will allow your SOC to act as the doctors and warn of early symptoms of infection.

Combine that with an informative user education program, which allows your staff to act as the aware public, who can take action to notify and sometimes prevent further spread of an infection.

ABOUT SECURA

Secura is a leading cybersecurity expert. Our customers range from government and healthcare to finance and industry worldwide. Secura offers technical services, such as vulnerability assessments, penetration testing and red teaming. We also provide certification for IoT and industrial environments, as well as audits, forensic services and awareness training. Our goal is to raise your cyber resilience.

Secura is a Bureau Veritas company. Bureau Veritas (BV) is a publicly listed company specialized in testing, inspection and certification. BV was founded in 1828, has over 80.000 employees and is active in 140 countries. Secura is the cornerstone of the cybersecurity strategy of Bureau Veritas.