Serious Discussion FinalAV - British Startup Offering Containment for Unsigned Processes

at least for antivirus ( the big players ) it is...
Most of them require card details for their trials.

Gen Digital requires it for most of their brands, only Avast and AVG seem to be the exception.

In addition to asking card details for their trials, they also run practices which very closely mimic scareware, exaggerated problems and statements accompanies by frequent pop-ups.

The local help manuals were long ago thrown out like rubbish, replaced with “online help” which serves as a conduit to display flashy upsell cards.

Even security-related blogs have been weaponised as a marketing platform.

That’s the state of the current “Security Software”.

There is a handful of companies against all that.
 
Most of them require card details for their trials.

Gen Digital requires it for most of their brands, only Avast and AVG seem to be the exception.

In addition to asking card details for their trials, they also run practices which very closely mimic scareware, exaggerated problems and statements accompanies by frequent pop-ups.

The local help manuals were long ago thrown out like rubbish, replaced with “online help” which serves as a conduit to display flashy upsell cards.

Even security-related blogs have been weaponised as a marketing platform.

That’s the state of the current “Security Software”.

There is a handful of companies against all that.
I haven't used any Gen Digital solutions in a long time, but the few I've tried—like Trend Micro, ESET, and Bitdefender—don't require payment data. FinalAV is a new company with no reputation, so I'm not sure people will feel comfortable giving payment info like that. It's very confusing: first they say no credit card is needed, then it is, but actually you can bypass it (without clear info)—just too messy.
 
I haven't used any Gen Digital solutions in a long time, but the few I've tried—like Trend Micro, ESET, and Bitdefender—don't require payment data. FinalAV is a new company with no reputation, so I'm not sure people will feel comfortable giving payment info like that. It's very confusing: first they say no credit card is needed, then it is, but actually you can bypass it (without clear info)—just too messy.
Yeah… it is aggressive indeed.
 
Do you know what’s even stranger? I completed the trial “purchase” process… and guess what? At no point were any card details or payment information requested... which makes all of this even stranger... what a mess.
 
Now that I am at it, I think I'll just push my luck 😱 ... and will try to address some of the more conceptual pushbacks in earlier posts, like the fact that there is quite a bit of digitally signed malware out there or that products like VoodooShield already provide a filtering by digital signature. Apologies in advance for the lenghty post 🙏

A couple of observations:
(1) We do think digital signature screening (done properly - see next point) is the future in endpoint security because legacy approaches are totally overwhelmed by a professionalised cybercrime, but we do also check for known virus signatures as a first filter. Let's be clear, with virus polymorphism enabled by mutation engines available cheaply in the dark web, a defense based on a blacklist of virus signatures is just a lost battle. It's probably still around due to legacy inertia... Further, behavioural analytics, even if AI powered, always suffers from false positives and negatives. This is unavoidable because there are behaviours that are only malicious if done by malware but that are totally legitimate in themselves (e.g., creating executable files, encryption). And let's not forget that hackers can dry run their malware against behavioural analytics tools in the market before releasing, to ensure they adjust their behaviour and they manage to fly under the radar. This has led to the emergence of security operation centre (SOC) service providers to deal with this deluge of alerts, but this is not an economically feasible option for consumers and small businesses due to its cost.​
​
(2) What we do is a bit more complex that what VodooShield (or Windows SmartScreen frankly) do, which is checking the digital signature of an executable file at load time and take a go/no-go decision. Problem with that is that you are missing two very common scenarios: i) injected DLLs on the fly and ii) the loading of compromised system DLLs, plus SmartScreen also gives the user the option to proceed anyway, and then all bets are off. Our product does not check the digital signature when an executable file is launched, but when a process memory space is created by the operating system and also for each image loaded into such process' memory space continuously, not just at launch time. This catches the aforementioned scenarios of DLL injections.​
​
Further, because the real-time sandboxing we operate on every process, if a user decides to 'proceed anyway', they are still protected. Say a teenager downloaded a free game from the web that unfortunately also brings some adware, or worse, some malware payload. Well, in our real-time sandbox the free game will work, but the behind the scene attempts to drop the payload will fail. Not a go/no-go decision at launch, but an ongoing monitoring.​
​
All that is a bit more complex to handle than just checking a file hash against a database of virus signatures, and can cause operating system/applications instability if something goes wrong. Part of our original product issues were due to this complexity. You could say our unstable initial releases were our MVP 😢​
​
If case it helps, you can take a look at a semi-technical blog we posted in our website that explains our approach in a bit more detail: Technical Blog: The FinalAV Security Framework | FinalAV Security​
​
(3) We are fully aware that digitally signed malware is a problem, and so we have also built some behavioural analytics in our product, but we think that i) it matters how prevalent it is, ii) in the long run the industry is driving towards reducing that problem, and iii) the virus signature blacklists and the behavioural analytics do not seem to move towards a resolution of their limitations, quite the contrary. In our minds, this would be akin to countries completely giving up on passport checks at border controls because some criminals can get hold of counterfeit passports. It seems more sensible to do passport controls and at the same time, take collective actions to reduce the ease and prevalence of passport fraud. And that's exactly what the tech industry is doing.​
​
Because we've been asked about this matter both by investors and customers a lot, we even have a slide in our deck:​

