Over the weekend, I wanted to run through an advanced attack scenario where a user would open and seemingly innocent phishing email which contains an email attachment of a .html webpage that, when clicked, a payload would deploy a piece of malware with a reverse TCP connection back to a C&C (Command & Control Server).
My goal was simple; I wanted to play for both the red and blue teams. The steps required to perform this attack went as follows:
The Red Team:
1. Create a clone of Google.com and save as a .html
2. Create an undetectable malware
3. Embed malware into the .html
4. Create phishing email with the .html file
5. Execute the malware
6. Redirect the .html to the legitimate Google.com
7. Create a reverse shell connection back to my C2 server
8. Execute PowerShell
The Blue Team:
1. Use Azure Sentinel to threat hunt the attack
2. Get the IP address of the C2 server
3. Stop Malware from spreading
4. Celebrate with a 12 Yr Macallan
Tools & Technologies used:
1. Kali Linux
2. SEToolKit
3. MSFVenom
4. WinPayloads
5. Metasploit Framework
6. Azure Sentinel
7. PowerShell
8. A lot of coffee & a big lunch
I began making a simple clone of a website. For this demonstration I used the SEToolKit within Kali Linux to create a clone of Google.com and then MSFVenom and WinPayloads to create the malware and reverse meterpreter tcp connection. Once that was all created, it was time to begin the attack.
A user receives and email.
Subject line:
“Hey, check this out new Google !! ”
As soon as the user opened the Google.html, they get a low-grade version of Google. The screen shot below shows the exact page the user sees.
After 1 second, it redirects to the real google (making it seem as though everything is okay).
Everything still seems relatively normal; the user goes about their business and day to day activities, none the wiser. But as soon as the user opened the HTML link, it actually launched a payload in the background. This payload is called “thebadguy.exe”. Unless the user is quite IT savvy, they may or may not open task manager and essentially “look” to see what processes are running, if they’re hogging CPU or memory etc.
So let’s assume everything is ok. Let’s flick to the Azure Security Center dashboard to see if we have any alerts.
At this point, there are no alerts in Security Center, so we can carry on with our business as usual. After a short period of time, we receive an incident in Azure Sentinel – “Rare Process Operations”.
So let’s start investigating, using the query below (which raised the incident).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
let starttime = 30m; let endtime = 1d; let ProcessCreationEvents=() { let processEvents=SecurityEvent | where EventID==4688 | where TimeGenerated >= ago(starttime) | project TimeGenerated, ComputerName=Computer,AccountName=SubjectUserName, AccountDomain=SubjectDomainName, FileName=tostring(split(NewProcessName, @ '' )[(-1)]), ProcessCommandLine = CommandLine, InitiatingProcessFileName=ParentProcessName,InitiatingProcessCommandLine= '' ,InitiatingProcessParentFileName= '' ; processEvents}; ProcessCreationEvents | where TimeGenerated >= ago(starttime) and TimeGenerated = ago(endtime) | summarize StartTimeUtc = min(TimeGenerated), EndTimeUtc = max(TimeGenerated), Computers = makeset(ComputerName) , HostCount=dcount(ComputerName) by tostring(FileName) ) on FileName // I've filtered out all common processes to reduce false positives (please feel free to add more) | where FileName !contains "conhost.exe" and FileName !contains "taskhost.exe" and FileName !contains "svchost.exe" and FileName !contains "taskhostex.exe" and FileName !contains "cscript.exe" and FileName !contains "rundll32.exe" and FileName !contains "WmiPrvSE.exe" and FileName !contains "WmiApSrv.exe" and FileName !contains "wermgr.exe" and FileName !contains "pmfexe.exe" and FileName !contains "ngentask.exe" and FileName !contains "sc.exe" and FileName !contains "ASMHost.exe" and FileName !contains "aitagent.exe" | project StartTimeUtc, Computers, HostCount, FileName | extend timestamp = StartTimeUtc |
This query, although it looks quite intense, its derived from the original “new-processes” query which can be found here on the Azure Sentinel GitHub Page. I’ve modified it slightly to exclude common processe, reducing the false positives and noise within Sentinel. We can see below that our query has returned a number of results.
The next step would be followed very closely by searching your entire infrastructure to see if any other computers/machines/servers are infected using Sentinel. Because we know the malware name, running a simple query like the one below should do the trick.
1
2
3
|
SecurityEvent | where EventID==4688 | where Process == "thebadguy.exe" |
We’ve now logged into our VM. If we open PowerShell, we can run Get-NetTCPConnection. This will view all TCP connection properties such as local or remote IP address, local or remote port, and connection state. Why are we doing this? Because we’re trying to see if this piece of malware is communicating to the outside world (i.e. talking to a Command and Control server). Because I am performing this attack locally, it’s displaying my local address – 192.168.124.234 – which is my Kali VM. The screen shot below is showing the outgoing connection & port.
What’s interesting is there are two public addresses which have a secure 443 connection to the internet. Doing a quick “Who IS” shows these are legitimate (MSFT) connections:
https://whois.domaintools.com/40.90.137.124
https://whois.domaintools.com/40.67.251.132
Moving on, doing some more investigation, I’ve found the exact PowerShell command which was used to help launch the payload reverse shell session in the event viewer.
1
|
[System.Text.Encoding] ::UTF8.GetString( [System.Convert] ::FromBase64String(base64-string-goes-here) |
Once run, we can see that it’s returned the PowerShell command, downloading a file using the Net.Webclient cmdlet from the IP of my Kali box.
If we flip over to our Kali VM, we can see that the session is currently successful and it’s active, which means our Kali box is listening and we have a valid connection session.
If we navigate through the meterpreter session, we can actually see we have quite a lot of freedom (because we’re in the Victims PowerShell session). From the screen shot below you can see the computer name, what user I’m running as, that I can get processes information etc.
But I want to check if I have administrator privileges; we can do this by running the below command:
1
2
|
$currentPrincipal = New-Object Security.Principal.WindowsPrincipal( [Security.Principal.WindowsIdentity] ::GetCurrent()) $currentPrincipal .IsInRole( [Security.Principal.WindowsBuiltInRole] ::Administrator) |
As you can see, it’s returned as TRUE…which means I have full administrative access!!
If I do a simple list command I can see a lot of familiar directories
I can download files (i.e. another piece of malware using the Invoke-WebRequest cmdlet). Iin this demonstration, I’m downloading a pwned.jpg to the user’s desktop.
Shortly after running the Invoke-WebRequest, I received an incident alert from Azure Sentinel, because I have previously set these up for capturing any suspicious downloads using PowerShell.
Sentinel is definitely doing its job; it’s captured both incidents (after some in-depth threat-hunting), but notice that Azure Security Center didn’t actually identify the HTML file as malware. This is because there is nothing in it but “legitimate” HTML code (or so the user thinks), so it won’t appear in the Security Center dashboard, nor will you receive an alert. But it did launch the payload, so why wasn’t this picked up by Security Center?
Well, this is because I encoded the payload binary multiple times for it to be fully undetectable by anti-virus (in this case Windows Defender). Windows Defender is great (probably one of the best AVs), but nothing and no one is ever safe from these types of scenarios. It may look like a genuine HTML file, but you don’t know what’s happening in the background. Malware creation is becoming increasingly creative and undetectable.
My Key takeaways:
1. Be sure to educate your entire organization on Security Awareness training.
2. Make sure your antimalware is up to date on every device (this helps with new viruses, trojans and backdoors etc.).
3. Be cautious of email attachments (especially in a .zip).
4. Learn Blue & Red Team security protocols. The best defense is a good offense; if you can create a FUD (fully undetectable) piece of malware, then you can create the protocols and framework to prevent that hitting your organization.
5. Implement a SIEM like Sentinel.
6. Sharing is caring – if you do something similar, share your research.
If you are unsure about the security posture of your business, connect with a New Signature security expert today to assess your current state and help you get to a better position.
About the Author
Craig Fretwell is a New Signature Azure Solutions Architect located in our United Kingdom region. He’s spent the last 12 years focusing on helping customers overcome challenges with cloud-based solutions. His primary focus is on architecting and designing cloud and hybrid solutions in Azure. He loves to troubleshoot problems he’s faced and write about those challenges to help others find success.