Notices by Alexandre Dulaunoy (adulau@infosec.exchange)

Recommendations on "Naming Threat Actors" provides advice on the naming of threat actors (also known as malicious actors). The objective is to provide practical advice for organizations such as security vendors or organizations attributing incidents to a group of threat actors. It also discusses the implications of naming a threat actor for intelligence analysts and threat intelligence platforms such as MISP.

🔗 https://www.misp-standard.org/rfc/threat-actor-naming.html
🔗 https://www.misp-galaxy.org/threat-actor/

#cybersecurity #opensource #threatintelligence #threatintel #standard

@misp

@cR0w We developed the open source vulnerability-lookup project (and also the sighting part) for providing actionable intelligence in the scope of NIS2 obligation and to share the information with all CSIRTs and SOCs efficiently.

https://www.vulnerability-lookup.org/

about the sighting aspect https://www.vulnerability-lookup.org/tools/#sightings

We have still plenty of ideas. If you see something missing, let us know.

@GossiTheDog @screaminggoat

@screaminggoat @jerry If you are curious about the evolution of sightings https://vulnerability.circl.lu/vuln/CVE-2023-34990#sightings

@iftas Do you share the hashes ? it might be useful for many other open source projects.

@jaz

The importance of sharing CSAM detection indicators cannot be overstated, it significantly improves detection at scale. Despite multiple requests for #DFIR activities, we were denied access to these databases. This restriction is a missed opportunity, as it limits detection capabilities.

Frankly, I don’t see the risks of sharing these indicators. The cybersecurity community has been sharing IoCs, malware hashes, and domains for years. Why should CSAM indicators be treated differently? With technologies like encrypted Bloom filters, even public sharing can be done securely.

If we truly want broad and effective detection in #fediverse and other social networks, we need widespread sharing of CSAM indicators.

A funny phishing targeting GitHub users with an email notification about a security issue on a existing repository.

Then the captcha verification on a malicious website is trying to trick the user to run a shell command on Windows.

🔗 Powershell to be executed by the user
https://gist.github.com/adulau/6cf6f3e9c5bbd9106af8814d0a22f473

🔗 File downloaded https://pandora.circl.lu/analysis/21e8f693-361b-4a04-853c-276f9dd841e4/seed-1XqUr4mADaFYlLAyrBH8oQUBgOoEbceZ586b8h05YyA - Lumma Stealer

🔗 Malicious domain analysis. https://lookyloo.circl.lu/tree/91106035-dfec-4acc-af06-c9fc36c62774

#malware #malwareanalysis #infosec

Extracting Training Data from ChatGPT

I’m wondering if OpenAI requested a CVE for the disclosure of this vulnerability.

#llm #llms #openai #vulnerability #chatgpt

🔗 https://not-just-memorization.github.io/extracting-training-data-from-chatgpt.html

🔗 https://arxiv.org/abs/2311.17035

Digging a little bit in the some ICC profiles added in signal-app, I updated the original issue and there is clearly an issue where new ICC profiles are created from the Google skia library.

https://github.com/signalapp/Signal-Desktop/issues/6031#issuecomment-1702432836

This issue only appears when the media-quality is to high. Maybe an allow-list strategy like the mat2 tool written by @jvoisin would be better to be sure that new metadata created are discarded by default.

@signalapp

#privacy #signal #signalapp #metadata