In veilige modus start Windows zo 'kaal' mogelijk op met alleen de meest noodzakelijke services om het besturings-systeem te laten functioneren.
Virus scanners, firewalls (ben niet zeker van de Windows firewall zelf) e.d zullen dus niet opstarten.

Wat je wel kan doen is in veilige modus een on demand scan-met MSE of een ander product-te draaien. Je dient de scan dus handmatig te starten vanuit het menu van het product. Aangezien de achtergrondservice van de on access scanner niet werkt in veilige modus, en er dus geen icoontje in de systeembalk staat, dien je MSE te starten vanuit het start menu, het icoontje op je bureaublad of in uiterste gevallen vanuit de executable van het product in program files.

Overigens dien je MBAM bij voorkeur niet in veilige modus te draaien. Op het forum van MBAM is daar door de ontwikkelaars meerdere keren op gewezen. In veilige modus schijnt een bepaalde driver van MBAM niet ingeladen te worden waardoor het detectievermogen aanzienlijk wordt verminderd. Ik raad je dus aan om nogmaals te scannen met MBAM in normale modus.

Info over Java/CVE-2010-0840.LR:
When the exploitation is successful, Exploit:Java/CVE-2010-0840.A attempts to download and execute a malicious program from a specified URL. In the wild, we have observed the downloaded binary file "game_id" being stored with Exploit:Java/CVE-2010-0840.L. The downloaded program is saved as
"%TEMP%\<random>.exe".

Bron:
http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Exploit%3AJava%2FCVE-2010-0840.L

@choi
Dank je voor die tip.
Ik heb Mbam nu in de nomale modus gedraaid. Resultaat negatief.
Het lijkt in orde.
Wel vond ik in een map Dowloads nog een Java 6.26 setup. Misschien dat daar misbruik van gemaakt is. Ik heb die in iedergeval verwijderd.
Ik ben er als lurker van security juist zo kien mogelijk op Java meteen handmatig te updaten. Nu 6.30 dus.

In iedergeval, mijn dank voor je info

Oude Java installaties zijn snel, volledig (bijv. resten in het register)en veilig te verwijderen met JavaRa (de software update ook Java indien gewenst):
http://raproducts.org/wordpress/software

Een paar kanttekeningen bij JavaRa:
Het is eerder dit jaar overgenomen door The Web Atom, en vervolgens door SingularLabs.
http://raproducts.org/wordpress/web-atom-to-aquire-javara
http://singularlabs.com/software/javara/
In de documentatie van SingularLabs, net als eerder in die van RaProducts, wordt een heel specifieke eis vermeld:
Onder Vista en Win7 moet UAC uitgeschakeld worden om JavaRa uit te voeren:
http://singularlabs.com/software/javara/javara-docs/
http://singularlabs.com/software/javara/javara-download/
Mei dit jaar meldde RaProducts nog:
" The Web Atom will re-engineer JavaRa from the ground up, utilizing the newest technologies available in Windows."
http://raproducts.org/wordpress/web-atom-to-aquire-javara
Ik hoop dat dat nog doorgezet wordt, ook onder SingularLabs, en dat er gauw een versie gebouwd wordt die gewoon netjes met UAC kan omgaan.

Ik zag inderdaad dat er doorgelinkt werd naar de pagina van Singular Labs

Bedankt voor de tip want dat wist ik niet. Ik heb de versie van Singular Labs alleen getest onder Windows XP alvorens advies te geven aan de TS. Het is inderdaad te hopen dat de nieuwe versie het probleem met UAC kan omzeilen.

@choi en Spiff

Ik had het gezien toen ik op aanwijzen van choi keek. Gaf mij een beetje onzeker gevoel. Ik zag er daarom vooraleerst van af. Ik ben niet bekend met die bedrijven.
Zoals ik het nu van jullie begrijp is dat OK.
Mijn machine lijkt mij nu schoon. Ik vind tenminste geen Java resten meer. Ik heb de website van Singular Labs nu onder mijn favo's staan en wacht een paar maand.
Ik zal als dat UAC verhaal niet meer nodig is het uit proberen.
Dank voor jullie reactie's.

