13 Antworten in diesem Thema

[Born2Hack]

Moin Leute

 

Ich schreibe seit einiger Zeit an einem Crypter/Downoader.

Das konzept sieht wie folgt aus:

 

Ich habe ein RunPe Modul in Form einer .DLL Datei (Verschlüsselt als Base64 String) auf xup.in hochgeladen

und lasse dann den String zur Laufzeit ins Programm laden/entschlüsseln und die .dll einbinden.
Danach wird auch dementsprechend die gewünschte server.exe (verschlüsselt) die bei xup.in hochgeladen wurde,

runtergeladen und mit dem RunPE aufgerufen.

Mit dieser Methode ist die output Datei nur 7kb klein.

Ein Minus Punkt ist aber, dass dann möglicherweiße die Firewall anspringt (ZoneAlarm etc.)

Aber andererweiße braucht jede Malware die gecrypted wird ein Internetausgang um die Daten zu übermitteln,

sei es ein Bot Stealer oder FormGrabber.

Was denkt ihr dazu ?

Ich hätte noch einpaar Fragen zum Crypter:

 

Wie genau baut man ein EOF Support ein ?

 

- Wie erkennt man die Daten die am Ende einer.exe geschrieben worden sind ?

- Wenn ich die EOF Daten auslese und wiederrum an die FUD output.exe dranhänge,

kommen mit hoher Sicherheit detections rein. Also wie soll man das umsetzen damit die Datei FUD bleibt ?

- Es werden auch Daten über die Resourcen übergeben,

muss ich alle Resourcen der server.exe auslesen und dann in meine gecryptete Datei schreiben ?

 

Mein Ziel ist es einfach meinen Crypter kompatibler mit anderen Malware zu machen.

Über einpaar Antworten(Snippets) würde ich mich freuen.
Egal ob VB.NET/C#

 

 

Bearbeitet von Born2Hack, 07 July 2015 - 05:26 Uhr.

[n1nja]

Hatte die selbe Idee gehabt, auch erst vor kurzen.

Theoretisch würde es klappen.

Das mit den Online sein, würde ich vorerst nicht berücksichtigen.

Denn wenn du ein RAT oder Stealer reinpackst, muss der Vic auch online sein:)

 

Firewall könnte anspringen. Würde aber auch nicht gerade XUP usen.

Was eigenens oder VPN etc.

Dann solltest du die hochgeladene Datei natürlich verschlüsselt mit den Public und Pivate - Key

 

Das mit den EOF, versuch es mit Resourcen.

Hab da aber scho ne eigene Idee, aber noch nie versucht bzw getestet.

Bei Interesse kannst dich gerne mal melden, könnten es event zusammen mal testen.

[juPP]

Um die Firewall zu umgehen könntest du auch dein programm in ein programm injecten welches in der firewall in der regel frei ist

[Born2Hack]

@juPP 

 

Sehr gute Idee, daran habe ich auch schon gedacht , aber noch nicht getestet.

 

Ich würde dann auf den ieexplorer tippen, weil so ziemlich jeder das Ding installiert hat.

Bearbeitet von Born2Hack, 06 July 2015 - 17:44 Uhr.

[n1nja]

Kommt drauf an, welche File du injecten willst. .Net Application kannst du auch in der vbc.exe laden.

[Born2Hack]

Wenn ich in die vbc.exe injecte meldet sich die Firewall. Mein Ziel ist es ein Crypter zu schreiben der die gängigste maleware egal ob

native/managed unterstützt. 

Und die Firewalls bypasst. 

 

Dabei wollte ich aber auch semtlichen schadcode aus dem Programm selbst raushalten (in dll's im Internet)

Die buildete Output Datei besteht nur aus ca 4 Zeilen  code und beträgt 7kb Dann ist es viel einfacher die Datei FUD zu halten da ja kaum Code enthalten ist. 

Alles wird zur Laufzeit ins Programm geladen. 

Als nächstes würde mich intressieren wie ein eof Support einbinden kann. Wenigstens die Theorie den code kann ich dann selber schrieben. 

[n1nja]

Also benutzt du Codedom zum Code ausführen?!

Ob du den Code so ausführst oder herunterlädst, kommt zum Schluss aufs selbe raus.

 

Da ja sowieso alles in IL "umgewandelt" wird.

 

EOF -  End of File:

Du schreibst die Daten/Maleware ans Ende der Stub.

Mehr ist es nicht

[Born2Hack]

Der Code selbst wird nicht per CodeDom ausgeführt,  sondern nur die exe erstellt/gespeichert.

Beim ausführen der exe wird dann die dll in den Speicher geladen(von xup.in) und zur Laufzeit ausgeführt. 

Wie jede andere ganz normale .dll eben nur das sie nicht auf der Festplatte liegt. Würde ich die dll in die Resourcen packen hätten dann die Antivirenscanner mehr Angriffsfläche zum scannen & die output datei wäre dann auch um einiges größer. Wenn du verstehst was ich meine.

 

Viele Rats Stealer Keylogger etc. hängen die Daten einfach ans Ende der Stub.

Deswegen muss ja die .exe die ich per codedom erstelle auch die EOF Daten haben mit den Splitzeichen etc. 

Damit die server.exe ordentlich funktionieren kann.
Oder habe ich da ein Denkfehler ?

Bearbeitet von Born2Hack, 06 July 2015 - 18:47 Uhr.

[n1nja]

Ich versteh was du meinst. Allerdings wie gesagt, glaube ich zu wissen, das es nicht viel bringen wird.

Ich hab das auch mal vorgehabt, leider ohne positives Ergebniss.

 

Du könntest allerdings komplett alles verschlüsseln und erst beim Ausführen entschlüsseln, sodas im RAM der verschlüsselte Code "entpackt" wird

und dann wie gewohnt weiter arbeiten lassen.

[Ar@m!s]

Wie erkennt man die Daten die am Ende einer.exe geschrieben worden sind ?

 

 

Im Pe Header kann man auslesen wie groß die exe sein sollte.
Ist sie größer weißt du das EOF Daten vorhanden sind und wo sie beginnen.

[sup3ria]

Früher wurde EoF anhand einem Chr erkannt (CTRL+Z oder 26 oder 0x1A).

Also dann als binary stream geöffnet und dann eben bis zum EoF Char ausfeführt.

Ich denke das wird aber nicht mehr gemacht.

 

Ich könnte das jetzt genauer beschreiben aber Ich denke es macht keinen sinn zu implementieren, da Malware die EoF verwendet eh scheisse ist.

[n1nja]

Man kann es aber auch mit den alten VB6 mitten machen und FileSplit verwenden:)

