Posted by InfoSec News on Sep 18
https://theconversation.com/payid-data-breaches-show-australias-banks-need-to-be-more-vigilant-to-hacking-123529By Paul Haskell-Dowland
theconversation.com
September 17, 2019
When we think of a bank robbery, we might imagine a safe with the door blown
open. But nowadays it might be more accurate to picture criminals accessing our
bank account online from another country. Bank robbers don’t need balaclavas
and shotguns anymore.
Australian...
Posted by InfoSec News on Sep 18
https://www.theregister.co.uk/2019/09/17/small_office_home_office_network_kit_security/By Tim Anderson
The Register
17 Sep 2019
A new report has suggested that 12 out of 13 network devices, such as routers
and network-attached storage appliances, are vulnerable to hacks that enable
"root-privileged access without any authentication".
Security consultants ISE took a look at devices from well-known vendors
including Buffalo,...
Posted by InfoSec News on Sep 18
https://www.lawfareblog.com/self-help-cyberspace-path-forwardBy Wyatt Hoffman, Ariel E. Levite
Lawfare.com
September 16, 2019
Recent years have seen sustained calls to “unleash” the private sector to more
assertively combat cyber threats. The argument has gained some sympathy in
Congress, where Rep. Tom Graves (R-Ga.) recently reintroduced the Active Cyber
Defense Certainty Act (ACDCA). As Bobby Chesney summarizes, the act, if passed,...
Posted by InfoSec News on Sep 18
https://www.atlanticcouncil.org/blogs/new-atlanticist/the-american-way-of-cyber-warfare-and-the-case-of-isis/By JD Work
The Atlantic Council
September 17, 2019
Many in the defense community have still not embraced hacking as a combat
mission or the work of securing systems and networks transitioning from
administrative job into warfighting function. This transformation has led to
much theorization and debate, yet as a practical matter...
Posted by InfoSec News on Sep 18
https://arstechnica.com/information-technology/2019/09/millions-of-americans-medical-images-and-data-are-available-on-the-internet/By Jack Gillum, Jeff Kao and Jeff Larson
PROPUBLICA
9/17/2019
Medical images and health data belonging to millions of Americans, including
X-rays, MRIs, and CT scans, are sitting unprotected on the Internet and
available to anyone with basic computer expertise.
The records cover more than 5 million patients in the...
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
I saw the same type of artifacts on my infected Windows host that I'd seen in recent Emotet and/or Trickbot infections. See the images below for details.
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]\AppData\Local\[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]\AppData\Local\[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]\AppData\Roaming\MyCloud\[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
I recently TA'd the SANS SEC 504 class (Hacker Tools, Techniques, Exploits, and Incident Handling) , and one of the topics we covered was attackers "editing" windows event logs to cover their tracks, 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 these days. This attack is easily scripted, so the whole sequence takes just seconds.
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 = "\\sharename\log-gaps\"+ $env:COMPUTERNAME+"-log-gaps.csv" |
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 \\sharename\log-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 <at> coherentsecurity.com
