App Review Malware Obfuscation Part 1

It is advised to take all reviews with a grain of salt. In extreme cases some reviews use dramatization for entertainment purposes.
Content created by
cruelsister
If it was dangerous EVERY country would ban it.
If we are going to use a basic definition of "dangerous" then every government anywhere would ban or prohibit both Windows and Linux way before Kaspersky.

The issue with Kaspersky is a matter of intelligence - and all the infos are not made publicly available that explain "Why K was banned?"


Someone in Biden Admin, got butt hurt and threw a sissy, hissy fit.
The moves to ban K began before the Biden Administration.
 
@Shadowra should test the various deny-by-default products head to head, including some of the 139 known malicious file types, along with a false positive / usability test.

Then we will all know which ones drive like a Mercedes ;).
I prefer apps with larger user base and rich telemetry, maintained by giant tech company, not to mentioned if free, preinstalled, and produced by the same company who produced the OS.
 
  • Like
Reactions: Khushal
My point is not to be argumentative - which I do not think you saw it as such. My intent was only to present one of the multitude of options threat actors have and the most determined and persistent will attempt to accomplish their objectives. For run-of-the-mill threat actors on the dark web that subscribe to services, not so much - they just do the "Spray and Pray" method.

Persistent and thorough are usually determined enough that they will keep trying until they succeed - and I do not mean just for targeted attacks. The motivation is money and there is so much money to be made that the motto "Just don't give up" is something like a lottery ticket with a big payoff.
My ISP was breached in March 2023, so my email inbox was littered with SPAM. It takes some time for the spammers to fade out, except for one spammer who seems to have an endless repeat loop, with changing sender addresses which still spams me after nearly three years!

The mail sequence it keeps sending from different sender addresses:
a) my antivirus subscription will end soon, so I need to take action
b) my firewall was breached, so I need to take action
c) my ISP noticed suspicious activity, so I need to take action
d) warning that my ISP subscription will be terminated when I don't take action
e) last warning that I need to pay now, otherwise I will be disconnected from the internet

They offer an official looking opt-out, but the opt-out website is a varying free hosting website where they only change a part of the URL. After opting out I notice an immediate change of (spoofed) email address starting with the first sequence of emails again.

Once I decided to look what AV I had to buy and how they would funnel the money to their accounts, but the surprising thing was that they directed me to an official McFee website (checked website certificate and URL with who-is) through some affiliate marketing scheme. So they "only" seem to operate as spammer, but do not seem to operate as scammer. I contacted McFee with a complaint providing some of sender addresses, but they replied that they had no registered affiliates with those domains.

Since Thunderbird does not has an easy auto block feature (and does not recognize the changing sender addresses as SPAM), I have started to create manual block filters, using parts of the repeating messages in the mail header title.
 
Last edited:
I prefer apps with larger user base and rich telemetry, maintained by giant tech company, not to mentioned if free, preinstalled, and produced by the same company who produced the OS.
Rich telemetry is not required for zero-trust, it is only required for allow-by-default.
 
Rich telemetry is not required for zero-trust, it is only required for allow-by-default.
Make zero-trust less annoying be reducing FP; protection is good, but obstruction usability with endless FP blocks is definitely not.
 
Make zero-trust less annoying be reducing FP; protection is good, but obstruction usability with endless FP blocks is definitely not.
But then it is not true zero-trust... it is simply a global whitelist. Those are 2 very different things. There are other methods to drastically reduce unwanted blocks without resorting to a global whitelist. I just seem to be the only one crazy or interested enough to spend 15 years developing methods to reduce unwanted blocks while increasing usability, and not taking the easy route of auto allowing by a global whitelist or a global code signing signature database.

To clarify, our products do have WhitelistCloud, but we do not auto allow solely on the WLC verdict because then it would break the true zero-trust model. It would be a global whitelist, which many of the standard AV's already have. SAC and WDAC (App Control) are essentially global whitelists as well. Technically you can configure WDAC (App Control) so that it is essentially zero-trust, but no one does that because then the endpoint is unusable.
 
I will buy the license if @Shadowra is interested.
WOW!

Now that is customer service.... Here, allow me to help you test this competitor.

I offered a PayPal or go-fundme solution to help, thanks for stepping up to the plate.

Maybe someone should inform Shadowra he has a free license....

At least you still have 50 dollars left, out of the 100 I spent the other day... Lol Just kidding.
 
Make zero-trust less annoying be reducing FP; protection is good, but obstruction usability with endless FP blocks is definitely not.
Yea I D K... I get a couple "Would you like to allow" question from PCMatic in a week. After I install everything, I want, and then it is done. No bother at all.
 
  • Like
Reactions: Trident

 
General note about the attack vector used in the video.

Such type of attacks has been successful against most of popular AVs/EDRs for some years.
The nice article about it can be found here:
Kaspersky blocked this URL :)
1769628778553.png
 
Yes, science can be dangerous, especially in Greece. :)
The article is a scientific report on well-known malicious techniques, so maybe the "risky" detection is justified.
I have been using ArXiv for more than 25 years, mainly for articles related to mathematics and physics.

