When an endpoint wants to communicate to internet within a IT infrastructure that requires all internet traffic have to pass a proxy. If you want to have more details about this topic, I can recommend reading the following blog post: -part-6-how-https-proxies-work/. The goal for this blog is not to explain in detail how a web proxy works. The problem: The effect of a non-transparent proxy on network connections The intention is to identify which process is responsible for communicating with this IP. One of these applications is connecting to IP 35.178.122.152. To make it as realistic as possible, the endpoint 172.31.16.50 is used to setup multiple connections to hosts on the internet using different applications. The endpoint with IP 172.31.16.50 is used to perform our memory forensics on. This server forwards the traffic to the gateway and sends back the result to the client. The host with IP 172.31.0.250 is the internal web proxy server. I have created a small lab setup to simulate an infrastructure where communications to the internet need to go through a web proxy. In this blog post I will explain how you can solve this with Volatility and strings. No other sources, except a memory dump, are available to you where you could find this information.An IT infrastructure where a non-transparent proxy is used for all outgoing network traffic (this is the case in many enterprise networks).However, answering this question is challenging when you have to deal with the following: It can really help your investigation when you know which process (or sometimes processes) are involved. One of the questions you will have is what is causing this traffic. malware calling home to its C2 server for new instructions). For example, because the IP is showing a suspicious beaconing traffic pattern (i.e. This does, however, benefit defenders as it is much more likely to get detected by AV/EDR tools if it has been seen previously before in the wild.Īlso, you may have missed it, but the Pastebin link contained a username and the number of how many times it was viewed.When dealing with an incident it can often happen that your starting point is a suspicious IP. This could indicate that the threat actor behind these attacks has not altered the payload for other campaigns, but is changing the delivery technique. It turns out the first file (the second stage payload) has been seen before by VirusTotal several months ago and was previously called Stub.exe. According to VirusTotal, the file ASTRO-GREP.EXE was created on yet the document was created on . Although the other EXEs were not necessarily used in these attack, they are malicious and I would consider blocking them too.įurther investigation into the malware samples used in this campaign revealed some more interesting features. We now have a clearer picture of the scope of the campaign and additional IOCs to prevent any further attacks from this infrastructure. Using the VirusTotal relations tab I (admittedly with the help of who beat me to it 😉) was able to locate the C&C server used to deliver the second stage payload: Using the IOCs we have gathered from the sandbox I investigated the infrastructure used by the threat actor further. I like to use several platforms for this including VirusTotal, Maltego, and draw.io, among others. If you have been reading my blog or following me on Twitter It is no secret that one of my favourite parts about threat analysis is mapping campaigns. Legitimate app - VT here, Sourceforge here.
We can see that WINDWORD.EXE drops ms.exe, which leads to two files: ASTRO-GREP.EXE (the malware) and ASTROGREP_SETUP_V4.4.7.EXE (the legitimate installer):
0 kommentar(er)
