www.download.windowsupdate.com & crl.verisign.com - ongoing research

[Pattern_Juggled]

{direct link: cryptostorm.ch/strangeness}
{this thread has been split from the Kebrum analytics thread, to improve access and clarity of organization ~admin}


Here's some unpolished data relating to an odd file format I found during this analysis:

The file in question is authroot.stl

Here's one of the few references I found on this format:

Certificate Trust List (.stl)

Certificate Trust List is generally used during SSL/TLS handshake when Client Certificate Authentication comes in to picture. During SSL Handshake the server sends the client the list of the distinguished CA names that it supports as a part of Server Hello message. The Client uses this list to draw up a list of client certificates that is issued by any of the CA’s in the list i.e., only those client certificates which are issued by any of the CA’s in the CTL will be populated. Below is an example of how a CTL looks like

Here's the file that came out of the unpacking of binaries:

kebrum.zip

(112.74 KiB) Downloaded 2234 times

The pre-compressed version is nearly 140kB long. Dunno, I'm no expert but that seems a bit big given the usage framework for which .stl is designed...

Cheers,

~ pj

[Pattern_Juggled]

This additional information regarding the authroot.stl issue has been generously provided by @wneessen (and is echoed over from pastebin):

• - CryptoAPI2 fetches a MS signed CAB file from ctldl.windowsupdate.com (Akami hosted)
  
  - CryptoAPI2 extracts the CAB and checks the signature. CAB file holds a list of authorized CAs/Root certs, that Windows will allow auto-fechting/updating for
  
  - If you open a website that Windows doesn't have a valid root cert for, that CA/Root cert will be looked up from the list (which is cached localy as far as I understood)
  
  - If the CA/Root cert is in that list, CryptoAPI2 will fetch that root certificate via http:// (yes, http not https) from ctldl.windowsupdate.com; the exact URL looks like this:
  

  Code: Select all

  http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/<SKI of root cert>.crt

  - If the DL is corrupt or times out (5 secs. or so), nothing happens and the process is not reproduced unless you restart your browser and open that website again
  
  - If DL succeeds, some validation mechanism checks the SKI and fingerprint of the certificate (I wasn't able to figure out, what exactly happens, but I couldn't just present a different root certificate. Windows wouldn't accept this).
  
  - If validation succeeds, the root cert is installed into the local trusted store

The process can be blocked either by disabling it via GPO (on Windows 8 via Registry Entry) or by pointing DNS for ctldl.windowsupdate.com to 127.0.0.1/blocking requests to ctldl.windowsupdate.com

[Pattern_Juggled]

If you open a website that Windows doesn't have a valid root cert for, that CA/Root cert will be looked up from the list (which is cached localy as far as I understood)

I'm still working to integrate the "Certificate Trust List" into this process, because that's the one that actually gets pulled during (for example) the process of executing the Kebrum installation binaries, above.

From the pcaps, here's what happens (apart from the pulling of the 'authroot.txt' file, which is outlined in full above:

1. A process within the instantiated installer initiates a DNS resolution query via...

Code: Select all

User Datagram Protocol, Src Port: blackjack (1025), Dst Port: domain (53)

2. DNS query syntax is as follows:

Code: Select all

95	15.546665	192.168.56.101	192.168.56.1	DNS	76	Standard query 0x6bfc  A crl.verisign.com

3. primary nameserver indicates a CNAME alias to:

Code: Select all

crl.ws.symantec.com.edgekey.net

4. that hostname, in turn, is a CNAME alias to:

Code: Select all

e6845.ce.akamaiedge.net

5. That, in turn, resolves via A Record to:

Code: Select all

23.5.245.163

6. HTTP request of:

Code: Select all

GET /msdownload/update/v3/static/trustedr/en/authrootstl.cab HTTP/1.1\r\n

Here's a screenshot of the underlying wireshark'd packet flow:

Which IP address - 23.5.245.163 - is indeed located in an Akamai-controlled block. It's also an IP address that is associated with a mix of (Verisign-affiliated, as Symantic now owns GeoTrust, Thawte, RapidSSL, and Verisign CA businesses) hostnsames that have resolved to it in the last 18 months alone...

VirusTotal's passive DNS only stores address records. The following domains resolved to the given IP address.

2015-01-29 e6845.ce.akamaiedge.net
2014-11-20 t.symcb.com
2014-07-19 st.symcb.com
2014-07-08 ga.symcb.com
2014-07-07 ica-crl.digitalcertvalidation.com
2014-07-07 orgc3-crl.verisign.com
2014-07-07 ssp-sia.verisign.com
2014-07-06 td.symcb.com
2014-07-05 svr-rapidssl-crl.rapidssl.com
2014-07-04 gb.symcb.com
2014-07-04 tb.symcb.com
2014-07-04 tc.symcb.com
2014-07-02 tj.symcb.com
2014-07-01 strato-crl.digitalcertvalidation.com
2014-06-30 th.symcb.com
2014-06-28 ica-aia.digitalcertvalidation.com
2014-06-25 crl.ws.symantec.com
2014-06-05 a23-5-245-163.deploy.static.akamaitechnologies.com
2014-05-22 a23-5-245-163.deploy.akamaitechnologies.com
2014-05-16 svrintl-t1-aia.verisign.com

An awful lot of nasty stuff has been communicating with that specific IP address recently (although it's of course quite possible that all that badware is simply doing routine background Windows cert-update stuff entirely unrelated to any badness, in which case this exact pattern would appear but would indicate nothing improper on the part of ):

Latest files submitted to VirusTotal that are detected by one or more antivirus solutions and communicate with the IP address provided when executed in a sandboxed environment.

13/56 2015-02-26 15:41:56 fd54cc6001a6dd809672dac15d97890a8738bcb701680210879acb79fed7f0ee
37/47 2013-05-21 23:42:34 97d56e716e29f566bd227c17f1531b11f3f66678bb53e156f7e66b66d1038c8a
3/47 2013-05-21 23:31:52 be0bb1db750c0a7c29d3db1af20b4b6fc407bf01a901a7d699006657717f8853
3/47 2013-05-21 23:31:42 ac0c23dfaf427190de25e915ad3f30da85753e60d8b91cef0dcad40854f0753b
5/47 2013-05-21 23:24:33 7e4be4daf139b3c79a532e02fae4810ea9408a3598050b94590ed67811e649dc
5/47 2013-05-21 23:22:28 617ade6180c64f8dc07ad38847f0749520f13e8e74c5a4a59489f716525b6c08
5/46 2013-05-21 23:19:51 20c0ab864a4338b714c299716fe9fc488768d01a1fad9fee6c6288e2536eec02
36/47 2013-05-21 23:17:11 ac4bffc0b2c321db9bc516acf8371cfc311d5ee3f25100af30869a5fc71c22d1
3/47 2013-05-21 23:16:29 1c096e8eb3af484fd9667bbb3c626eb1db44a0fad0fa1e67b7d1c8c7ef5aa7c4
35/46 2013-05-21 22:42:48 e2ec948c1bb9bb08f5608b6c93484bf7b26cc673c130ed1403491cf27ea5148a
36/47 2013-05-21 22:41:23 8eae3d417cd295581be4648d811cce0801e35b285f2243b9818983aa0d892d01
38/47 2013-05-21 21:58:54 1cd07c608c6b046db532f17f1f24654291fe762eea8f437b92171bbcce460da9
3/47 2013-05-21 21:55:29 b709088c6b681912a7e4a0c8e28acf51e6c410f3d9223b8b2056a1e3a0dcfef9
8/47 2013-05-21 14:06:12 636898c5358a35856e37a6f22ea1f840cd7343e71e64df98fb08260029513dc7
8/47 2013-05-19 00:36:08 469fbe016536dbb42266f38147dd07578a21e048217d84b17c9b4f1cc0fd7151
1/47 2013-05-18 15:34:09 f968f6102333afe793d8cce85d35b89a77130e182e6dc473b7e51f5971dcf228
32/46 2013-05-16 09:16:54 60a9e49e8007429a4bdd6a52d9541a38662d241f2653c2ed010f280e92658e7b
1/46 2013-05-15 04:43:19 52070c17d639df3fd921bb1d0c52c13220aa9e84fe1dc20ca7a8eab53712ac0b

I still don't understand what purpose the complex welter of subhostnames serves in this: wouldn't resolving crl.verisign.com to 23.5.245.163 directly be more secure, less complex, and easier to administer? I say that with an awareness of these things given our use of similar layered hostname-IP resolver pools (our Hostname Assignment Framework), so I'm as much curious as anything else - assuming it's legitimate, then there's some reason they add that extra layer of arbitrary subhostnames into the process flow). Of course, I do understand the benefits of putting akamai in as one lookup layer... sorta. Only not really.

Do you really want to outsource to an amorphous cloud-based CDN the delivery of... CRLs? Or in this case CTLs (certificate trust lists)? These aren't exactly multi-gigabyte streaming video files. They don't change every 5 minutes (do they?), and they aren't subjected to enormous pressure to cut every millisecond from RTT pingtimes (are they?). They're compact, relatively static files that are extremely - extremely! - security-relevant given that they control what root certs are or are not injected silently into the windows trust store locally on countless millions of PCs.

Subvert that process, and you've got one bad-assed exploit avenue. You can now do things with those PCs unimaginable without that subversion... like, ooooh, MiTM all of their https sessions invisibly, without any hint it's going on. At massive scale.

It would seem to me, naive as I am, that Symantec/Verisign/Thawte Corporation would - given that they are a Certificate Authority - want to actually manage the process of controlling and delivering those CRLs and CDLs themselves, in-house, firsthand. Managed closely, with audit trails and accountability. Maybe a hostname like svrintl-t1-aia.verisign.com helps that, via some internal tracking process. Seems alot of complexity just asking to be broken, to my way of thinking - but then again my world includes a different mix than that of the folks at Symantec who likely designed this.

Finally, for this point anyhow, I'm really not sure how one would do an audit trail given that this is Robtex's graphical representation of what happens to get a request from a Windows machine wanting a CRL (version 3, which dates back to 2006... because of course, that makes sense?) and asking the DNS system to give it an IP address to which packets can be sent:

. . .

Anyway, so presently we see that crl.verisign.com resolves via a somewhat complex, multi-step process, to IP address 23.5.245.163.

That's not always been the case; a look back through records shows that these mappings have been noted as in effect at in the past 18 months:

2014-07-29 23.9.85.163
2014-07-19 23.7.69.163
2014-06-26 23.5.5.163
2014-05-27 23.9.117.163
2014-05-21 23.13.165.163
2014-04-17 23.5.245.163
2014-03-16 23.50.69.163
2014-02-13 23.64.165.163
2013-10-30 23.49.133.163
2013-10-19 23.61.181.163
2013-10-17 23.60.133.163
2013-10-15 23.61.69.163
2013-10-07 23.65.5.163
2013-09-26 23.4.53.163
2013-09-18 23.35.165.163
2013-08-23 23.38.85.163
2013-08-20 23.53.181.163
2013-08-17 2.22.133.163
2013-08-17 23.43.133.163
2013-08-16 23.36.149.163

Which is twenty different IPs - all ending in 163, what are the chances? - since August of 2013. So each IP lasted less than a month, on average. They are:

• 23.7.69.163
  23.5.5.163
  23.9.117.163
  23.13.165.163
  23.5.245.163
  23.5.245.163
  23.50.69.163
  23.64.165.163
  23.49.133.163
  23.61.181.163
  23.60.133.163
  23.61.69.163
  23.65.5.163
  23.4.53.163
  23.35.165.163
  23.38.85.163
  23.53.181.163
  2.22.133.163
  23.43.133.163
  23.36.149.163

I haven't looked into all of these yet - they should all cleanly WHOIS to either Akamai, or Symantec... right?

I'd have more confidence - and perhaps not include the question mark - if stuff like this didn't show up in my research on this post. First, malware that explictly calls some of these verisign.com CRL hostnames:

Second, this anomaly when checking the WHOIS records for crl.verisign.com (yes, doing WHOIS lookups for subdomains is a bit nonstandard, but it can still provide hints of interesting things):

This, I don't even remember where I screenshotted it tbh, so I'm sticking it here to remind myself (or anyone else curious) to follow up and see what's in the file referenced. That version is also very old, isn't it?

Oh, and here's the "CSL" that comes out of that cab at the "windowsupdate.com" URL (which itself cascades, via a series of DNS zone file records returned in response to the initial resolver request, from CNAME www.download.windowsupdate.com to CNAME www.download.windowsupdate.nsatc.net - both of which are subdomains, not http-based resources... which is not supposed to be possible, is it? - to CNAME download.windowsupdate.com.edgesuite.net to CNAME a767.g.akamai.net which is actually - woohoo! - a real A Record listing IP address of 184.25.56.93, which is the actual IP address that actually provided the below-attached file to the test run we did of this installer - pulled out of the full-payload pcaps gathered during the process) discussed earlier in this thread...

authrootstl.cab

(56.24 KiB) Downloaded 2355 times

That, in turn, unpacks to this .stl:

authroot.stl

(132.73 KiB) Downloaded 2347 times

..which, and you'll get used to reading this alot, I've not been smart enough to unpack using any tool I can find (though I'm not a Windows native, so perhaps it'll be easy for others - I hope so!). It's pretty big for a "certificate trust list," in any case. Not a CRL, remember... a trust list.

(incidentally, IP address 184.25.56.93 a little odd in that it's been the answer to DNS resolution requests for domains nextgennbn.gov.sg, abercrombie.com, caranddriver.com, rediff.com, mashable.com, a184-25-56-93.deploy.static.akamaitechnologies.com, and nfl.com... all since December of 2014. That's quite a record! Now Akamai is a CDN, of course, so they can remap IPs to client domains as often as they want, and perhaps they've been fast-fluxing this stuff in the last few months because, ummm... something something. Because of some obvious corporate reason I'm not smart enough to figure out by myself, obviously.)


Anyway, authroot.txt & authroot.stl both come down as confirmed by pcaps. They come from deep within Akamai, via a series of CNAME redirects that's pretty impressive. They end up at IP addresses that are impressively ecumenical in the sorts of domains (and subdomains) to which they'll answer.

And it's all related to the authority to inject root certificates into the Windows trust store arbitrarily, without any approval (or even admin access) from the user required. Which is to say: figure a way to hijack, even temporarily or ephemerally, that process and you've got the door open to root cert inserts at an unmatched scale... it makes Superfish seem a drop in the bucket, in comparison.

Has someone managed that trick? Is there evidence of it in these files? I honestly don't know. Personally, I can't rule it out based on the data I've collated thus far... nor can I say I've got the proverbial smoking gun that it has taken place (or is taking place). Additionally, it fails to pass my tech-world sniff test... admittedly not terribly objective, and far from a perfect metric: I'm a bit jaded after years of network security front lines & yes I have been known to see ghosts in the shadows when there's only shadows.

Even so, this is all... so terribly ripe for exploitation. Were it my job to figure out how to inject root certs into alot of Win machines without causing a fuss, I'd sure as heck be checking this whole complex, unstable, multi-entity, http-encoded mess really closely for any little corners to pry up and use along the way. That smells like ripe ground for exploits to me... and I've had enough time around exploits to have a half-decent gut sense on that sort of thing, albeit far from perfect.


Whatever the case, it's fascinating. It's very instructive, in terms of the layering of DNS and CA-based certification that produces certificates in the local trust store, and thus the magical "green lock in the browser" that means https is secure. Only, of course, it doesn't... not at all.

Not yet, anyhow

Cheers,

~ pj


edited to add: these are recently-enumerated examples of malware that have the hostname "crl.verisign.com" embedded in their post-compile strings somewhere; as noted before, that could simply be a result of them including routine CRL administrative matters in pre-compile code that comes through as binaries and thus pops up as this kind of list (indeed, on the same virustotal page one can see a list of non-flagged binaries that include this URL in strings but haven't raised red flags on virus scanning sites - which may or may not indicate they're clean files, tbh)... but it's something I'd be remiss not to at least note. I've not gone to them and checked each one to see if they'd have a legitimate reason to be calling a verisign CRL hostname as part of their compiled-in duties...

Latest files that are detected by at least one antivirus solution and embed URL pattern strings with the domain provided.

25/54 7b28837f16a9941b979c4e4031cb214ec67d29097e6d26f03fe96b0d9e101568
1/54 8d81c92d1d02e9aa0027dc18b0022b89639bb74dbef43afec398645d9d80b191
44/54 9bb200bc3259cc724009d923c2ca0845c652f71e5c50bce2894311f57434872b
49/53 5158b19ba52311bd8a888323507e3d43119eda32630d387a8cad4b3ac50a7246
48/54 451d822ddab6e1642d20c248fbbb27efcb5eb62f78e52279b51709898c765244
4/54 3a67623c9f0038feefd667bb56ce7a7ec0e6d6ba292fadca02d75105b9a8b6df
46/53 a67841ba3adbdeceb65a6538d637ba1a48e7edb0fdc5679e1f0c285a91aa314f
14/54 f3ef72da9bf5dc1752abf8ddfc8505ce52d7cf5e963783c4bb30e4f065651dd9
2/53 f97293c29716811a30852b6186c65d8c1d8632b2f223a8cf70035c8530281de3
43/54 54c259ac27a886e79ab2dd8eb9c6bad3d8879084e3e20419b09c1cdcaad6c5e2
47/53 f79ef0189485f6e24d14d9b705cb3cab0dc01417adaabca6ea9f858b84e7d8ff
45/53 ab3e371c3ad484954bd88a5ceee2ce9c957bddbc08a292517823419b571c8687
42/53 e1276ec2f6b0c18e4878b294f0e4b6fd6320599942b5e8fd9afa1f1d13f60665
43/54 b70e6130cda1b9ac32237f8f07d03434ba4e9caa7e1eacaca58a1886bb708ef9
50/54 9571818ee19cbcb2a9dd0241e0e5a1f33a539b2dd576ae55124b5466ac29ecc6
40/52 ce984a3033b9c3507ef0e15b9d9beaf6caedaa9ae9c8e802a861fa26a2a31023
47/53 33d4e518a57f1bacdb1dc8c6e22ce02e7fe62fe7e011b6ecd79151ec451d346c
48/53 c83deebaa0e4ff771046423c77133b61a7ff655a6aa6c195f813b429f6c8f6f1
1/50 67ce83ac8b3cb2792222c58cf068f4808ff4ed9b0a44a13ee8b229e50e2632e3
3/54 52634de789cc5ba63a445e186d7c888a0032dd64a4609ca3970412f5d7c270db
43/54 c0fca0132257134d0f403123cab2e2fcff07dd94eaf49a9a77f2f0b6c74a28c2
48/53 7a0ba519a5d14564c3628935fa662f7f73ea0d91546d6d34bab2c38e369addd6
43/54 943ff1eaea992e80ba99fa4283f2247464cec40398e2c239fde9b51e80af25e6
42/53 04710d9d767e6cf262cc4777d04df13b6b9375645dbb053b29faad4ad2007a03
43/54 f1419e115a60ab4a9525ebe5ae51e3e1611a8b328bc51bbf284dd4e73e2e6663
42/53 b769b22fe24bbe254787b4b50ce0a5981a7f75c4cab537d40117518b714a5120
26/54 302ae701ece4e031afa4428e86957fa56574dfdb7a496951df30cc97e64b4178
43/54 75ca5a6d0b08b31f92484bf83dd728a7487182bd353119a06115fd886834931f
43/54 30feaf83619509479e9e17707b04d8d30915b7764153821f05ce6abdcca1e339
41/54 1ddaaf94c06d4fc974e43e859e6ec6b15f30aede27454dab2b79dff2a722a8e6
48/54 9c66ab11b944b96702ded52b553685aa9cd56f1738e142f9eb1475104829391e
43/54 7ce554c9e1bf31acdf06e1b5abf5f3aeec50ea33bd96fa2538dc6e4984cca571
43/54 a480346105b3d831cb5be816de3cd6c834798757ef002e609d80330b0a6f4e59
1/54 b9f35917c3593b36c4bb8930e9c589354063b7612338022dba506d60a8a8d769
24/54 911f1f70155219e648155982b12c019a332cf21ea361aa3b84b45745c9661445
42/54 53cb74f7605efd4017258bbe8001867ef1bc4a5de063e064aef5c959dab16fac
49/54 dce782d51f265990f5ace8abd0f934b25a9389c1a7864c3ed8046a4e1e2d8fd8
43/54 054fc4368316f11bc17c998c33240afc21073f7077e478f5e6d8788b153847aa
46/54 1af8514edab296c3fc4b91c814ea9c08e2aca63c4cc60018451e59fc6ed83443
48/54 f53c9effd57e9b5a1f0b35c4614cabfe1a134ddded29d90b30d645bf74cf4211
26/54 49c64d18629e9efad31c5c9a77ce6df53c68b1998dbbdef0e2fadb08413fcc41
42/54 6a73d6fed9247d8bf343a03284ec8d3632a661ea690d9faf3a760956a0cd3fd0
27/54 6eec0856dba595b0d8454755e6b2b799dbef051e7be443ec52258d64245f53d5
48/54 49c5d6e790a7b1f17ed0554a6fa79b49e54002bc5a6a809a173ca060089376be
48/54 3b4df336d1244d84f42382b52c2cf159a5a30732cff8ab48d645ebee23b36aa9
43/54 7e374e4b1c1d31c4cf4a1da35f50cd238431e027333e88548aecc5141578e71b
50/54 b86d700d317ae62185907bbc7e1958e96db7b9d39042c34117f239bfc6f50df6
49/54 dea017e8333cb57fd9150fb1cfb81353ef701801dfe596d5fa76dba77046c9db
48/54 e66fa6d49c2e172b2d13490da56e3878b886f999f7e3478b46f77a6c4ee2cb3e
37/48 aaef1045dbd77cdbd13a11e73fe038c0733e80ec44b218dc7e8cd3958fcb98b8
47/54 c3b8ed5e5856d228c2a2c2d8eb8d8e07c225e2a0180c7723364aa66f7b8e5140
43/54 8dbd3adf01b60108be9a7e2f1c5f75e91625a6181d8064aea52a156bea8b1b5f
42/53 a77307b8499051f90a6922cce8007ad2af3c698b7d48c2ad5141d6034d478640
43/54 4e2698f38fa92732971ee9aa5634b4a89703be1b5509b5d82cb67ee6482850de
43/54 4112278766b225b7960e130cb92c7d1e5ab0197170b8fa85409fc760caeb0fb7
48/54 a36cc9fe6d358901f805d62dc955a6b3f47b71419f830fd80808acb51f9d1558
43/54 ba8d94ad5e143749d0f5c9455e9c9a1bc82a0449c61c3c65b324afd10f15110d
49/54 179f1bfea87c2dae771ebc4e59c36fae31c40df74b8b6b7c5db9072015d31a05
1/54 c48f3e169ccb553ea237901902994c685ff28e3e6b96f9d2018ac795555f5104
12/54 02f15fd9714b845e852df64dc014afca416c0c449767d3f04e597dd2c38195fc
8/54 a46b8a3e78e0103a50b7d07df02123e485f65070d39912bf5e3f231037e826c2
1/54 4b84963b7be73176d3df04b6a96c65bcd9982de1e71ceba879a8227681baac52
1/54 29a6e5fd43402f7ab9e1c2fd782524ecd6d9b2eeef84227b35b6ab7f6e312480
1/54 612dbd56d7bc19919a3a89a45377066883a074fce9de7847fdeff04e88564f95
1/54 020d79d8b6f89b6f602917cda563cd3ebe39fdf0e70a07dd222e0a976d9b9bfb
1/54 5634ac6be67187c5d6e8b5c03ed89944ecb06bf32d705db2e11cfc7c0191fadf
8/54 9aacf3df6b5227078f1b2d2da1077d59898f6e28a038e78508406ba1da9e2d97
2/53 1bd433fcc02007616709e06c4bd14ee252eaa16b945a5f3221fed0513ae2dc94
6/53 03cdfffebcb2a5861f19fb4cbeb64b522d141ec5979f438a424d004ca2bc3224
9/54 6fd94fe238e8b4187090cdc5436f483d62f898290c305f75ec7e4d92b26b0156
5/54 b8809fe358726bd7b5a0e87d93ef8fc4ba2fec9d2fdd300bd048bc684cc8dbf5
5/54 00de56d51b7be49f42126687862661f454b4141088e1193770f4bcd32e5807ef
3/54 cb20843d2ad8679739e62d020572b3ef77d69dee10a1e26a2fd426d468ebfbe7
2/54 981dffac632f107320b2df9b092833d9ce2e421e5e4731b940e5d58ff8d1007a
1/54 1352c216f06dd81768af0e8b0a99ab222465917354acd81381890f81aeea347c
6/54 c35b56bc5eea3698f0b9f37c04db8f063f02c16261b9a005500d03dad6d4a11d
2/53 885e69834195bcce39b279d4f401d51095c3dec22b6be85a6987b986dffebeb7
1/54 42c4a94bb75b0b5576e1d086f823f0e08a279d38c1b3edc537670540a802342d
5/54 bc14862f14f8dd5f6a05e19eefa21a51bbe5b5b3acb1ca610dfa783b1a2e5fdb
3/54 de4a6b5a38099888c1888c0b314fa980b1229e6f3783e65bb9d8f9c6937bc236
2/53 be7b1e4eadbba0986179efdd8e82c87d90b226cf006991d4ca3f2eab86f1bc47
5/54 5938037f046420fbaddda64e82fb370b165796ce13e52a1ca2ea7595bac655d9
5/53 a45f52e586c2e6e5700b5db2bf34fd5bf8a698367c881af2b08dac10bc146d35
1/53 92190daeff3c7d84a9038abcba3cdbebbf087d0cdc5c5415adddbb448cfbd49a
5/53 ae90488a1702b4149755432bd19865b37bb43d9bbd881c468a46e7b958405814
2/53 6243230c2fa78ef681d425c5a542cba1111f162c0b758dd77ac9b90d45fa7ac8
4/53 3fded5ee5de03c5d55226b1c141fed9997b2c1af71da23446ae6d68b8ff41ab9
5/53 d047016811cd780dfd5b22eef5c1f37f7eec836ebd909a25e63eb6b7a1dce3b0
2/53 0307b4f42bf05f5acf89f33aa0a3d3437a7fe50b26ebaea1fc4c4ee77f2ab73d
6/53 072807a177b1150e34f2a8c09a78ed5710bc05414d3614b11b44b9a488e4e6eb
4/53 8d2795552f37adeb62a9891948346b8ef9c2a9321d77223dd43a7c108186cd94
5/51 80203119554176f7c911bc79046d9de5596ee7e7c6abdca4c0ceaa7c391066ce
10/55 41f2899c34776ca8bba876e6e0f0874d9a333a4340dbaf5eef31d5fff939cbe5
12/55 8b5ef37d01165498859dd83f752a6e8cba514ace82b1477e58b0d1fa374e3891
1/55 205aae8464fc05c60c26d8711a782ee456dc3bed2da5ae93535462ae459de674
1/55 12bf51608bd95c8cc948129c7fbb9679eb917ea7bc04f49dd3dd9108c481feb8
5/54 22b8e6c5d308247c1a6300e5f53468faceee1bac87cde53925bd8d324ca188fa
3/55 b741a4dcf2bc703459652e8f5c5c4344dc7506564b8924dacfa2c4804a2da96a
21/55 5e5bf94f225bb7b4d12f6a6416ee078ef69806aa7d6d3c79d295da61b1762bd9
20/55 06334b6500d90d283d36cb1eebd3bb2ef02b37f439d3cd4ed6ab2195ac5764f3

[Pattern_Juggled]

Looks like the two ends of the bridge are coming closer together.

Here's a confirmation from Malware Must Die that the hostname crl.comodoca.com is used to deliver a payload 'EssentialSSLCA.crl' - which then gets installed into the trust store, which then... it's quite a chain, isn't it?

This is a step in the process of the functioning of the Upatre trojan downloader - which in turn was (is?) a part of the P2P/Gameover family of botnet agents. So that fills in one more piece.

added: take a single step deeper into the P2P/Gameover botnet forensics and you run into this:

Well, how very interesting. Black Lotus is very, very closely affiliated with a particular VPN company most folks will know by name. What are the chances, eh? All those ISPs all around the world, and two wires cross right down in Texas under the name Black Lotus. Quite a coincidence, indeed.


Still digging...

Cheers,

~ pj

[Pattern_Juggled]

A colleague pointed out a long thread on Microsoft's TechNet site, discussing the http://www.download.windowsupdate.com host and the files it serves. Here's one sample post, from 2009:

THIS SOLVED MY PROBLEM
downloaded & installed this file.....

http://www.download.windowsupdate.com/m ... ootstl.cab

but check the error log in your event viewer... this was my message

Failed extract of third-party root list from auto update cab at: <http://www.download.windowsupdate.com/m ... ootstl.cab> with error: The data is invalid.
.
Log Name: Application
Source: CAPI2

and the name of the file in the temp folder which caused the problem was tmp9ccc.vbs

i also faced other errors.... 513 and 1002

check your services...... the properties of each service

i guess all programs mentioned in the dependency tap should be on automatic

http://download.microsoft.com/download/ ... rvices.doc

There's ample data in the thread to dig into, for those following along. I'll be posting more of my own summary analyses, as time allows.

Cheers,

~ pj

[Pattern_Juggled]

Here's a search query on the "social" side of TechNet that turns up a vast pool of questions relating to this hostname; I've only just begun reading, but wanted to post out the full search so others have easy access meanwhile, as well:

https://social.technet.microsoft.com/Fo ... update.com

Cheers,

~ pj

[marzametal]

23.0.0.0 - 23.15.255.255 Akamai block
23.32.0.0 - 23.67.255.255 Akamai block
2.22.128.0 - 2.22.143.255 Akamai block

Working on STL extraction...

List of predefined items that have been signed by a trusted entity; may consist of a list of filenames or a list of certificates; each item in the list has been approved by the signing entity.

Certificate trust lists (CTLs) are used by Microsoft IIS to store trusted websites and other addresses that require a secure connection.

I am limited... I use Windows 7 Home Premium, if I had Professional or higher, I could go further! Sorry PJ.
Stopping short of installing Windows Server 2008 RC2, or upgrading to W7 Professional so I can make use of Group Policy Editor (one can be custom-injected into Home Premium, but its reach compared to Professional is quite limited), I'm down for the count mate. From what I saw, there were a hell of a lot of certificates in there, all languages...

[marzametal]

Ran it in a sandbox, right clicked to install "CTL"...
rundll32.exe kicked up a fuss, wanted to talk to 23.63.99.202 (Akamai)...

According to an anti-executable...
command line switch - "C:\Windows\system32\rundll32.exe" cryptext.dll,CryptExtOpenCTL D:\Downloaded\authroot.stl
digital signature - Unknown
file publisher - Microsoft Corporation

V1, V2, V3... WTH!

[Pattern_Juggled]

{cross-posted to twitter ~admin}

Ran it in a sandbox, right clicked to install "CTL"...
rundll32.exe kicked up a fuss, wanted to talk to 23.63.99.202 (Akamai)...

According to an anti-executable...
command line switch - "C:\Windows\system32\rundll32.exe" cryptext.dll,CryptExtOpenCTL D:\Downloaded\authroot.stl
digital signature - Unknown
file publisher - Microsoft Corporation

ctl01.jpg

Ok, so if the CTL is genuine it'll have a bunch of certificates in it that Windows can grab and assume are good/trusted... so merely seeing a bunch of certs in there isn't an automatic red flag.

However, from what little I can see in those screencaps, they don't look like the trusted root certs that are legit. Edited: looked again, aaaah... that's the cert that signed the CTL itself. Yikes. That's a fishycert, for sure. Not a good sign...

Can you dump the certs out of the file? They'll be in PEM or DER format, afaik, or worst-case Windows versions of them which are easy to convert.

And yes, those IPs all resolve to Akamai blocks, which again is at least surface-level legitimate: Microsoft does use Akamai's CDN to distribute some (or all?) Windows Update files... which as I said above, seems unwise to me, but what do I know of such things as managing Windows update production requirements? Not much, honestly.

That said, those IPs are the destination of resolution for some decidedly non-Windows and most likely non-legitimate domain names in time windows right up against when they show up as "legitimate" resolver answers for this windowsupdate hostname... and those IPs sure do end up serving alot of verified malware in those close time windows too.

My working hypothesis right now, which may be total bunk, is that there's a trick using AAAA/IP6 DNS lookups that enables this redirect trick. It's come up a few times in related research, and it makes sense: IP6 resolver pathways are preferred by most modern browsers, so if you can jump the AAAA records and get traffic headed to your machine, you're in good shape.

Note that all of the analysis in this thread is solely IP4-based. That's myopic. What's happening in IP6-space? I'm running off machines - indeed, the entire cryptostorm network - that's got IP6 hard-disabled, so I'm seeing at best a partial picture here. Most of the world will be IP6-active, and that presents some new angles to consider.

Cheers,

~ pj

[marzametal]

I'll try and dump them PJ.. worst case scenario, I will load up a VM for Windows Server. I didn't see any option to dump when I took the screenshots. It was all read only.

[Pattern_Juggled]

Fraudulent issued certificates

The following list of Common Names in certificates are presumed to be generated by the attacker(s):
...
*.windowsupdate.com (3)
...

[cryptostorm_ops]

Well, looks like we weren't wrong about this, after all...

Full paper citation available here.

[Fermi]

Direct link: crysys.hu/skywiper/skywiper.pdf


{direct file access ~admin}

skywiper.pdf

(645.34 KiB) Downloaded 2066 times

/Fermi

[marzametal]

http://www.download.windowsupdate.com is a dodgy one... more so now than ever before due to the release of Windows 10. The long list of DNS addresses that Windows calls out to also contains the above address. I doubt I will go to W10 any time soon; I would much rather stick with W7 or just swap to Linux (after I buy some proper equipment like a 2nd rig and a flashable router).

My testing on W7 did silence a hell of a lot of DNS callouts, but there was one that I could not... yep, you guessed it; the one mentioned above. I included methods such as:

• hexing out hardcoded addresses in DNSapi.dll for both Windows/system x86 and x64 folders,

• employing lil' apps like PeerBlock to complement anti-MS and anti-Windows firewall rules,

• disabling a buttload of Scheduled Tasks and Windows Services (watch out for Software Protection and SPP Notification - if set to disabled or manual will turn your legit Windows install into a pirated one),

• HOST file population,

• converting callout address to CIDR and inputting them into outbound block rules for the 3 Windows Services mentioned below,

• among others...

Consider the above a lesson in idiocy; trying to circumvent callouts on the system you are using by installing apps and mods and tweaks on said system while trying to silence it. Ummmm, dickhead much? Mind you, it was for educational purposes so yeah, I don't mind taking the hit to pride. I managed to track down the callouts to 1 of 3 services (Network Location Awareness, Cryptographic Services, DNS Cache). I've had trouble disabling DNS Cache while maintaining a live browsing experience, so kept it on. Disabling NLA kills the Internet and I doubt I want to much around with Crypto stuff...

The only band-aid solution I could get to work was to use a program called Acryclic DNS Proxy, which provides wildcard support for HOSTS file. So in laymens terms, to nerf MS and Windows, simply attach *microsoft*, *windowsupdate* and *msftncsi* (this one pings DNS for net condition status) to the Acrylic HOSTS file and it's done. This can be extended to other stuff like *google* or 1e100.net, and *facebook* etc...

[Pattern_Juggled]

http://www.download.windowsupdate.com is a dodgy one... more so now than ever before due to the release of Windows 10. The long list of DNS addresses that Windows calls out to also contains the above address.

Keeping in mind that this hostname has been formally tied (per above posts) to APT-class malware command-&-control, that's a pretty worrisome thing to see. Though I'm a month late in commenting, do you perhaps have more data on this finding?

I've my own run-in with it recently, when researching a CRL - ocsp.thawte.com - that's showing up in certs but throws weird errors when contacted for testing (more on that in another thread, perhaps, someday... tl;dr is that CRLs are shady beyond belief, and best blocked as we do with CRLblock, network, wide).

In a technet thread that mentions this particular shady CRL, I found the following post, by "vgerNYC"...

These Windows 7 Home Edition PC's people's home computers? If they are, they really should get into the practice of going to Windows Update every month.

If anything install the following update on these other troublesome computers.

Code: Select all

http://download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe

Don't know if these are the same file or not. In Vista and Windows 7 they're supposed to quietly fetech their root certificate updates. In XP in Windows Update, it's listed as an optional update.

A copy of the .exe pulled from that URL for your analytical pleasures:

rootsupd.exe

(405 KiB) Downloaded 2055 times

Here's the hybrid-analysis sandbox run on the binary:

Malicious Indicators

Installation/Persistance
Allocates virtual memory in foreign process
Writes a PE file header to disc
System Security
Modifies System Certificates Settings
Unusual Characteristics
Contains ability to reboot/shutdown the operating system
Spawns a lot of processes

Basically, it's a shady piece of work - I'd not recommend running it on any Windows box... though I'd love to see what happens when it's launched in a safely disposable win VM.

So that subdomain is the gift that keeps on giving, eh?

Cheers,

~ pj


ps: no, I've not done any IP or packet-level analysis of the fetch of the binary itself... though I suspect the results would be duly fascinating if someone decides to do so and post them here.

[dfkt]

Virustotal says the file is (technically) fine - https://www.virustotal.com/en/file/d7a7 ... 443822518/

I unpacked the sfx-exe but I haven't found anything useful to convert those merged ".sst" certs to another format. (I was looking at this: https://technet.microsoft.com/en-us/lib ... 48628.aspx)