Da hat man ein Trennzeichen bzw einen Trennstring zB. "n1nja".

[juPP]

Du kannst deine zu verschlüsselnde datei auch in eine neue section der pe hinzufügen, EOF ist tatsächlich eher ne unschöne Lösung

[Trillium]

Hey also hier mal ein Beispiel ist zwar VB6 aber sollte sich leicht zu VB.Net umwandeln lassen:

Public Function ReadEOFData(sFilePath As String) As String
On Error GoTo Err:
Dim sFileBuf As String, sEOFBuf As String, sChar As String
Dim lFF As Long, lPos As Long, lPos2 As Long, lCount As Long
If Dir(sFilePath) = "" Then GoTo Err:
lFF = FreeFile
Open sFilePath For Binary As #lFF
sFileBuf = Space(LOF(lFF))
Get #lFF, , sFileBuf
Close #lFF
lPos = InStr(1, StrReverse(sFileBuf), GetNullBytes(30))
sEOFBuf = (Mid(StrReverse(sFileBuf), 1, lPos - 1))
ReadEOFData = StrReverse(sEOFBuf)
Err:
ReadEOFData = vbNullString
End Function

Sub WriteEOFData(sFilePath As String, sEOFData As String)
Dim sFileBuf As String
Dim lFF As Long
On Error Resume Next
If Dir(sFilePath) = "" Then Exit Sub
lFF = FreeFile
Open sFilePath For Binary As #lFF
sFileBuf = Space(LOF(lFF))
Get #lFF, , sFileBuf
Close #lFF
Kill sFilePath
lFF = FreeFile
Open sFilePath For Binary As #lFF
Put #lFF, , sFileBuf & sEOFData
Close #lFF
End Sub

Public Function GetNullBytes(lNum) As String
Dim sBuf As String
Dim i As Integer
For i = 1 To lNum
sBuf = sBuf & Chr(0)
Next
GetNullBytes = sBuf
End Function

So liest du die Eof Daten von dem zu Cryptenden Datei ein:

 

Dim Eof as String

 

Eof = ReadEofData(Dein File.exe)

 

 

und nach dem du mim crypt process fertig bist fügst du das hinzu

 

Call WriteEofData(Crypted.exe,Eof)

 

Natürlich ist das CryptedFile dann detected weil die größen im PE Header nicht mehr mit der Data übereinstimmen müsstest sie alle wieder neu berechnen z.b. SizeOfImage, BaseOfCode, BaseOfData , Checksum usw dann isses auch wieder FUD

 

Am besten ist man denkt sich seine eigene Storage Methode aus hier mal eine Private von mir :

 

Das Crypted File + Settings zu nem ByteArray machen den ByteArray zu einem Icon Umwandeln den Crypter (Builder) das Icon

auf die Stub Changen lassen und dann einfach das Icon in der Stub einlesen umwandeln zu nem bytearray und dann kann man damit arbeiten Nachteil bei dieser Methode wenn man das Icon des Crypted File ändert funzt es net mehr.

 

Ne andere Methode wäre einfach die Datei in den Dos Header Schreiben und die Pointer Updaten

 

 

So zu den Resourcen ne musst du nicht aber z.b. wenn dein Server.exe ein Password Recovery Tool und nutzt die Nirsoft Resourcen die bei der ausführung gedroppt werden isses Runtime nicht FUD weil das AV die Nirsoft Tools erkennt das problem kannste lösen in dem du prüfst ob das zu Cryptende File Resourcen hat liest sie jede einzeln ein verschlüsselt sie und fügst sie zum  Crypted.exe File hinzu und dann halt bei Runtime Decrypten.

 

 

MFG

Trillium