Tools Used:

  1. IDA Pro
  2. Proc Mon


  1. Lab03-04.exe SHA256: 6ac06dfa543dca43327d55a61d0aaed25f3c90cce791e0555e3e306d47107859


  • Detection Rate: 22/54
  • Analyzed on 30 Jan 2016
  • Compilation Date: 2011-10-18 18:46:44
  • View report here

Lab 3-4

Analyze the malware found in the file Lab03-04.exe using basic dynamic analysis tools. (This program is analyzed further in the Chapter 9 labs.)


1. What happens when you run this file?

Lab03-04.exe got deleted via cmd.exe del command!

Proc mon: cmd.exe del

if we use IDA Pro to trace the cmd.exe /c del string we would find this function call.

/c del
calling ShellExecuteA to delete self

2. What is causing the roadblock in dynamic analysis?

There are 7 scenarios that will cause self delete function to be called. We need to reverse the codes to see what is causing it to self delete. Some malwares detect for things like checking if the current OS is a VM, checking if debugger is attach, checking if AV is running, checking if an argument is passed in etc.

delself xref

3. Are there other ways to run this program?

There are several ways to run this program

  1. One way of doing it is running it in ollydbg. Break before delself is called and change the process flow.
  2. Patch the program to change jz opcode to jnz etc
  3. reverse the program and figure out the exact cause

However we might still need to figure out the exact cause of why the program fails to run in order for us to execute it correctly. Simple patching might not work.




Tools Used:

  1. Regshot
  2. Proc Mon
  3. Inetsim
  4. Wireshark
  5. Process Explorer


  1. Lab03-03.exe SHA256: ae8a1c7eb64c42ea2a04f97523ebf0844c27029eb040d910048b680f884b9dce


  • Detection Rate: 42/54
  • Analyzed on 31 Jan 2016
  • Compilation Date: 2011-04-08 17:54:23
  • View report here

Lab 3-3

Execute the malware found in the file Lab03-03.exe while monitoring it using basic dynamic analysis tools in a safe environment.


1. What do you notice when monitoring this malware with Process Explorer?

Lab03-03.exe spawn a new child svchost.exe. Then it exit leaving svchost with no parent.

svchost.exe with no parent

2. Can you identify any live memory modifications?

In svchost image vs memory we can see that the strings are very different from each other in which it shouldn’t be the case. In the memory we can see SetWindowsHookExA which highly suggest that the exe is probably doing keylogging. The malware is probably using a technique called process replacement to replace the then suspended svchost and once replaced with malicious code it then resume the thread.

We can also see familiar strings from Lab03-03.exe inside svchost which further reinforced that the current svchost might actually be Lab03-03.exe itself.

3. What are the malware’s host-based indicators?

Using proc mon, we set the filer to process name contains “svchost” and parent pid != 672 (services.exe). This will filter out the legitimate svchost from proc mon.


practicalmalwareanalysis.log is created in the same folder where the malware is residing. Inside the log file are all the keystrokes that the victim has entered.

4. What is the purpose of this program?

So far we can conclude that the program hide itself as a svchost in the system to avoid detection by the victim. It then log all keystrokes by the victim. Typically these types of malware would sent out the keystrokes to the server… we would need to go through the static code to see what are the other capabilities of this malware.

No registry changes of interest detected via regmon.



Tools Used:

  1. IDA Pro
  2. Regshot
  3. Proc Mon
  4. Inetsim
  5. WIreshark
  6. Process Explorer


  1. Lab03-02.dll SHA256: 5eced7367ed63354b4ed5c556e2363514293f614c2c2eb187273381b2ef5f0f9


  • Detection Rate: 40/49
  • Analyzed on 30 Jan 2016
  • Compilation Date: 2010:09:28 02:00:25+01:00
  • View report here

Lab 3-2

Analyze the malware found in the file Lab03-02.dll using basic dynamic analysis tools. Questions

1. How can you get this malware to install itself?

IDA Pro (exports)

We can see in IDA Pro that several functions are available for us to call. It even include uninstall for us to call!

A way to execute dll manually is via RunDll32.exe. The syntax is as follows

RUNDLL32.EXE <dllname>,<entrypoint> <optional arguments>

So lets try RUNDLL32.exe Lab03-02.dll,install

So what happen when the dll is installed?