Op de SingularLabs site ontdekte ik trouwens ook nog dat er recent een JavaRa versie 2.0 alpha is uitgebracht (N.B. dus zelfs nog niet bèta, dus zeker niet bedoeld voor gebruik, maar slechts voor het testen).
Ik zie bij die 2.0 alpha echter nog niets vermeld over het kunnen functioneren met UAC.
http://singularlabs.com/2011/12/16/javara-2-0-alpha-build-available/

Op Tweakers.net Meuktracker, waar die 2.0 alpha eveneens vermeld wordt, lees ik eveneens niets over het kunnen functioneren met UAC.
Wat ik van het Meuktracker stukje overigens nog wel leerde, dat is dat The Web Atom niet is overgenomen door SingularLabs, maar dat de naam is veranderd naar SingularLabs.
http://tweakers.net/meuktracker/27260/javara-20-alpha.html

@Spiff;
Leuk! Het beeld wordt stil aan duidelijker.
Ik las de reacties op de meuktracer en die lijken toch aan te geven dat javara zaken laat staan.
In iedergeval ook zelf controleren dus.
Dat de toekomstige versie (misschien ook de oude) in het register sleuteld is boven mijn begrip.
Het lijkt me daarom goed om eerst maar eens af te wachten of dat wijzigen in het register voordeel oplevert als de programma resten zijn weggehaald.
Het doet mij een beetje denken aan het opschonen van het register via CCleaner. Daarvan las ik bij jullie ook dat dit geen snelheidswinst van betekenis op levert, en dat je het daarom beter zo kunt laten en volstaan met bestandsopruiming.

In iedergeval dank!

Ik zou gewoon vanuit het configuratiescherm alle javaversies uninstallen. Opnieuw opstarten en een nieuw herstelpunt aanmaken.
Dan java.com bezoeken om te controleren dat java niet meer werkt ('heb ik java').
Mocht later blijken dat java toch ergens voor nodig is, dan de laatste versie downloaden en installeren.

Zelf ben ik na enige aarzeling overgegaan op ccleaner en gebruik ik (op mijn eigen computer) ook de registry cleaner waarbij ik alles aanvink. Ik laat wel een backup van de registry wijzigingen maken!
Bij computers van anderen doe ik dit niet omdat opnieuw installeren veel tijd kost, maar bij mijn eigen computer heeft dit nog geen problemen opgeleverd en mocht dit wel zo zijn dan heb ik backups van alle belangrijke data.

Er is wel een probleem met ccleaner en ms security essentials. En ms search cleanen kan een lange opstarttijd opleveren (database moet dan opnieuw aangemaakt worden). Ook durf ik Thunderbird niet te laten cleanen omdat die nu elke 6 weken een nieuwe (major) versie heeft. Mail is heilig!

hth

P.S. In de tijd van Windows 95 had Microsoft haar eigen cleaner voor het registry die je op hun site kon downloaden :-)

Als dat een eerder door jezelf gedownload Java installatiebestand was, dat je daar zelf opgeslagen hebt bij download, en het vervolgens toentertijd hebt geïnstalleerd (al dan niet als update), dan hoefde je je over dat installatiebestand niet werkelijk druk te maken. Dat is inactief. Pas door het uitvoeren ervan voer je een installatie of update uit. Pas het resultaat daarvan, de geïnstalleerde programmabestanden, die kunnen bij aanwezigheid van een ongepatcht lek een beveiligingsrisico betekenen. Niet het inactieve installatiebestand. Desondanks, opgeruimd staat netjes.


Het is mij niet bekend wat JavaRa exact doet.
De documentatie geeft aan dat het onder meer doet wat nieuwe Java versies ook doen, eerder geïnstalleerde oude versies verwijderen.
http://singularlabs.com/software/javara/javara-docs/
Voor Java versies vanaf JRE 6 update 10 doet Java dat bij update, voor oudere versies, ouder dan JRE 6 update 10, moet je zelf die oude versies deïnstalleren.
http://www.security.nl/artikel/23426/Sun_verwijdert_eindelijk_oude_Java_installaties.html
http://www.security.nl/artikel/39012/1/Oude_Java-_installatie_bedreigt_Windows-gebruikers.html
Oude Java versie deïnstalleren, ouder dan JRE 6 update 10, dat kan door middel van een normale deïnstallatie, of eventueel kun je ervoor kiezen dat te doen met behulp van JavaRa.
Gezien het feit dat me nooit precies duidelijk werd wat de toegevoegde waarde van JavaRa precies was, en wat JavaRa exact doet, heb ik JavaRa nooit gebruikt.


