[148204] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] Cryptolocker

daemon@ATHENA.MIT.EDU (Greg Broiles)
Thu Nov 21 21:12:05 2013

X-Original-To: cryptography@metzdowd.com
In-Reply-To: <092C3428-5492-480D-BCEC-AB3AA2E9BDC6@lrw.com>
Date: Thu, 21 Nov 2013 18:08:20 -0800
From: Greg Broiles <gbroiles@gmail.com>
To: cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

--===============1453524880363935749==
Content-Type: multipart/alternative; boundary=e89a8f3b9c23fc09c304ebba7caa

--e89a8f3b9c23fc09c304ebba7caa
Content-Type: text/plain; charset=ISO-8859-1

According to Steve Gibson at https://www.grc.com/sn/sn-427.txt, when
CryptoLocker contacts the central server(s), the servers generate a unique
(per victim) 2048-bit RSA keypair; the public key is sent from the server
to the infected machine. The infected machine generates a random 256 bit
AES key, which is then encrypted with the public key and sent to the
server, and used locally to encrypt the ransomed files. The key stored in
the infected machine's registry is the public half of the RSA key.


On Thu, Nov 21, 2013 at 5:12 PM, Jerry Leichter <leichter@lrw.com> wrote:

> There's some malware making the rounds that applies a technique that's
> been talked about for years:  It (allegedly) generates a public/private key
> pair, sends the private key off to the mother ship, then starts encrypting
> all accessible files.  When it's done enough, it starts demanding money for
> the key to decrypt everything.  One article about it:
>
>
> http://krebsonsecurity.com/2013/11/cryptolocker-crew-ratchets-up-the-ransom/
>
> Nasty piece of work, apparently - it locates and encrypts accessible
> network-mounted disks, so it often encrypts people's backups.
>
> Anyway ... I'll leave the virus analysis and hunting to others.  But
> there's also a crypto question here.  Has anyone seen an analysis of what
> this thing *really* does internally.  Obviously, it will *say* it's using
> all kinds of strong algorithms, but that doesn't mean it actually *is*.
>  (In particular, I'm curious about how they are doing the encryption.
>  Doing bulk encryption in RSA or even using elliptic curves is slow, though
> it might be fast enough for this purpose.  The obvious technique would be
> to generate a random AES key per file, encrypt *it* with the public key and
> store that away, then use AES for bulk encryption.  But I haven't seen any
> hints of a store of such keys anywhere; in fact, there are reports that the
> magic key is stored in one registry entry.
>
> Anyone following this story from the crypto side?
>                                                         -- Jerry
>
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>



-- 
Greg Broiles, JD, LLM Tax
gbroiles@gmail.com (Lists only. Not for confidential communications.)
Legacy Planning Law Group
California Estate Planning Blog: http://www.estateplanblog.com
Certified Specialist- Estate Planning, Trust & Probate Law, California
Board of Legal Specialization

--e89a8f3b9c23fc09c304ebba7caa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">According to Steve Gibson at <a href=3D"https://www.grc.co=
m/sn/sn-427.txt">https://www.grc.com/sn/sn-427.txt</a>, when CryptoLocker c=
ontacts the central server(s), the servers generate a unique (per victim) 2=
048-bit RSA keypair; the public key is sent from the server to the infected=
 machine. The infected machine generates a random 256 bit AES key, which is=
 then encrypted with the public key and sent to the server, and used locall=
y to encrypt the ransomed files. The key stored in the infected machine&#39=
;s registry is the public half of the RSA key. <br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu,=
 Nov 21, 2013 at 5:12 PM, Jerry Leichter <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:leichter@lrw.com" target=3D"_blank">leichter@lrw.com</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">There&#39;s some malware making the rounds t=
hat applies a technique that&#39;s been talked about for years: =A0It (alle=
gedly) generates a public/private key pair, sends the private key off to th=
e mother ship, then starts encrypting all accessible files. =A0When it&#39;=
s done enough, it starts demanding money for the key to decrypt everything.=
 =A0One article about it:<br>

<br>
<a href=3D"http://krebsonsecurity.com/2013/11/cryptolocker-crew-ratchets-up=
-the-ransom/" target=3D"_blank">http://krebsonsecurity.com/2013/11/cryptolo=
cker-crew-ratchets-up-the-ransom/</a><br>
<br>
Nasty piece of work, apparently - it locates and encrypts accessible networ=
k-mounted disks, so it often encrypts people&#39;s backups.<br>
<br>
Anyway ... I&#39;ll leave the virus analysis and hunting to others. =A0But =
there&#39;s also a crypto question here. =A0Has anyone seen an analysis of =
what this thing *really* does internally. =A0Obviously, it will *say* it&#3=
9;s using all kinds of strong algorithms, but that doesn&#39;t mean it actu=
ally *is*. =A0(In particular, I&#39;m curious about how they are doing the =
encryption. =A0Doing bulk encryption in RSA or even using elliptic curves i=
s slow, though it might be fast enough for this purpose. =A0The obvious tec=
hnique would be to generate a random AES key per file, encrypt *it* with th=
e public key and store that away, then use AES for bulk encryption. =A0But =
I haven&#39;t seen any hints of a store of such keys anywhere; in fact, the=
re are reports that the magic key is stored in one registry entry.<br>

<br>
Anyone following this story from the crypto side?<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Jerry<br>
<br>
_______________________________________________<br>
The cryptography mailing list<br>
<a href=3D"mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><=
br>
<a href=3D"http://www.metzdowd.com/mailman/listinfo/cryptography" target=3D=
"_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Greg Broiles, JD, LLM T=
ax<br><a href=3D"mailto:gbroiles@gmail.com" target=3D"_blank">gbroiles@gmai=
l.com</a> (Lists only. Not for confidential communications.)<br>Legacy Plan=
ning Law Group<br>
California Estate Planning Blog: <a href=3D"http://www.estateplanblog.com" =
target=3D"_blank">http://www.estateplanblog.com</a><br>Certified Specialist=
- Estate Planning, Trust &amp; Probate Law, California Board of Legal Speci=
alization
</div>

--e89a8f3b9c23fc09c304ebba7caa--

--===============1453524880363935749==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============1453524880363935749==--

home help back first fref pref prev next nref lref last post