The root certificate is not the main issue for an attacker here. Although I do not use Kapersky, from your description it’s fairly clear that what it does is install itself as a proxy locally in your computer.
When you connect to for example our server using SSL that proxy can’t see and inspect the encrypted content unless it actually decrypts the traffic. Since it’s configured as the system proxy, what actually happens when you connect to https://www.axcrypt.net/ is that you are connecting to your proxy. This is where the installed root certificate comes in (this is likely a unique certificate generated locally just for you). The proxy now generates a certificate for “https://www.axcrypt.net/” and signs it with that root certificate. Since you have previously installed the root certificate as “trusted” in your computer, your browser will now trust the connection.
What the Kapersky software does is essentially a “man in the middle” attack in your own computer.
The connection over the Internet then proceeds as usual, except that it’s Kapersky who will be validating the certificate presented by “https://www.axcrypt.net/” and establish the encrypted connection over the Internet. If the Kapersky software is implemented as I am guessing above, this means that the Internet connection is just as hard to listen in to as before. It does require quite a lot from Kapersky to do the connection negotiation properly, I would rather trust Microsoft or Apple etc for this (if I have to trust someone, which I do for this).
Mounting an attack against an SSL connection over the Internet is no small thing, even if the server (i.e. http://www.axcrypt.net) certificate is somehow compromised. The attacker needs access to the data stream, and that requires some actions that are really hard to achieve unless you’re a provider or in national security. The provider would normally not be interested, unless its being forced to comply by national security – which is what has happened in a few known cases in the US.