Cisco Talos Blog

I'm not a reverse engineer or a white hacker but I like reading about it. Most of the malware is made for Windows OS because of the Windows' enormous market share.

Majority of information about Windows malware I get from big computer security companies' research blogs like:

https://www.trendmicro.com/en_us/research.html

https://www.proofpoint.com/us/blog

https://research.checkpoint.com/

https://blog.talosintelligence.com/

https://www.welivesecurity.com/en/

Microsoft also got good security research blog: https://www.microsoft.com/en-us/security/blog/

Majority of the research combes down to researching malware's capabilities regarding malware persistence, anti-VM techniques and anti-debugging techniques.

Here is for example good compilation of malware's anti-debugging and anti-VM techniques:

https://anti-debug.checkpoint.com/

https://github.com/CheckPointSW/Evasions

In this URL,
https://blog.talosintelligence.com/2018/05/VPNFilter.html?m=1

it mentions snort rules for detection and protection for VPNFilter and ClamAV Signatures.

But it didn't explain how to use them.

The way I understand SNORT after googling it, I need to able captures the traffic (wan port) and feed that to SNORT for analysis, is that correct?

Also for ClamAV, do I need to clone/mount the rootfs from the wifi router to Linux and use ClamAV to scan that rootfs for those signatures?

The URL mentions the infested device have /var/run/vpnfilterm, /var/run/vpnfilterw. I checked they are not in my wifi router's fs.

The URL also mentions it modified/insert entry the crontab, but I can't find what exe name, possible file locations I should search in my router. Do anyone else know such info?

You have a point, but I don't think a thirteen year old slashdot post is the best way to illustrate it. Fingerprint authentication has to be implemented correctly, or else it does face the problem you mentioned, and other ones as well. Which Apple did. You can't steal the fingerprint out of an Apple Secure Enclave and compromise it like you're thinking. So it would need to be done right, which Google is capable of mandating for Chromebooks.

As far as Gummy bears are involved, my read of the Cisco Talos Threat Intelligence group report*, vs the competency and resources available to 13-year olds (who are not to be underestimated, tbc), is that the gummy bear trick no longer works.

* https://blog.talosintelligence.com/fingerprint-research/

This is almost certainly related to some sort of Russian cybercrime investigation. If you ever read Krebs or peruse some of the seedier Russian forums, xmpp.ru will sound familiar to you, because it is. Not imputing anything to the operator, that's just the nature of operating an anonymous service.

https://ddanchev.blogspot.com/2021/03/exposing-currently-active-portfolio-of_82.html

https://ddanchev.blogspot.com/2019/07/profiling-currently-active-portfolio-of.html

https://blog.talosintelligence.com/picking-apart-remcos/

https://flashpoint.io/wp-content/uploads/Plea-Agreement-USA-v.-Vitalii-Chychasov.pdf

Really interesting writeup though. I guess it's a practical example of why everyone should get a CT monitoring service!

https://en.wikipedia.org/wiki/Search_domain

An example:

The attacker posts a message to a forum, chatroom, etc. like:

Download: 2024YourCompanySalaryData.zip

When the user clicks "2024YourCompanySalaryData.zip", it is actually a domain name, and loads that website. This website then asks you to enter your corp credentials, or executes a 0-day on the victim's browser, etc.

The forum doesn't need to allow file downloads (i.e. a real .zip might not even work), and even if it does, client or server side virus scanning doesn't have a .zip to inspect.

The user is less wary of phishing, having never seen the .zip TLD. They assume they are downloading a file.

https://blog.talosintelligence.com/zip-tld-information-leak/

The CVE and the patch came out on March 7. Exploits were already being detected in the wild at the time by perimeter security vendors. See http://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html

Equifax "believes" that the hackers got in on May 13. They had some kind of intrusion detection system that finally detected the intrusion on July 29. 5 months after the "Critical" CVE alert went out. During that time security vendors were adding firewall rules to stop the attack. But apparently Equifax didn't have any other security in front of the Struts server.

That just seems like unconscionable incompetence and malpractice for such a high value target.