Bedoel je dit:
"JavaRa makes significant changes to your registry and filesystem"
http://singularlabs.com/2011/12/16/javara-2-0-alpha-build-available/
Mogelijk wordt daar niet veel meer mee bedoeld dan een grondige deïnstallatie. Ook bij een normale deïnstallatie worden bestanden verwijderd en tevens register-items aangepast.
Of JavaRa iets 'extra' doet dat risico's met zich mee kan brengen, dat is me niet bekend.

Het register is geen statisch gebeuren. Tijdens het gebruik van je PC worden er steeds onderdelen aangemaakt en verwijderd
Elke de-installatie, of het nou om een browser of malware gaat, verwijderd ook onderdelen van het programma uit het register.
Dat heeft niks met snelheidswinst of andere voordelen te maken dus de vergelijking met CCleaner gaat hier niet op.

Ik ken maar weinig Windows programma's die zch volledig laten verwijderen maar dat heeft in de meeste gevallen verder geen invloed op het functioneren van het systeem. Zelfs Revo Uninstaller laat hier en daar wat onderdelen achter, vooral in het register.

Wat Javara betreft, deze geeft na de de-installatie in een tekstbestand aan wat allemaal verwijderd is.
JavaRa verwijderd de volgende vooraf gedefinieerde mappen en registeronderdelen (deze staan in een tekstbestand in de JavaRa map): http://pastebin.com/wTCRMH7P

Overigens is JavaRa nog steeds open source, dus al je het niet vertrouwd en je hebt wat kaas gegeten van C++, dan kan je de code zelf bekijken: http://sourceforge.net/projects/javara/files/javara/JavaRa/JavaRaSource.zip/download

Dat is nogal een lijstje.
Weet je ook in hoeverre die deïnstallatie uitgebreider is dan een reguliere deïnstallatie?
En wanneer door JavaRa meer verwijderd wordt dan bij een reguliere deïnstallatie, hoe relevant is dat dan? Kun je aangeven wat nut en noodzaak precies zijn? De beschikbare JavaRa documentatie geeft dat mijns inziens niet aan.

Naast alles over JavaRa, nu even terug naar de door Microsoft Security Essentials gevonden drie Java exploits.
De vraag moet denk ik zijn hoe je die opgelopen hebt, S-q.
Gebruikte je mogelijk een Java installatie die niet goed up to date was, of stond er naast een up to date versie mogelijk nog een zeer verouderde lekke versie geïnstalleerd?
Of doken die exploits op zónder een bekend lek in je Java installatie?
Zou dat laatste het geval geweest zijn, dan ben ik benieuwd of iemand daar een verklaring voor kent.

Geen flauw idee, ik zou er RegMon tegenaan moeten gooien en de output vergelijken met de log van JavaRa.
Ik heb JavaRa jaren gebruikt omdat deze automatisch oude Java versies verwijderde. Als het inderdaad zo is dat de nieuwe Java versies dat zelf doen (het verwijderen van oude Java installaties) dan zie ik op het eerste gezicht het nut van JavaRa dan niet meer in.

Echter, het is een bekend fenomeen dat Windows programma's zich niet volledig laten verwijderen als je gebruik maakt van de ingebouwde de-installatie. Het zal me niet verwonderen als dat bij Java ook zo is.

Dat is misschien een onderzoekje waard bij de volgende update.

De drie exploits kunnen in de browser cache hebben gestaan. Alleen als je een kwetsbare java versie draait word je dan besmet. Je moet je wel afvragen of je veilig aan het surfen bent als je zulke dingen drie keer tegenkomt.