Procmon RegSetValue
Regshot Registry added
new Services.msc

The malware install itself as a service. using svchost.exe. The dll is added as parameter thus executing the malicious code.

If we look at IDA Pro of the install function. You will easily see that it is trying to install a service via SCManager. It then add description etc via registry changes to hide itself in plain side. A call was made to to get the current dll path and used that path to add to the service’s registry as well.

2. How would you get this malware to run after installation?

I know of 2 manual ways to run this malware.

  1. we can use command prompt “net start IPRIP
  2. start the service via Services.msc as shown in the image above

3. How can you find the process under which this malware is running?

Finding malicious svchost via Process Explorer

By going through the svchost.exe, we will come across a process in which Lab03-02.dll is loaded. That is the malicious process. For this case the PID is 1032. This can be easily achieve by using the find handle (Ctrl-F) option in process explorer as shown below.

Find Handle

4. Which filters could you set in order to use procmon to glean information?

we can either set PID to 1032 or set command line containing netsvcs.

5. What are the malware’s host-based indicators?

  1. Service – IPRIP with a name of Intranet Network Awareness
  2. Registry – HKLM/services/CurrentControlSet/Services/IPRIP

6. Are there any useful network-based signatures for this malware?

An attempt to resolve dns can be used to detect if a machine has been infected. We can also look out for http get request for serve.html.

wireshark traffic

Other stuff


There are some strings that are encoded using base64. Let’s decode them and hopefully it will help when analyzing the program in IDA Pro.

.data:10006010 0000000D C Y29ubmVjdA== //connect
.data:100060B8 0000000D C dW5zdXBwb3J0 //unsupport
.data:100060C8 00000009 C c2xlZXA= //sleep
.data:100060D4 00000005 C Y21k //cmd
.data:100060DC 00000009 C cXVpdA== //quit

Since this question is on dynamic analysis, I shall cover static analysis in more detail the next time.




Tools Used:

  1. IDA Pro
  2. PEID
  3. Regshot
  4. Proc Mon
  5. Inetsim
  6. WIreshark
  7. Process Explorer
  8. OllyDbg


  1. Lab03-01.exe SHA256: eb84360ca4e33b8bb60df47ab5ce962501ef3420bc7aab90655fd507d2ffcedd


  • Detection Rate: 49/53
  • Analyzed on 27 Jan 2016
  • Compilation Date: 2008:01:06 15:51:31+01:00
  • View report here

Lab 3-1

Analyze the malware found in the file Lab03-01.exe using basic dynamic analysis tools.


1. What are this malware’s imports and strings?


The only import that this malware uses is ExitProcess from kernel32 Library.


We can gather more intel from the malware’s strings. Fortunately for us, these strings are not obfuscated. We need to monitor in the network traffic. We can also monitor/check the registry SOFTWARE\Classes\http\shell\open\commandV (IExplorer.exe) and Software\Microsoft\Active Setup\Installed Components\. We should also check systems for vmx32to64.exe, most likely infected machines would have this executable hidden somewhere.

The possibility of this Malware being packed is low since the Malware’s Strings seems to be legit. But just to be sure let’s run the malware on PEID.

junkcode detected

It seems like this malware is not packed. However Anti Reversing Techniques is used in this binary. Below is a screenshot taken from ollydbg. We can see that at address 0x401259 a call was made to 0x401265. This opcode caused the return address of 0x40125e to be pushed in the stack. At address 0x401265, a call was made to kernel32.LoadLibraryA. But as we know, LoadLibrary needs a LPCSTR argument passed in… If we look at the stack what is pushed in earlier is actually a pointer to a char array! The return address pushed in earlier by the CALL opcode actually pushed in “user32”. Instead of using push, this author used call to push in arguments.


  1. Regshot
  2. Wireshark
  3. Proc Monitor
  4. Process Explorer
  5. OllyDbg


Persistency via run registry key

Using Regshot we found out that the malware is trying to execute c:\windows\system32\vmx32to64.exe on startup. We should be able to see from proc mon on howvmx32to64 gets into the system32 folder.


wireshark traffic

we can see that a call was made to (DNS resolve) and a SSL connection was made. Following the TCP stream we can see some random looking 256 bytes being sent.

256 bytes


Process Explorer

Mutex “WinVMX32”
Memory Strings

