Bork Tuesday, Any Problems Yet?

Well, WUMT did the trick for me. So no reason to look elsewhere.

Like you, I as a rule don't block Win Updates. This bugger is an exception due to its exhibited malware behavior.

 

ICMP protocol resides on network layer, not application. 'System' is a pseudo-process, in this case representing the IP stack/OS kernel. Type 8 (echo) packets are usualy fixed in size (this is not always the same and depends on many things, OSes used included) and encapsulated TCP can usually be recognized by the unusually large size of ICMP packets without even looking into them. There are firewalls that can limit the size of ICMP packets thus preventing such encapsulation.
But let's not get off-topic again, here we have documented what is being sent (in the links I provided above) and would be nice to actually look into the packets to see if this fits.

I agree.

 

Those are Microsoft statements. If anyone actually believes verbatim anything they publish anymore, then they do so at their own peril.

 

Sure. That's exactly why it does not hurt to look.
But sedsvc's been running for a couple of hours (only sedsvc) and nothing. It does not open any sockets.

 

That's an anthill.

Wha- why did you poke it?!

Stop poking it!

Fast! Get him!

Ah! They're getting everywhere!

It's too late! Ants in my pants!

AH! Be careful! They're getting angry!

Oh, don't you dare poke this one too!!

 

LOL

Right, it's you guys who should be poking this, you have borked updates.
I can't reproduce this in a fresh VM.

 

I'm using the WuMgr now that you shared, seer. It looking so good, I'm getting all antsy.
I just wish I could just click and it would download the update. I seems like I have to search them on the website, right?

 

What happens when you select 'manual download/install' and click on 'download'? -

 

Your main culprit is sedlauncher.exe. It initially runs at noon and then every 23 hours thereafter.

Now a few other interesting observations about this bugger I haven't mentioned. If you disable the task, upon next boot sedsvc.exe will reenable the scheduled task. If you block sedlauncher.exe startup, it somehow will mysteriously try to run again a couple of hours after the scheduled start time. I could not figure out what caused this second startup since nothing in the scheduled task parameters existed to cause this behavior.

 

Exporting the task to xml should reveal the CLSID in the 'actions' section of xml, then seach for that CLSID in the registry should reveal AppID and at least provide some clues.
I turned off the VM now, but I may play with this tomorrow some more. If I find some sense in it, since you guys wish to disable it anyway.

 

Haven't really been following this KB4023057 issue(s) but just seen now in update history it has updated (again) on two machines, yesterday 7 Dec (previously 19 Nov) and today 8 Dec (previously 16 Nov).

Have been checking WU, and have otherwise seen no evidence of this update having occurred, so WTF, not what I expected ... anything I should be aware of?

 

It's a forced update that will occur at boot time and/or next system auto check for Win Updates.

As far as if you want it, read the prior postings and make your own decision.

 

OK thanks. Just hadn't seen any of the normal 'preparing ...' signs ...

If MS want me to have it, I'll just leave it .

 

If what you are doing is monitoring ICMP packet size, fire up the VM slightly prior to the scheduled startup of sedlauncher.exe. I believe this process's function is to upload the current .etl file diagnostic data.

The suspect behavior I observed from sedlauncher.exe is for the first few days it ran, it would start and immediately shut down based on scheduled task history event times. Then inexplicitly, it would start at scheduled time and run continuously. Bottom line - trying to catch sedlauncher.exe actual ICMP tunnel data transmissions might be quite difficult.

 

I was also hoping to look inside the packets. This connection is not encrypted and the packets should be readable.

Exactly the same here. I actually logged in to post this.


All is fine.

The task returns 0x1 as the Last Run Result which translates to 'incorrect/invalid function'.



This is being returned by the process (sedlauncher) but the functions reside in sedlauncher.dll which is (by the last accessed timestamp) called by the exe.
But nevermind all this, I will assume that what you have observed regarding the connection is true.

I'm still waiting for this to occur.

If this was happening on a live system, then it wouldn't be. I'll keep an eye on this for a couple of days.

 

I uploaded the files to hybrid-analysis.com yesterday to see what that'll do. And turns out, they all have code to detect a VM.
"The input sample contains a known anti-VM trick"
https://www.hybrid-analysis.com/sample/ced74d58752b22f251f16c58ebf94a5442bfafa2b4f1c0cb9ebfa7844e6d0c43

Also for some reason the zip I made is considered malicious, but nothing else.

 

Two more failed attempts on the old laptop and now I notice this:

Code:

Failed to add user mode driver [%SystemRoot%\system32\DRIVERS\UMDF\uicciso.dll]

Third attempt with card reader disabled started. Hope that’s the culprit...

 

Below is a screen shot of one day's event history nonsense in regards sedlauncher.exe:



Task starts at scheduled time and runs for a little over a hour and terminates. It then restarts itself approx. 50 mins. later and would have run until system shutdown time if I didn't manually terminate it. Suspect a data upload occurred upon startup of second run of it.

 

Unfortunately not.

How can I find out which device/drivers is requiring this (non-existent on this PC!) driver?

 

Looks like it's not unique to the 1809 Upgrade: https://answers.microsoft.com/en-us...-several/0102190d-3ca9-41be-8fae-6463d569722a . Was not fixed in that thread until Microsoft issue a patch.

Here: https://techtablets.com/forum/topic/trouble-updating-to-1803/ states it was an Intel driver:

 

The file is also non-existent here (on 1809). I have uiccspb.dll at that location though.
uicc stands for Universal Integrated Circuit Card and while it may refer to card reader it may also refer to a phone sim card.
Try going to Device Manager and set it to show hidden devices. Then uninstall all ghosted devices - this will remove any leftovers from once connected devices. Then restart the upgrade.

[EDIT] Sorry for the late edit, but just to clarify a bit.
It is possible that a device was once installed that needed that dll. While the device was removed, a reference to the dll is still in the registry, Windows is trying to migrate the driver (so you can connect the device again if you wish) but it can't find the file.
Just a thought.

 

The 'tricks' collect hardware/software info and then look for vm identifiable specifics (CPU type, certain reg keys, many other things), which is basically what this update does - collect the same type of info but for a different purpose. If you just uploaded the zipped folder, there is a json file there in plain text which is probably being flagged. Unless the 'trick' is specifically defined, the detection basically means nothing.

 

Oh that makes sense. Thank you

 

Disabled the card reader in BIOS, deleted all non-connected devices in Device Manager, and deleted all uicciso references in the registry and tried again.

Another failure; this time because the Arial Nova (TrueType) font is missing...

 

I have seen more than a few web recommendations that sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth be run prior to any Win 10 upgrade.