On the 22nd of May Lukas Apynis from Baltimax shared information [1],[2] about newly discovered malware. After populating information into NRD Cyber Security’s internal MISP system, and checking for IOCs in CyberSOC client environments, a case was observed where an email with a malicious attachment was received from a trusted domain. Analysis of the email shows that the content uses the image of a law firm to increase the credibility of the email in the eyes of the recipient.
Thus, in the case of this specific letter, we have as many as three victims:
1. The recipient of the letter is the direct victim of this incident.
2. The sender of the email is the “attacker” of this incident, which is understood to be an email account hijacked by another company, so they are also a victim of another incident.
3. A legal firm is an indirect victim of this malicious campaign.
Which data do you think is appropriate, permissible, mandatory or even prohibited to make public? Currently there is no standardised practice in the field.
1. Recipient information – not identifiable. The SOCshare project scope is based on the principle that when raising information related to cyber threats – the details of the victim or target will not be disclosed. If necessary, we can tag information that identifies the sector and/or country of the victim’s organisation, as this information may help in the wider investigation of an attack to identify who is being targeted, or even to identify who is carrying out the malicious acts.
2. Sender information.
3. The company being impersonated – in the available examples of this attack, we can see that the image of the same organisation is being used, even when emails are sent from accounts compromised by other organisations. This company is not a direct victim of this attack, nor is it a malicious actor in this attack. However, as their attributes are overused in the emails of this attack campaign, this information can be an additional effective IOC to help identify malicious emails. In this particular case, the organisation is a small company registered in Lithuania and working in the legal field. We need to strike a balance between building resilience to attacks and preserving the company’s reputation, so we can provide personalised information about the content of the email.
These are the ethical and procedural issues that we are facing in the development of the SOCshare project and the creation of a cyber threat intelligence sharing community. The project’s technical work focuses on the processing of information from systemic sources (such as SIEMs or EDR/XDR automated messages) in order to generate valuable cyber threat intelligence. We do not plan to automate cases such as this letter, as they require a lot of subjective judgement. However, during the course of the project, we can create other value by having clear internal processes for dealing with such information – both to discuss existing practices and, together with the community, to develop new arrangements for sharing. Not mentioned above, but we can always share sensitive information in a restricted way, e.g. only with trusted members of the community who have signed a policy agreeing to restrict the dissemination of information to specified TLP (Traffic Light Protocol) levels. Only first do we all have to agree on what is appropriate to share and what is not.
At the FIRST CTI 2024 conference in Berlin in April, Joe Slowik (Parglus) in his presentation “The Disclosure Dillema and Ensuring Defense” analysed this very topic – when is it appropriate to share sensitive data, and when is it more likely to cause more harm? His suggestion is to assess the criticality, value and outcome of disclosures and to make a subjective judgement on the balance. Meanwhile, the three incentives for never disclosing sensitive data are marketing, sales or gaining attention.
[1] https://www.linkedin.com/posts/lukas-apynis_malware-fileless-investigation-activity-7198914911798755328-ixtB?utm_source=share&utm_medium=member_desktop
[2] https://github.com/Wortexz/sneaky-bat
Part-funded by the European Union. The views and opinions expressed are those of the authors alone and do not necessarily reflect the views and opinions of the European Union or the European Cyber Security Centre of Excellence. Neither the European Union nor the European Cyber Security Centre of Excellence can be held responsible for them.