Using ProcExplorer, we are able to see more strings (decrypted in memory) and the mutex handle.


RegSetValue for persistency


Writing File to windows\system32\vmx32to64.exe

Proc Mon allows us to see the Registry edit and the file creation in the target’s machine.


By breaking at LoadLibraryA we know that the malware actually loads these library

  1. 0012EFC4 0040123C /CALL to LoadLibraryA from Lab03-01.00401236
    0012EFC8 0040122D \FileName = “advapi32”
  2. 0012EFC4 00401253 /CALL to LoadLibraryA from Lab03-01.0040124D
    0012EFC8 00401247 \FileName = “ntdll”
  3. 0012EFC4 0040126B /CALL to LoadLibraryA from Lab03-01.00401265
    0012EFC8 0040125E \FileName = “user32”
  4. 0012EFC4 00401505 /CALL to LoadLibraryA from Lab03-01.004014FF
    0012EFC8 004014F7 \FileName = “advpack”

2. What are the malware’s host-based indicators?


check if vmx32to64.exe exists in c:\windows\system32.


Check if WINVMX32 mutex is opened. If it does your machine is most likely infected.

Mutex: WinVMX32

3. Are there any useful network-based signatures for this malware? If so, what are they?


256 random looking bytes sent via port 443.

Other Stuff to note

get kernel base
peb + 30h & 0ch offset
1ch offset to InInitializationOrderModuleList

So how did the malware retrieves its own kernel32 base address? It uses the fs:30h to locate its PEB then offset of 0Ch to get its Ldr and finally offset of 1ch to get to the InInitializationOrderModuleList. The kernel32 is located in the 2nd entry of the linked list away thus explaining why the malware uses an offset of 8 @ line 0x401207. However newer operating system does not have its kernel32 set in the 2nd entry thus the malware would crash in other newer OS. Looking at the time of compilation (2008), this malware is probably written for winxp.



Tools Used:

  1. Cerbero Profiler 2.5
  2. IDA Pro
  3. PEID


  1. Lab01-04.exe SHA256: 0fa1498340fca6c562cfa389ad3e93395f44c72fd128d7ba08579a69aaf3b126
  2. resource.exe SHA256:819b2db1876d85846811799664d512b2f1af13e329f5debe60926c3b03424745

Lab 1-4
Analyze the file Lab01-04.exe.
1. Upload the Lab01-04.exe file to Does it match
any existing antivirus definitions?

As of 25th Jan 2016 there were 44/54 anti virus detection ratio for Lab01-04.exe.

View Lab01-04.exe Report here

2. Are there any indications that this file is packed or obfuscated? If so,
what are these indicators? If the file is packed, unpack it if possible.

3. When was this program compiled?

PEID did not suggest that the file is packed. IDA Pro’s imports table looks legitimate as well.

PEID (no packer detected)

However opening the file is Cerbero Profiler highlights that the file contains a binary resource which has a MZ header (executable). Let’s extract the resource and re-analyze it with virus total and PEID.

payload found in resources

As of 25th Jan 2016 there were 45/53 anti virus detection ratio for resource.exe.

View resource.exe Report here

PEID (no packer detected)

PEID did not suggest that the extracted binary is packed. IDA Pro’s imports table looks legitimate as well.

To answer when is the binary compiled we can use Cerbero Profiler again to check.

Lab01-04.exe – Aug 31 2019
resource.exe – Feb 27 2011 08:16:59 (GMT+8)

From the above we can see that Lab01-04.exe compile date/time is fake. But the resource binary’s datetime stamp might be the real deal.

Lab-1-04.exe: Aug 31 2019 06:26:59(GMT+8)

resource.exe: Feb 27 2011 08:16:59 (GMT+8)

4. Do any imports hint at this program’s functionality? If so, which imports
are they and what do they tell you?


Lab-1-04.exe’s imports

There are several interesting imports here.

  1. OpenProcessToken
  2. LookupPriviligeValueA
  3. AdjustTokenPriviliges
  4. WinExec
  5. WriteFileA
  6. CreateFileA
  7. CreateRemoteThread
  8. FindResourceA
  9. MoveFileA
  10. LoadResource

The ADVAPI32 Library allows us to gain higher privileges so as to facilitate in some of the functions call later. Kernel32 Library in this case allows us to loadlibrary, execute application, write file to disk and access resources.