The same article in the PDF:

The scientists included their work addresses to make the lives of cyber police easier:
  1. Theodoros Apostolopoulos Department of Informatics, University of Piraeus, 80 Karaoli & Dimitriou str., 18534 Piraeus, Greece
  2. Vasilios Koutsokostas Department of Informatics, University of Piraeus, 80 Karaoli & Dimitriou str., 18534 Piraeus, Greece
  3. Nikolaos Totosis Department of Informatics, University of Piraeus, 80 Karaoli & Dimitriou str., 18534 Piraeus, Greece
  4. Constantinos Patsakis Department of Informatics, University of Piraeus, 80 Karaoli & Dimitriou str., 18534 Piraeus, Greece
  5. Information Management Systems Institute of Athena Research Centre, Greece
  6. Georgios Smaragdakis Delft University of Technology, Netherlands
From Wikipedia:
arXiv (pronounced as "archive" ... is an open-access repository of electronic preprints and postprints (known as e-prints) approved for posting after moderation, but not peer reviewed. It consists of scientific papers in the fields of mathematics, physics, astronomy, electrical engineering, computer science, quantitative biology, statistics, mathematical finance, and economics, which can be accessed online.
 
Last edited:
  • Like
Reactions: Khushal
@Bot,

Could you provide some short info about how effective the current methods (last three years) of detecting obfuscated malware are? Please also include the articles below:
"Obfuscated Malware Detection: Investigating Real-world Scenarios through Memory Analysis"
"Detecting new obfuscated malware variants: A lightweight and interpretable machine learning approach"
Obfuscated malware is still hard to “solve” with one technique, but the last ~3 years have seen practical progress by shifting detection away from static signatures and toward runtime visibility (behavior + memory) and models that can generalize better to “new-but-related” variants.

What works reasonably well today (in practice)
  • Behavior + telemetry (EDR-style): process tree, command-line, LOLBins usage, script engines (PowerShell/WScript), suspicious memory permissions, injection patterns, persistence changes. This is generally more resilient than static file scanning when malware is packed/obfuscated.
  • In-memory detection (memory forensics / memory features): obfuscation often tries to hide “on disk,” but execution still leaves artifacts in memory (process/module/service/handle/network related footprints). This has driven multiple recent ML papers using memory-dump-derived features.
  • Deobfuscation/emulation for scripts/macros: detonating/deobfuscating staged scripts, intercepting at runtime (where the “real” code materializes) tends to outperform purely static string/pattern matching.
  • ML used carefully (feature selection + explainability): a clear trend is toward smaller, interpretable models that can run fast and be explained (important for IR and for reducing noisy blocking decisions).

What still limits effectiveness (important reality check)
  • Dataset bias / “lab-to-real-world” gap: many academic results are excellent on specific datasets, but real-world diversity (OS versions, enterprise software, different user behavior) can change error rates a lot.
  • Evasion against sandboxes and ML: delayed execution, environment checks, staged payloads, and “living off the land” can reduce dynamic visibility or make behavior look more like admin activity.
  • Operational constraints: memory-dump-based approaches can be heavy for always-on prevention; they’re often more natural for investigation/triage or selective monitoring than for continuous scanning on every endpoint.

The two papers you referenced (key takeaways)
  • “Obfuscated Malware Detection: Investigating Real-world Scenarios through Memory Analysis” (arXiv 2404.02372v1)
    This work focuses on memory dump analysis using machine-learning models (decision trees, ensembles, neural nets) on the CIC-MalMem-2022 dataset, aiming to reflect “real-world scenarios” for obfuscated malware detection and comparing algorithm strengths/limitations. It’s also positioned as cost-effective/simple and provides code for reproducibility. ([arxiv.org](https://arxiv.org/abs/2404.02372?utm_source=openai))
  • “Detecting new obfuscated malware variants: A lightweight and interpretable machine learning approach” (ScienceDirect / Array journal)
    This paper explicitly targets adaptability to unseen obfuscated malware subtypes. It reports very high accuracy and very fast classification using a random-forest approach with only the top 5 features, plus SHAP for interpretability, evaluated on CIC-MalMem-2022. ([sciencedirect.com](https://www.sciencedirect.com/science/article/pii/S2667305324001467?utm_source=openai))

Practical interpretation for home users vs enterprises
  • Home users: the most effective “anti-obfuscation” is usually layered default-hardening + script controls (and good attachment hygiene), not chasing a perfect static signature engine.
  • Enterprises/IR: memory-feature approaches are promising for triage/DFIR pipelines and for building higher-confidence detections, but they still need validation on your own environment to understand false positives.

Side note on the arXiv blocks shown in the thread
A lot of “URL is dangerous” events on academic pages happen because the HTML contains example code (PowerShell reverse shells, shellcode, etc.), triggering heuristic/content rules.

Also, one screenshot posted shows “arvix.org” (a common typosquat pattern) rather than “arxiv.org”. Treat look-alike domains as high risk and only use the correct domain (or the PDF link on arxiv.org) when in doubt.

Sources
 
  • Like
Reactions: simmerskool