NDISPlan phishing/malware email

Based on my previous blog entry about emails I have analysed an email that was received from *@ndis.gov.au.

From the email it seems that you have received an email for a Shelby’s plan. A question to ask who is Shelby ?

File name  – Shelby-MyNDISPlan.zip – Have checked online and identified this is indeed a spam email. myonlinesecurity.co.uk/ndisplan-fake-pdf-malware

Extracted file – Shelby- MyNDISPlan.scr – yes the plan is a screensaver 🙂

Exiftool results :

ExifTool Version Number : 10.00
File Name : Shelby- MyNDISPlan.scr
Directory : .
File Size : 40 kB
File Modification Date/Time : 2015:09:22 15:46:02+10:00
File Access Date/Time : 2015:09:23 16:01:49+10:00
File Inode Change Date/Time : 2015:09:23 15:59:42+10:00
File Permissions : rw——-
File Type : Win32 EXE
File Type Extension : exe
MIME Type : application/octet-stream
Machine Type : Intel 386 or later, and compatibles
Time Stamp : 2015:03:30 09:35:32+11:00
PE Type : PE32
Linker Version : 7.10
Code Size : 11264
Initialized Data Size : 29184
Uninitialized Data Size : 0
Entry Point : 0x18ee
OS Version : 4.0
Image Version : 0.0
Subsystem Version : 4.0
Subsystem : Windows GUI
File Version Number :
Product Version Number :
File Flags Mask : 0x0000
File Flags : (none)
File OS : Win32
Object File Type : Executable application
File Subtype : 0
Language Code : Spanish (Castilian)
Character Set : Unknown (90A0)
Company Name : MonlinA Corporation
File Description : MonlinA launch tools
File Version : 7.00.146
Internal Name : monlin.EXE
Legal Copyright : В©MonlinA Corporation. All rights reserved.
Original File Name : monlin.EXE
Product Name : MonlinAВ® launch tools
Product Version : 1.00.146

This is indeed suspicious as the SCR file has an exe embedded which is monlin.exe.

Dynamic analysis files provided no communication to any external hosts or IP addresses.

Likely the file changes values within registry or a process in relation to a screensaver. Also, will try and run the EXE and see the changes.

Sandbox > https://tria.ge/220423-q1jjmsggfk/behavioral1

Identified as Upatre – https://malpedia.caad.fkie.fraunhofer.de/details/win.upatre

Emails – The good, The bad and The ugly side

Emails – as we know is a very efficient way to communicate without physically visiting the intended recipients. Emails have been with us from many years and initial take for email was to reduce time and effort in communication.

But recently emails are being used for social engineering and phishing. Forget about the good old days where you were receiving emails only from known parties. Now even prince of Nigeria have your email and wants to give you money.

As an security researcher and a SOC analyst, have noticed that email communication is top and one of most used channel to transfer these malicious files. It’s like yelling name John in a crowd. Somebody will eventually respond.

Detecting suspicious emails ?

  1. Language  – typos and grammar will be there – sometimes they are not.
  2. Sender domain – may have typo or a legitimate one.
  3. Roll over you mouse to the embedded links in the email and you will see random site.
  4. Attachment – names are too close or suspicious.

The best way to fight this is with user awareness. Emails exploit most vulnerable entity  – HUMAN. A mind where curiosity inevitably kills the cat.

Attackers thrives on 2 human characteristics – FEAR and CURIOSITY.

  1. FEAR – we have noticed a suspicious transaction on your account. Please click on this link to change the password.
  2. CURIOSITY – sorry we have missed you and have a package waiting for you. Please open the attached file to get more information. There is package indeed but for your PC – malware I mean 🙂

Other ways to detect :

  1. Mail gateways with proper monitoring
  2. DLP – can be used to monitor the content of the email.


Hunting as an SOC analyst

Been security analyst in SOC for more than 3 years. Besides waiting for the alerts triggering from the device such as IPS or end point protection, one can write up rules in SIEM to analyse logs. SIEM needs to be constantly updated with new Intel. Below are few things that I look for for a customer during hunting remotely or on-site. Understand Incident response and threat hunting can be integrated.

  1. Central logging place such as SIEM logs from various network devices.
  2. Traffic violating security standards.
  3. Traffic going to or coming from countries where customer does not do business with.
  4. Access/running executables or confidential files on hosts/servers – this can be done by acceptable use monitoring.
  5. Threat intelligence and/or threat feeds – open source and subscribed and matching against the logs.
  6. Endpoint protection logs – especially the ones that are cleaned or quarantined. We need to understand how endpoint and/or AV vendors are identifying or logging these entries to get a broader picture and what type of tools or malware are being used against you.
  7. Publicly available information for the customer and analysing how that information can be used to target customers and monitoring those open doors.
  8. Windows logs – privilege escalation, failed attempts, user accounts on the system, which user logged into the system, what services/process running, one can also make list of folders that should not have any executables or services starting from.
  9. Proxy and/or DNS logs – suspicious packets, HTTP request, large/similar number of bytes in and bytes out, any traffic going via clear-text protocols such as 22. Look for specific keywords in DNS logs, also check what DNS servers requests are going – may find some foreign DNS.

To identify IOCs and/or malicious entities independent of any customer logs:

  1. Randomly accessing websites on top-level domains to identify any suspicious/malicious re-direction – the traffic is passed to the interface being monitored by snort. Windows machine will also have procmon with Virus Total integration and ofcourse wireshark.
  2. Analysing spam emails and run it over Security Onion to see if any alerts gets trigger. Extract domains and IP address and use them in the SIEM.
  3. Check specific parameters in the URL/HTTP requests that can be used to exploit web applications – although the IDPS may trigger the rule for it but there are instances where we do not get IDPS logs.
  4. Lastly, honeypot to identify bad actors.
  5. Lurking on private forums, IRC and dark web – hell yeah.
  6. Following threat campaigns.

Hope this helps. Happy hunting!!!!!!