I started my exploration after I saw that one program adds some lines to certmgr.msc (PC wasn't connected to the Internet, so, I don't think, that this cert can be downloaded by MS). Installer of the program contains this .p12 file, Virustotal says it is clear, but I did some more research. I checked my Certificate store using

sigcheck -tuv

A rather strange certificate was found:

    Cert Status:    Valid
    Valid Usage:    All
    Cert Issuer:    Google
    Serial Number:  00 CD 0B 32 EF B4 F4 CD 13
    Thumbprint: 33FCD70343BBE07972D73CDEFDEB3C9F4DCEFE28
    Algorithm:  sha1RSA
    Valid from: 0:05 22.07.2015
    Valid to:   0:05 21.07.2020

There is too low info about

Thumbprint: 33FCD70343BBE07972D73CDEFDEB3C9F4DCEFE28

on the Internet, but I found some interesting links (sorry, I am a newbie on this forum and can't post more than 2 links, I posted others as quotes to this topic).

Now, I am very scared and confused. I do not understand what kind of danger it creates. And I don't know what to do with this. I am absolutely sure I didn't install this certificate manually. The same certificate was found on another computer on my local network.

I need to add that I also checked my computer with several "on demand" AV scanners (CureIt, KVRT), they did not see any problem in this certificate.

The result of execution certutil -verify -urlfetch is

    L=Silicon Valley
  Хэш имени (sha1): 407d40e1a0d9d25bb8196644ddfda715a850b236
  Хэш имени (md5): bf22e164aaf0a93af128e23e7a26f74c
    L=Silicon Valley
  Хэш имени (sha1): 407d40e1a0d9d25bb8196644ddfda715a850b236
  Хэш имени (md5): bf22e164aaf0a93af128e23e7a26f74c
Серийный номер сертификата: cd0b32efb4f4cd13

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

CertContext[0][0]: dwInfoStatus=10c dwErrorStatus=0
  Issuer: CN=Google, O=Authenticode, L=Silicon Valley, C=US
  NotBefore: 22.07.2015 0:05
  NotAfter: 21.07.2020 0:05
  Subject: CN=Google, O=Authenticode, L=Silicon Valley, C=US
  Serial: cd0b32efb4f4cd13
  Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
  Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  Сертификат AIA  ----------------
  Отсутствуют URL "Нет" Время: 0
  ----------------  Сертификат CDP  ----------------
  Отсутствуют URL "Нет" Время: 0
  ----------------  OCSP сертификата  ----------------
  Отсутствуют URL "Нет" Время: 0

Exclude leaf cert:
Full chain:
Проверенные политики выдачи: Все
Проверенные политики применения: Все
Не удалось проверить состояние отзыва сертификата
CertUtil: -verify — команда успешно выполнена.

(System language: rus)

A little later... I found another "strange" certificate, "Dekart Certificate Authority", there is too low info about them, but some sites note, that this is an additional WebMoney (WM Transfer Ltd, Russian analog of PayPal) certificate. Ok, but why sigcheck detects main WebMoney certificate as absent in the MS trusted list, but don't detect Dekart? This is some kind of mystic. Generally speaking, where can I see this list in plaintext form?


Yeah, that looks fake to me, I agree with your link. These lines in particular are suspicious:

  Cert Issuer:    Google
  Algorithm:  sha1RSA
  Valid from: 0:05 22.07.2015
  Valid to:   0:05 21.07.2020

Let's dissect this and compare it against the cert presented when I browse to google.com.

Root CA

What you posted is a self-signed Root CA cert, we can tell because the subject and issuer are the same

  Cert Issuer:    Google

Google does now own their own Root CA; it looks like they have an intermediate CA off a GeoTrust root:

google.com cert chain


Algorithm:  sha1RSA

Yeah, that's wrong. Google has been waging war to remove SHA1 from the internet since about 2015: as of January 2017 Google Chrome browser no longer displays the green lock icon for SHA1 certs, and in February 2017 Google researchers demonstrated the first publi collision attack against SHA1. So yeah, there's no way in hell Google would issue themselves a SHA1 cert in 2015 and continue to use it until 2020.

For comparison, the real Google Internet Authority G2 uses SHA-256 With RSA and renews it cert every year and a half (currently valid from May 2017 to Dec 2018).


I would delete that cert from your trust store, and see if anything stops working. Keep running regular virus scans out of fears that your system is already compromised. If that cert (or ones like it) show up in your trust store again, it might be time to wipe your hard drive and re-install the OS.


In response to the extra info you posted:

Subject: CN=Google, O=Authenticode, L=Silicon Valley, C=US

LOL! Yeah, that's completely bogus. Here's how Google actually identifies itself in a certificate:

CN=*.google.com, O=Google Inc, L=Mountain View, ST=California, C=US
  • GeoTrust root uses SHA-1 for Google Internet Authority G2, does it a matter? I can't understand, why antivirus scanners don't detect this certificate as some dangerous. – WallOfBytes Aug 6 '17 at 14:50
  • @WallOfBytes Hmm, good point about GeoTrust using SHA1. That's odd. Do antivirus scanners search your cert store? Is that a thing they do? – Mike Ounsworth Aug 6 '17 at 14:52
  • I don't sure. What software must to detect such security problems? I used DrWeb CureIt, Kaspersky Virus Removal Tool, I also can try to use MBAM. SHA1 used in 2 cases of 3 in certmgr.msc and in google.ru – WallOfBytes Aug 6 '17 at 15:05
  • I don't sure that antivirus scanners check my sert store, so, i posted this question to find out which security software detects and responds to problems like fake serts. – WallOfBytes Aug 6 '17 at 15:11
  • 1
    SHA1 in root certificates is ok and browsers don't warn users about obsolete signature algorithm, because roots use explicit trust. – Crypt32 Aug 6 '17 at 15:57

Looks bad.

This seems to be a bad CA cert. Best to nuke and rebuild your computer.

Edit 1: Just for fun: some digging around.

Some in depth analysis of the contents of that P12 file. Read this only if you like this sort of thing.

Splitting apart the P12 file

Let's have a look at that p12 file and unwrap it:

$ sha256sum.exe cert.p12
c33d12dc723dfb5af945e69dd2af8a475234d3fae779b444bea924dcb816620a *cert.p12

$ openssl pkcs12 -in cert.p12 -out pembundle.pem -password pass:"" -nodes -info
MAC Iteration 2048
MAC verified OK
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Certificate bag
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048

$ csplit -f individual- pembundle.pem '/^Bag Attributes/' '{*}' --elide-empty-files

Now let's look inside and give these objects some nicer names:

$ head individual-0*
==> individual-00 <==
Bag Attributes
    localKeyID: 70 04 3C 28 93 39 60 37 92 DA 92 8F 73 F5 50 86 60 3F BF 27
subject=/C=US/L=Silicon Valley/O=Authenticode/CN=PortableWares
issuer=/C=US/L=Silicon Valley/O=Authenticode/CN=Google

==> individual-01 <==
Bag Attributes: <No Attributes>
subject=/C=US/L=Silicon Valley/O=Authenticode/CN=Google
issuer=/C=US/L=Silicon Valley/O=Authenticode/CN=Google

==> individual-02 <==
Bag Attributes
    localKeyID: 70 04 3C 28 93 39 60 37 92 DA 92 8F 73 F5 50 86 60 3F BF 27
Key Attributes: <No Attributes>

Now that we have an idea what's inside, we can give them proper names. Let's also pump them through openssl to get the full parse out (via the -text parameter) along with the Base64 encoding.

$ cat individual-00 | openssl x509 -text > portablewares.cer

$ cat individual-01 | openssl x509 -text > fakegoogle.cer

$ cat individual-02 | openssl rsa -text > someprivkey.key

What about that privkey?

Now let's see if any of these certs belongs to the privkey:

$ openssl x509 -in portablewares.cer -pubkey | openssl pkey -pubin -pubout -outform der | sha256sum
041b989566cd1174449d4f74dbdeb82b58365a8942936676cbff662998f58fb0 *-

$ openssl pkey -in someprivkey.key -pubout -outform der | sha256sum
041b989566cd1174449d4f74dbdeb82b58365a8942936676cbff662998f58fb0 *-

$ openssl x509 -in fakegoogle.cer -pubkey | openssl pkey -pubin -pubout -outform der | sha256sum
1a0873fe3d24bf8e77775694eaab0940c37ac3d03b3d3b42acb4f600bb4f112f *-

It seems that the privatekey might belong to the "portablewares.cer".

Let's make sure and try to actually sign something with this. (I'm using the method recommended by journalist Hanno Böck to do this.)

