6. Perform Browser use-case in Goal 1 and look at sequence generated

Flow of What I Did

Open Microsoft Edge → Go to Skype.com → Download Skype.exe → Open Skype.exe

Looking into Process Sequence

Command to tail docker logs: sudo docker logs -f orientdb --tail 20

Looking at the logs in real time, there were two lines that were related to what I was doing:

System > smss.exe > smss.exe > winlogon.exe > userinit.exe > explorer.exe > msedge.exe > msedge.exe

System > smss.exe > smss.exe > winlogon.exe > userinit.exe > explorer.exe > msedge.exe > Skype-8.72.0.82.exe > Skype-8.72.0.82.tmp > Skype-8.72.0.82.exe

Through the logs, it tells us the process sequence that led to the creation of msedge.exe and Skype.exe.

Out of curiosity, I tried using Google Chrome and got the same process sequence as well. This means that different browsers does not affect process sequence.

Sequence: System > smss.exe > smss.exe > winlogon.exe > userinit.exe > explorer.exe > chrome.exe > chrome.exe

Some information about the processes:

Skype-8.72.0.82.tmp: A TMP file is a temporary backup, cache, or other data file created automatically by a software program. It is sometimes created as an invisible file and is often deleted when the program is closed. TMP files may also be created to contain information temporarily while a new file is being generated. Hence why Skype.exe → Skype.tmp → Skype.exe.

Refer to Goal 5 for information about the other processes since they are the same.

Normal process chain seen again since all but Skype.exe are files from Microsoft Windows.

Visualization in OrientDB:

In the case of Skype.exe, the CommandLine was:

"C:\Users\User\Downloads\Skype-8.72.0.82.exe" /SPAWNWND=$11005A /NOTIFYWND=$7047C

What does SPAWNWND & NOTIFYWND mean? https://stackoverflow.com/questions/10312418/installer-built-by-inno-setup-and-spawnwnd-notifywnd-parameters-on-uac-window

Basically just parameters used for communication between the elevated and non elevated parts of the setup.

Now that we know the normal process sequence of when a user downloads and opens an attachment in IE, deviations from this normal process could indicate a red flag.

When you run a file that you downloaded on the browser, msedge.exe will create a foreground process e.g. msedge.exe (FG) → WordPad.exe (FG).

You visited a website but did not run/do anything on the website. However, msedge.exe triggered creation of background processes i.e. msedge.exe > A (BG) > B (BG). This could mean that the website contained some sort of malware that has infected the machine, causing msedge.exe to create malicious processes that run in the background.

An example when Organisation (MyCompany) is switched to detection mode.

Once you click that ProcessCreate that has Process Tampering tag, the Activities column will start to load what that ProcessCreate did. In this test-case, we see msedge.exe was caught ProcessTampering.

So relate back to that comment of crafting a SQL statement for a given ProcessGUID to fetch what the process did, we obviously don't want that for day-to-day operational scenario. All that should be automated, that exercise is for you to understand how it works under the hood.

Jym's Comments

You can navigate as root to your ODB webUI & see that function.

Notice the event type from line 83 to 88, it will always be linked to ProcessCreate

For the rest, we check if it is in ProcessWatchList.

If your Organisation is set to Profiling mode, then there will be no alerts in wekan Frontend.

Use the Browse tab or if u prefer the ODB console.sh, then Select * from Sysmon where ProcessGUID = 'fill in the processGUiD'

Note that class name is NOT case-sensitive but field name is.

How to "dig" OpenEDR backend?

I use the FollowedBy edge as an example. FollowedBy edge help us show in the Case frontend a timed-order presentation of the process.

Here we see 2 functions that has that string "FollowedBy", so what calls FindPreviousProcesses?

If you search in ODB under Functions tab, it will only yield back the same FindPreviousProcesses.

So search Github/OpenEDR:

So you can see startDetection.js which is the externalised controller for detection mode.

From https://github.com/jymcheong/OpenEDR/blob/165dfe42898749feb18a5224a0d834d0930f3478/backend/startDetection.js#L49 you will see that if an Organisation is still in profiling state, it will just bail out.

How much you learn depends on how much you dig & link the observations & insights together.