Sextortion Spam Scientifically Scrutinized
Topinambour & Windows event logs
Sextortion scams are one of the big newcomers in Internet fraud of the last year. In these campaigns spammers send e-mails which claim that they have hacked into the victim's computer and used its webcam to film the victim masturbating while surfing adult websites. In order to prevent the crooks from publishing the compromising material they demand a certain amount of money in bitcoin within a certain timeframe. Of course, these claims are largely false which is easy to see if you think about the amount of work and expertise it would take to break into millions of desktop computers, monitor the browsers for accessing porn websites, capturing "evidence", and looking through it to make sure it actually contains what the attackers want, etc.
Nevertheless, these campaigns are pretty successful and a new research paper (see URL below) takes a scientific look into them. Some of the key takeaways are:
- Sextortion campaigns are much cheaper than traditional spam campaigns as there is no need to set up and maintain credible looking websites, purchase, sell and ship (poor quality) goods, etc. This may increase the profit for the criminals compared to "traditional" spam, although the authors' don't say anything about this.
- Cryptocurrencies make these campaigns much easier to pull of compared to using old-school money.
- In the examined campaigns the price for the ransom varies for different languages.
- A lot of the bitcoin addresses are shared throughout multiple campaigns and many can likely be tied to a single real-world entity, but this can be due to the infrastructure the spammers are using, not due to the small number of spammers themselves.
This research proves with numbers what many people in (IT-)security experience everyday: If there is an easy, quick, and cheap way to earn money, most criminals will prefer it compared to more sophisticated methods.
Research paper: https://arxiv.org/abs/1908.01051
Author: Dimitri Robl
MeliCERTes Training in Vienna
- Block outgoing SMB traffic if you can.
- Hunt or Monitor for event ID 106 in "Microsoft-Windows-TaskScheduler%4Operational.evtx".
- Think about enabling "Audit Process creation" in "Security.evtx" and command line logging.
- Hunt or monitor for event ID 4688 in "Security.evtx".
While reading through the recent Kaspersky report
on the renewed arsenal of the Turla group, I was first getting a little bit frustrated by the fact that it is still too easy for the attackers. After coming over this I focused on the question "How would I detect/hunt for it in Windows event logs?"
First of all, according to the report outgoing SMB is used by the dropper to download the next stage. Blocking outgoing SMB is not a new recommendation and while this still fits the "too easy for attackers" category it has nothing to do with event logs and is not the reason behind this blog post. Accepting that security is not only about prevention but also about detection brings us back to the aforementioned question.
The dropper function "make_some_noise" generates a new scheduled task on an infected machine to gain persistence. Focusing on Win7+ here, this generates the event ID 106 "Scheduled Task created" in "Microsoft-Windows-TaskScheduler%4Operational.evtx". This log entry includes the time when the task was added, which user added it and the name of the task. If you go hunting for this event ID, make sure you are looking into the right event log file; as far as I know there is no guarantee that event IDs are unique accross all possible event logs. Not every new Scheduled Task is per se evil, but if you start looking and investigating, you will quickly end up with a list of expected/known good tasks. And before saying "No, too much work": Do you actually know how often this happens on your clients?
Enable process creation logging: run gpedit.msc with administrative rights, navigate the following path: "Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Detailed Tracking" and set the value for "Audit Process Creation" to either "Success" or "Success and Failure"
This would give you the event ID 4688 in the "Security.evtx" log.
To enable the inclusion of the supplied command line arguments: run gpedit.msc with administrative rights, navigate the following path: "Computer Configuration-> Windows Settings -> Administrative Templates -> System -> Audit Process Creation" and set the value for "Include command line in process creation events" to enabled. Enabling this will give you the supplied arguments in the 4688 event enabled above.
Microsoft provides a nice description
as well, which you can refer to for additional reading. In case your system language is different from English, your exact path may vary due to localisation.
Now let me raise a question: "Is it normal for a standard user to run 'cmd.exe /c net use \\$IP-ADDRESS\...'?" I would say it's not and therefore seeing this in an event log can be considered an investigative hint, or can be an event triggering an investigation in a SOC team.
I'm not saying building up a centralized monitoring of Windows client event logs including relevant events is easy or that using event logs is the only way for detection. What I'm saying is: if you don't do it, you are missing a lot of incredibly useful information for SOC teams as well as client administrators.
Author: Olaf Schwarz
From March 11th to March 13th CERT.at hosted an introductory MeliCERTes Training which covered the basic functionalities of the applications used in MeliCERTes as well as the topic of CSIRT maturity as laid down in the SIM3 model and covered by the CSIRT maturity self-assessment survey by ENISA.
Together with teams from the Czech Republic, Hungary, Italy, and Croatia, as well as the trainers from the MeliCERTes consortium we spent three days looking into the MeliCERTes project and discussing how it could be improved to better meet the needs and expectations of CERTs/CSIRTs in the EU.
We also had the possibility to talk to the leading software engineer about the current status of the project as well as what remains to be done.
During the labs and excercises a number of bugs were found and noted by the trainers to pass them on to the developers. Additionally, the hands-on part spawned a lot of questions about the technical and implementational details of the platform and the applications it provides in the default configuration. The discussions which followed helped all participants to evaluate MeliCERTes more objectively for their particular situations.
In summary we had three days to learn about MeliCERTes in general, get to know its design goals but also have a look at its current technical as well as architectural shortcomings. The attendees also provided a lot of feedback to the trainers about what MeliCERTes is expected to be capable of once it is to be used productively by CSIRTS/CERTs in Europe on a daily basis.
Thanks to all participants and trainers, we are looking forward to the upcoming exercises and stresstests. We hope these will prove the usefulness of the project for the CSIRT community.
This blog post is part of a series of blog posts related to our CEF-Telcom-2016-3 project, which also supports our participation in the CSIRTs Network.
Author: Dimitri Robl
Since our "old" (2014 vintage) PGP-keys are near their expiry date, we have generated a new set of keys. They are available via our usual CERT.at PGP keyring
A transition-document, (inline) signed with both old & new keys, can be found at key-transition-2019.txt
Author: Robert Waldner