$ ./TryAndSignWithThis.sh portablewares.cer someprivkey.key
4a96b377cd177bcece1af794cdcb5144cc9e3f7285e5652b0bc36c4f0551f439 *SignThisBlob.bin
4a96b377cd177bcece1af794cdcb5144cc9e3f7285e5652b0bc36c4f0551f439 *BlobAfterVerify.bin
Files SignThisBlob.bin and BlobAfterVerify.bin are identical

Yup. This privkey belongs to that certificate.

Let's give it a nicer name:

$ mv someprivkey.key portablewares.key

Script Listing

$ cat TryAndSignWithThis.sh
# Usage: TryAndSignWithThis.sh somecert.cert somekey.key
# Adapted from the script by Hanno Böck ( https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html , https://archive.is/RZgXp )
openssl x509 -in $1 -noout -pubkey > TryThisPubkey.pem
dd if=/dev/urandom of=SignThisBlob.bin bs=32 count=1 status=none
openssl rsautl -pkcs -sign -inkey $2 -in SignThisBlob.bin -out BlobWithSignature.bin
openssl rsautl -pkcs -verify -pubin -inkey TryThisPubkey.pem -in BlobWithSignature.bin -out BlobAfterVerify.bin

sha256sum -- SignThisBlob.bin BlobAfterVerify.bin
diff --report-identical-files -- SignThisBlob.bin BlobAfterVerify.bin