Juist Spiff, Zoals ik eerder opmerkte let ik op aanduidingen op security.nl en webwereld of er een update van Java is.
En dat al geruime tijd (paar jaar). Deze installatie van W7 is een schone installatie geweest in juni dit jaar.
Oude versie's van Java hebben er dus zo wie zo, nooit opgestaan.
Daarbij ben ik gewoon na elke update te controleren of er niet toch(!) een versie is blijven staan. Ook niet dus, zoals voor vanaf 6.10 al is genoemd.

Ik moet nu dus constateren dat deze drie exploits er zonder een mij bekend lek binnen zijn gekomen.
Tot dusver volstond ik -uit gemakzucht geef ik toe- met een snelle scan van MS Sec.Ess.
Tot ik van iemand op security.nl las dat het zinvol kon zijn 1 keer in de maand een volledige scan te doen, omdat door de melder gezien was dat de snelle scan soms wat niet oppikt.

Prompt die 3 exploits.
Ik heb die in het proces van Sec.Ess. opgeruimd en ik heb dan ook geen installatie datum gezien.
Ik kan niet anders bedenken dan dat ik ooit op een website geweest ben die besmet was, of dat ik een besmet fotobestand heb binnengehaald via mail. (Die krijg ik van vrienden en kennissen met enige regelmaat (fotobestanden dus))

Ik ben dan ook benieuwd of iemand iets kan verklaren.

Ow:
Vorige week een memorystic geaccepteerd met foto's van de kleinkinderen. En die stick is ook bij de fotomaker in de pc geweest. Ik ga maar eens een rondje bellen.

Ik weet niet zeker of alle relevante Java updates daar wel altijd aan de orde komen.
FileHippo.com en GratisSoftwareSite.nl zijn wellicht handiger sites om Java updates (en meer) in het oog te houden.
En/of het gebruik van Secunia PSI en FileHippo Update Checker.


Een interessante vraag is of je systeem ook zonder lekke Java versies op een of andere manier kwetsbaar kan zijn voor Java exploits.
In het geval je die Java exploits hebt binnengehaald via een besmette memorystick kwamen ze mogelijk wel op je systeem terecht, maar konden de exploits zich bij gebrek aan een kwetsbare Java versie wellicht niet kwaadaardig manifesteren? Mogelijk was dat waarom Microsoft Security Essentials ze pas ontdekte bij een diepe scan?

Wil je wat meer aandacht voor die materie, dan is het misschien een idee om het onderwerp van je start-bericht, dus van deze thread, te veranderen van "SecurityEssentials start niet in veilige modus" naar zoiets als "Java exploits zonder lekke Java?"
Dat intrigeert wellicht, en zorgt mogelijk voor wat extra reacties op je thread.
In het geval je dat zou doen, het onderwerp zou veranderen, dan is het wellicht wel verstandig een aanvulling toe te voegen aan je start-bericht, betreffende die materie van gevonden Java exploids zonder een bekend Java lek. Dit omdat beslist niet iedereen de moeite neemt een vrij lange thread helemaal door te nemen om alle relevante details te lezen.

Dank je Spiff;

Ik heb het aangepast.

Zal moeilijk te achterhalen zijn hoe je de besmetting-ervan uitgaande dat het geen false positive was-opliep. Ik gok erop dat je of een oude versie van JRE op je machine had staan met nog ongepatchte kwetsbaarheden, of dat je gepakt bent door een zero-day exploit op de meest recente versie van JRE.

Over de door jou genoemde malware onder CVE (Common Vulnerabilities and Exposures) 2010-0840 is weinig meer bekend dan dat het om een ongespecificeerde kwetsbaarheid gaat in de Java Runtime Environment waarvan er steeds andere varianten van ontdekt worden (dat zijn de letters achter 'Java/CVE-2010-0840.'): http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0840

Zoals je wellicht weet lopen de klassieke, op signatures gebaseerde scanners, hopeloos achter op de snelheid waarmee nieuwe malware uitkomt. Nieuwe malware moet eerst in-the-wild actief worden (lees: iemand moet als eerste besmet raken) om opgepikt te worden door de bedrijven die anti-malware software maken. Die moeten dan eerst een signature van die malware maken en vervolgens uploaden naar jouw machine (of in het geval van cloud scanners, de server).