FinalAV Security - Code-signing Certificate Abuse.jpg

By the way, our product can coexist with other AV solutions, so customers can use it either standalone or as an extra layer of security in their architecture. We're not suggesting a comprehensive cybersecurity defense should only use a digital signature screening approach, but for cost conscious consumers and small businesses it is probably a better solution.

Look forward to hear your thoughts on the above arguments!
 
Now that I am at it, I think I'll just push my luck 😱 ... and will try to address some of the more conceptual pushbacks in earlier posts, like the fact that there is quite a bit of digitally signed malware out there or that products like VoodooShield already provide a filtering by digital signature. Apologies in advance for the lenghty post 🙏

A couple of observations:


By the way, our product can coexist with other AV solutions, so customers can use it either standalone or as an extra layer of security in their architecture. We're not suggesting a comprehensive cybersecurity defense should only use a digital signature screening approach, but for cost conscious consumers and small businesses it is probably a better solution.

Look forward to hear your thoughts on the above arguments!
So, your approach, is almost the same as pcmatic?
 
So, your approach, is almost the same as pcmatic?
Somewhat, but not exactly. As I understand it PC Matic uses a "global application allowlist", so it is all done at application level, when it is launched. As I tried to explain in my post, we do check not only the main executable file, but also all the hundreds of DLLs that get loaded in and out of a process space. This goes on in real-time for the life of the process, and I can assure you there is a lot going on.

This application whitelist approach is very easy to break, and in our demos to investors when we were seeking funding we were able to show it. You just need to inject a malicious DLL into a whitelisted app and you're off to the races. To achieve that, you can either use an OS vulnerability to obtain administrative rights, or just use social engineering (e.g., fool user to install an application they think is legit, etc, etc). By the way, this approach also fools SmartScreen.

Hope that makes sense.
 
Look forward to hear your thoughts on the above
Too much information for me to read at the moment.

From what I understand, slight hint of unsigned code running (one dll), and you go ahead and sandbox the process…?

How you validate signatures in this case is not important unless you maintain a highly robust list of abused signatures (temeletry driven with behavuoural indicators and preferably, third-party enriched).

This “trust the signature and you will succeed” approach is what Trend Micro used to use, it didn’t work for them and they abandoned it.

Despite industry measures to more strictly control digital signatures, services like Azure Artefact Signing (previously Trusted Signing) and the new requirements for OVs to be kept on a physical token or HSM, there is still signed malware, including but not limited to malicious kernel drivers in circulation.