rm -- TryThisPubkey.pem SignThisBlob.bin BlobWithSignature.bin BlobAfterVerify.bin

Re. Hexatomium post

Also: This fake google cert is in fact the certificate that was mentioned in the HexAtomium blog post above. He has this available for download. And the pubkey is the same as for our cert.

$ curl -s https://www.trustprobe.com/TI/fake_google.cer | openssl x509 -inform der -pubkey | openssl pkey -pubin -pubout -outform der | sha256sum
1a0873fe3d24bf8e77775694eaab0940c37ac3d03b3d3b42acb4f600bb4f112f *-

Some googling

Let's do some further websearch for these certs/keys

$ openssl x509 -in fakegoogle.cer -outform der | sha1sum
33fcd70343bbe07972d73cdefdeb3c9f4dcefe28 *-

Googling for this turns up nothing too interesting.

$ openssl x509 -in portablewares.cer -outform der | sha1sum
70043c289339603792da928f73f55086603fbf27 *-

Googling for this turns up some VirusTotal scans of a files that are signed with that cert/key. Nice! ->

Now what about that key?

$ openssl rsa -in portablewares.key -outform der | sha1sum
writing RSA key
a8ab813368f9f9ef13d70ea6e2489d0d2f7eb36c *-

Googling for this results in nothing.

Now what if we search for the serial numbers?

$ openssl x509 -in fakegoogle.cer -noout -serial

Googling for this only turns up the Hybrid-Analysis scan again.

$ openssl x509 -in portablewares.cer -noout -serial

This serial number is just bizarre and waves all sorts of red flags.

Full cert/key listing

Full parse outs of the certs/key:

Edit 2.

I actually found a sample EXE file that is signed with that cert/key.

Edit 3.

I don't know what to make of this signtool output. The main signature is obviously fake. (As we found out above.) But what about the signed timestamps? Are they for real? Maybe somebody else can explain this.

C:\> signtool verify /all /pa /v /debug RadioSurePortable_x.x.x_online.paf.exe

Verifying: RadioSurePortable_x.x.x_online.paf.exe