Tussen het moment van verschijnen van een nieuwe variant en de ontdekking daarvan verstrijken vaak dagen. In de tussentijd raken er meerdere mensen besmet. Gedurende deze periode zal geen enkele scanner de besmetting detecteren. Als je geluk hebt detecteert de heuristics van de scanner het als een generieke trojan of iets dergelijks.

Hier zie je een recente scan (6-12-11) op VirusTotal van een 2010-0840 variant: http://www.virustotal.com/file-scan/report.html?id=4af44c28bb82c1988b228044a6b918567997b984a862691b72b949ed319a69d4-1323167870
Zoals je kan zien is het detectiepercentage nog geen 70% (30 van de 43 scanners w.o een paar van de grote namen).

Om optimaal beschermt te zijn dien je aanvullende maatregelen te treffen. Ten eerste een goed rechtenbeleid door de UAC van Win7 op het hoogste nivo te zetten. Daarnaast is een goede HIPS geen overbodige luxe. De HIPS van Comodo (Defense+) is een van de beste-gratis en betaald-van het moment.

Een groot gedeelte-zeg maar gerust het overgrote deel-van de besmettingen vindt plaats via drive-by downloads waarbij op de achtergrond JavaScript wordt uitgevoerd die dan weer een kwaadaardige payload binnenhaalt.
Hiertegen kan je je beschermen door JavaScript selectief toe te staan. Er zijn voor dit doel extensies beschikbaar z.a Noscript voor Firefox en Notscript voor Chrome en Opera.

Op z'n minst zou je een scanner moeten gebruiken die ook het http-verkeert scant z.a Avast (MSE doet dat ook maar uitsluitend i.c.m Internet Explorer9).

