pe.log¶
Earlier we looked at the data provided by Zeek’s files.log. In this
section we will take a step further for one type of log – Zeek’s
pe.log. In this instance, “pe” stands for portable executable, a format
associated with Microsoft binaries.
For more details on the specifics of the format, please refer to
PE::Info.
Starting with conn.log¶
This example starts with the conn.log. It’s not strictly necessary to
explain the pe.log, although I wanted to include a very recent example
of a modern application conducting activities via HTTP.
{
"ts": "2020-09-23T00:24:31.210053Z",
"uid": "Cq2b9jR12c4lqZafg",
"id.orig_h": "192.168.4.152",
"id.orig_p": 59125,
"id.resp_h": "63.88.73.83",
"id.resp_p": 80,
"proto": "tcp",
"service": "http",
"duration": 25.614583015441895,
"orig_bytes": 5753,
"resp_bytes": 1975717,
"conn_state": "SF",
"local_orig": true,
"local_resp": false,
"missed_bytes": 0,
"history": "ShADadttFf",
"orig_pkts": 521,
"orig_ip_bytes": 29041,
"resp_pkts": 1367,
"resp_ip_bytes": 2030409,
}
This example shows a host, 192.168.4.152, conducting a HTTP session with
63.88.73.83 over port 80 TCP. The server sends 2 MB of content to the
client.
Continuing with http.log¶
The http.log entries associated with UID Cq2b9jR12c4lqZafg are
fascinating. There are multiple entries. I have reproduced a sample of them
below.
{
"ts": "2020-09-23T00:24:31.235201Z",
"uid": "Cq2b9jR12c4lqZafg",
"id.orig_h": "192.168.4.152",
"id.orig_p": 59125,
"id.resp_h": "63.88.73.83",
"id.resp_p": 80,
"trans_depth": 1,
"method": "HEAD",
"host": "r8---sn-8xgp1vo-p5ql.gvt1.com",
"uri": "/edgedl/release2/chrome/SAWXCyZhLAbPfxC5kv_Fkw_85.0.4183.121/85.0.4183.121_85.0.4183.102_chrome_updater.exe?cms_redirect=yes&mh=t-&mip=-public-ip-edited-&mm=28&mn=sn-8xgp1vo-p5ql&ms=nvh&mt=1600820539&mv=m&mvi=8&pl=19&shardbypass=yes",
"version": "1.1",
"user_agent": "Microsoft BITS/7.8",
"request_body_len": 0,
"response_body_len": 0,
"status_code": 200,
"status_msg": "OK",
"tags": []
}
The first entry shown above provides details on a HEAD request for a binary
titled 85.0.4183.121_85.0.4183.102_chrome_updater.exe. The user agent is
the Microsoft Background Intelligent Transfer Service (BITS). The server
responses with a successful message, 200 OK. Note that I have inserted
-public-ip-edited- in the URI rather than expose the public IP address of
the system requesting this file.
The fact that the BITS client provides the public IP address in the URI indicates that either the server is sending this information to the client, or that the client is requesting this information from an Internet-residing system. There is no native way for this client to know its public IP address when it is sitting behind a network address (port) translation device.
This aspect of the URI could help administrators better understand their
networks, as it can sometimes be difficult to map private IP addresses (like
192.168.4.152) to their public representations (here
-public-ip-edited-).
Also note the value for the host field showing
r8---sn-8xgp1vo-p5ql.gvt1.com. I resolved the odd name to see the
following:
$ host r8---sn-8xgp1vo-p5ql.gvt1.com
r8---sn-8xgp1vo-p5ql.gvt1.com is an alias for r8.sn-8xgp1vo-p5ql.gvt1.com.
r8.sn-8xgp1vo-p5ql.gvt1.com has address 63.88.73.83
r8.sn-8xgp1vo-p5ql.gvt1.com has IPv6 address 2600:803:f00:1::13
Let’s look at the next http.log entry.
{
"ts": "2020-09-23T00:24:31.334435Z",
"uid": "Cq2b9jR12c4lqZafg",
"id.orig_h": "192.168.4.152",
"id.orig_p": 59125,
"id.resp_h": "63.88.73.83",
"id.resp_p": 80,
"trans_depth": 2,
"method": "GET",
"host": "r8---sn-8xgp1vo-p5ql.gvt1.com",
"uri": "/edgedl/release2/chrome/SAWXCyZhLAbPfxC5kv_Fkw_85.0.4183.121/85.0.4183.121_85.0.4183.102_chrome_updater.exe?cms_redirect=yes&mh=t-&mip=-public-ip-edited-&mm=28&mn=sn-8xgp1vo-p5ql&ms=nvh&mt=1600820539&mv=m&mvi=8&pl=19&shardbypass=yes",
"version": "1.1",
"user_agent": "Microsoft BITS/7.8",
"request_body_len": 0,
"response_body_len": 1392,
"status_code": 206,
"status_msg": "Partial Content",
"tags": [],
"resp_fuids": [
"FGYKX64SkXc4OcvlFf"
]
}
In the previous http.log entry we see that the BITS client has made a
GET request for the same file. The server is providing it via “partial
content”, represented by the 206 status code.
Also note we now have a file UID present in the http.log:
FGYKX64SkXc4OcvlFf.
The next http.log entry is similar, although the amount of data sent is
different.
{
"ts": "2020-09-23T00:24:35.247333Z",
"uid": "Cq2b9jR12c4lqZafg",
"id.orig_h": "192.168.4.152",
"id.orig_p": 59125,
"id.resp_h": "63.88.73.83",
"id.resp_p": 80,
"trans_depth": 3,
"method": "GET",
"host": "r8---sn-8xgp1vo-p5ql.gvt1.com",
"uri": "/edgedl/release2/chrome/SAWXCyZhLAbPfxC5kv_Fkw_85.0.4183.121/85.0.4183.121_85.0.4183.102_chrome_updater.exe?cms_redirect=yes&mh=t-&mip=-public-ip-edited-&mm=28&mn=sn-8xgp1vo-p5ql&ms=nvh&mt=1600820539&mv=m&mvi=8&pl=19&shardbypass=yes",
"version": "1.1",
"user_agent": "Microsoft BITS/7.8",
"request_body_len": 0,
"response_body_len": 1995,
"status_code": 206,
"status_msg": "Partial Content",
"tags": []
}
I have removed the half a dozen or so intervening messages as they are very similar to the preceding entries. I include the last one for reference. It is similar to the previous entries, although the response body length shows much more data was sent.
{
"ts": "2020-09-23T00:24:46.547359Z",
"uid": "Cq2b9jR12c4lqZafg",
"id.orig_h": "192.168.4.152",
"id.orig_p": 59125,
"id.resp_h": "63.88.73.83",
"id.resp_p": 80,
"trans_depth": 12,
"method": "GET",
"host": "r8---sn-8xgp1vo-p5ql.gvt1.com",
"uri": "/edgedl/release2/chrome/SAWXCyZhLAbPfxC5kv_Fkw_85.0.4183.121/85.0.4183.121_85.0.4183.102_chrome_updater.exe?cms_redirect=yes&mh=t-&mip=-public-ip-edited-&mm=28&mn=sn-8xgp1vo-p5ql&ms=nvh&mt=1600820539&mv=m&mvi=8&pl=19&shardbypass=yes",
"version": "1.1",
"user_agent": "Microsoft BITS/7.8",
"request_body_len": 0,
"response_body_len": 652148,
"status_code": 206,
"status_msg": "Partial Content",
"tags": []
}
That concludes the relevant http.log entries. Using the file UID we can
search the files.log next.
Continuing with files.log¶
The relevant files.log entry contains the following:
{
"ts": "2020-09-23T00:24:31.334435Z",
"fuid": "FGYKX64SkXc4OcvlFf",
"tx_hosts": [
"63.88.73.83"
],
"rx_hosts": [
"192.168.4.152"
],
"conn_uids": [
"Cq2b9jR12c4lqZafg"
],
"source": "HTTP",
"depth": 0,
"analyzers": [
"MD5",
"PE",
"SHA1",
"EXTRACT"
],
"mime_type": "application/x-dosexec",
"duration": 15.468528032302856,
"local_orig": false,
"is_orig": false,
"seen_bytes": 1967360,
"total_bytes": 1967360,
"missing_bytes": 0,
"overflow_bytes": 0,
"timedout": false,
"md5": "a5843bd951f148e99b7265e5bd159fb7",
"sha1": "fc8b8deb5b34fec1f3f094e579667b2bddee0b21",
"extracted": "/nsm/zeek/extracted/HTTP-FGYKX64SkXc4OcvlFf.exe",
"extracted_cutoff": false
}
This files.log entry shows that the content returned by the BITS server
included a Windows executable. Zeek calculates MD5 and SHA1 hashes, and also
shows the location on disk for the extracted file.
Do you remember a similar entry from the Zeek documentation on
files.log?
"analyzers": [
"EXTRACT",
"PE"
],
In that example, we have active extract and PE analyzers.
In the current files.log, we have additional analyzers present:
"analyzers": [
"MD5",
"PE",
"SHA1",
"EXTRACT"
],
Thanks to these analyzers, we have the MD5 and SHA1 hashes, along with a
pe.log entry and an extracted file.
Continuing with pe.log¶
Finally we come to the pe.log. We are able to connect it with the
appropriate activity using the file UID FGYKX64SkXc4OcvlFf.
{
"ts": "2020-09-23T00:24:36.395445Z",
"id": "FGYKX64SkXc4OcvlFf",
"machine": "AMD64",
"compile_ts": "2020-09-19T00:10:08.000000Z",
"os": "Windows XP x64 or Server 2003",
"subsystem": "WINDOWS_GUI",
"is_exe": true,
"is_64bit": true,
"uses_aslr": true,
"uses_dep": true,
"uses_code_integrity": false,
"uses_seh": true,
"has_import_table": true,
"has_export_table": false,
"has_cert_table": true,
"has_debug_data": true,
"section_names": [
".text",
".rdata",
".data",
".pdata",
".00cfg",
".rsrc",
".reloc"
]
}
The compile time is one of the more interesting details for analysts. This is a freshly compiled Windows executable.
Reviewing the Extracted Binary¶
As we did in the files.log documentation, we can analyze our extracted
file using the command line version of VirusTotal.
Here is the extracted file on disk. Notice the filename includes the file UID
calculated by Zeek, i.e., FGYKX64SkXc4OcvlFf.
$ file /nsm/zeek/extracted/HTTP-FGYKX64SkXc4OcvlFf.exe
/nsm/zeek/extracted/HTTP-FGYKX64SkXc4OcvlFf.exe: PE32+ executable (GUI) x86-64, for MS Windows
We use the Linux md5sum utility to calculate the MD5 hash.
$ md5sum /nsm/zeek/extracted/HTTP-FGYKX64SkXc4OcvlFf.exe
a5843bd951f148e99b7265e5bd159fb7 /nsm/zeek/extracted/HTTP-FGYKX64SkXc4OcvlFf.exe
Note the MD5 hash matches the one provided by Zeek in the files.log
entry.
Next we submit the hash, not the binary, to VirusTotal for analysis. Whenever possible, submit hashes to cloud file analysis engines. This preserves the confidentiality of your sample.
The output is edited for readability.
$ vt file a5843bd951f148e99b7265e5bd159fb7
- _id: "14a1b9947b77174244a6f6bfd2cd7e1b1c860a09b3b5d74f07b81e45b5548de4"
_type: "file"
authentihash: "a4a6a1011bb3e33af37a1dce19bd41b72d5360dc4175d570ec7260d1d9815747"
creation_date: 1600474208 # 2020-09-19 00:10:08 +0000 UTC
first_submission_date: 1600711798 # 2020-09-21 18:09:58 +0000 UTC
last_analysis_date: 1600840562 # 2020-09-23 05:56:02 +0000 UTC
last_analysis_results:
ALYac:
category: "undetected"
engine_name: "ALYac"
engine_update: "20200923"
engine_version: "1.1.1.5"
method: "blacklist"
...edited...
eGambit:
category: "undetected"
engine_name: "eGambit"
engine_update: "20200923"
method: "blacklist"
last_analysis_stats:
confirmed-timeout: 0
failure: 0
harmless: 0
malicious: 0
suspicious: 0
timeout: 0
type-unsupported: 4
undetected: 69
last_modification_date: 1600878930 # 2020-09-23 16:35:30 +0000 UTC
last_submission_date: 1600830769 # 2020-09-23 03:12:49 +0000 UTC
magic: "PE32+ executable for MS Windows (GUI) Mono/.Net assembly"
md5: "a5843bd951f148e99b7265e5bd159fb7"
meaningful_name: "mini_installer"
names:
- "85.0.4183.121_85.0.4183.102_chrome_updater.exe"
- "mini_installer"
- "HTTP-FjcOYuaXbbQFV1cJj.exe"
pe_info:
entry_point: 4096
imphash: "ec06ab323a50409817b4a6a54b98f157"
import_list:
- imported_functions:
- "CommandLineToArgvW"
library_name: "SHELL32.dll"
- imported_functions:
- "GetLastError"
- "GetVolumePathNameW"
...edited...
- "GetEnvironmentVariableW"
library_name: "KERNEL32.dll"
machine_type: 34404
overlay:
chi2: 1124223.375
entropy: 4.492208003997803
filetype: "binary Computer Graphics Metafile"
md5: "ddc7adbbc3760a81d8510e57fedbe055"
offset: 1951232
size: 16128
resource_details:
- chi2: 286.0988464355469
entropy: 7.999892711639404
filetype: "Data"
lang: "ENGLISH US"
sha256: "133ccfebc6cebb05333ed1677bb419716a8ad00b39417f2f4fa6ee45bdbb92df"
type: "B7"
...edited...
timestamp: 1600474208
reputation: 0
sha1: "fc8b8deb5b34fec1f3f094e579667b2bddee0b21"
sha256: "14a1b9947b77174244a6f6bfd2cd7e1b1c860a09b3b5d74f07b81e45b5548de4"
signature_info:
copyright: "Copyright 2020 Google LLC. All rights reserved."
counter signers: "TIMESTAMP-SHA256-2019-10-15; DigiCert SHA2 Assured ID Timestamping CA; DigiCert"
counter signers details:
- algorithm: "sha256RSA"
cert issuer: "DigiCert SHA2 Assured ID Timestamping CA"
name: "TIMESTAMP-SHA256-2019-10-15"
serial number: "04 CD 3F 85 68 AE 76 C6 1B B0 FE 71 60 CC A7 6D"
status: "Valid"
thumbprint: "0325BD505EDA96302DC22F4FA01E4C28BE2834C5"
valid from: "12:00 AM 10/01/2019"
valid to: "12:00 AM 10/17/2030"
valid usage: "Timestamp Signing"
- algorithm: "sha256RSA"
cert issuer: "DigiCert Assured ID Root CA"
name: "DigiCert SHA2 Assured ID Timestamping CA"
serial number: "0A A1 25 D6 D6 32 1B 7E 41 E4 05 DA 36 97 C2 15"
status: "Valid"
thumbprint: "3BA63A6E4841355772DEBEF9CDCF4D5AF353A297"
valid from: "12:00 PM 01/07/2016"
valid to: "12:00 PM 01/07/2031"
valid usage: "Timestamp Signing"
- algorithm: "sha1RSA"
cert issuer: "DigiCert Assured ID Root CA"
name: "DigiCert"
serial number: "0C E7 E0 E5 17 D8 46 FE 8F E5 60 FC 1B F0 30 39"
status: "Valid"
thumbprint: "0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43"
valid from: "12:00 AM 11/10/2006"
valid to: "12:00 AM 11/10/2031"
valid usage: "Client Auth, Code Signing, Email Protection, Server Auth, Timestamp Signing"
description: "Google Chrome Installer"
file version: "85.0.4183.121"
internal name: "mini_installer"
product: "Google Chrome Installer"
signers: "Google LLC; DigiCert SHA2 Assured ID Code Signing CA; DigiCert"
signers details:
- algorithm: "sha256RSA"
cert issuer: "DigiCert SHA2 Assured ID Code Signing CA"
name: "Google LLC"
serial number: "0C 15 BE 4A 15 BB 09 03 C9 01 B1 D6 C2 65 30 2F"
status: "Valid"
thumbprint: "CB7E84887F3C6015FE7EDFB4F8F36DF7DC10590E"
valid from: "12:00 AM 11/07/2018"
valid to: "12:00 PM 11/17/2021"
valid usage: "Code Signing"
...edited...
ssdeep: "49152:zS2WLLoAgkZlbpkJDy5KrwM4wN9UT90hZv6AFV56vt9IWA:m2WvgSbpkFAKrwMpTZJV5kgW"
tags:
- "peexe"
- "assembly"
- "overlay"
- "runtime-modules"
- "signed"
- "64bits"
- "trusted"
times_submitted: 2
total_votes:
harmless: 0
malicious: 0
trid:
- file_type: "OS/2 Executable (generic)"
probability: 33.6
- file_type: "Generic Win/DOS Executable"
probability: 33.1
- file_type: "DOS Executable Generic"
probability: 33.1
trusted_verdict:
filename: "85.0.4183.121_85.0.4183.102_chrome_updater.exe"
link: "https://dl.google.com/dl/release2/chrome/SAWXCyZhLAbPfxC5kv_Fkw_85.0.4183.121/85.0.4183.121_85.0.4183.102_chrome_updater.exe"
organization: "Google"
verdict: "goodware"
type_description: "Win32 EXE"
type_tag: "peexe"
unique_sources: 2
vhash: "016076651d151515751az36hz1lz"
This file appears to be a component of the Google Chrome Installer. It is not malicious software.
Conclusion¶
Although the pe.log was only part of this section, I wanted to show an
integrated set of Zeek logs for this example, beginning with the
conn.log, continuing with the http.log and files.log,
and concluding with the pe.log. This is recent activity and shows that
modern software still uses HTTP in some cases!