disable windows file protection

The above screenshot shows that the malware is attempting to increase its privileges to SeDebugPrivilige. Once adjusted, it begin calling sfc_os.dll’s 2nd ordinal function which is the CloseFileMapEnumeration function.

sfc_os.dll’s export

We can find out more details in what this function can do here… in a nut shell, it is trying to disable the write protection that winlogon is providing. Once the protection is disabled, the malware then move the file “windows directory\system32\wupdmgr.exe” to “temp\winup.exe”. It then read its own resource @ #101 and write it out as a file at “windows directory\system32\wupdmgr.exe”. The malware then executes this freshly written binary using WinExec.

Disabling Windows File Protection: 


resource.exe’s imports

There are only 4 imports of interest here.

  1. URLDownloadToFileA; downloads a file from a given url to the victim’s machine
  2. GetWindowsDirectoryA; get the windows directory of the victim’s machine
  3. GetTempPathA; get the path of the directory designated for temporary files
  4. WinExec; run command/application

From the above import functions, we can make an educated guess that the malware is attempting to download another binary from a URL into either the victim’s temp directory or windows directory and execute it.

disassembled resource.exe

the disassembled code simply executes an exe located in “temppath\winup.exe” where temppath refers to the temporary folder specified in the environment variables. It then attempts to download another exe from and save it in “windows directory\system32\wupdmgrd.exe”. It then executes this exe via winExec.

5. What host- or network-based indicators could be used to identify this
malware on infected machines?


Host based indicator: temppath\winup.exe & windows directory\system32\wupdmgrd.exe


Network based indicator:

Host based indicator: temppath\winup.exe & windows directory\system32\wupdmgrd.exe

6. This file has one resource in the resource section. Use Resource Hacker
to examine that resource, and then use it to extract the resource. What
can you learn from the resource?

Solutions to question 4 and 5 would have answered this question. A lot of malwares uses these techniques to drop malicious executables on the victim’s machine. there are various form of payload hidden in the dropper. Some are in the form of images (hidden via stengo) while some are just purely address offsets. Encryption/Encoding such as Rc4/XOR/Base64 is commonly used in droppers as well. What is interesting in this exercise is probably the technique to disable windows file protection using user code.



Tools Used:

  1. IDA Pro
  2. PEID
  3. Cerbero Profiler 2.5
  4. OllyDbg
  5. ImpRec


  1. Lab01-03.exe  SHA256:7983a582939924c70e3da2da80fd3352ebc90de7b8c4c427d484ff4f050f0aec

Lab 1-3
Analyze the file Lab01-03.exe.
1. Upload the Lab01-03.exe file to Does it match
any existing antivirus definitions?

As of 22nd Jan 2016 there were 43/54 anti virus detection ratio for Lab01-03.exe.

View Lab01-03.exe Report here

2. Are there any indications that this file is packed or obfuscated? If so,
what are these indicators? If the file is packed, unpack it if possible.

Virus total and PEID both detect that this binary is packed using FSG.

In IDA Pro we can observe that there is only 2 functions in the import table which is too few for a proper executable.

Import Table

The strings doesn’t tell/show much either. Most likely this binary is packed.


Cerbero Profiler shows that the section headers has no name, a virtual size header of 3000 and a raw size of 0. This is a signature of FSG packer.


Lets try to unpack this packed executable. I cant see a tail jump (via IDA Pro’s graph view) in this case. So I decided to break on GetProcAddress in OllyDbg. Reason for doing so is that I want to find the real OEP and dump the debugged process from there. A packed executable involves 3 steps to unpack.

  1. Decrypt the real executable contents
  2. Repair the Import tables
  3. Jmp to the real OEP in the decrypted contents

So by breaking @ the GetProcAddress I would be jumping straight to step 2. Stepping through a little bit more I should reach the real OEP. Before going further, note that there is an easier solution out there that involves the use of plugins in OllyDbg to find the real OEP… but i prefer to manually find it so as to have a better understanding how assembly code flows.

breakpoint @GetProcAddress

Click on the run button and you will eventually break at the above breakpoint. Stepover till you hit RETN 8. You will be returned back to the user code.

Break @ GetProcAddress
GetProcAddress return to user code