Dit fenomeen heb ik eerder gezien. Bij een gecompromitteerde site die ik bezocht werd geprobeerd meerdere Java exploits uit te laten voeren. Er werd er 1 door de virusscanner gedetecteerd, maar de anderen bleven -onopgemerkt- in de browser cache (en directory op m'n schijf) staan. Een upload daarvan naar virustotal wees uit dat er op dat moment nog nauwelijks detectie voor bestond, in elk geval niet door de op dat moment toegepaste virusscanner.

Wacht je in zo'n geval een paar dagen en doe je een volledige scan van je schijf, dan is de kans groot dat die exploits in je browser cache alsnog worden gevonden.

Het vinden van malware op je PC wil niet zeggen dat er "besmetting" heeft plaatsgevonden. Het doel van exploits is dat de exploit (1) gedraaid wordt en (2) effectief is en (3) de uiteindelijke malware (bijv. een spambot of banking malware) gedownload wordt en tot uitvoering komt. Stap 2 werkt alleen als de betreffende kwetsbaarheid aanwezig is in de betreffende software (Java virtual machine in dit geval) en is vaak ook nog van andere omstandigheden afhankelijk (zoals een exacte versiematch en/of taalversies van dat soort software).

Tenzij jij een interessant doel bent (en er geen sprake is van een persoonsverwisseling), is de kans niet zo groot dat je ooit verse 0day exploits te zien krijgt. Verse 0day exploits zijn geld waard, die "brandt" men zelden op aan drive-by exploits (er zijn voldoende gewillige slachtoffers met oudere Java, Flash, Adobe Reader, Quicktime, Realplayer, WinAmp, Word, Excel, Powerpoint etc. versies). Oudere exploits krijg je wel aangeboden en de kans dat die een tijdje in je browser cache blijven staan is best groot - maar geen reden voor paniek.

Ik heb nog nooit Java exploits op een USB stick gezien en ze liggen ook niet erg voor de hand (in een targeted attack voor een mixed OS omgeving zou dit kunnen). Daarnaast zie ik geen reden waarom die op je schijf zouden belanden, ze kunnen net zo goed vanaf een USB stick draaien.

Zodra de exploit gedraaid heeft, is het bestand met de exploit zelf daarna nergens meer nuttig voor. Sterker, de aanvaller zal deze bij voorkeur van de schijf verwijderd willen hebben, het gaat natuurlijk om gepubliceerde malware waar binnenkort virusdefinities voor te verwachten zijn (antivirus-detectie van nageladen malware is vaak veel slechter dan van exploits).

Het aantreffen van exploits op je schijf betekent dat je een gecompromitteerde site bezocht hebt (of ze op een andere manier hebt "opgelopen") maar is geen bewijs dat de aanval gelukt is, in veel gevallen betekent dit eerder dat een aanval niet of deels gelukt is. E.e.a. is natuurlijk wel aanleiding voor een grondige check, bij voorkeur een scan vanaf een extern bootable medium.

Mee eens.
Zoals uit de beschrijving (in de eerste reactie) van een van de 2010-0840 varianten blijkt, is het vooral de payload (een gedownloade executable) waar je voor moet oppassen. In de meeste gevallen zal die zich in een tijdelijke map ophouden. Maar ook dan hoeft er nog niks aan de hand te zijn. Pas als de executable in actie komt en gaat lopen rommelen aan je systeem wordt het gevaarlijk.

De kans dat de AV de executable oppikt is echter groter dan dat die de exploit zelf detecteert (althans dat blijkt uit de praktijk), Zeker als het om een zero-day exploit gaat. Je hebt echter ook een reële kans dat je AV helemaal niks detecteert. Hier zal goede systeembewaking in de vorm van een HIPS zich kunnen bewijzen.

Het starten van een onbekende executable en de veranderingen die deze aan het systeem tracht aan te brengen zal door een goede HIPS onderschept worden. De gebruiker krijgt dan in ieder geval de kans om e.e.a te blokkeren.

En als je gebruik maakt van NoScript of iets dergelijks dan had je de exploit zelf waarschijnlijk kunnen voorkomen door alle externe scripts (die de exploit uitvoeren) te blokkeren.

Als MSE verder geen executables of andere uitvoerbare bestanden heeft gevonden dan is er waarschijnlijk niks aan de hand.

In je browsers de instelling maken dat de browser-cache standaard geleegd wordt bij het afsluiten van de browser kan wellicht een goed idee zijn, mocht je die instelling nog niet hebben gemaakt en mocht het verwijderen van de browser-cache (dus de browsegeschiedenis) niet bezwaarlijk voor je zijn.
Daarnaast kun je ook regelmatig (andere) tijdelijke mappen leegmaken (bijvoorbeeld met behulp van CCleaner), voor het geval zich daar iets naars zou proberen schuil te houden.

@Choi, Bitwiper en Sniff;
Bedankt voor jullie reaktie's. Heel mooi uitgelegd allemaal en vooral voor mij geruststellend.
Ik had na de ondekking uit schrik al meteen UAC op maximum gezet; na de opruiming door MS Sec.Ess. Nog eens Mbam voor de zekerheid eens losgelaten en daarop Ccleaner gebruikt om eventuele rommel op te ruimen.

Mijn http verkeer wordt, begrijp ik, gescant omdat ik als browser inderdaad IE9 gebruik.
Ik begrijp nu dat er niet veel voor mij aan de hand is omdat ik de machine consequent bij 1e mij bekend berich update, zo ook voor Java. Het zou dus inderdaad zo kunnen zijn dat de exploit door de stap 2 situatie afgestopt is en feitelijk wat betreft zijn effectiviteit vast is gelopen.

Hoera dus.

Voor de zekerheid vandaag nog een volledige scan gedaan. Er werd geen verdere malware gevonden.
Gisteravond nog een Hijackthis log naar een daar voor bestemd forum gestuurd. Daarvan is ook vastgesteld dat er geen bijzonderheid mee was. Daarop nog een log van Combofix. Daarvan moet ik nog een beoordeling krijgen.
Omdat ik toch Mbam geinstalleerd had deze laten staan. Deze kijkt nu dus ook mee. Of dat nog heel zinvol is weet ik niet, maar het idee is: dubbel gestikt houdt beter! In iedergeval bijten MS Sec.Ess. en Mbam tot dusver elkaar niet.

Voel me dus gerustgesteld.
Nogmaals bedankt.