First of all i require a tangible ANSWER which deals with the issue at hand and not technically unrelated copy pasta spam <edited> This has been asked before and locked without a solution nor a given reason for the lock. Windows Web Credentials (on a spanking new installation) are showing up that are unexplained, contain urls that are technically not URLs but strings of data keys and hashed pashwords associated with them, and sometimes not a identifiable application listed that generated them. Example string found on so many machines that it actually yields a google result : e93ec0bd-878d-4933-9e3a-89160c088da9 The screenshot shows a long numerical user name (redacted) , a HTTP (not HTTPS!!) url that is clearly not feasible The even more cryptic and quite troublesome is the one tha is created by an Unknown APP that is named like a SID, uses a simlar format bogus URL as the first example and a massively long crypted password which is even too long to show in credential manager, and is associated with my gmail account/username. I can only guess this is some form of integration. But i would clearly like to know for sure and i dont want to remove it outright in fear of breaking things on a substantial level. First of all i require a tangible ANSWER which deals with the issue at hand and not technically unrelated copy pasta spam <edited> This has been asked before and locked without a solution nor a given reason for the lock. Windows Web Credentials (on a spanking new installation) are showing up that are unexplained, contain urls that are technically not URLs but strings of data keys and hashed pashwords associated with them, and sometimes not a identifiable application listed that generated them.
as a working URL created by EDGE.
Example string found on so many machines that it actually yields a google result :
e93ec0bd-878d-4933-9e3a-89160c088da9
The screenshot shows a long numerical user name (redacted) , a HTTP (not HTTPS!!) url that is clearly not feasible
as a working URL created by EDGE.
The even more cryptic and quite troublesome is the one tha is created by an Unknown APP that is named like a SID, uses a simlar format bogus URL as the first example and a massively long crypted password which is even too long to show in credential manager, and is associated with my gmail account/username. I can only guess this is some form of integration. But i would clearly like to know for sure and i dont want to remove it outright in fear of breaking things on a substantial level.
Hi and thanks for reaching out. My name is William. I'm a Microsoft Windows Certified Professional and Systems Administrator. I'll be happy to help you out today.Related to http://ww1.e93ec0bd-87bd-4933-9e3a-89160c088da9.... It's hosted in Romania. It doesn't seem to host anything of real content other than random links. I dont see anything malicious in the site. You can remove this from Credential Manager without doing any hard. It was likely cached as part of some cross domain linking from another website, but no way to tell.
Thanks for answering . The string was modified by you adding ww1 infront of it. Obviously that site in Romania (Europes capital country of most shady internet dealings and internet criminality) used the string due to it being a popular search term on google the shady undisclosed owners bot of that site registered that term as a domain adding the ww1 descriptor infront of it to make it possible). This does not explain the origin or functionality of the string at all. The string is unique and does not contain ww1 , ww1 is also nothing that is automatically resolved or added infront of an URL by any browser i know of, if you just enter the pure string without ww1 you will reach no site.
So this does not quite answer the question at hand how did it get into my web credentials in the first place containing a non valid URL.
Imagine how the Web Credential list would look like if this was possible. It would EXPLODE.
There is no way to ascertain how that got cached on your system. What you want is some soft of forensic analysis of your system, which is not possible here. The best we can do here is provide whatever information is available from a domain registrar. The I can offer you is some internals or technical information, but, as I pointed out, we cannot provide information on your particular instance.https://www.sciencedirect.com/topics/computer-s...
https://docs.microsoft.com/en-us/previous-versi...(v=ws.11)
You are not getting it im sorry. I may also worded parts of my response wrongly ...
What i ment is:
HTTP and HTTPS is protocol level while WWW , ww1 and the .com are not.
There is NO DNS entry/register for e93ec0bd-87bd-4933-9e3a-89160c088da9a
because ofc that is not possible to register as a valid domain.
obvious proof:
ping e93ec0bd-87bd-4933-9e3a-89160c088da9
Ping request could not find host e93ec0bd-87bd-4933-9e3a-89160c088da9.
Please check the name and try again.
Using http:// infront does not resolve anything ofc.
The string in web credentials does not contain any web protocol resolvable information and also it makes absolutely no sense
to be named like that in the first place, also why is a user and a password that was either encrypted or autogenerated or both
and does not exist on my machine associated to it.
Only by manually adding ww1 and .com to the string did you come to your assumption that these would have anything to do with the problem. That is plain wrong as a train of thought of what might be the underlying cause of the entry.
The string was scraped by a bot of google and automatically registered as http://ww1.e93ec0bd-87bd-4933-9e3a-89160c088da9.com/
to gain clicks on the site. This site has nothing to do with how the pure unmodified credential came to be on peoples machines.
The operating system/edge added this credential, it was not added in a legitimate or transparent user interaction.
The other example containing my gmail user name and email adress may be a part of cell phone integration or gmail account setup in the default windows 10 mail app but since this is not revealed by web credentials because the origin of the entry is obfuscated with a app name that looks like a SID ..theres no transparency to deduct this clearly.
I have removed them both now and will monitor if there are any sideeffects.
It is not necessary to add ww1 to the string in the CM. e93ec0bd-87bd-4933-9e3a-89160c088da9.com works on it own and is redirected to ww1, which is irrelevant.As for masking as a SID (actually a GUID), this may have been done for nefarious purposes, but that is an assumption ... which is also irrelevant. A domain name that looks like a GUID is not violating any domain naming conventions.
you also ADDED .com to it BY YOURSELF, did .com magically appear on its own when u typed the string to resolve its unresolvable adress?!?
Lets just call it a day before you start to enfuriate me, are you trying to TROLL here or what.
You should relax. This is too trivial to get hung up about. <>- タグ ：
- #windows
- #Windows
- #10
- #Security
- #privacy