I would now remove the previous breakpoint @ GetProcAddress and place my breakpoint at 0x004050E9. This would give me a better picture of the user code process flow. You may find the above address statically via IDA Pro also. Now click on run. The program should stop at the point before calling into GetProcAddress. Now observe the stack.


We can see that the program is trying to rebuild the address for CoCreateInstance. Step through and analyse how the program repairs the Import table. Note that after the repair is done the packer most likely will jump to the real OEP.


After stepping over several iterations, you will realize that the opcode as highlighted above has yet to take the jump. The address is also quite different from the above jump opcodes. The above jumps are all pointing to 0x405??? but this is pointing to 0x401090. While highlighting the above opcode, press enter to jump to the immediate constant address.

OEP found

This looks like a typical function call’s prologue. Most likely this is the original OEP. How did we miss this function back in IDA Pro? Most likely these codes are generated dynamically (decryption etc). Let’s investigate shall we? Right click on address 0x401090 and set a hardware breakpoint (R/W) there. Then restart the debug.

breakpoint @0x401090

If we look at the opcode at 0x405022, a mov instruction is executed to move a byte from ESI to EDI. EDI is currently pointing at 0x401091. If we look at the memory address at 0x401090, we would see that 0x55 is written on it. The rest of the address space after it is still empty. This is the part where the packer is unpacking the real code for us in memory. Continue stepping through and you will see the entire code unpack before your eyes. To dump out the unpack process into a physical file, i set a software breakpoint at address 0x401090 (after the decryption) and let my program runs till it hit this address. Now dump the debugged process via the OllyDumpEx Plugin (You would need to install this plugin).


Change the PE’s Entry point to 1090 (we found the OEP at 0x401090; minus off the image base of 0x400000). Click on dump and we are nearly there… If you try to execute the dumped exe… the program will crash. This is because the IAT has yet to be fixed. The current imports is the old imports (LoadLibraryA and GetProcAddress) and we have just lose our code on rebuilding the IAT (packers code) since we set the OEP to the decrypted function.

To repair the imports table, launch ImpRec tool.

  1. Select the currently debugged process (top drop down list)
  2. Change OEP (bottom left) to 1090
  3. Click on IAT AutoSearch and finally click on Get Imports
  4. You should see the imported functions populate.

Now we have one issue… there is a imported FThunk with a validity status set to NO. Expand the tree and we see thate @rva 204C ImpRec thinks that CoCreateInstance belongs to combase.dll. This is wrong… it should be ole32.dll

Resolving imports

There we are good to go. Click on Fix Dump to save a copy of the unpacked executable.

Good to go

3. Do any imports hint at this program’s functionality? If so, which imports
are they and what do they tell you?

The packed executable contains LoadLibraryA and GetProcAddress function. This is a good tell tale sign than the executable is packed and it is using the functions to rebuild the IAT.

The unpacked executable contains the following imports


The only interesting function here is CoCreateInstance. According to MSDN, CoCreateInstance creates a single uninitialized object of the class associated with a specified CLSID. The following is the syntax for CoCreateInstance.

HRESULT CoCreateInstance( _In_  REFCLSID  rclsid,
_In_  LPUNKNOWN pUnkOuter,
_In_  DWORD     dwClsContext,
_In_  REFIID    riid,
_Out_ LPVOID    *ppv );


rclsid: 00022DF01-0000-0000-C000-000000000046

In ollydbg breaking before the call to CoCreateInstance we can see that the rclsid is targeted to “00022DF01-0000-0000-C000-000000000046”. In Registry this value refers to Internet Explorer.


Internet Explorer

Stepping further down in ollydbg we can see a function call being made with an offset of 2C. Note that EDX is a pointer to ppv from CoCreateInstance.


Question is what is this offset? If we step over this function call, Internet Explorer will pop up with the malicious site loaded. Let’s look at the executable modules in ollydbg.

ieproxy loaded at address 0x56EF0000

We now know that the program is attempting to call a function in ieproxy.dll at address 0x56F2d340. If we deduct the image base of the dll the offset is 0x56F2d340 – 0x56EF0000 = 0x3D340. Loading c:\windows\System32\ieproxy.dll in IDA Pro and finding the instructions at offset 0x3D340… we can conclude that the Navigate function is being called which explains why internet explorer pops up after this call.

Navigate Function Call in ieproxy.dll