Believing that every safe piece of software will be signed is naive, there is quite a lot of goodware out there that is not signed due to the rolling coats and complexities that a single developer may struggle with.

And believing that everything signed is goodware is also naive.
Reports have previously shown that milk farmers and companies selling a few kilograms of Sodium Laureth Sulfate and soap, have all had digital signatures issued—without knowing.

In the end, this is the same “we’ll catch most but not all” approach that vendors achieve with layering different technologies.
The destination is the same, the transport is different.
 
Hi @Josep_FinalAVSecurity

I have some questions for you

1. Any infos for a multilanguage support for it available

2. How can I submit samples for review checking

3. An which scan engines did you use

4. Will you add these to virustotal

5. On which Windows does it work

6. What is your Roadmap of it

7. Any Changelog site available

8. Will you release Beta / RCV versions

Mops21
 
or that products like VoodooShield already provide a filtering by digital signature. Apologies in advance for the lenghty post 🙏
I will most likely try your app, but I can wait for @Shadowra to run a test and conclusion. Not sure why you mention Cyberlock (fka Voodooshield) with a somewhat negative connotation in an effort to boost your software. I am not a coder, but I'm pretty sure Cyberlock does more than filter by digital signature and it has helped protect my computer(s) for more than 10 years. "pushing your luck" has not convinced me, yet..., and good luck developing a good software product.
 
Calling CyberLock’s certificate handling simple is adorable. Our certificate handling is a multi‑stage validation pipeline we have built and refined over 15 years. And that is just the certificate logic, which is one of the least interesting layers of our tech.
 
Somewhat, but not exactly. As I understand it PC Matic uses a "global application allowlist", so it is all done at application level, when it is launched. As I tried to explain in my post, we do check not only the main executable file, but also all the hundreds of DLLs that get loaded in and out of a process space. This goes on in real-time for the life of the process, and I can assure you there is a lot going on.

This application whitelist approach is very easy to break, and in our demos to investors when we were seeking funding we were able to show it. You just need to inject a malicious DLL into a whitelisted app and you're off to the races. To achieve that, you can either use an OS vulnerability to obtain administrative rights, or just use social engineering (e.g., fool user to install an application they think is legit, etc, etc). By the way, this approach also fools SmartScreen.

Hope that makes sense.
Welcome to MT! Honestly, no, it does not make sense. How are you going to install a non-whitelisted app? Same applies to the OS vulnerability. As my boss used to say when I was 24... "You can't get there from here."
 
Hi @Josep_FinalAVSecurity

I have some questions for you

1. Any infos for a multilanguage support for it available

2. How can I submit samples for review checking

3. An which scan engines did you use

4. Will you add these to virustotal

5. On which Windows does it work

6. What is your Roadmap of it

7. Any Changelog site available

8. Will you release Beta / RCV versions

Mops21
Hi Mops21, many thanks for your questions.
Let me try to answer them as best as I can:

1. Currently we only support English, and we are aware we need to provide multilanguage support. Given our limited budget, we had to prioritise but fair point.

2. At the moment we are not set up yet to take samples, but it is a very interesting suggestion we'll have to incorporate.

3. We do not use third party scan engines, but note that the core of our product is based on digital signature screening rather than virus signature blacklisting, although our mini-filter drivers does both.

4. We will and with the team we'll have to automate our submissions process.

5. Currently only on Windows 11 (and 10). We started developing in parallel for all Windows versions, from XP to 7, 8, Vista and 10, but as we realised the scope of the project and our budget, we decided to prioritise the larger customer base. That said, our code base has been written with that in mind, carefully isolating OS version specific elements to facilitate us retaking that in the future. We do think there is an interesting underserved niche market out there of old public infrastructure still running on legacy Windows, including XP.

6. We have a list of additional features to better handle the situations that have been discussed in this thread, such improving our support for virus signature screening, maintaining a black list of abused certificates, support for IT management support systems, multilanguage support, other Windows versions support, Android/iOS support, etc.