Signature Index: 0 (Primary Signature)
Hash of file (sha1): 148528EE2FDB92441711B3E10760E1D191AD108D

Signing Certificate Chain:
    Issued to: PortableWares
    Issued by: Google
    Expires:   Thu Jul 20 23:05:12 2017
    SHA1 hash: 70043C289339603792DA928F73F55086603FBF27

The signature is timestamped: Sun Oct 04 23:04:08 2015
Timestamp Verified by:
    Issued to: Thawte Timestamping CA
    Issued by: Thawte Timestamping CA
    Expires:   Fri Jan 01 01:59:59 2021
    SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

        Issued to: Symantec Time Stamping Services CA - G2
        Issued by: Thawte Timestamping CA
        Expires:   Thu Dec 31 01:59:59 2020
        SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1

            Issued to: Symantec Time Stamping Services Signer - G4
            Issued by: Symantec Time Stamping Services CA - G2
            Expires:   Wed Dec 30 01:59:59 2020
            SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4

Number of signatures successfully Verified: 0
Number of warnings: 0
Number of errors: 1
SignTool Error: WinVerifyTrust returned error: 0x800B010A
        A certificate chain could not be built to a trusted root authority.
  • I see, the same problem have people, who got Lenovo Superfish, Dell eDellRoot or Comodo PrivDog. There is some advices to use RCC, but how can i trust in 3rd-party proprietary program? A fun fact: Virustotal don't trust in them. – WallOfBytes Aug 6 '17 at 21:45
  • Thanks for so detailed answer! But one little question about sigcheck -tuv. This command must to download a copy of authrootstl.cab or authroot.stl and place it to their directory. But it doesn't do it! How can I be sure of the reliability of the program if it does not perform the function specified in its description? Some sites offer their local copies of these files, but, of course, this is not a safe way to get them. – WallOfBytes Aug 6 '17 at 21:47
  • I'm completely confused. If there is so big security problem, why antivirus scanners ignore them? How many other ways to сompromise my PC i am and my AV don't know? Finally, how to avoid re-infection of my system when i will install all my programs again? Damn. – WallOfBytes Aug 6 '17 at 21:47
  • Found some strange "damaged" intermediate cert named "root agency" (id: 12 e4 09 2d 06 1d 1d 4f 00 8d 61 21 dc 16 64 63, serial number: 06 37 6c 00 aa 00 64 8a 11 cf b8 d4 aa 5c 35 f4), incomprehensible root authority "Dekart" cert (‎6f 09 3a 9d c9 cc c6 09 b3 1f 46 4f 10 48 d0 ce 44 bb 7e c7)... – WallOfBytes Aug 6 '17 at 21:59
  • Wow. That's an impressive amount of digging Stackz! This should be the accepted answer. – Mike Ounsworth Aug 6 '17 at 22:53

If you didn't install the root certificate and the PC is not connected to PC, then the certificate came from a local trusted root certificate cache (in Crypt32.dll library).

By default, only a subset of trusted roots are preinstalled in the MMC. However, when CryptoAPI builds a chain, it checks whether the particular root certificate is stored in the cache. If found, then certificate is copied from Crypt32.dll to certificate store (what you see in MMC). It is expected behavior for MS CryptoAPI and there is no harm in this.

  • Yes, but the other way I can get (potentially malicious/fake) sertificate is hide importing by a program, installed with admin access rights, isn't it? I think, that this is such case. Anyway, a genuine certificate, imported by Microsoft (online or offline) must to pass the test and mustn't be showed in output of sigcheck -tuv. – WallOfBytes Aug 6 '17 at 14:00
  • You need to use certutil -store command in order to examine certificate store from command line. – Crypt32 Aug 6 '17 at 14:04
  • Sorry, i don't understand, how it can help. certutil -store dumps certificate store (my/CA/root) in plain text mode. For interested certificate there isn't information about cert provider and certutil cant' find private key to decrypt. But similar info showed for other certificates. I did certutil -verify -urlfetch. The result added to my question. – WallOfBytes Aug 6 '17 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.