But where is ppv pointer pointing to? we know that we derive to Navigate function via [EDX+2C] in olly dbg. So EDX contains the pointer to ppv.


*ppv = 0x56F27188

doing our math again by deducting the image base of ieproxy.dll we derived the offset of 0x56F27188 – 0x56EF0000 = 0x37188.

In IDA Pro we can see that this address is a table pointing to different functions.

vftable of CWebBrowserHandler_Interface

0x37188 + 0x2c = 0x371b4 == Navigate function call. With these we now know what offset equates to which function call! =)
Some interesting functions are:

Offset function
1C GoBack
20 GoForward
24 GoHome
28 GoSearch
2C Navigate
30 Refresh
34 Refresh2
38 Stop
CC put_fullscreen
D0 Navigate2
D8 ExecWB

So by calling navigate function, the malware will popup internet explorer and navigates to the url:

To inexperience malware analyst, this function call can be easily ignored since it doesn’t look malicious in the first place and it depends on the CLSID used… so do watch out for it the next time =).

4. What host- or network-based indicators could be used to identify this
malware on infected machines?

The only network based indicator I could find is the url You may filter/sniff network traffic to detect if any terminals are infected with this malware.



Tools Used

  1. UPX
  2. IDA Pro
  3. PEID


  1. Lab01-02.exe  SHA256:c876a332d7dd8da331cb8eee7ab7bf32752834d4b2b54eaa362674a2a48f64a6

Lab 1-2
Analyze the file Lab01-02.exe.
28 Chapter 1
1. Upload the Lab01-02.exe file to Does it match
any existing antivirus definitions?

As of 22nd Jan 2016 there were 33/54 anti virus detection ratio for Lab01-02.exe.

View Lab01-02.exe Report here

2. Are there any indications that this file is packed or obfuscated? If so,
what are these indicators? If the file is packed, unpack it if possible.

UPX Packer Detected
Nothing found on peid but EP Section says: UPX1

The above has already suggested to us that the executable is most likely packed with UPX. Lets take a look at how IDA Pro sees this binary.

Tail Jump in Graph
Small import table
Only 4 strings?

Ok we are pretty sure that the exe is packed using UPX. So far I have known of only 2 techniques in unpacking UPX… the easiest one is to unpack using UPX command line itself. The other one is to do it the hard core manual way using olly dbg. We shall run through the easier one here. For the manual approach it will be in my next post.


To decompile a upx packed binary is very simple. Just download the upx tool and run the following command upx.exe -d [packed binary file]

Done =)

Let’s upload the unpacked binary to virus total again.

As of 22th Jan 2016 there were 32/54 anti virus detection ratio for Lab01-02_unpacked.exe.

View Lab01-02_unpacked.exe Report here

3. Do any imports hint at this program’s functionality? If so, which imports
are they and what do they tell you?



  1. InternetOpenA; Initializes an application’s use of the WinINet functions we can see what user agent is used to initiate the connection.
  2. InternetOpenUrlA; Opens a FTP or HTTP URL
  3. CreateMutexA; create mutex lock to prevent multiple running instances of the malware
  4. OpenMutexA;open a created mutex
  5. CreateServiceA; create a service object to the victim’s machine. Often use for persistency
  6. OpenSCManagerA; called before CreateService is invoked to establish a connection to the service control manager
  7. StartServiceCtrlDispatcherA; When the service control manager starts a service process, it waits for the process to call the StartServiceCtrlDispatcher function. The main thread of a service process should make this call as soon as possible after it starts up (within 30 seconds)

I guess that this malware is trying to install a service for persistency. It probably uses http traffic to get commands from the C2 server.

4. What host- or network-based indicators could be used to identify this
malware on infected machines?

In Lab01-02.exe (unpacked) we can observe the following artifacts in the executable.

We can look out for the service name (Malservice) in the system (services.msc), network traffic with dns lookup for (, network traffic with user agent as Internet Explorer 8.0 and a mutex (HGL345) on the victim machine.

Unpacked Executable’s Strings
Service Name: Malservice

The above shows that the malware is trying to add itself as a service in the victim’s machine for persistency.

unique mutex

The above shows that the malware is using a hardcoded unique string as a mutex (HGL345) we can use this to see if a machine is infected with this malware.


Communicating with a server

The above shows that the malware is using a hard coded useragent and url. We can create rules in the firewall to catch/block such traffic.