7. We maintain an internal changelog, but we hadn't thought about making it public.

8. We offered a beta version before we went live, but I take from your question that it would be a good idea to keep releasing them with whatever new functionalities we're working on.

Hope this helps.

Josep
 
Calling CyberLock’s certificate handling simple is adorable. Our certificate handling is a multi‑stage validation pipeline we have built and refined over 15 years. And that is just the certificate logic, which is one of the least interesting layers of our tech.
Please accept my apologies for a poor choice of words when trying to highlight the differences between our screening approach and that of VodooShield/CyberLock 🙏

If indeed CyberLock verifies the digital signatures of all the DLLs being loaded into a process space throughout the life of a process, then I stand corrected. This is what our product does too.

Our understanding from the CyberLock settings was that the screening is done at the executable level, which is what Microsoft SmartScreen does too, but then it seems we may have been wrong.

CyberLock Screenshots.jpg

I apologise again 🙏
 
Welcome to MT! Honestly, no, it does not make sense. How are you going to install a non-whitelisted app? Same applies to the OS vulnerability. As my boss used to say when I was 24... "You can't get there from here."
Fair enough.

Our working assumption when designing our product was that the malware will be dropped, either because of an OS vulnerability exploitation or social engineering fooling the user into installing something they think is legitimate. So we operate on the pessimistic basis that we need to try to defend from it once it is already running in the system.

I'm not a black hat myself, but to try to install a non-whitelisted app on a system protected with an application whitelist, I would use an exploit kit (widely available on the dark web) to launch a small process in the target system (not installing it, just running it in memory), then this process would move laterally by injecting a malicious DLL (the first payload) into a running whitelisted app (e.g., Microsoft Word, Windows Explorer). Once running in that application process space (and thus whitelisted), my malicious DLL would be able to ensure persistency by dropping an executable file (the second and main payload) in the startup folder, modifying the Windows registry, and possibly replacing operating system DLLs. An alternative to the exploit kit would be to use social engineering to fool a user into installing a presumably legit application (for instance a free game or utility from the web), so they would add it to the whitelist, not realising it would be used to drop other stuff. Ultimately, humans tend to be the weakest link in any security system. As I said, we assume that somehow malware will be dropped in the system.

We do like the whitelist concept ourselves and we have built our product around it 🙏
 
Too much information for me to read at the moment.

From what I understand, slight hint of unsigned code running (one dll), and you go ahead and sandbox the process…?

How you validate signatures in this case is not important unless you maintain a highly robust list of abused signatures (temeletry driven with behavuoural indicators and preferably, third-party enriched).

This “trust the signature and you will succeed” approach is what Trend Micro used to use, it didn’t work for them and they abandoned it.

Despite industry measures to more strictly control digital signatures, services like Azure Artefact Signing (previously Trusted Signing) and the new requirements for OVs to be kept on a physical token or HSM, there is still signed malware, including but not limited to malicious kernel drivers in circulation.

Believing that every safe piece of software will be signed is naive, there is quite a lot of goodware out there that is not signed due to the rolling coats and complexities that a single developer may struggle with.

And believing that everything signed is goodware is also naive.
Reports have previously shown that milk farmers and companies selling a few kilograms of Sodium Laureth Sulfate and soap, have all had digital signatures issued—without knowing.

In the end, this is the same “we’ll catch most but not all” approach that vendors achieve with layering different technologies.
The destination is the same, the transport is different.
Agreed, we also layer different technologies to try to cover all the potential attack scenarios. Of course, each vendor will claim their choice of 'tools' is a better combination, and this is also how we pitch our product offering. We do think digital signature screening has more long term potential (for the reasons I explained above), but also use other tools to complement it due to its current limitations too (certificate abuse).

A way we like to present and compare our product is using this map of attack surfaces (but please take with a pinch of salt, as you know these diagrams are always designed to shine the light on the good features of your own product 😬):

