Jump to content

blub

Expert Member
  • Gesamte Inhalte

    7.598
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von blub

  1. btw: Ich würde nicht mehr NLA als Option aktivieren, da unsichere Protokolle verwendet werden.
  2. http://www.heise.de/security/meldung/Trend-Micro-Produkte-oeffneten-triviale-Hintertuer-3159436.html gar nicht schön! Und der Exploit ist gleich dabei :-(
  3. Das Skript regelmäßig als Task laufen lassen und die verschlüsselten Passwörter auf ein Sharefile oder in eine DB schreiben. Nur mit dem Private-Key kommt man an die echten PWs ran. Das geht sogar super gut :-). Ist leider nicht mein Skript, daher kann ich es nicht rausgeben.
  4. Zugriffsrechte auf und Verschlüsselung von vertraulichen Daten sind ja nur ein Teil dieser Aufgabe, vielleicht sogar der noch relativ einfach zu Lösende. Was helfen "supersicher" gespeicherte Dateien, wenn der Client zum Bearbeiten der Dateien, das Netzwerk zwischen Fileablage und Client, eventuell auch der Ausdruck und der Dateiaustausch z.B. zwischen den Geschäftsführern nicht auf demselben "supersicheren" Niveau sind. Bei einem Gesamtkonzept für vertrauliche Daten fängt's dann an, wo sich "Berater" und "Berater" trennen. Die einen können realistisch administrierbare, finanzierbare und sichere Ansätze vorschlagen, die anderen nicht. "Ach übrigens, Ich muss auf meine streng-vertraulichen FirmenDaten natürlich auch mit meinem Mobildevice (MacBook) jederzeit zugreifen können!"
  5. jeder einfache User kann die Members der Administrator-Gruppe auslesen
  6. Ich nutze immer Arrays zum Vergleichen von Listen: $GroupA_Members = @("user1","user2","user3","user4") $GroupB_Members = @("user3","user4","user5","user6") Write-Host ""`n"show duplicates" $DupMembers = $GroupA_Members | Where {$GroupB_Members -Contains $_} $DupMembers Write-Host ""`n"remove duplicates" $AllMembers = $GroupA_Members + $GroupB_Members | sort -Unique $AllMembers Compare-Object funktioniert aber genauso gut blub
  7. Meistens versuchen diese Programme nach der Infektion als erstes den eigentlichen Schadcode nachzuladen. So ja auch bei dir von "store.clarksvillevw.com", einem vermutlich ebenfalls gehackten Server. Ohne LAN bekommst du den genannten Fehler, "die angegebene Resource kann nicht gefunden werden". Ohne nachgeladenes php-File kannst du natürlich auch nicht sehen, was der eigentliche Schadcode veranstalten würde. Auch in Powershell ist das Schutzlevel vor Malware-code über "set-executionpolicy" maximal als nice2have zu bezeichnen. Es gibt etliche einfache Wege, diese Policy zu umgehen. Ich denke, in VBS wird es nicht anders gewesen sein. Ein mögliches Schutzkonzept vor Malware dieser Art mit Windows-Boardmitteln wäre übrigens "DNS-Sinkholing" evtl. gepaart mit einem Honeypot-Server. blub
  8. wenn es dir wörtlich um "erweitern" geht, dann besorg dir ein Powershell 5.0 Buch. Bei PS 5.0 ist sehr viel Neues (und Nützliches) dabei. Die deutschen PS 5.0 Bücher erscheinen allerdings erst in den nächsten Wochen. Mit PS 5.0 werden z.B. die ganzen Klassiker unserer Jugend wie ping.exe/ netsh/ ipconfig abgelöst. :) Geht es "nur" um Einarbeiten, dann wirst du auch in Büchern über ältere Versionen genügend Stoff finden. blub
  9. Das ist interessant, ehrlich! hast du einen Paragraphen, Beispielurteil, oder sonst eine juristische Quelle? Viele Admins werden gar nicht wissen, ob sie diese Möglichkeit haben oder nicht.
  10. lokales Adminkonto -> Anmeldung mit NTLMv2 -> schlecht
  11. Lokale Accounts sind security- und betriebstechnisch meist nicht so gut zum Arbeiten.. Wenn der Server in einer Domäne steht, dann benutze besser einen Domänenaccount ohne besondere Rechte im AD und stecke den dann in die lokale Administratorgruppe des Servers. Ab Domänenlevel 2012 ist eine Mitgliedschaft in der Domain Gruppe "protected users" für diesen Account sinnvoll, da dadurch dem Account einige sehr gefährliche, aber so gut wie nie benötigte, Privileges (Debuggng, Driver Installation, etc) genommen werden. Außerdem muss er dadurch immer Kerberos nutzen. https://technet.microsoft.com/en-us/library/dn466518.aspx Den lokalen 500-er würde ich nicht deaktivieren, aber gib ihm ein 30-stelliges keepass-Zufallspasswort. (pro Server ein eigenes!) und wechsle das auch regelmäßig z.B. jährlich. Für Software bzw. Serviceaccounts benutze möglichst keine (lokalen) Accounts mit Adminrechten. Die können einfach zu viel bzw. haben zu viele unnötige und gefährliche Privileges https://technet.microsoft.com/en-us/library/cc771990.aspx Diese Liste an Maßnahmen für lokale Accounts ist sicher nicht vollständig Konkret zu deiner Frage Zwischen dem lokalen 500-er Account und einem neuen lokalen Account in der Administratorgruppe ist so gut wie kein Unterschied in Bezug auf Security. Beide können Alles auf der Maschine! blub
  12. ohne die empfehlen zu können oder zu wollen und nur weil ich sie gerade parat habe! brainloop.de (die Frage war auch andersrum)
  13. dann hat sich der Fehler im Vergleich zum ersten Post aber verändert. Nicht funktionierende KDCs sind eine vollkommen andere Baustelle als die WinRM-Config. Wenn es eh nur 2 DCs in einer virtuellen Testumgebung sind, installier diese neu. Dann wird der KDC und damit der WinRM funktionieren. Beide Services gehören eher zu den Unkomplizierten ihrer Art.
  14. Edgar, du bist doch selbst Profi und sicherheitsbewusster Administrator. Da darfst du solch Ratschläge, "lade dir einfach mal irgendwo was runter" einfach nicht geben!
  15. Erstens dieses und zweitens kann man anhand der Zertifikatskette auch etwas über die Vertrauenswürdigkeit der Website sagen. Schau dir -nur als beliebiges Beispiel- die Downloadseite von keypass an https://sourceforge.net/projects/keepass/files/KeePass%202.x/2.32/KeePass-2.32-Setup.exe/download?accel_key=77%3A1458636669%3Ahttp%253A//keepass.info/download.html%3A448cbc65%249b374a9dae6c2f196b0cd35715e5777d67f4f59e&click_id=39228c94-f00b-11e5-a711-0200ac1d1d8f-2&source=accel Im Browser kannst du die Zertifikatskette sehen. Aussteller des Zertifikats ist bei keypass Geotrust. Die sind schonmal gut bekannt, ähnlich wie Verisign, Baltimore oder etliche andere. Man könnte sich da auch die Geotrust-Website ansehen. Microsoft bzw. Mozilla vertrauen ebenso diesem Zertifikatsanbieter, daher ist das Schlosssysmbol grün. Du kannst so relativ sicher sein, dass du auf keiner gefakten Seite russisch/ ukrainisch/ chinesischen Seite gelandet bist, die dir sonstwas unterjubeln wollen. Und wie von testperson gesagt, kannst du nur so sicher sein, dass du unverändert das bekommst, was du auch angeklickt hast. Nicht mehr und nichts anderes! Wie ebenso schon weiter oben gesagt, nur vom Hersteller downloaden. Und wenn der Hersteller die SW nicht mehr anbietet, hat er wahrscheinlich einen guten Grund. Wenn sich ein Hersteller oder Anbieter für seine Site kein vertrauenswürdiges Web-Zertifikat leisten kann oder will, dann vergiss die Seite am besten. Perfekt ist https auch nicht, aber es ist viel besser als gar kein Schutz! Security ist oft relativ einfach :)
  16. dann hast du testsrv2 richtig konfiguriert und WinRM funktioniert. Warum der testsrv3 nicht an den testsrv2 hinkommt, findest du am besten mit einem Netzwerksniffer wie wireshark.org heraus. Unter dieser Seite gibt es reichlich sehr lohnenswerte Anleitungen für alle Level, falls du dich in dem Gebiet noch nicht so auskennst!
  17. Nimm dir einen Netzwerkmonitor wie Wireshark und vergleiche was vor "Set objLocalPrinters = WshNetwork.EnumPrinterConnections" im Gutfall und Schlechtfall passiert. Wenn das nichts bringt, dann den Process Monitor
  18. das Script parst den Output offenbar auf English z.B. $sysvol1 = Receive-job $sysvol if($cmp::instr($sysvol1, "passed test NetLogons")) { Write-Host $DC `t Netlogons Test passed -ForegroundColor Green müsstest du wohl etwas anpassen. Zusätzlich zum üblichen Monitoring finde ich ein flexibles Überwachungsskript für DCs übrigens extrem hilfreich! Mit den aktuellen Powershell ADcmdlets und WMI (https://msdn.microsoft.com/en-us/library/windows/desktop/aa746437%28v=vs.85%29.aspx) ist ein ADMonitoring heutzutage schnell gebaut. Auf Textausgaben von Tools wie dcdiag -wie das Skript oben- würde ich nicht mehr setzen. Die gesammelten Daten noch in einer kleinen Datenbank (SqlExpress, zur Not sogar MSAccess oder gar Excel) abspeichern und man hat ein zusätzliches, mächtiges Betriebswerkzeug an der Hand. Auch dieses Speichern ist mit Powershell heute ohne tiefe Programmierkenntnisse möglich.
  19. dcdiag ist drauf? OS am DC ist English?
  20. du machst bei jedem Schleifendurchlauf einen neuen Filezugriff mit Öffnen und Schließen. Bei relativ wenigen Gruppen ist es kaum merkbar, aber bei vielen Schleifendurchläufen wird es Performance kosten. Da ist es besser erst alle Daten in ein Object zwischenzuspeichern ($AllOutPut += $OutPut) und am Ende alle Einträge $AllOutPut zusammen in einem einzigen Vorgang abzuspeichern. $AllOutPut | Format-Table * -auto | Out-File "$outputFile" auch $AllOutPut | export-csv oder $AllOutPut | export-clixml sind so einfach durchführbar
  21. Hallo, Ich benutze in solchen Fällen gerne das PSObject etwa so (ungetestet) Foreach ($gruppe in $gruppen) { [PsObject]$OutPut = "" | Select-Object Verzeichnisname_ohne_RW,Verantwortlicher,LetzterZugriff $OutPut.Verzeichnisname_ohne_RW = $($gruppe.SamAccountName) $OutPut.Verantwortlicher = $($gruppe.info) $OutPut.LetzterZugriff = $($gruppe.LastAccessTime) $AllOutPut += $OutPut }#Foreach $AllOutPut | Format-Table * -auto Damit hat man ein flexibles und übersichtliches Array in der Hand. Bei Bedarf kann man ja die Table noch anpassen (width, etc) https://technet.microsoft.com/de-de/library/ee692794.aspx
  22. eher nicht, da ja der symmetrische AES-Key, mit dem wahrscheinlich verschlüsselt wurde, wiederum durch einen asymetrischen RSA Public/ Private Keypair verschlüsselt ist. Dieser zugehörige private-RSAKey liegt wahrscheinlich nicht (mehr) auf deinem Rechner. btw1: locky hatte (so ich gelesen habe) immer eine gewisse Karenzzeit zwischen Infektion und Aktion, um sich dazwischen innerhalb des Netzwerkes noch weiter verbreiten zu können. -> Kein Domainadmin meldet sich interaktiv (RDP oder am Gerät) mit seiner Admin-Kennung auf Clients an! Never Ever! Ich würde die anderen Rechner des Kunden auf die von dir gefundenen Dateien untersuchen und ggf. die Sicherung wichtiger Dateien überprüfen. btw2: es handelt sich um einen kriminellen Erpressungsversuch. Wenn ein Jurist in der Firma greifbar ist, würde ich ihn mal kontaktieren, ob eine Anzeige sinnvoll ist.
  23. und von nicht https-gesicherten DownloadSeiten ala Chip.de, sollte man besser zweimal die Finger lassen!
×
×
  • Neu erstellen...