FinalAV Security - Attack surfaces diagram.jpg


Of course, it matters how large one thinks each box/scenario is...

On the matter of goodware, yes, we do understand that there is a lot of goodware out there that is not digitally signed. Note that our sandboxing is not like the Windows integrity levels, whereby a process with AppContainer integrity has not access to the file system for instance. We restrict very malware specific functionality (e.g., persistency, encryption, data extraction) so a piece of goodware that is non-digitally signed will run in our sandbox largely unaffected. Of course, if it tries to do something suspicious like dropping an executable file in the startup folder, that function call will be blocked. Ultimately, a user also has the ability to add an application as an exception so it won't be disturbed by our product, like many other products in the market do.

Indeed protecting against malware is not an easy endeavour, and using a combination of defence techniques is probably the best solution for now. We just wanted to throw our hat in the ring, but again I apologise if I offended anyone by getting carried away describing our product abilities 🙏

And thanks again for the advice on our confusing trial sign up process. We'll get it fixed (y)
 
Last edited:
Please accept my apologies for a poor choice of words when trying to highlight the differences between our screening approach and that of VodooShield/CyberLock 🙏

If indeed CyberLock verifies the digital signatures of all the DLLs being loaded into a process space throughout the life of a process, then I stand corrected. This is what our product does too.

Our understanding from the CyberLock settings was that the screening is done at the executable level, which is what Microsoft SmartScreen does too, but then it seems we may have been wrong.

View attachment 297230
I apologise again 🙏
No problem at all, I was just wanting to clarify a few things.

Again, I cannot stress this enough... How are you going to install a non-whitelisted app? Same applies to the OS vulnerability. You said "launch a small process in the target system (not installing it, just running it in memory)". Adding the "small" modifier to "process" does not change anything, and neither does running the process in memory, without touching the disk. It is still going to be blocked.

Also, one of the last things I would ever do is verify all of the certificates of all of the .dll dependencies and block the app if one of the dependencies does not have a valid signature. And the reason is simple... the vast majority of software has at least one unsigned dependency, and this will break the app while adding almost no meaningful security. Also, checking all of the dll's for a signature does not make a protection layer sophisticated.

We are on completely different wavelengths, so I am not going to respond anymore, but I do wish you the best of luck with your software!
 
Hi Mops21, many thanks for your questions.
Let me try to answer them as best as I can:

1. Currently we only support English, and we are aware we need to provide multilanguage support. Given our limited budget, we had to prioritise but fair point.

2. At the moment we are not set up yet to take samples, but it is a very interesting suggestion we'll have to incorporate.

3. We do not use third party scan engines, but note that the core of our product is based on digital signature screening rather than virus signature blacklisting, although our mini-filter drivers does both.

4. We will and with the team we'll have to automate our submissions process.

5. Currently only on Windows 11 (and 10). We started developing in parallel for all Windows versions, from XP to 7, 8, Vista and 10, but as we realised the scope of the project and our budget, we decided to prioritise the larger customer base. That said, our code base has been written with that in mind, carefully isolating OS version specific elements to facilitate us retaking that in the future. We do think there is an interesting underserved niche market out there of old public infrastructure still running on legacy Windows, including XP.

6. We have a list of additional features to better handle the situations that have been discussed in this thread, such improving our support for virus signature screening, maintaining a black list of abused certificates, support for IT management support systems, multilanguage support, other Windows versions support, Android/iOS support, etc.

7. We maintain an internal changelog, but we hadn't thought about making it public.

8. We offered a beta version before we went live, but I take from your question that it would be a good idea to keep releasing them with whatever new functionalities we're working on.

Hope this helps.

Josep
Hi @Josep_FinalAVSecurity

Okay thank you very much for your infos

I will follow you here

Mops21
 

Recently browsing

Members who viewed this thread in the last 5 minutes

Back
Top